Stream: implementers
Topic: MustSupport elements in Vital Signs
Ashwin Djorai (Jan 27 2021 at 13:12):
In our project we use a derived profile. This profile is based on Vital Signs from HL7. The Vital Sign profile contains 'MustSupport' elements and according to the guidelines you must indicate what this means exactly. This is not specified in the Vital Signs profile and we wonder if is this specified somewhere?
MustSupport page: https://hl7.org/fhir/STU3/profiling.html#mustsupport
Derived profile: https://simplifier.net/NictizSTU3-Zib2017/zib-VitalSigns
Base resource: https://hl7.org/fhir/STU3/vitalsigns.html
Yunwei Wang (Jan 27 2021 at 14:22):
The summary tab of vital sign profile has some information
Eric Haas (Jan 27 2021 at 14:40):
@Ashwin Djorai you are correct, must supports are defined in implementation guides not on the base specification. I think there is a tracker to fix this for FHIR R5. The latest draft version of USCORE vital signs is derived from them and defines what it means.
René Spronk (Jan 27 2021 at 14:51):
The Nictiz project (author of the derived profile mentioned above) also has documented what they mean by MustSupport.
Lloyd McKenzie (Jan 27 2021 at 15:23):
The vital signs profiles are defined in the core spec and declare mustSupport there - therefore the meaning of mustSupport must be defined in the core spec.
Eric Haas (Jan 27 2021 at 17:36):
They are not. and "The meaning of "support" is not defined by the base FHIR specification, " So are these profiles not part of the core spec? I authored these profiles a while back a was not careful with regards to making a bunch of element must support. Surprisingly no one objected (until recently), most folks were focusing on why we used LOINC which probably distracted them from this issue. I were to author the profiles today, my leaning would be not have MS tags at all.
Lloyd McKenzie (Jan 28 2021 at 00:26):
I think having MS is reasonable. Having Observation.value is 0..1. Not flagging and saying that it must be supported - and sending narrative only or some extension instead with just a string or something isn't sufficient is reasonable (and necessary if we want base computable interoperability). The mustSupport expectation documentation should be relatively light - and allow for a variety of uses, including systems that don't care about value at all. Key thing is that if you want data that would typically appear in value and you're sending, you must express the value data you have in that element and if receiving, you must be capable of extracting the value data you need from that element.
Grahame Grieve (Feb 02 2021 at 21:56):
I think I created the task to remove MS from the core profiles, but I'm ok if they are retained with an explanation, though this will require minor wording changes elsewhere in the specification (where must-support is defined and documentated)
Niek van Galen (Feb 05 2021 at 09:22):
@Grahame Grieve can you provide a link to the tracker? I have done some searching but can't find it. We can then see if we can pre-adopt the change in our STU3 profiles.
Lloyd McKenzie (Feb 05 2021 at 15:09):
I'm not in favor of removing MS in the profiles, but I'm certainly happy for us to clarify what it means
Grahame Grieve (Feb 05 2021 at 19:32):
apparently I did not. So #J30934
Lloyd McKenzie (Feb 05 2021 at 19:48):
Mark Kramer (Apr 19 2021 at 14:32):
In considering the meaning of MS, I think it is helpful to consider that MS flag on an element does not necessarily mean the element must be implemented. Separate the "Obligation to Implement" (OTI) from the appearance of a MS flag (MS). There is not a 1-to-1 relationship and when people say "interpretation of MS" they might be talking about what must be implemented, and _assuming_ the MS flag means the same as OTI.
Let me explain by giving some examples -- some of which may be hard to understand or controversial:
- Profiles with top-level MS flags are OTI. Implementation of other profiles is elective.
- If a profile is not implemented, then none of the elements of that profile must be implemented, regardless of MS flags in that profile.
- An element with an MS flag is OTI if it is a top-level element, or a a second-level or lower element whose parents all have MS flags.
- If an implementation elects to implement the non-MS elements in the nested element’s hierarchy, and the nested element is MS, then the nested element becomes OTI.
- An element with an MS flag whose cardinality is 0..0 is not OTI (yes, this can happen)
- For Data Senders, a required element is OTI, regardless of whether that element has an MS flag. This is because Data Senders must populate required elements.
- For Data Receivers, a required element without an MS flag is not OTI. This is because Receivers have the option of ignoring an element passed to them if they have elected to not support that element.
Then there are cases of complex elements, data type choices, and reference choices, which US Core attempted to work out in more detail. This is where things get really interesting, because adding an MS flag can actually reduce what must be implemented.
- For an complex element that is MS and OTI:
- If there is no MS flag on any subelement:
- A data sender must implement at least one sub-element, and SHOULD implement every sub-element for which the server might possess data
- A data receiver should (must?) implement all sub-elements, since the Receiver cannot anticipate which sub-elements might be populated
- If there is an MS on one or more subelements:
- Data senders must implement only the sub-elements that are explicitly flagged
- Same for receivers
- If there is no MS flag on any subelement:
- For a choice [x] type:
- If there is no MS flag on any choice:
- A data sender must implement at least one datatype choice, and SHOULD implement every datatype for which the server might possess data
- A data receiver should (must?) implement all choice types, since the Receiver cannot anticipate which datatype s might be populated
- If there are MS flag(s) on certain choice types:
- Data senders must implement only the sub-elements that are explicitly flagged
- Same for receivers
- If there is no MS flag on any choice:
This is getting long, so I'll stop here. Other cases we've looked at include sliced arrays, references with multiple profiles or resource types, and more.
Lloyd McKenzie (Apr 19 2021 at 15:18):
There are 'degrees' of 'implement'. While it's true that mandatory elements must be present, there's a difference between "my system hardcodes a value" vs. "my system allows a user to capture a value and transmits it" - so min=1 with mustSupport=false and min=1 with mustSupport=true can drive considerably different amounts of implementation effort. Also, there's some degree of implementation effort for "modifier" elements, whether mandatory or mustSupport - systems are required to check for them and check that they recognize the values. So I'm not sure that the notion of OTI as a boolean would be terribly useful.
Mark Kramer (Apr 19 2021 at 15:29):
I agree there are different degrees of implement. Also that modifier elements are always "must implement" in the sense of checking for them. But the key point I'm trying to make is that Must Support flags are not the same as "you must implement" (to whatever degree that may be).
Lloyd McKenzie (Apr 19 2021 at 15:48):
It's a "you must implement if you implement the parent". I'm not aware of any situation where that's not true.
Mark Kramer (Apr 19 2021 at 16:09):
That is a good generalization (not always true, but almost). Is there a similarly powerful generalization about choice[x], sliced arrays, and references with multiple targets?
Lloyd McKenzie (Apr 20 2021 at 02:30):
If there are slices, you must implement each slice marked as mustSupport. For the other two, we've talked about adding extensions that would allow you to flag specific types and target types as mustSupport, though I'm not sure where we're at with that. In the absence of an extension or text giving more specific guidance, the expectation is "at least one". There's a similar expectation for children of mustSupport elements where none of the children are mustSupport, with the inferred expectation of 'reasonable' - i.e. a mustSupport of Patient.name wouldn't be well satisfied by a system that only supported Patient.name.use.
Eric Haas (Apr 20 2021 at 04:50):
For the other two, we've talked about adding extensions that would allow you to flag specific types and target types as mustSupport,
This is implemented and described in US Core : see for example here:
and is discussed here and here
Jose Costa Teixeira (Apr 26 2021 at 08:24):
Related question (I hope) if a national profile defines a field as MS 0..1, can a derived profile mark it as 0..0?
Oliver Egger (Apr 26 2021 at 08:43):
@Jose Costa Teixeira I don't think this would be valid, the spec says:
If creating a profile based on another profile, Must Support can be changed from false to true, but cannot be changed from true to false.
setting the cardinality to zero would violate that indirectly (the element would be removed from the snaphsot), or not?
Jose Costa Teixeira (Apr 26 2021 at 08:44):
@Oliver Egger that is my struggle.
With our MS we roughly indicate: "Receivers must support it if sent, and must send it if available and adequate (e.g. for relevancy or privacy reasons)"
and now we want to say "in this specific case we want to not send it, so we profile it out"
Jose Costa Teixeira (Apr 26 2021 at 08:46):
mechanically it seems possible. From a conformance profile I think it would be sensibe depending on the meaning of MustSupport.
I'm interested in thought.
I don't think however that changing cardinality to 0..0 also implies removing MustSupport..
Oliver Egger (Apr 26 2021 at 09:16):
for that usescase it sounds reasonable to put 0..0
John Moehrke (Apr 26 2021 at 13:07):
Given that MS is defined at an IG level, I don't see how FHIR core could have any declaration on ability for derived profiles to set 0..0. It does feel like it is similar to going from true to false, but it is not really. It is eliminating the element. One might even say it is eliminated in the MS = true state.
John Moehrke (Apr 26 2021 at 13:12):
Note I am also not sure I would agree that a derived profile should not be able to change a MS true to false. A derived profile is, in theory, a more refined use-case with tighter conformance needs. Of which in that use-case the element might still not be forbidden (your use-case), but for which the original IG definition of MS does not apply in the derived profile. I am not against that this being discouraged. Is the "cannot" word being used in the spec intended to be an informative word? Or was it intended to be "shall not"?
Jenni Syed (Apr 26 2021 at 13:17):
In general, I thought making any element 0..0 in a profile was heavily discouraged since it makes it very incompatible/hard to implement. EG: a server or client that works with several profiles must somehow know not to set it (vs just indicating the field is not required for the specific use case, which is fine if a field is optional and cardinality is 0..1). I understand that must support makes this specific situation more difficult.
John Moehrke (Apr 26 2021 at 13:29):
I agree that is a need for our profiles.. a "ShouldNotSendButWeKnowSomeneWill"
John Moehrke (Apr 26 2021 at 13:31):
I think that is more of an application of Postel's Law... be specific in what you send, liberal in consuming from others. I fear we are too often setting one profile for an interaction, and setting it to the most restrictive. When the receiver should really be informed that it might receive stuff that is not as strictly conformant.
Eric Haas (Apr 26 2021 at 14:18):
Based on this it is technically conformant but you pay a big price as Jenni points out. This is certainly not a good "loophole" to get out of supporting 0..1 MS elements.
Lloyd McKenzie (Apr 26 2021 at 17:19):
First, be very cautious about 0..0. It should only be used when it's an error if the data is present. That said, an inherited MS=true and 0..0 aren't strictly in conflict. As an example, you might say that Patient.deceasedDate is "mustSupport" in a general profile, but in a more restrictive profile declare that the element is prohibted because the use-case doesn't allow deceased patients. Part of the issue is that inheriting "mustSupport" is a very tricky business.
John Moehrke (Apr 26 2021 at 19:03):
right, so what alternative is there for that use-case? The only one I can think of is to not derive from the profile that set the MS flag. Which seems like a bad solution too.
John Moehrke (Apr 26 2021 at 19:03):
this would drive people to copy a predicate profile, rather than inherit it... because the predicate profile had one constraint that they disagreed with.
Lloyd McKenzie (Apr 26 2021 at 20:50):
I'm saying you can constrain to 0..0 in the case described, just that it's going to feel a bit confusing.
Last updated: Apr 12 2022 at 19:14 UTC
