Skip to end of metadata
Go to start of metadata

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 still evolving.

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 and the communities they represent are not completely aligned regarding the interpretation of the "must support" flag and supporting narrative in the guides. This has led to some confusion, with some implementers interpreting the “must support” flags in profiles beyond the intended scope or the community’s expectation for the element it is attached to.

The underlying intent of the "must support" flag definition in the FHIR Core specification was not to indicate that implementers "must support" all the possible data values, data type choices, and reference targets of the element.  Some Implementation guides (IGs) may seem to imply that some or all choices listed are intended to inherit the "must support" requirement, or have not always applied a consistent interpretation of ‘must support’ within the same IG. Additional specific guidance for each of the underlying data values and choices is required in order to unambiguously describe an implementation guide’s intent.

Further, where an underlying element includes a reference choice or an attribute[x] choice, and a profile omits those choices, these choices are prohibited from use, and specific guidance would have to be provided if any of the choices listed in the profile should be considered either as optional or "must support". However, some IGs may seem to imply that the omitted choices are still optionally allowed for that profile, while the actual choices listed in the profile are to be interpreted as "must support". 

Using the HL7 FHIR® US Core Implementation Guide STU 3.1.1as an example, the following references to “must support” demonstrate some of the ambiguities:

  • Observation.value[x] lists all permitted data types. The IG community editors intended to allow all data types listed, but not require support for each of these and therefore not compel the underlying system to start to capture data that way to conform to US Core.  E.g., SampledData should not be interpreted as a requirement to implement anew, rather to apply only IF you have SampleData in the underlying data source.
  • Provenance.agent.who is marked must support and includes 3 reference choices. The community editors did not intend to require systems to support all 3 choices. E.g., not all systems support Patient write capability, so systems are not compelled to enable patient writes in order 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 conflicts with the description of how profiling elements works as documented in the base standard and needs to be resolved.  However, the IG community editors intended to allow for other references also to be valid.  Irrespective of that intent, the methodology as documented in the base standard and the supporting FHIR validator do not permit use of any resources not included in the reference choice list and would fail validation.
  • The US Core IG references the vital signs profile from the base FHIR specification, which in turn includes a number of profiles. One of those is the Vital Signs Panel.  If one opts to support the vital signs profile, which sets the “must support” flag on .hasMember is not intending to require support for MolecularSequence in all cases.  The vital signs editors intended to allow any of the data types listed, but not require support for all and therefore does not compel the underlying system to enable molecular sequence to conform to US Core. Note that there is not, at present, a formal definition of what ‘must-support’ means in the base specification.

We recommend that any formal conformance testing and validation should not automatically treat the "must support" flag by applying it to the entire set of data values, data type choices, and reference targets described for the element – and unless or until such guidance is provided one should not require all elements to be supported by the sender.  Rather, what is sent should reflect what their systems have available.

We look forward to working with the HL7 members and the FHIR community to establish the necessary tooling and guidance in future implementation guide/profile versions to remove these ambiguities.

How to engage?

If you are interested in engaging with the work Hl7 is undertaking to further clarify the relevant specifications, you can engage with the following committees/workgroups:

Committee/WorkgroupFunctionZulip ChannelRegular web conference link

FHIR methodology and tooling

FHIR-IManage the tooling / publishing infrastructure used to generate the specifiations#ig creation
Modeling and MethodologyResponsible for the overall conformance framework#methodology
FHIR Management GroupCoordination between the above groups, and approves publications / adjudicatesn/a
Implementation Guide (Example)
US Realm Steering CommitteeOverall control of US specifications, and working with ONC/US Government#united states
Cross-Group ProjectsDirect Control of the US Core Specificationn/a

Other workgroups developing and enhancing implementation guides will also be addressing this topic whenever the need for further clarity is identified.  You can find the work group that owns the implementation guide of interest by going to the FHIR IG's home page through the implementation guide registry, scroll to the page footer and click on the work group listed.  On the workgroup's web page you will find a leadership tab to contact a co-chair, as well as an additional resources tab where you can find the confluence page where the workgroup collaborates. Confluence pages for all work groups can be accessed at . To find the regular web conference call links you can go to, select the workgroup, select a meeting date (highlighted), and use the call details for the coordinates.

Updated letters:

  • No labels