Stream: implementers
Topic: Mandatory Extensions
Richard Kavanagh (Dec 15 2017 at 11:44):
We are currently building a profile for the CapabilityStatement resource and need some extensions. We've looked at the standard HL7 extensions as we do not want to create our own if they already exist. The extension-capabilitystatement-expectation at face value looked perfect and we set out to use it.
We have however met a problem. The extension has been built with a root cardinality of 1:1 which (according to Forge) means that when you use this extension it becomes mandatory - you can't use this extension and have it as optional.
For our purposes we need it to be optional, which means that we will have no choice but to create a copy of the extension with the root as 0:1 - is this is what is expected with the HL7 extensions? It seems strange to have these mandatory HL7 extensions which are not flexible enough to support a wider variety of use cases.
Have I missed something here?
Lloyd McKenzie (Dec 15 2017 at 16:31):
I think the expectation was that if you introduced it in a profile, it wouldn't be useful to have some elements that didn't bother to declare SHOULD/SHALL/MAY when others did not. What's your use-case for doing that?
David Hay (Dec 15 2017 at 19:08):
I must admit, I always thought that it was the use of an extension in a profile that would be made mandatory, rather than the definition of it...
Lloyd McKenzie (Dec 15 2017 at 19:29):
The definition of the extension sets the maximum (can this extension repeat or not?) as well as the minimum (if used in a profile, must it be mandatory?)
Lloyd McKenzie (Dec 15 2017 at 19:30):
It's very rare for the minimum to be set to 1. Doing so is a declaration that "we don't think it makes any sense to support this extension at all unless you're going to require that it be present". This was one of the few situations where we thought that actually made sense.
Lloyd McKenzie (Dec 15 2017 at 19:32):
If you're going to assert SHALL/SHOULD/MAY on some elements, leaving the others as totally undefined (because there's no default) didn't make a lot of sense to me when I designed the extension. That doesn't mean that an error wasn't made though. We could certainly loosen it in a future release if there's a use-case for making it optional.
Grahame Grieve (Dec 15 2017 at 20:16):
I think it makes sense to say 'expect to see this extension in your capability statements' but not want to say 'since we said you should expect to see it, everyone must always populate it'
Lloyd McKenzie (Dec 15 2017 at 21:56):
I guess I don't unerstand a situation where the notion of the extension would apply, but you wouldn't expect it to always be populate.
Grahame Grieve (Dec 15 2017 at 23:11):
what, like an optional element?
Lloyd McKenzie (Dec 16 2017 at 15:56):
I'm speaking of this extension specificly - the SHALL/SHOULD/MAY one
Lloyd McKenzie (Dec 16 2017 at 15:56):
I don't understand the use-case for including it but making it optional
John Moehrke (Dec 16 2017 at 16:46):
I might be not understanding, as I have on my TODO to use this extension in IHE but have not yet started to use it. But it seems to me it is not uncommon for a profile to constrain a few elements that are critical to the use-case while having no compelling motivation to set all the other elements. This enables two profiles to be used together that have constants on non-overlapping sets of elements.
John Moehrke (Dec 16 2017 at 16:47):
So is this why the US-CORE has this extension absolutely everywhere? I was wondering why they seem to be so opinionated about everything.
Lloyd McKenzie (Dec 16 2017 at 19:02):
So what does it mean if you say 2 elements are SHALL, 3 elements are SHOULD, 1 element is MAY and 4 elements have nothing listed?
John Moehrke (Dec 16 2017 at 19:59):
it means for the usecase that the StructureDefinitno is solving that those last 4 are not used. I guess they could be marked MAY, but why.
Lloyd McKenzie (Dec 17 2017 at 00:42):
Because the default isn't "MAY"
Lloyd McKenzie (Dec 17 2017 at 00:43):
If you don't specify the extension, the interpretation is "it's unknown whether there's an expection that systems need to support this element or not" - which isn't a terribly useful thing to say.
Richard Kavanagh (Dec 17 2017 at 11:12):
For us, we want all of our CapabilityStatements to abide by one profile. Some of our solutions use that extension, some don't. As it stands we now have to either force some of the solutions to use an extension they don't need, create two profiles or create our own version of the extension that is less opinionated. We will probably go for the last option.
David Hay (Dec 17 2017 at 16:58):
@Lloyd McKenzie - given that there's also a min/max on the Profile ElementDefinition that refers to the extension SD - what happens if they are different? It seems odd that that the min/max of the elements in the Profile SD determine the multiplicity of all elements except extensions...
Michel Rutten (Dec 17 2017 at 17:11):
Generally, profiles are only allowed to constrain. This also holds for cardinality. So if a datatype (incl. extension) specifies a minimum cardinality, then referencing profiles will automatically inherit that constraint. This is a fundamental design choice and I'm very reluctant to change these rules.
However for this specific extension, the responsible WG could reconsider the existing minimum cardinality constraint.
Lloyd McKenzie (Dec 18 2017 at 03:38):
So the intention of the master profile is to "Create awareness" of the extension (and perhaps require support for rendering/understanding it), rather than profiling a system that declares the profiles. That makes sense as a use-case. Please submit a change request to loosen the cardinality. For STU3, you may have to define your own extension
Lloyd McKenzie (Dec 18 2017 at 03:41):
@David Hay The min/max of the root element of every resource, data type and profile-there-on set the boundaries of what the cardinalities can be when they are referenced. All data types and resources are thus defined with min of 0 and max of * because those artifacts are contextless and their cardinality needs to be unconstrained. However, profiles on data types (and on resources) can place different cardinality limits. We do this all the time with maxOccurs, indicating that certain extensions are not permitted to repeat. It's done less often with minimum cardinality on extensions. But it's in no way limited to extensions. You could just as easily define a profile on PersonName called "preferred name" and place a constraint that there can only be one of them (though that wouldn't necessarily be wise as it doesn't take into account the possibility of "old" preferred names).
David Hay (Dec 18 2017 at 16:57):
@Lloyd McKenzie Sorry - I think I'm being obscure. Suppose I create a profile on, say, Patient . Then in the ElementDefinition for the path Patient.name I can set the .max element to 1 - meaning that there can only be one name in the profile. Now I want to add an extension to Patient (say religion). I create an ED with the path Patient.extension to set the discriminator, then another ED with the path Patient.extension, and set type.code to 'Extension' and type.profile to the url of the SD that defines the religion extension.
Now, this ED (that defines the Patient.extension element) has min/mix properties, and I've been using those to indicate the multiplicity of the extension in my profile (exactly as for Patient.name). So I could set .max to * to allow a patient to have multiple religions. But this thread suggests that I should instead use the min/max element from the extension definition - not the one in the patient profile, which is ignored.
Does that make sense?
Lloyd McKenzie (Dec 18 2017 at 17:05):
The cardinality in your profile isn't ignored - it just has to be a proper constraint on the cardinality of the base type. If the extension is defined with a cardinality of 1..1 and you reference it in a profile and give it a cardinality of 0.., your profile is invalid. On the other hand, if the extension is defined with a cardinality of 0.. and you reference it in your profile with a cardinality of 1..1, the validator will enforce the 1..1
David Hay (Dec 18 2017 at 17:29):
Ah - in this case the 'base type' is the Extension Definition (the SD) that I'm referencing from the profile? And it's up to the profile author to ensure that the cardinality to that extension in the profile is a proper constraint on what the extension definition itself has. That makes sense. My confusion arose because the base type of the profile (in this case Patient) has a Patient.extension element with a cardinality of 0..* ...
Lloyd McKenzie (Dec 18 2017 at 18:10):
Right. And 0..* is aligned with the cardinality of the base type it's pointing to - which is the Extension data type which also has 0..* cardinality
Lloyd McKenzie (Dec 18 2017 at 18:10):
But if you constrain to a more refined type (an extension profile), then the cardinality of the referencing element is constrained by the cardinality of the root element of that profile.
Simon Knee (Jan 02 2018 at 13:31):
Bit late to the party but have added FHIR Change Request [#14378]. For STU3 purposes NHSD we will create a copy of the extension and relax the root cardinality.
Lloyd McKenzie (Jan 02 2018 at 15:10):
And submit a change request for the cardinality of the official extension to be loosened in a future release?
Lloyd McKenzie (Jan 02 2018 at 15:11):
Sorry. Not fully awake. Thanks for the CR :)
Simon Knee (Jan 02 2018 at 15:34):
No problem. Hope it was completed correctly. HNY to you
Lloyd McKenzie (Jan 02 2018 at 15:38):
Looks good. And HNY to you too :)
Last updated: Apr 12 2022 at 19:14 UTC
