EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot 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

Implementation

This IG describes a FHIR API surface for EHR systems that supports implementation of the EHDS Interoperability Component requirements. EHR systems are one part of a broader European interoperability landscape: Member States operate national and cross-border infrastructure, healthcare providers deploy EHR systems, and EHR systems expose Interoperability Component capabilities that national and access-service infrastructure can use. The same capabilities can also support national and provider use cases beyond EHDS.

This page provides informative guidance for how EHR systems supporting the Interoperability Component fit into the European interoperability landscape and can support different actors in meeting their EHDS obligations. While EHDS does not dictate interoperability implementation details at the Member State or healthcare organization level, Member States and healthcare organizations can deploy these capabilities within their existing domains to support EHDS implementation. For example, the Member State obligation to connect all healthcare providers to their MyHealth@EU national contact point (NCP) (Art. 23(5)) can be supported by a healthcare provider deploying an EHR system as a Document Access Provider to make the organization's priority-category data available to the NCP, which retrieves it by acting as a Document Consumer.

The European Interoperability Landscape

The diagram below shows the EHDS actors and the boundaries between them. The blue boxes represent use cases: contexts where the API surface of the Interoperability Component is deployed or consumed.

The figure shows different elements:

• Environments (white/grey boxes), different environments within the European interoperability landscape with specific rules and deployment options.
• System actors (black boxes), systems in an environment.
• Human actors (user icons), key users in different environments that interact with the systems in that environment through a user interface. HP = Health Professional, Pat = Patient.
• Use cases (blue boxes), contexts where the API surface of the Interoperability Component is deployed or consumed.

This Implementation Guide describes the API surface of the EHDS Interoperability Component: document exchange, resource access, patient lookup, authorization, and document publication. The use cases outlined in this section show where the Interoperability Component can be deployed in the European interoperability landscape. Some use cases directly involve data exchange with EHRs; others indirectly make use of data that has previously been consumed via data exchange with EHRs.

Each use case and environment might have its own rules and requirements, which are outside the scope of this Implementation Guide; here, we focus on how the Interoperability Component as described in this Implementation Guide can support actors across the use cases.

EHDS Environments and Actors

MyHealth@EU

Cross-border exchange routes through National Contact Points (NCPs) over the MyHealth@EU network (Art. 23(2)). When a patient from Country A receives care in Country B, Country B's NCP requests the patient's data from Country A's NCP, which then queries national infrastructure to retrieve it.

Member States

Member States must operate the national and cross-border infrastructure that enables EHDS primary-use exchange. The following environments and actors are relevant:

• National interoperability infrastructure: Member States define how health data is exchanged between healthcare providers in order to meet EHDS obligations and other national use cases. This IG does not prescribe national architecture choices, but shows how EHR systems conforming to this IG can support Member State interoperability infrastructure.

  • MyHealth@EU and National Contact Points (NCPs): Member States must operate NCPs that connect to the MyHealth@EU central platform (Art. 23(2)) and must ensure healthcare providers are connected to that infrastructure (Art. 23(5)). NCP-to-NCP exchange is governed by the NCPeH API specification, not by this IG.

  • Health data access service (HDAS): Member States must operate a patient-facing health data access service (Art. 4). For the purposes of this Implementation Guide, this is modeled primarily as a user-facing interface that can act as a consumer of the Interoperability Component API surface; its service requirements are not specified here.

  • Health professional access service (HPAS): Member States must operate a health professional access service (Art. 12). For the purposes of this Implementation Guide, this is modeled primarily as a user-facing service that can act as a consumer of the Interoperability Component API surface; its service requirements are not specified here.

• Healthcare providers: Healthcare providers deploy one or more EHR systems to support care delivery, including EHR systems which support internal clinical workflows within an organization as well as EHR systems which support cross-organization exchange with national infrastructure, for example to meet the member state requirement Art. 23(5) to connect their data to the national NCP for cross-border exchange. This environment holds the following system actors:

  • EHR systems: EHR systems must conform to the Interoperability Component implemented in this IG. Art. 25(1) requires EHR systems to include the European interoperability software component; Annex II §2.1–2.4 requires that component to provide and receive priority-category data in EEHRxF format. An EHR system may expose the API surface directly, or the capability may be delivered by an associated gateway or facade treated as part of the deployed EHR (EHR System Composition Patterns).

  • Gateway EHR system: A specific EHR system that connects to the national infrastructure to facilitate cross-organization exchange.

• Wellness applications: A wellness application is software, or a combination of hardware and software, intended for use by a natural person to process electronic health data for information on a person's health or for the delivery of care for purposes other than the provision of healthcare (Art. 2(2)(ab)). A wellness application may claim interoperability with an EHR system (Art. 47-48) by implementing the applicable Interoperability Component functionality. It may also be the mechanism by which the patient exercises their (Art. 5) right to insert data into their own EHR through electronic health data access services or applications linked to those services. Article 48 frames wellness-app interoperability as patient-controlled sharing or transmission of data from the wellness application to the EHR - a wellness application may therefore exchange EEHRxF data through the health data access service, or via an EHR system directly depending on the needs of the implementation. This IG models that exchange using the same Interoperability Component transactions described here.

Use Cases

• Retrieve a European Patient Summary — A generic example showing how the components described in this IG (authorization, patient lookup, document retrieval) can be used to access a patient summary.

• Cross-Border Exchange via NCP — How EHR systems support cross-border exchange of data via national interoperability infrastructure, National Contact Points, and MyHealth@EU.

• Health Professional Access Service — Health professionals accessing EEHRxF data through a member state access service.

• Health Data Access Service — Patients accessing their own health data through a member state access service, and exercising their patient rights.

• Wellness Apps — How wellness applications can access patient data through an authorized service context and insert patient-provided data into an EHR under Articles 5 and 48.

• Cross-Organization via National Infrastructure — How EHR systems act as participants in national interoperability infrastructure to exchange data across healthcare providers.

• Provider-Internal Exchange — How a healthcare provider using multiple EHR systems can use the same Interoperability Component capabilities for internal exchange or external aggregation.