Using Must-Support
Jan 29, 2019FHIR defines a Must-Support attribute as a piece of metadata on every element. About this, the specification says:
Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide “support” for the element in some meaningful way. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as
mustSupportmustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
For this reason, the specification itself never labels any elements as MustSupport.
This piece of metadata is principally defined so that applications can say, in their formal descriptions of their functionality that they support a particular element. This is different to making the cardinality 1..1, so that the element must always be present.
The goto example for this element is LMP for a female patient (commonly collected on admission and particularly before xray etc for safety reasons), but obviously not applicable for many patients due to gender or age. Note, btw, that in FHIR this would be an Observation with a LOINC code of 8665-2, and cardinality / must-support is not so simple. Never the less, it’s common to have elements that can’t be mandatory, but which systems need to support, and where it is appropriate to claim support (middle name is another good example).
It’s a little less obvious how to use must-support when writing implementation guides. Concerning this, the FHIR specification says:
When a profile [labels an element as mustSupport=true], it SHALL also make clear exactly what kind of “support” is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc
In the simple case, must-support could mean that a system must store and display the element if it’s present. But profiles could go a lot further than that, particularly in the case of profiles orientated towards decision support.
The problem for profile authors is that there’s quite a lot of things to say about using elements, and must-support is a single boolean flag. Some profiles have gone to public comment and there’s been some argument about how the fine details work. So…
The first thing to remember is that must-support is a computable flag to help rendering engines highlight an element to human readers. It doesn’t have more significance than that. For example, there’s no validation hanging off it. A human has to look at the written documentation and determine what the significance is - whether writing automated test cases (e.g. TestScript), user acceptance tests, or implementing systems. So the most important focus is to get the documentation correct.
Must-Support is primarily a visual cue. I’ve never heard any discussion about implementers not having to read the documentation of all elements (though, of course, no one reads documentation if they can avoid it anyway), so not setting it doesn’t make any genuine difference.
So overall, the best thing I can say is, “chill”. (now watch the comments show a complete lack of chill…)