We are very concerned that the FHIR US Core R3.1.0/R4 Build Must Support construct remains too ambiguous and not granular enough as it yields interpretations of what is required to support as a communication profile AND adds as new functions/capabilities to the underlying data source/EHR per ONC’s policy declaration that supporting “mandatory” and “must support” elements includes that the underlying EHR supports collection, storage, and management of those elements.  Particularly the latter is not reasonable to require by way of a communication standard to access and exchange available EHI. Specifically, US Core has not sufficiently documented its intent, thus creating  ambiguity, for data types as to whether choices (e.g., references and data types) and data type components are actually all required to be supported, inherited from the Must Support statement on the attribute, or actually have the flexibility that a choice list or the data type definition referenced in the base standard implies.  As we understand, the intent of the Must Support at the attribute level was not to require all elements/components within the data type to be required, but rather that IF the underlying data is available in the underlying systems to make it available without requiring to add such data to the underlying system if that capability just does not exist.  The specific inclusion of certain reference or data type choices and selective profiling of some but not all data type elements and overall absence of documented intent has created the interpretation that everything is Must Support unless otherwise indicated where the reverse was the intent.

This JIRA focuses on the overall definitions of Must Support and ambiguity it introduces, and a proposed update to provide an interim solution until the ambiguity has been fully addressed, and then points to a specific set of JIRAs that have been submitted to address each individual attribute where we identified attributes where reference and data type choices result in data source documentation requirements that are not appropriate at this stage. 

The proposals also consider that FHIR US Core and C-CDA should align on these topics as they represent alternative methods to access the same USCDI data.  I.e., it would not benefit users that USCDI is available through one, but not the other method, or expected to be available through one where it cannot be provided by the data source as that data is not EHI.

The sections referenced are currently published/available in:

• US Core R3.1.0 - http://hl7.org/fhir/us/core/STU3.1/general-guidance.html#must-support
• US Core R4 Build - https://build.fhir.org/ig/HL7/US-Core-R4/general-guidance.html#must-support

The following two Must Support Statements in these published and build versions clearly acknowledge that the data source system may not have certain data and what to do in that situation:

• In situations where information on a particular data element is not present and the reason for absence is unknown, US Core Responders *SHALL NOT*include the data elements in the resource instance returned as part of the query results.
• When querying US Core Responders, US Core Requestors *SHALL*interpret missing data elements within resource instances as data not present in the US Core Responder’s system.
• NOTE: The above definition of _Must Support_is derived from HL7v2 concept “Required but may be empty - RE” described in HL7v2 V28_CH02B_Conformance.doc.

I.e., in the context of reference and data type choices there should be no expectation either that the data source ever has data that uses either of the reference or data type choices as their system may never document such data.  The sections also further indicate that it aims to model Must Support closely after the HL7 v2 RE construct which is informative to the missing elements in the FHIR US Core guidance.

However, FHIR US Core does not provide clear, unambiguous, complete guidance that extends beyond the attribute level into the data types used.  E.g., in CarePlan.category there is clarity that there be at least one code and system but unclear whether all other components are truly optional or still implied to be Must Support since CarePlan.category is Must Support., And for CareTeam.participant.role and many other attributes that use CodeableConcept, there is no clarity what the minimum set is that is required under the attribute’s Must Support flag as it points to the FHIR R4 base definition for that data type without further clarification on which components are Must Support or not.    It would be unreasonable to expect that ALL CodeableConcept data type components are Must Support.  There are numerous examples like that where there is no explicit indication what components are actually subject to Must Support. For some attributes the data type was clearly profiled, but for most it is not, thus leaving ambiguity what the expectations are, and whether it requires data sources to support it, or that it only indicates whether it should be able to be communicated if present: two different perspectives that are mixed ambiguously.

We note that we have also experienced with HL7 v2 implementation guidance the need to be more specific as guides started to be used for certification and conformance testing.  The lesson learned was that any complex data type component cannot be assumed to be RE based on the RE attribution of the segment/field as  It was necessary to define optionality at every component level in the context of the implementation guide/profile to avoid ambiguity and drive consistency.  Tedious, but necessary to avoid any confusion and ambiguity when it comes to conformance testing and claims.

Recognizing the current ambiguity yet need for that clarity to avoid any confusion, we propose that Must Support guidance be updated with the following additional statement:

• Must Support SHALL apply to the attribute level only. Unless attribute components are fully decomposed with specific cardinality and Must Support statement on each (sub-)component, or the Description & Constraints specifically indicates that certain components are Must Support, attribute components are considered as optional as the underlying standard allows.

With that statement in place, every Must Support attribute must be updated to fully specify Must Support on the components and choice lists to be explicit and unambiguous.

We must recognize this has not fully occurred to date with limited implementation experience to understand all the implications as more organizations are embarking on fully implementing FHIR US Core and be subject to certification and conformance testing.  This impacts not only how to enable access to EHI/USCDI actually available, but also whether the underlying data source is obligated, or not, to add more documentation capabilities that are otherwise not necessary/relevant for the system at hand.  We have therefore entered the following JIRAs focusing on attributes with the greatest need to make updates accordingly while recognizing more may be needed to get the necessary clarity as we collectively understand the implications and realities that we need to balance.

Once the related JIRAs are created will list them here or in the comments.