isModifier and mustSupport in FHIR

There’s been a discussion on the FHIR list about ‘mustSupport’ and ‘isModifier’ that I think I now understand – but I’m going write down for when I forget later! (Most of the wording below has been directly copied from comments by Grahame or Lloyd either in the spec or in comments on the list)

First, what  do they mean.

isModifier

From the spec:

If true, the value of this element affects the interpretation of the element or resource that contains it, and the value of the element cannot be ignored. Typically, this is used for status, negation and qualification codes. The effect of this is that the element cannot be ignored by systems: they SHALL either recognize the element and process it, and/or a pre-determination has been made that it is not relevant to their particular system.

Only the definition of an element can set IsModifier true – either the specification itself or where an extension is originally defined. Once set to false, it cannot be set to true in derived profiles. An element/extension that has isModifier=true SHOULD also have a minimum cardinality of 1, so that there is no lack of clarity about what to do if it is missing. If it can be missing, the definition SHALL make the meaning of a missing element clear.

 Then Lloyd commented:

We mark something as a modifierExtension not because a human might care about it, but rather because it might impact what a computer is doing with existing data.  If you’ve got a decisions support system that’s driving off of data elements and your extension changes the interpretation of any of those, then you need to flag to the decision support engine “don’t try to process this data unless you understand the extension”.  So long as the meaning of existing data is unchanged, it doesn’t matter how clinically relevant/important the data is, it’s not a modifierExtension.  (Data perceived to be clinically important/relevant by the originator should however be highlighted prominently in the narrative.)

 And Grahame added:

What makes something is a modifier is not that it might modify care, but that it might modify the understanding of existing data elements. This should be understood in a narrow sense, not an expansive one – it’s really about “is it safe to use the existing data without knowing the additional information”, not “would knowing the additional information influence my course of action in interpreting the data”.

mustSupport

From the spec

If true, conformant resource authors SHALL be capable of providing a value for the element and resource consumers SHALL be capable of extracting and doing something useful with the data element. If false, the element may be ignored and not supported.

“Something useful” is context dependent. This flag is never set to true by the FHIR specification itself – it is only set to true in profiles, and when the profile sets it true, it SHALL describe what it means for applications to support the element. In general, the question is what would a reasonable observer expect of a system that explicitly claims to “support” this element?.

And Lloyd added:

The purpose of “mustSupport” is for use in situations such as national program created profiles where they want to leave an element as “optional” (data won’t always exist and thus no need to include the element in all instances), but want to state that implementers playing in a particular space (and thus declaring conformance to the profile) must *support* that element (e.g. be able to capture, display, process, store, etc.)  The specific meaning of mustSupport would need to be declared by the Profile.  As an example, the panCanadian v3 profile for Patient identifies “date of death” as being “required” in our v3 message specification.  That means minOccurs=0, conformance=required.  Systems don’t have to send it, but they must be capable of sending, capturing and storing it.  With FHIR, we’d accomplish the same thing by setting minOccurs=0 and mustSupport=true in our profile.

and

mustSupport is meaningless at run time.  mustSupport only matters at conformance time.  Someone publishes a profile that says “If you want to comply with my profile (and thus get paid ‘meaningful use’ $$ or be eligible to respond to this RFP or be allowed to be installed in my hospital, etc.), you must support this element.  You declare that you support the profile in a contract or an RFP response or whatever.  It’s entirely possible that the profile will never be referenced in an instance at all.  (And if it were, it shouldn’t cause any change of behavior.)

 My Comments

Both mustSupport and isModifier flags are recorded in the profile resource.

isModifier can apply both to core elements (i.e. elements of resources that in the spec) and also to extensions. In some cases the base specification has marked elements as isModifier – eg MedicationPrescription.status. If you do define an extension in a profile, and mark it as ‘isModifier=true’, then when an actual resource instance contains this extension, it must use the modiferExtension element, rather than the usual extension element. This makes it really explicit to a consumer that this extension can modify the meaning of the resource.

Remember that all the core FHIR resources also have a profile attached to them. You can retrieve these from either Grahames or Ewouts server by a query against the profile resource – eg http://fhir.healthintersections.com.au/open/Profile?name=Person or http://spark.furore.com/fhir/Profile?name=Person

Updated: Grahame commented that all profiles are provided directly from the spec

mustSupport can apply to both elements and extensions, but are only set in a profile – i.e. the base specification has no elements marked as mustSupport. A resource instance will use an ordinary extension element (unless it it isModifer too of course).

Hope that all makes sense!