EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/euridice-org/eu-health-data-api/ and changes regularly. See the Directory of published versions

Home

0.1.0

Official URL: http://hl7.eu/fhir/eu-health-data-api/ImplementationGuide/hl7.fhir.eu.eu-health-data-api				Version:	Highlight text changes?
				Computable Name: EuHealthDataApi
Copyright/Legal: Copyright HL7 Europe. Licensed under Creative Commons public domain (CC0 1.0).

Regulatory Basis and Scope

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 page for more detail on the link to the EHDS regulation requirements, and the technical interpretation of those requirements used here.

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 - 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 can access FHIR information using SMART authorization and resource access. IPA is the primary reference for resource access.
• 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 has a content profile defining the data model, maintained in separate Content IGs.

This API IG defines interoperability behavior - the transactions and exchange patterns that systems use to share data. It does not prescribe internal system architecture or design. Systems that choose to comply with EHDS interoperability requirements implement this behavior alongside one or more Content IGs.

Priority Category	Content IG	Exchange Pattern
Patient Summary	HL7 Europe Patient Summary	Document Exchange (MHD)
Medical Test Results	HL7 Europe Laboratory Report	Document Exchange (MHD)
Hospital Discharge Report	HL7 Europe Hospital Discharge Report	Document Exchange (MHD)
Medical Imaging	HL7 Europe Imaging Study/Report / Imaging Manifest	Document Exchange (MHD)
ePrescription / eDispensation	HL7 Europe MPD	IHE MPD

Authors

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

Role	Name	Affiliation
Project co-chair IHEeu	Josh Priebe	Epic/HL7 EU
Project co-chair HL7eu	Bas van den Heuvel	Philips/IHE EU
Contributor	John Moehrke	IHE
Contributor	Andreas Klingler	Siemens/ IHE Europe
Contributor	Vassil Peytchev	Epic
Contributor	Katie Reynolds	Epic
Contributor	Giorgio Cangioli	HL7 Europe
Contributor	Kai Heitmann	HL7 Europe