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

Cross-Organization via National Infrastructure

Overview

An EHR system acts as a participant in a Member State's national interoperability infrastructure, enabling cross-organization data exchange.

Scope

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.

Participants

Example Deployment Patterns

Federated

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.

Central Repository

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.

Patient Lookup

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

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.