MyHealth@Eu Laboratory Report
0.0.1 - qa-preview
150
MyHealth@Eu Laboratory Report - Local Development build (v0.0.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
This guide:
The following figure shows how the eHN guidelines, MyHealth@EU Functional Requirements and HL7 FHIR specifications are documented thorugh the different used HL7 FHIR IGs
Figure 1 - From the eHN guidelines to the MyHealth@EU specifications
The eHN guidelines is documented in the HL7 Europe Laboratory Report as HL7 FHIR Logical Models, including how this data set is implemented in HL7 FHIR; while this guide documents cross-borders reuqirements and associated profiles.
This guide includes three main kinds of content (see figure below)
Figure 2 - Guide Content
The design choices adopted for representing MyHealth@EU Functional Requirements are describe in the MyHealth@EU Requirements page; those used for HL7 FHIR Conformance Resources and ConceptMap below
Most of the design choices adopted by this guide are detailed in the parent guide HL7 EU Laboratory Report Design choices page.
A detailed description on how to read HL7 FHIR Implementation Guides is provided in the Reading Implementation Guides guide.
This guide doesn't use the Must Support flag, however, to highlight the elements realizing the fields identified by the MyHealth@EU Functional Requirements a generic handle obligation is used in the profile.
For the purpose of this guide handle elements are supposed to be:
More deatiled Obligations will be defined in the future, a first example of detailed obligations is given in the Obligations page
Implementers should be aware about the differences in the design of HL7 FHIR and HL7 CDA. This explain the different apporach followed on the way mandatory, required, or optional elements are represented in the implemantable specification.
In HL7 CDA, unless explictly flagged otherwise, elements can be always nullflavored. This is not what is expected to be done in general in HL7 FHIR, where there is not a nullFlavor attribute and the "1.." cardinality is supposed to be used only for the mandatory elements.
For this reason required field are not necessarly mapped into "1.." elements, unless it has been decided otherwise and the data-absent-reason extension used.
Obligations are expected to be adopted to enforce the functional requirements; the inclusion of warning invariants may also be considered in the future to highlight missing required elements.
This guide uses ConceptMap to formalize the models to profiles forward mapping.
Author are aware that ConceptMaps have been designed for managing the termonology concpet maps; but it is recognized that they may be used for mapping concepts model-to-model, when the scope is not a structural mapping (for which StrcutureMap shoudl be used).
This choice has been made to: