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
A Health Data Access Service (Art. 4) is provided by a Member State to natural persons or their representatives for accessing their health data. The service can be delivered as a web portal, an API, or other means. It authenticates the patient and accesses data from EHR systems on the patient's behalf. The infrastructure behind these services is country-specific — see Member State Architectures.
This IG defines the Interoperability Component API surface the access service uses when querying EHR systems. The access service itself — patient authentication (national eID, EU Digital Identity Wallet), consent management, and how queries are routed across EHR systems — is governed by Member State requirements and is out of scope here.
The patient's identity and authorization are established at the access service. At the Interoperability Component API surface, the consumer is an authorized system-to-system caller; the mechanism is described in Authorization. Patient consent preferences and app-linking rules are established by the access service or Member State infrastructure; this IG describes only the EHR-facing system-to-system exchange.
Article 5 gives patients the right to insert information into their own EHR through health data access services or applications linked to those services.
EHDS has not fully specified the expected data, service-linking model, review workflow, or transport path for Article 5 insertion.
A Health Data Access Service may submit patient-provided priority-category data in EEHRxF format to an EHR system using the Document Publisher interactions defined in this IG (ITI-105), where the receiving EHR system supports the Document Submission Option.
To distinguish patient-provided data from clinician-authored data, resources may carry .meta.security tags and/or Provenance resources indicating the patient as the source.
Patient-provided data extends beyond priority-category documents. For individual resources (observations, medications, etc.), we recommend future work follows an approach analogous to the FHIR CGM specification, modeling the needs of a specific use case and its interaction with care providers — for example: