FHIR Chat · Extension element cardinality

Stream: conformance

Topic: Extension element cardinality

Ward Weistra (Feb 08 2021 at 13:07):

When I make one specific extension mandatory (1..*), the cardinality of the extension element remains the default 0..*. For example: See Subscription.criteria.extension:trigger-description and Subscription.criteria.extension in StructureDefinition-argo-sub-notif.

Intuitively one would say that this means: IF you are adding any extension, you should at least have one trigger-description in there. While the current behavior of validators (.NET and Java) just seems to ignore the cardinality of the .extension element and throw an error when you do not provide one.

The IG publisher seems to not render the .extension cardinality, the .NET Simplifier.net renderer doesn't render it if it hasn't been changed (which Forge doesn't let the user do) in that profile.

Should we make clear in the spec that the cardinality of .extension is ignored? We couldn't find it mentioned.
Should we going forward remove it from snapshot generation?

Chris Moesel (Feb 08 2021 at 13:37):

Hmmm... SUSHI automatically aggregates extension cardinalities to the base extension element. So if you say extension:race is 1:1, SUSHI automatically bumps extension to 1..*. It does the same for slices; if you say component:systolic is 1..1 and component:diastolic is 1..1, SUSHI automatically bumps component to 2..*. Is this incorrect?

I thought that if you wanted to say that a specific extension is required only if any extension is present, you would have to use an invariant; e.g., extension.exists() implies extension("http://hl7.org/fhir/us/core/StructureDefinition/us-core-race").exists().

Ward Weistra (Feb 08 2021 at 13:41):

The more general question is indeed on any slicing. Currently, even if Patient.identifier is 0..* and you have a slice Patient.identifier:bsn with cardinality 1..1 the .NET validator will still return an error if you do not provide the bsn slice. Forge will allow you to edit the cardinality of Patient.identifier to match your intentions, but as we see it might not serve any other purpose than visual.

Ward Weistra (Feb 08 2021 at 13:44):

The question indeed came up whether Forge should calculate those combined cardinalities for you and whether it would matter. Or whether we should just not render them in our rendering, since they seem to be ignored.

Ward Weistra (Feb 08 2021 at 13:46):

@Chris Moesel Indeed, that's also what @Alexander Zautke suggested, the 'IF any, then at least one of X'-case should be done with an invariant. Which would at least allow us to assume we don't need to support that with cardinalities and should be able to calculate a combined cardinality.

Chris Moesel (Feb 08 2021 at 13:53):

OK, I think I misunderstood your original message, @Ward Weistra, but I get it now. It sounds like at least a few of us are on the same page here, but we need it spelled out in a more official capacity as well as some guidance re: whether we need to put aggregate cardinalities in the differential (and/or snapshot) or if that aggregation is implicit and does not need to be explicitly recorded in the differential/snapshot. Is that right?

Ward Weistra (Feb 08 2021 at 13:57):

That's it @Chris Moesel. Calculate just for display but ignored, calculate and use or just leave out.
I'd like to hear the behavior and intentions of the Java stack in validating, snapshot generating and rendering of these situations so we can align.

Grahame Grieve (Feb 08 2021 at 22:33):

well, I thought that I had a test to check this- the minimum cardinality of an element is the sum of the minimum cardinalities of it's slices. And if a slice is mandatory, an overall minimum cardinality of the element = 0 doesn't override the fact that the slice is mandatory; it's just an error.

Grahame Grieve (Feb 08 2021 at 22:34):

that's why I don't render the cardinality of the root for extensions - it's not expected to say anything interesting. But the maximum can; I'll review how this works

Chris Moesel (Feb 09 2021 at 13:38):

Thanks for the confirmation, @Grahame Grieve -- I for one am glad that we implemented it correctly! Less work for me! ;-)

Ward Weistra (Feb 09 2021 at 17:23):

Thanks @Grahame Grieve. Based on that we plan to:

Start calculating the min cardinality for extensions array in Forge, like @Chris Moesel is doing. (Even though tooling currently generally seems to ignore it, it's the right thing going forward)
Continue to render the slice entry cardinality, because of consistency and that it can provide extra information.
Likely continue the current behavior in validation (consider a slice mandatory with a min cardinality of 1, even if entry slice has min cardinality of 0) for backwards compatibility. Unless current tests and stack alignment say differently.

Btw, the Argonaut examples I referred to above are from 2018 apparently, so it might well not be representative of the current validation/snapshot generation behavior and sure is not for rendering.