This page is part of the FHIR Specification (v5.0.0-snapshot3: R5 Snapshot #3, to support Connectathon 32). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

5.2 Implementation Obligations

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Trial-Use

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.

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. 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 as part of the base specification, and no obligations are defined for any elements (except for an example profile).

This section and the element ElementDefinition.obligation is considered Trial Use for FHIR Release 5.

5.2.2 Obligations

If an element is labelled as "must-support", the element can specify the obligations associated with it's use by providing one or more obligations. Each obligation has the following features:

code	one or more codes that specify the details of the obligation. The codes are taken from the Obligations Code system. The codes say things like 'SHALL store this data item', 'SHOULD populate this if a data element is available', or 'HL7 v2 expectations apply'. If multiple codes are specified, then all the obligations apply. See below for more details about how the combination obligation codes work.
actor	One or more references to actors that are involved in the exchanges associated with the element. If any actors are indicated, then the obligations are only associated with those actors; if no actors are indicated, the obligations apply to all applications exchanging the element. Since this includes in any derived profiles, designers should be wary of defining obligations that don't have any associated actors.
documentation	Markdown documentation that provides additional information about the obligation, including it's rationale and justification
usage	A set of qualifiers that restrict the scope of the obligation. Typically, the obligation is restricted by jurisdiction/realm, but it may also be restricted to particular clinical or workflow contexts. This specification does not detail exactly how implementations determine when usage criteria apply, so this is a subject that should be addressed in implementation guides when usages are specified
filter	A FHIRPath expression that indicates a subset of elements to which this obligation applies. This is typically used with elements with a max cardinality greater than 0. The same outcome can be achieved by slicing the element, but this has a real price for implementers, so a filter is preferred if the element is not sliced for other reasons
filterDocumentation	A human readable description of the filter. This SHOULD be provided if a filter is specified, for the benefit of readers not familiar with FHIRPath expressions.
process	One or more URIs that reference processes that involve handling the data element. The references may be to Operations defined by the FHIR specification, or processed defined elsewhere, including in the EHR-FM specification .

5.2.3 Obligation Codes

There are two kinds of codes specified by the obligation codes coding system:

• Duplicate codes combining "shall" or "should" with a functional code
• Composite codes that specify one or more combinations of duplicate codes

The functional codes are defined in three different groups, according to whether obligations apply to resource creators, consumers or applications that are just transferring them from one application to another (a category that includes general purpose FHIR repositories). Note that actors, whether clients or servers or something else, typically both create and consume resources.