This page is part of the EU Health Data API (v1.0.0-ballot: STU1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Home

Acknowledgment
The development of this Implementation Guide version has been supported by the Xt-EHR Joint Action. Xt-EHR provided expertise, alignment with European health policy priorities, and validation of specifications to enable consistency with EHDS requirements.

Regulatory Basis

The European Health Data Space (EHDS) regulation describes an obligation for EHR systems to include an Interoperability Component that does the following:

• §2.1: "SHALL provide an interface enabling access to the personal electronic health data [formatted in EEHRxF]"
• §2.2: "SHALL be able to receive personal electronic health data [formatted in EEHRxF]"

This Implementation Guide:

1. Defines a set of EHR functionalities that meet the Interoperability Component requirements: describes how existing IHE profiles and other specifications can be used to provide secure access and enable secure exchange of EEHRxF data between systems.
2. Shows how these EHR functionalities can be used in real-world data exchange for EHDS use cases: outlines how these EHR functionalities can be used to provide patients access to their own data, to allow providers access to patient data, and to support the cross-border data exchange in the myHealth@EU network.

See Regulatory Anchors for more detail on the link to the EHDS regulation requirements, and the technical interpretation of those requirements used here.

Scope

This IG defines exchange patterns — actors, transactions, and security — that systems use to find, retrieve, and publish EEHRxF health data via FHIR APIs. It covers authorization, patient matching, document exchange, resource access, and capability discovery.

This IG does not define clinical data models. Separate Content IGs maintained by HL7 Europe define the structure and content of each priority category: what fields a Patient Summary contains, what codes a Laboratory Report uses (see Priority Categories). An implementable system combines this IG for transport with a Content IG for the data model.

This IG excludes ePrescription and eDispensation workflow transactions, user-level authorization, audit logging formats, and bulk data export. See Regulatory Anchors for requirements traceability.

Audience

The intended audiences of this Implementation Guide are:

• Manufacturers of EHR systems: EHR vendors looking to develop support for APIs that meet the needs of EHDS should refer to the Functional Requirements for a list of functional specifications EHRs should support.

• Architects of national infrastructures: National eHealth agencies looking to understand how to use the capabilities of EHRs required by EHDS to meet the goals of EHDS in their Member States should refer to the Implementation for examples of how the EHR APIs can be used for the EHDS use cases.

Summary of Functional Requirements ("the API")

• Capability Discovery - Discover which priority categories a server supports
• Authorization - SMART Backend Services (IUA actor model)
• Patient Matching - PDQm Patient Demographics Query
• Document Exchange - MHD transactions (ITI-67, ITI-68, ITI-105)
• Resource Access - International Patient Access (IPA) resource query patterns

Approach

We define exchange patterns by inheriting and defining transactions, system actors, and associated capability statements from existing IHE and HL7 specifications:

• IHE MHD - Defines exchange of Documents, which we use to exchange FHIR document content.
• HL7 SMART App Launch - Backend Services - Defines authorization in FHIR. We use the SMART Backend Services profile for system-system authorization, including the FHIR scopes defined in this specification.
• IHE IUA - Defines authorization and access control actors and mechanisms. Aligned with SMART. We use the actors and transactions model from this specification.
• IHE PDQm - Defines how a client can perform patient lookup against a server.
• HL7 International Patient Access (IPA) - Defines how an application accesses patient information using SMART authorization and resource query. International Patient Access is the primary reference for resource access patterns in this IG.
• IHE QEDm - Defines how a client can query for existing FHIR resources from a FHIR server. Referenced where compatible with IPA.

We define composite actors that inherit and combine actors defined in these existing specifications. See Actors and Transactions for detailed actor definitions, transactions, and actor grouping.

At a high level, the following actors are specified:

Document Exchange Actors

• Document Publisher - Produces EEHRxF FHIR Documents and publishes to Document Access Providers
• Document Access Provider - Serves EEHRxF FHIR Documents via query API. Optionally accepts documents from Document Publisher (Document Submission Option).
• Document Consumer - Queries and retrieves EEHRxF documents from Document Access Providers

Resource Exchange Actors

• Resource Access Provider - Provides query access to individual FHIR resources
• Resource Consumer - Queries FHIR resources from Resource Access Providers

These resource actors are initially scoped for search + read. See Resource Access for detailed discussion and possible approaches for resource exchange patterns.

Priority Categories

EHDS defines priority categories of health data for interoperability. Each pairs a Content IG (data model) with an exchange pattern (this IG). See Priority Categories for details.

For medication data, this IG covers reading medication resources (MedicationRequest, MedicationStatement) as resource access — e.g., "what medications is this patient taking?" The ePrescription and eDispensation workflow transactions (prescribing, dispensing) are out of scope and handled by IHE MPD.

See the HL7 Europe Implementation Guides registry for the canonical list of Content IGs and their current publication URLs.

Authors

This guide is the result of a multi-stakeholder effort involving different experts from several European countries, projects, initiatives, SDOs, and companies.