# About this guide - MyHealth@Eu Vaccination v10.0.0-preview

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

## About this guide

**At a glance – MyHealth@EU Vaccination history IG**
* **Foundation:** Core FHIR profiles and logical models shared across all MyHealth@EU domain IGs.
* **Alignment:** Refines EHDS logical models from Xt-EHR with MyHealth@EU-specific obligations, derived from the HL7 Europe Base and Core IG.
* **Obligations:** Actor-based obligations (Mandatory / Required / Optional) applied to data elements to reflect MyHealth@EU functional requirements.
* **Goal:** Enable consistent, interoperable cross-border health data exchange across EU Member States.

### 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](http://www.xt-ehr.eu/fhir/models/ImplementationGuide/xtehr.eu.ehds.models) to reflect MyHealth@EU-specific obligations.
* Is derived from the [HL7 Europe Base and Core IG](https://build.fhir.org/ig/hl7-eu/core), adding MyHealth@EU cross-border requirements on top of the European foundation.

### 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.
1. **HL7 FHIR Conformance Resources**— profiles, value sets, and code systems describing how to implement HL7 FHIR for MyHealth@EU cross-border exchange.
1. **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](https://build.fhir.org/ig/FHIR/ig-guidance/readingIgs.html) 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](https://hl7.org/fhir/R4/extension-data-absent-reason.html) is used where a value may be legitimately absent.

### Models to Profiles Forward Mapping

The [Model to Profile Mappings](profiles.md) 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).

