Da Vinci Health Record Exchange (HRex), published by HL7 International / Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 1.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ehrx/ and changes regularly. See the Directory of published versions
Page standards status: Trial-use |
Da Vinci IGs, including this one, make use of conformance language such as SHALL, SHOULD and MAY to describe the behavior of systems. The meaning of these words shall be interpreted as per the FHIR core spec.
The following rules around mustSupport elements are expected to apply to all Da Vinci IGs. Some Da Vinci IGs might impose additional conformance expectations and some Da Vinci IGs might 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:
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.
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 profile, the referenced resource SHOULD be a US Core profile if a US Core profile exists for the resource type.
Many of the profiles are based on US Core 7.0.0 while also declaring conformance with US Core 6.1.0 and 3.1.1. In some cases, the 7.0.0 and/or 6.1.0 releases introduce new "mustSupport" elements that are not mustSupport in 3.1.1. The intention of this implementation guide is NOT to move forward the timelines by which EHRs and/or payers must support USCDI 3 and 4 content. Rather, it is to allow seamless transition as systems start to support the newer US Core releases as systems start to bring them on stream. As such, clients and servers have no obligations with respect to elements that are newly mustSupport in 6.1.0 or 7.0.0 beyond "don't error if these elements are present" until such time as those systems claim conformance with the US Core release which introduces those elements as mustSupport. Once a system claims conformance to US Core 6.1.0 or 7.0.0, then the conformance expectations of those release of the US Core guide come into play.