# About this guide - MyHealth@Eu Laboratory Report v9.1.1-ci-build

* [**Table of Contents**](toc.md)
* **About this guide**

## About this guide

### Overview

This guide:

* specifies a set of rules to be applied to HL7 FHIR to define how to represent a **Laboratory Report** for the **European cross-borders exchange**, coherently with the European eHN Guidelines (see the [European eHealth - Key documents](https://health.ec.europa.eu/ehealth-digital-health-and-care/key-documents_en) ).
* provides a representation of the Laboratory Result Content specified in the MyHealth@EU Functional Requirements [13.01 Create the MyHealth@EU Laboratory Result Report Content](https://webgate.ec.europa.eu/fpfis/wikis/display/EHDSI/13.01+Create+the+MyHealth@EU+Laboratory+Result+Report+Content) expressed as HL7 FHIR Logical Model.
* is derived for the [HL7 Europe Laboratory Report](https://hl7.eu/fhir/laboratory/) HL7 FHIR IG fulfilling the MyHealth@EU Functional Requirements. More details in the [MyHealth@EU Laboratory Models Overview](overview-laboratory.md) page.

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

Figure 1 - From the eHN guidelines to the MyHealth@EU specifications

The eHN guidelines is documented in the [HL7 Europe Laboratory Report](https://hl7.eu/fhir/laboratory/) 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.
1. HL7 FHIR Conformance Resources (e.g. profiles, value sets) describing how to implement HL7 FHIR for the purpose of this guide.
1. Simple Mapping Tables describing models to profiles forward mapping.

Figure 2 - Guide Content

The design choices adopted for representing MyHealth@EU Functional Requirements are describe in the [MyHealth@EU Laboratory Models Overview](overview-laboratory.md) 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](https://hl7.eu/fhir/laboratory/design-choice.html).

A detailed description on how to read HL7 FHIR Implementation Guides is provided in the [Reading Implementation Guides](https://build.fhir.org/ig/FHIR/ig-guidance/readingIgs.html) 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](https://hl7.org/fhir/R4/extension-data-absent-reason.html) 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](profiles.md) page.

