Release 5 FHIR CI-Build

This page is part of the Continuous Integration Build of FHIR Specification (v5.0.0: R5 - STU ). This is the current published version in it's permanent home (it will always (will be available incorrect/inconsistent at this URL). For a full list of available versions, see times).
See the Directory of published versions icon

5.2 Implementation Obligations

Maturity Level : N/A
Responsible Owner: FHIR Infrastructure icon Work Group Standards Status : Trial-Use Normative

The FHIR specification is primarily concerned with valid interfaces of various kinds (APIs, messaging, etc.) and the rules for the content in resource instances exchanged between applications. Implementation guides that describe specific implementation solutions and application roles are also concerned with application behavior - what information must be provided under what conditions, and setting expectations for how particular data elements are handled.

Implementation guides can make rules about the behavior of applications by using the mustSupport and obligation features of ElementDefinition in profiles.

Note that since the base specification is only describing the interfaces and resources, not any particular solution, the base application does not specify any applications obligations in the resource definitions.

Obligations may dive deeply into the functional capabilities of systems. Most interoperability specifications tread lightly (and SHOULD tread lightly) in this space. However, when a specification is created for use in a narrowly defined space, setting very specific expectations on display, storage, data entry, etc. may be necessary.

5.2.1 MustSupport

Any element can be labelled as 'must-support' using the mustSupport flag on an Element Definition in an applicable profile. Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way.

The mustSupport flag itself does not define exactly what "support" for an element means. When a profile contains an element labelled as "must-support", 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.

Profiles can make the expectations clear by either:

  • Providing a narrative description of the obligations associated with the element as part of an implementation guide in which the profile is published, or in the narrative description of the element
  • Providing detailed expectations about the element using the obligation element

Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. (e.g., one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.

The base FHIR specification is intended to be independent of any particular implementation context, so no elements are flagged as mustSupport =true or assigned obligations as part of the resource definitions in base specification, and no specification (though obligations and/or mustSupport are used in some profiles defined for any in the base specification).

When a repeating element is labelled as 'must-support', it can be ambiguous whether the intent is that at least one of the repeating elements (except for an example profile). must be supported, or whether every element must be supported. The must support documentation SHOULD explicitly discuss this issue, and make the expectations in such cases clear to the implementers. In the absence of such documentation, implementer cannot be sure what the meaning of the specification is, though the community may issue new advice to clarify the meaning.

5.2.2 Obligations

If an element is labelled as "must-support", the element can specify the obligations associated with its use by providing one or more obligations using the Obligation Extension . For further details about how to use the obligation extension, consult the extension documentation .

If an element has obligations, it SHOULD also set the mustSupport flag to true. However, in some cases, legacy interpretation of the meaning of mustSupport makes making the flag true problematic. If an element with obligations has the mustSupport flag left as false, the mustSupport documentation of that profile or IG SHOULD document the rationale for the discrepancy.