This page is part of the MyHealth@Eu Core (v1.0.0: Wave 9) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

About this guide

Overview

This guide:

• Provides core HL7 FHIR artifacts (logical models, profiles, terminologies) shared across all MyHealth@EU domain-specific IGs.
• Refines the EHDS logical information models from the Xt-EHR project to reflect MyHealth@EU-specific obligations.
• Is derived from the HL7 Europe Base and Core IG, adding MyHealth@EU cross-border requirements on top of the European foundation.

The following figure shows how the eHN guidelines, MyHealth@EU Functional Requirements, and HL7 FHIR specifications relate across the different IGs.

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

What is in this Guide

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

1. HL7 FHIR Logical Models — representing the MyHealth@EU core information requirements, derived from EHDS logical models. Logical models are not intended to be directly implemented or exchanged.
2. HL7 FHIR Conformance Resources — profiles, value sets, and code systems describing how to implement HL7 FHIR for MyHealth@EU cross-border exchange.
3. Model-to-Profile Mappings — inline tables documenting how each logical model element maps to a FHIR R4 path in the corresponding profile.

Figure 2 - Guide Content

A detailed description on how to read HL7 FHIR Implementation Guides is provided in the Reading Implementation Guides guide.

Obligations Framework

This guide uses an actor-based obligations framework to express MyHealth@EU functional requirements on data elements, rather than relying solely on FHIR cardinality or Must Support flags.

Three obligation levels are defined:

• Mandatory (SHALL:handle) — the data element must be provided.
• Required (SHOULD:handle) — the data element must be provided, although exceptional justifications may apply.
• Optional (MAY:able-to-populate) — the data element may be omitted.

These are applied via reusable FSH rule sets (ObligationMandatory, ObligationRequired, ObligationOptional) defined in the Core IG.

Representing Functional Requirements

Implementers should be aware of the differences between HL7 FHIR and HL7 CDA when interpreting obligation levels.

In HL7 CDA, elements can generally be nullFlavored unless explicitly flagged otherwise. In HL7 FHIR, 1.. cardinality implies a truly mandatory element. For this reason, required fields are not necessarily mapped to 1.. cardinality — the data-absent-reason extension is used where a value may be legitimately absent.

Models to Profiles Forward Mapping

The Model to Profile Mappings page documents how each MyHealth@EU logical model element maps to a specific FHIR R4 path in the corresponding profile. Mappings are expressed as tables with three columns:

• Logical model element — the element name as defined in the MyHealth@EU logical model.
• FHIR Path (R4) — the target FHIR R4 element path in the profile.
• Comment — clarifications on the mapping, including use of extensions or R5 preadoption patterns.

Note that some logical models map to more than one FHIR profile. For example, MyHealthEuDocument maps to both CompositionMyHealthCore (structured clinical documents) and DiagnosticReportMyHealthCore (report-oriented diagnostic content).