|
Type
|
Reference
|
Content
|
|
web
|
example.org
|
subject
: Jan Jansen
|
|
web
|
example.org
|
author
: Dr. Maria Schmidt
|
|
web
|
example.org
|
custodian
: Amsterdam University Medical Center
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/eps-jan-jansen
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/hdr-jan-jansen
|
|
web
|
example.org
|
author
: Radiology Department, Amsterdam UMC
|
|
web
|
example.org
|
http://example.org/fhir/ImagingStudy/ct-chest-study
|
|
web
|
example.org
|
http://example.org/wado-rs/studies/1.2.840.113619.2.55.3.604688119.969.1234567890.123/series/1.2.840.113619.2.55.3.604688119.969.1234567890.124/instances/1.2.840.113619.2.55.3.604688119.969.1234567890.125
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/imaging-report-jan-jansen
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/lab-report-jan-jansen
|
|
web
|
github.com
|
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
|
|
web
|
hl7.eu
|
|
|
web
|
ihe-europe.net
|
|
|
web
|
euridice.org
|
|
|
web
|
hl7.eu
|
IG © 2025+ HL7 Europe
.
Package hl7.fhir.eu.health-data-api#1.0.0-ballot based on FHIR 4.0.1
.
Generated
2026-08-05
|
|
web
|
profiles.ihe.net
|
IUA Authorization Server
|
|
web
|
profiles.ihe.net
|
IUA Resource Server
|
|
web
|
profiles.ihe.net
|
IUA Authorization Client
|
|
web
|
eur-lex.europa.eu
|
The EHDS Regulation initially defines six priority categories of electronic health data that all Member States must support first for cross-border primary use. These categories are explicitly listed in Article 14
of Regulation (EU) 2025/327.
|
|
web
|
eur-lex.europa.eu
|
Article 105
specifies the date when support for these priority categories is required: 26 March 2029 for categories (a), (b) and (c); 28 March 2031 for (d), (e) and (f).
|
|
web
|
eur-lex.europa.eu
|
The definitions of the priority categories comes from ANNEX I
of the EHDS Regulation.
|
|
web
|
profiles.ihe.net
|
IHE IUA
— Internet User Authorization
|
|
web
|
eur-lex.europa.eu
|
EHDS Regulation (EU) 2025/327
|
|
web
|
www.xt-ehr.eu
|
Xt-EHR Joint Action
|
|
web
|
profiles.ihe.net
|
IHE IUA
- Defines authorization and access control actors and mechanisms. We use the actors and transactions model.
|
|
web
|
profiles.ihe.net
|
IHE Consistent Time
- Defines the use of Network Time Protocol (NTP) to provide consistent time across systems.
|
|
web
|
profiles.ihe.net
|
IHE ATNA
- Referenced for secure transport requirements (TLS 1.2 Floor using BCP195 Option).
|
|
web
|
profiles.ihe.net
|
IUA Resource Server
- Required
|
|
web
|
profiles.ihe.net
|
IUA Authorization Server
- Required if authorization is handled internally; not required if using external authorization infrastructure. See Authorization Server Deployment
.
|
|
web
|
profiles.ihe.net
|
Authorization Server
|
|
web
|
profiles.ihe.net
|
Resource Server
|
|
web
|
profiles.ihe.net
|
Authorization Client
|
|
web
|
profiles.ihe.net
|
In deployments using an external Authorization Server, token validation commonly involves coordination with that Authorization Server; where supported and required by policy, Resource Servers MAY use token introspection via IHE IUA ITI-102
.
|
|
web
|
profiles.ihe.net
|
All API communications SHALL use secure transport as defined by IHE ATNA §9.2.6.4 TLS 1.2 Floor using BCP195 Option
.
|
|
web
|
profiles.ihe.net
|
This IG uses IHE IUA for actor definitions and groups those actors with SMART Backend Services behavior. IUA itself notes its relationship to SMART-on-FHIR
: "IUA is not based on SMART-on-FHIR, but does strive to not conflict with that standard."
|
|
web
|
www.udap.org
|
User-level authorization (including patient-mediated access) is out of scope for this version of the implementation Guide. For patient-mediated access patterns, readers are encouraged to consider SMART on FHIR App Launch
and International Patient Access
. Implementors might consider UDAP for dynamic client registration (see UDAP Security
).
|
|
web
|
profiles.ihe.net
|
IHE IUA
|
|
web
|
profiles.ihe.net
|
IHE Document Sharing
distinguishes type
(specific document types, typically LOINC codes) from category
(broad classification) on DocumentReference. This IG constrains type
for document discovery but leaves the category
vocabulary to content IGs
and implementations. Providers still support the category
search parameter.
|
|
web
|
eur-lex.europa.eu
|
Article 14
of the EHDS regulation defines six priority categories of electronic health data. EEHRxFDocumentPriorityCategoryCS
provides informative codes for these categories, organizing them by the LOINC type
codes consumers use for document search.
|
|
web
|
hl7.eu
|
Europe Laboratory Report
|
|
web
|
profiles.ihe.net
|
IHE Document Sharing
|
|
web
|
eur-lex.europa.eu
|
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
.
|
|
web
|
eur-lex.europa.eu
|
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.
|
|
web
|
build-fhir.ehdsi.eu
|
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.
|
|
web
|
eur-lex.europa.eu
|
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.
|
|
web
|
eur-lex.europa.eu
|
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.
|
|
web
|
eur-lex.europa.eu
|
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:
|
|
web
|
eur-lex.europa.eu
|
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
).
|
|
web
|
eur-lex.europa.eu
|
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
).
|
|
web
|
eur-lex.europa.eu
|
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.
|
|
web
|
eur-lex.europa.eu
|
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.
|
|
web
|
eur-lex.europa.eu
|
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.
|
|
web
|
eur-lex.europa.eu
|
EHDS Annex II §2.1
: "SHALL provide an interface enabling access
to the personal electronic health data [formatted in EEHRxF]"
|
|
web
|
eur-lex.europa.eu
|
EHDS Annex II §2.2
: "SHALL be able to receive
personal electronic health data [formatted in EEHRxF]"
|
|
web
|
profiles.ihe.net
|
IHE IUA
- Defines authorization and access control actors and mechanisms. Aligned with SMART. We use the actors and transactions model from this specification.
|
|
web
|
hl7.eu
|
HL7 Europe Laboratory Report
|
|
web
|
hl7.eu
|
HL7 Europe Hospital Discharge Report
|
|
web
|
hl7.eu
|
HL7 Europe Imaging Study/Report
/ Imaging Manifest
|
|
web
|
github.com
|
Open issues under discussion in this IG. Each has a corresponding GitHub Issue
where you can add input to existing issues, or create your own.
|
|
web
|
github.com
|
GitHub Issue
|
|
web
|
github.com
|
GitHub Issue
|
|
web
|
github.com
|
GitHub Issue
|
|
web
|
fhir.ehdsi.eu
|
In most European exchanges the consumer already holds a trusted patient identifier (national health ID, MRN, or similar). Identifier-based lookup produces an unambiguous match and avoids dependence on demographic data quality, which varies in completeness and localization across member states. The MyHealth@EU cross-border infrastructure
already follows this pattern.
|
|
web
|
hl7.eu
|
This section defines the API requirements for EHR systems that provide EEHRxF data that conforms to the HL7 EU Hospital Discharge Report
content profile.
|
|
web
|
hl7.eu
|
For detailed content profiles, see the EU Imaging Study Manifest IG
.
|
|
web
|
hl7.eu
|
The EURIDICE MADO profile
defines both a FHIR encoding and a DICOM KOS encoding for imaging manifests. When a system supports both representations, it publishes two DocumentReference resources
linked via relatesTo
:
|
|
web
|
github.com
|
This pattern was chosen ( #50
) because it works across all Document Sharing transports (MHD, XDS, XCA) without requiring content negotiation at the server.
|
|
web
|
euridice.org
|
Feedback requested on the dual-DocumentReference pattern.
The MADO profile
dual-encodes imaging manifests in both FHIR and DICOM representations. This IG uses two DocumentReferences linked via relatesTo.transforms
so that consumers can select the encoding they support based on contentType
. This pattern was chosen for compatibility with document sharing infrastructures (MHD, XDS, XCA), where each document entry carries exactly one format.
|
|
web
|
github.com
|
Implementers: does the dual-DocumentReference pattern work for your imaging infrastructure and content negotiation needs? Would a single-DocumentReference model be preferable? Feedback is welcome via Issue #50
.
|
|
web
|
hl7.eu
|
The content is defined by the HL7 EU Medication Prescription and Dispense
profile.
|
|
web
|
hl7.eu
|
HL7 Europe Laboratory Report
|
|
web
|
eur-lex.europa.eu
|
The regulatory basis is primarily found in EHDS ANNEX II - Essential Requirements for EHR Systems ( EUR-Lex
), which describes an obligation for EHR systems to include an Interoperability Component
that does the following:
|
|
web
|
www.xt-ehr.eu
|
For more details on the Xt-EHR work, see the Xt-EHR Website
. The Xt-EHR deliverables, including D5.1, D5.2, and D8.1, are available on the Xt-EHR deliverables page
.
|
|
web
|
www.xt-ehr.eu
|
For more details on the Xt-EHR work, see the Xt-EHR Website
. The Xt-EHR deliverables, including D5.1, D5.2, and D8.1, are available on the Xt-EHR deliverables page
.
|
|
web
|
profiles.ihe.net
|
[Out of Scope] 6 Logging Component Requirements:
This Implementation Guide does not specify the logging component format or the interoperability of logs from EHR systems. EHDS ANNEX II requires the generation of local audit logs for review, but does not specify the data format or require interoperability of those logs. Implementers needing standardized audit logging should consider IHE ATNA
and IHE BALP
(Basic Audit Log Patterns), which define FHIR AuditEvent-based audit log profiles. The IHE profiles used in this IG (MHD, PDQm, IUA) recommend but do not require ATNA grouping.
|
|
web
|
eur-lex.europa.eu
|
The Access Provider
actors ( Document Access Provider
, Resource Access Provider
) satisfy EHDS Annex II §2.1
by serving Document and Resource FHIR queries.
|
|
web
|
eur-lex.europa.eu
|
Alternatively, this IG proposes a path for EHR systems to delegate their EHDS Annex II §2.1
obligations to another system.
|
|
web
|
eur-lex.europa.eu
|
The Consumer
actors ( Document Consumer
, Resource Consumer
) satisfy EHDS Annex II §2.2
by initiating Document and Resource queries to retrieve and receive data from Access Providers.
|
|
web
|
eur-lex.europa.eu
|
Systems that need to accept documents pushed from Publishers (e.g., national infrastructure, regional repositories, integration engines) may implement the
Document Submission Option
on the Document Access Provider actor. This is an additional
capability for systems acting as aggregation points—it is not required to satisfy EHDS Annex II §2.2
.
|
|
web
|
www.xt-ehr.eu
|
Note: D8.1
is published on the Xt-EHR deliverables page. This section summarizes the concepts this IG builds upon.
|
|
web
|
profiles.ihe.net
|
The IHE mXDE
profile provides more detail on how to extract resources from documents while maintaining provenance.
|
|
web
|
profiles.ihe.net
|
IHE mXDE
|
|
web
|
eur-lex.europa.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.
|
|
web
|
build-fhir.ehdsi.eu
|
NCP-to-NCP exchange over MyHealth@EU is governed by the NCPeH API specification
, not by this IG. National infrastructure design — how a Member State routes an NCP query to the holding EHR systems — is a Member State choice (see Cross-Organization via National Infrastructure
).
|
|
web
|
eur-lex.europa.eu
|
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
.
|
|
web
|
eur-lex.europa.eu
|
A Health Professional Access Service
( Art. 12
) is provided by a Member State to health professionals for accessing their patients' health data. The service can be delivered as a web portal, an API, or other means. It authenticates the professional, locates the patient, and accesses data from EHR systems. The infrastructure behind these services is country-specific — see Member State Architectures
.
|
|
web
|
eur-lex.europa.eu
|
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)
).
|
|
web
|
eur-lex.europa.eu
|
Under EHDS, wellness application interoperability is not a separate API defined by this IG. A wellness application may claim interoperability with an EHR system only when the relevant common specifications and Annex II requirements are met ( Art. 47-48
). Article 48 limits sharing or transmission of data from the wellness application to the patient's Article 5 right to insert information into their EHR, with patient consent and control over the categories and circumstances of sharing.
|
