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 lead 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 that actually were listed in the profile are interpreted to be interpreted as "must support".
- Observation.value[x] lists all permitted data types. The IG community editors intended to allow all data types listed, but not require support for all 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 126.96.36.199 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 DocumentReference.author.” 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 still 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 work working with the HL7 members and the FHIR community to establish the necessary tooling and guidance through the next in future implementation guide/profile versions to remove these ambiguities.
Other workgroups developing and enhancing implementation guides will also be addressing this topic as well where whenever the need for further clarity is neededidentified. You can find the workgroup work group that owns the implementation guide of interest be by going to the FHIR IG's home page through the implementation guide registry, scroll to the page footer and click on the workgroup 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. To Confluence pages for all work groups can be accessed at https://confluence.hl7.org . To find the regular web conference call links you can go to http://www.hl7.org/concalls/Default.aspx?ref=nav, select the workgroup, select a meeting date (highlighted), and use the call details for the coordinates.Note that some final editing on the above is still in progress. This page will be moved to an HL7 web page to be locked in once finalized. The attached two letters below would be posted on the FHIR and US Core product brief pages as well.