EU Health Data API
1.0.0-ballot - ballot
150
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
An EHR system acts as a participant in a Member State's national interoperability infrastructure, enabling cross-organization data exchange.
National infrastructure design is a Member State choice and is not prescribed by EHDS or this IG. This IG defines the Interoperability Component API surface at the EHR system boundary, and this deployment scenario shows how EHR systems conforming to this IG can support data exchange in different Member State architectures.
The patterns below are illustrative; Member States may combine them or use other national infrastructure designs.
A national "record location" service holds references to where patient data resides. A consumer queries the record locator to identify which EHR systems hold data for a patient, then uses this information to query those systems directly or through a proxy. The record locator is national infrastructure and is not specified by this IG.
Consumer → Record Locator ──→ EHR System A
└──→ EHR System B
In this scenario, data-holding EHR systems acting as Document/Resource Access Providers offer query access to their data to destination EHR systems acting as Document/Resource Consumers.
In this model, source EHR systems publish documents to a central national repository (or repositories), which enables access to this data by offering query access to consuming systems.
EHR System (source) ──[publish]──→ National Repository ──→ Consumer
The source EHR acts as Document Publisher towards the central repository (Document Access Provider), which enables EHRs acting as Document Consumers to query.
Both patterns use the same Interoperability Component API surface defined in this IG. See Member State Architectures for more detail.
In both patterns, a consumer needs to identify which patient data to retrieve. One approach is a national patient identity service that resolves a set of identity attributes to a national patient identifier, which the consumer then uses to query EHR systems.
Authorization methods to secure cross-organization exchange are a national architecture choice outside the scope of this IG. Member States choosing to align with SMART Backend Services client credentials can use the EHR system support defined in Authorization.