EU Health Data API
1.0.0-ballot - ballot
150
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
This section provides concrete examples and use cases showing how the functional requirements defined in this IG are applied in practice.
The EU Health Data API can be implemented in various deployment models to fit different Member State architectures and organizational structures.
Direct EHR Implementation: The EHR system directly implements the API specifications.
Organizational Façade: A hospital or healthcare organization deploys an aggregation layer implementing the API in front of one or more EHR systems.
Regional/National Hub: Regional or national infrastructure implements the API, federating queries to underlying EHR systems or serving from a centralized repository.
Registry Pattern: A registry system implements the API and provides standardized interfaces for EHR systems to publish and retrieve information.
See Member State Architectures for more details on how this specification accommodates different architectural patterns.
The following pages provide examples of common use cases:
A step-by-step walkthrough showing the complete flow: authorization → patient identification → document query (IHE MHD ITI-67) → document retrieval (IHE MHD ITI-68). Demonstrates the most common pattern using the Document Consumer and Document Access Provider actors with IHE MHD transactions.
Healthcare providers accessing EEHRxF data through a professional portal. Shows how clinicians can query and retrieve patient information from other organizations.
Patients accessing their own health data through a health data access service. Demonstrates patient-facing access patterns.
Health information exchange across borders through National Contact Points and MyHealth@EU infrastructure. Shows how this API specification fits within the broader EHDS ecosystem.
All use cases leverage the composite actors defined in Actors and Transactions: