Skip to end of metadata
Go to start of metadata


The recent roll-out of FHIR R4 US Core 3.1.0 and 3.1.1 have highlighted ambiguity in understanding conformance implications for elements of attributes that have been marked "MustSupport".

  1. There is one understanding that would propagate MustSupport to each of the attribute’s elements defined through the data type and reference or target list.
  2. There is another understanding that would indicate that unless specific elements are marked as MustSupport, they are not subject to the MustSupport requirement. As a result, Meaningful use  is based on what the source system has available.

The US Core project team has recognized the need for clarity for each of the elements.  At times, depending on the attribute, at least one of the elements/choices must be supported, while in other cases multiple.  We expect this to be tremendously helpful to reduce ambiguity and create more predictable interoperability.

In the meantime, there must be clarity on which of the two interpretations is correct as this is not yet sufficiently documented in FHIR R4 Conformance.  The following is the proposed clarification with rationale for FMG, FHIR-I, and Conformance to adopt for inclusion in the Conformance section of FHIR Core.

FHIR Methodology Understanding

Profiles are created on top of FHIR Core or other Profiles to provide clarity and specificity on what attributes and elements must be supported to enable predictable, minimum interoperability (a floor) for the use case(s) at hand.  US Core intends to cover a wide variety of use cases, and thus needs to be more flexible, while a DME implementation guide can be more specific and restrictive in the context of a specific use case.  Consequently, certain profiles may only want to specify Must Support at the attribute level and leave the specific element requirements for subsequent, targeted profiles.

We have clarified that MustSupport is only intended to apply to the FHIR element it is applied to and does not propagate down to any of its subsequent elements reflected in the data type definition, reference or target list. Additional guidance on how to clarify which elements are to be supported is work in progress.  

Consequently, a profile must explicitly define any such subsequent MustSupport requirement.  Otherwise, it would not be possible to support further targeted profiling since a MustSupport cannot be overridden by a subsequent profile built on it.

It is therefore an incorrect interpretation of the methodology to apply a MustSupport on an attribute to its elements, be they data type components and/or reference or target choices, and/or backbone elements. Those would have to be specifically marked as MustSupport as this enables creation of further constrained profiles based on another profile, e.g., DME based on US Core.

For US Core that means that an attribute such as Observation.value[x] that is marked as MustSupport the list of target data types does not become required to be supported by the data source in total just because the attribute was marked as MustSupport.  Each entry in the list would have to be marked as MustSupport for that to be true.

FMG/FHIR-I/Conformance Ask

Formally confirm and publish the above as the standard is not fully explicit on that to enable users/interpreters to understand what is or is not required/expected.


The following is a draft statement in progress.

As the FHIR specification is maturing and worldwide adoption is growing, we've seen strong demand for the precise, computable expression of conformance requirements. This area of the specification -- and especially the precise semantics for describing which data elements a FHIR implementation "must support" - is under development.

After reviewing how FHIR's "must support" flag is being used in profiles today HL7 recognizes that in a number of cases the intent of implementation guide/profile authors is not fully reflected in the application and inclusion of the "must support" flag and other essential narrative, while some interpreting the “must support” flags in profiles are extending the scope of its impact beyond the element it is attached to.

The underlying intent of the "must support" flag in the FHIR Core specification was not to assume a "must support" on an attribute to be automatically applied to all its elements unless there was specific guidance for each of the elements within the attribute to provide more varied and flexible "meaningful" ways that the profile authors could use describing their intent.   Conversely, absence of choices available in the base standard but not in the profiled choice lists were not meant to be permissible if the attribute is flagged as “must support”, yet some implementation guide specific language does explicitly permit that.

The following examples from US Core demonstrate “must support” ambiguities:

  • value[x] lists all permitted data types. The IG community editors intended to allow all data types listed, not require support for all and therefore not compel the underlying system to start to capture data that way to conrom to US Core.  E.g., SampledData should not be a requirement to implement anew, rather that IF you have SampleData in the underlying data source you should support that.
  • agent.who is marked must support and includes 3 reference choices. The community editors did not intend to require systems support all choices. E.g., not all systems support Patient write capability, so US Core Patient Profile should not be required and therefore not compel a system to enable patient writes to conform to US Core.   
  • The US Core IG states in section Referencing US Core Profiles “Other resources allowed in the base FHIR specification may be referenced even though the current publication framework does not display them. For example, RelatedPerson is an allowed target reference in”. This seemingly conflicts with the express intent of the scope of “must support” in the base standard and needs to be resolved.  However, the IG community editors intended to allow for other references still to be valid.
  • The US Core IG references the vital signs profile, which in turn includes a number of profiles. One of those is the Vital Signs Panel.  If one opts to support that vital signs profile it the “must support” flag on .hasMember is not intending to require support for MolecularSequence.  The vital signs editors intended to allow all data types listed, but not require support for all and therefore not compel the underlying system currently to enable molecular sequence to conform to US Core

We recommend that any formal conformance testing and validation should not automatically treat the "must support" flag by applying it to the entire hierarchy of data within the attribute and until such guidance is provided one cannot require all elements are supported by the sender, rather reflect what their systems have available..

We look forward to work with the implementer community to establish the necessary tooling and guidance through the next implementation guide/profile versions to remove these ambiguities.

  • No labels


  1. "We have clarified that MustSupport is only intended to apply to the FHIR element it is applied to and does not propagate down to any of its subsequent elements reflected in the data type definition, reference or target list. How to further clarify which elements are further to be supported is work in progress.  "

    This is a very important consideration. In V2 methodology the backbone element/structure of a data element may be profiled as a reusable components (e.g. US Address for public health - mandates the use of county, US address for medical records does not mandate the use of county, it's optional).

    Incidentally, using a richer set of usage indicators, similar to V2, would allow us to specify reusable component definitions at the data element level as well (e.g. US Name with middle name, US name with middle initial).