Stream: conformance
Topic: reusable profiling
Jens Villadsen (Nov 21 2017 at 14:29):
When you read the standard (https://www.hl7.org/fhir/formats.html#table states what cardinalities are allowed, https://www.hl7.org/fhir/profiling.html#cardinality states that it is not used, https://www.hl7.org/fhir/profiling.html#5.1.0.8 talks about ruling out) ... should this perhaps be harmonized a bit? @Grahame Grieve I'm looking at you.
Jens Villadsen (Nov 21 2017 at 14:34):
so in the spirit of reusable profiling, is it better to basically spray out a lot of mustSupport on all fields that are 0..*/0..1 in ones profile instead of 0..0 on the fields that are unused as this basically makes it less reusable? @Simone Heckmann what is your take on this?
Jens Villadsen (Nov 21 2017 at 14:51):
and of course using 1..1/1..* where it makes sense
Simone Heckmann (Nov 21 2017 at 19:54):
I agree Jens! I think especially profiles that are rather on a top level like IHE or national profiles shouldn't set any cardinalities to 0..0 simply because they don't use or need the element unless they explicitly want to forbid their use.
I guess the "mustSupport" Flag is our best bet to mark the elements of relevance to a specific profile. It feels a bit like abuse, but it's the one thing that allows us to convey the information. Instances that don't use a flagged element are still valid and so are those who populate an unflagged element (which may be required in another profile the instance needs to conform to).
The only problem I see with this is that derived profiles are unable to "unflag" elements if they don't support them. But the more I think about it, the more I tend to agree with @nicola (RIO/SS) that maybe derived profiles aren't such a good idea after all...
Lloyd McKenzie (Nov 21 2017 at 22:54):
Constraining the upper cardinality at all essentially says "you must customize your interface to not send me data that I could freely ignore". So rather than constraining the upper cardinality to 1, instead define a mandatory "must support" slice, where the discriminator is sufficiently narrow to identify the repetition you care about from others that might reasonably be present. Rather than constraining the upper cardinality to 0, just don't mark the element as supported. Setting max to 0 should only be done if it's clearly an error (e.g. someone sending you a deceased date when you don't want to receive dead patients) or if you're in one of those rare circumstances where there's legal responsibility attached to allowing something past your front door that you later ignore/throw away.
Jens Villadsen (Nov 22 2017 at 07:55):
@Simone Heckmann and @Lloyd McKenzie - it sounds like we are pretty aligned on this, and yes, regarding derived/inheritance - @nicola (RIO/SS) I won't say that it should be avoided, but I would say use it with extreme caution - just as you do when doing software development. Now, if we could only get something sneaked into the profiling tools (@Michel Rutten wink, wink) that would make it a little more cumbersome to ie. change cardinality to 0..0 or making derived profiles or put info boxes in the face of others doing so (telling them a little about the consequences of their actions), we could all avoid that specifiers accidentally make their profiles too strict and narrow for reusable purposes.
Ewout Kramer (Nov 24 2017 at 11:32):
Haha, you recognize that feeling? I started typing that I totally disagreed, but while stating my arguments, realized you are actually right ;-)
Jens Villadsen (Nov 24 2017 at 11:53):
:thinking_face: ... I know it all too well ... :laughing:
Last updated: Apr 12 2022 at 19:14 UTC
