The following rules around mustSupport elements are expected to apply to all Da Vinci IGs. Some Da Vinci IGs may impose additional conformance expectations and some Da Vinci IGs may choose not to reference this guidance and define their own independent set of expectations.

In the context of an HRex compliant IG, mustSupport on any data element SHALL be interpreted as follows:

• Data Sources SHALL be capable of populating the data element when sharing resources compliant with the profile. I.e. the system must be capable of having data for the element and sharing it.
• Data Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
• If the minimum cardinality of an element is greater than 0 – i.e. the element is ‘required’, then the element SHALL be present in the instance and SHALL have a value unless:
  • The profile explicitly declares the dataAbsentReason extension or other extension for the element, in which case an extension can be present in place of the value.
  • The profile is inherited from U.S. Core, in which case a dataAbsentReason extension may be sent in place of the value even where dataAbsentReason is not explicitly declared in the profile.
• Data Consumers SHALL interpret missing data elements within resource instances as data not being present in the Data Source’s systems or was not deemed to be shareable with the Data Consumer for privacy or other business reasons.
• Where the value set for an element includes concepts such as “unknown”, “refused to answer”, “not available” or where dataAbsentReason is explicitly referenced in a profile, then Data Sources SHALL use these values/that extension to communicate the reason for missing data.
• Data Consumers SHALL be able to process resource instances containing data elements that have extensions in place of a value where such extensions are declared as part of the profile.

NOTE: mustSupport indicates what Da Vinci conformant systems are expected to be able to handle. Systems are free to include additional data - and receivers SHOULD NOT reject instances that contain unexpected data elements if those elements are not modifier elements. However, sending systems should be aware that they can't count on receivers storing, processing or doing anything other than ignoring data that is not marked as mustSupport.

Referencing US Core Profiles

Many of the profiles in this guide reference other FHIR resources that are US Core profiles. This is defined in the formal profile definitions. For example, US Core Patient. For any other references not formally defined in a US Core profiles, the referenced resource SHOULD be a US Core profile if a US Core profile exists for the resource type.