Stream: shorthand
Topic: slice definitions missing mustSupport constraints
Rob Hausam (Oct 19 2020 at 00:18):
Here is a snippet of a slice declaration and first slice definition on CodeSystem.property in FSH (generated by GoFSH):
* property ..6 MS
* property ^slicing.discriminator[0].type = #value
* property ^slicing.discriminator[0].path = "code"
* property ^slicing.rules = #open
* property ^short = "Additional information supplied about each concept"
* property ^definition = "A property defines an additional slot through which additional information can be provided about a concept."
* property ^comment = "To cover through slices: Component, Property, Time, System, Scale, Method."
* property.code 1..1 MS
* property.code ^short = "Identifies the property on the concepts, and when referred to in operations"
* property.code ^definition = "A code that is used to identify the property. The code is used internally (in CodeSystem.concept.property.code) and also externally, such as in property filters."
* property.uri 0..1
* property.uri ^short = "Formal identifier for the property"
* property.uri ^definition = "Reference to the formal meaning of the property. One possible source of meaning is the [Concept Properties](codesystem-concept-properties.html) code system."
* property.uri ^mustSupport = false
* property.description 1..1 MS
* property.description ^short = "Why the property is defined, and/or what it conveys"
* property.description ^definition = "A description of the property- why it is defined, and how its value might be used."
* property.type 1..1 MS
* property.type only code
* property.type = #string (exactly)
* property.type ^short = "code | Coding | string | integer | boolean | dateTime"
* property.type ^definition = "The type of the property value. Properties of type \"code\" contain a code defined by the code system (e.g. a reference to anotherr defined concept)."
* property contains ln_component 1..1 MS
* property[ln_component] ^short = "Additional information supplied about each concept"
* property[ln_component] ^definition = "A property defines an additional slot through which additional information can be provided about a concept."
* property[ln_component] ^comment = "To cover through slices: Component, Property, Time, System, Scale, Method."
* property[ln_component].code 1..1 MS
* property[ln_component].code only code
* property[ln_component].code = #COMPONENT (exactly)
* property[ln_component].code ^short = "Identifies the property on the concepts, and when referred to in operations"
* property[ln_component].code ^definition = "A code that is used to identify the property. The code is used internally (in CodeSystem.concept.property.code) and also externally, such as in property filters."
And here is the "translation" of that into the StructureDefinition json file in the fsh-generated/resources folder:
{
"id": "CodeSystem.property",
"path": "CodeSystem.property",
"slicing": {
"discriminator": [
{
"type": "value",
"path": "code"
}
],
"rules": "open"
},
"comment": "To cover through slices: Component, Property, Time, System, Scale, Method.",
"min": 6,
"max": "6",
"mustSupport": true
},
{
"id": "CodeSystem.property.code",
"path": "CodeSystem.property.code",
"mustSupport": true
},
{
"id": "CodeSystem.property.uri",
"path": "CodeSystem.property.uri",
"mustSupport": false
},
{
"id": "CodeSystem.property.description",
"path": "CodeSystem.property.description",
"min": 1,
"mustSupport": true
},
{
"id": "CodeSystem.property.type",
"path": "CodeSystem.property.type",
"short": "code | Coding | string | integer | boolean | dateTime",
"definition": "The type of the property value. Properties of type \"code\" contain a code defined by the code system (e.g. a reference to anotherr defined concept).",
"fixedCode": "string",
"mustSupport": true
},
{
"id": "CodeSystem.property:ln_component",
"path": "CodeSystem.property",
"sliceName": "ln_component",
"min": 1,
"max": "1"
},
{
"id": "CodeSystem.property:ln_component.code",
"path": "CodeSystem.property.code",
"fixedCode": "COMPONENT"
},
The 'property:ln_component' and 'property:ln_component.code' elements in the slice definition aren't picking up the mustSupport flags from the fsh. Note that other items like the cardinality and type constraints and the 'short', 'definition' and 'comment' text also aren't being carried forward, but in this case I think that all of those are just duplicated from the base resource, so that's not really a problem (and could even be a design decision/feature?). But the missing mustSupport flags are, of course, only available in the profile and they clearly do need to be in the json.
Nick Freiter (Oct 19 2020 at 12:50):
This is actually an expected behavior from SUSHI. Since the mustSupport flag has been applied on CodeSystem.property, SUSHI does not add it to the differential for CodeSystem.property:ln_component, since the flag is indicated by CodeSystem.property. It comes down to a question of how we generate a differential on a slice element. Currently, we generate the differential by comparing to the sliced element (CodeSystem.property here) on the profile you are generating, so since mustSupport is already on that element, we do not add it to the differential of the ln_component slice. I don't think we have ever been entirely clear on if there is a single "correct" way to generate this differential according to the spec, but let us know if you think the current method is insufficient and how we could improve it.
Chris Moesel (Oct 19 2020 at 12:50):
Right. I guess it's a fair question. If you say that implementors must support CodeSystem.property, is it necessary to say they must support specific slices of CodeSystem.property? If so, what does it mean for a slice that doesn't have the MS flag when the thing being sliced does?
Nick Freiter (Oct 19 2020 at 12:58):
Maybe relevant to know that SUSHI does add flags defined on a sliced element to the slices of that element. So for example:
Profile: MyCodeSystem
Parent: CodeSystem
* property ^slicing.discriminator[0].type = #value
* property ^slicing.discriminator[0].path = "code"
* property ^slicing.rules = #open
* property contains ln_component 1..1
* property MS
That property MS rule will apply a MS flag on property and on the ln_component slice. And that is definitely an intentional choice. So SUSHI adopts the idea that a flag on a sliced element implies that same flag on the slices of that element.
Chris Moesel (Oct 19 2020 at 13:03):
These statements seem mutually exclusive to me:
Since the mustSupport flag has been applied on CodeSystem.property, SUSHI does not add it to the differential for CodeSystem.property:ln_component, since the flag is indicated by CodeSystem.property.
and
Maybe relevant to know that SUSHI does add flags defined on a sliced element to the slices of that element. So for example... That property MS rule will apply a MS flag on property and on the ln_component slice.
Are you just talking about what SUSHI does internally, but by the time it generates the differential it strips out the flag on the slices?
Chris Moesel (Oct 19 2020 at 13:05):
Or is the difference the ordering of the statements? (That if you apply MS to a sliced element after slices have been declared, then (and only then) it applies the flag to all slices? If so, we may want to consider if that type of order dependence is what we actually want...
Nick Freiter (Oct 19 2020 at 13:09):
No, not just internally, in the example I showed, SUSHI will output JSON that has a mustSupport flag on both property and ln_component. The difference is the ordering of statements as you say. It comes down to the fact that to generate a differential, SUSHI compares the slice element to the sliced element on that profile. So if you have already made constraints on the sliced element, those constraints will not be on the differential of the slice element.
Chris Moesel (Oct 19 2020 at 13:12):
OK. I'm not sure how I feel about that behavior...
Rob Hausam (Oct 19 2020 at 15:46):
Yeah. It seems to me that it would be easier (and better) to just be able to put MS in FSH on whatever you want to be mustSupport and have it show up that way in the rendering. :) I'm not sure how smart SUSHI should try to be with this to figure out what the author thought they really wanted or what they should have been thinking that they wanted?
Rob Hausam (Oct 20 2020 at 03:40):
Are we thinking of going anywhere with this? @Nick Freiter @Chris Moesel
Rob Hausam (Oct 20 2020 at 03:48):
Since the actual definition of "must support" is left up to the individual IGs to determine and describe, then I think the use and placement of the mustSupport flags in the final profile renderings needs to be under the full control of the IG and profile authors. They need to be able to specify and show the mustSupport flag on any element that they want, whether or not it occurs inside or outside of a slice. That's my take on it.
Chris Moesel (Oct 20 2020 at 12:38):
Here is a question... If I put MS on something (say, identifier) and then I slice it into different identifiers (NPI, etc), should the slices automatically get the MS too? Again, I don't know what it means for something to be MS but for its slices not to be MS. But as you said, the definition of MS is left up to authors, so maybe I'm not supposed to know what that means?
David Pyke (Oct 20 2020 at 12:40):
As I understand it, a slice is marked as MS or not. But if the base element has MS, then that element must be supported. A slice only needs to be supported if marked MS.
Nick Freiter (Oct 20 2020 at 13:54):
Is there a difference between how this should work for property vs property.code? For example, if property.code is MS, does that also imply that property:someSlice.code is MS? I think in that case the answer is yes, since the MS on property.code applies to all slices.
Chris Moesel (Oct 20 2020 at 14:52):
I would think that the behavior would not change based on if it is the sliced element itself or a nested path of the sliced element. To me, either any and all MS get inherited from the base element(s) or none do.
Nick Freiter (Oct 20 2020 at 16:56):
From my experimenting, the IG Publisher seems to make the decision that if a MS is applied to a nested path of a sliced element, then that MS applies to all slices as well. I tested out letting the IG Publisher generate a snapshot from a resource that had property.code set to MS, but made no constraints on property:ln_component.code, and the Publisher generated a snapshot that looks like:
image.png
Note that the MS is specified on All Slices.
Chris Moesel (Oct 20 2020 at 17:51):
OK, but does that only come through in the rendering of the documentation? If you look at the SD itself, do you see the MustSupport applied anywhere else or is it still only on the base property.code element?
Nick Freiter (Oct 20 2020 at 18:03):
Hm yeah, the MustSupport is just applied on the property.code element.
Chris Moesel (Oct 21 2020 at 12:35):
OK. This was discussed some over in the #conformance stream and then in a MnM meeting. It resulted in this guidance:
If an element is marked as 'Must Support' and is then sliced, that does not imply that each of the slices is 'Must Support'. If the intention is that a slice must be supported, then that slice should be marked as 'Must Support'. As an example, if Medication.identifier is marked as 'Must Support', and is then sliced to specify different types of identifiers, unless marked otherwise, the different slices are not 'Must Support'. This implies that a system must support Medication.identifier but can choose to support any of the slices, unless those slices were intentionally marked as 'Must Support'.
If an element is marked as 'Must Support' in its parent's slicing base, that does imply that the element is 'Must Support' in each of the slices. As an example, if Medication.identifier.system was marked as 'Must Support', and then Medication.identifier was sliced, the identifier.system would be 'Must Support' in each of those slices. NOTE: This means that if you do not intend an element to be 'Must Support' in every slice, that you should not mark it as 'Must Support' in the slicing base.
Chris Moesel (Oct 21 2020 at 12:36):
So, I've filed #647 on SUSHI for us to fix this.
Rob Hausam (Oct 22 2020 at 03:11):
Thanks, @Chris Moesel. I've added some further questions in the conformance topic about how the IG Publisher is expected to handle this in the profile rendering.
Chris Moesel (Nov 04 2020 at 20:26):
Hi @Rob Hausam -- I just wanted to let you know that this has been fixed in the just-announced SUSHI 1.0.0 Beta 4 release!
Rob Hausam (Nov 04 2020 at 20:32):
Thanks, Chris. That's great!
Last updated: Apr 12 2022 at 19:14 UTC
