MyHealth@Eu Laboratory Report
9.1.1-ci-build - trial-use 150

MyHealth@Eu Laboratory Report - Local Development build (v9.1.1-ci-build) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

About this guide

Overview

This guide:

The following figure shows how the eHN guidelines, MyHealth@EU Functional Requirements and HL7 FHIR specifications are documented through the different used HL7 FHIR IGs

From guidelines to specifications

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.

What is in

This guide includes three main kinds of content (see figure below)

  1. HL7 FHIR Logical Models representing the MyHealth@EU Functional Requirements. Logical Models are not supposed to be implemented and exchanged.
  2. HL7 FHIR Conformance Resources (e.g. profiles, value sets) describing how to implement HL7 FHIR for the purpose of this guide.
  3. Simple Mapping Tables describing models to profiles forward mapping.
Guide Content

Figure 2 - Guide Content

The design choices adopted for representing MyHealth@EU Functional Requirements are describe in the MyHealth@EU Laboratory Models Overview page; those used for HL7 FHIR Conformance Resources and ConceptMap below

Conformance Resources

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.

Flagging elements

This guide uses obligations on the logical models to highlight the elements identified by the MyHealth@EU Functional Requirements. Three types of obligations are defined based on the MyHealth@EU requirements perspective:

  • Mandatory: the data element must be provided
  • Required: the data element must be provided, although exceptional justifications can be provided
  • Optional: the data element can be completely omitted

These obligations are implemented using the following rule sets:

  • ObligationMandatory - SHALL:handle for mandatory elements
  • ObligationRequired - SHOULD:handle for required elements
  • ObligationOptional - MAY:able-to-populate for optional elements

Important: Regardless of whether data elements are mandatory, required, or optional, if they are present in the document, they cannot be omitted when displaying information to health professionals. All present data elements must be displayed by consuming systems.

Representing functional requirements

Implementers should be aware about the differences in the design of HL7 FHIR and HL7 CDA. This explains the different approaches followed on the way mandatory, required, or optional elements are represented in the implementable specification.

In HL7 CDA, unless explicitly 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 necessarily mapped into "1.." elements, unless it has been decided otherwise and the data-absent-reason extension used.

Models to profiles forward mapping

This guide uses simple mapping tables to formalize the models to profiles forward mapping.

These tables provide a clear, readable format showing how logical model elements map to specific FHIR paths, along with relevant comments and constraints. The mapping tables are organized by model type and can be found in the Mapping to Profiles page.