EU Health Data API
0.1.0 - ci-build
150
EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 0.1.0 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
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
The following artifacts define the types of individuals and/or systems that will interact as part of the use cases covered by this implementation guide.
| EEHRxF Document Access Provider |
The Document Access Provider actor provides access to EEHRxF FHIR Documents by receiving documents from Document Publishers and serving them to Document Consumers. This composite actor groups MHD Document Recipient, MHD Document Responder, PDQm Patient Demographics Supplier, and IUA Authorization Server/Resource Server. See Document Access Provider CapabilityStatement for technical requirements. |
| EEHRxF Document Consumer |
The Document Consumer actor consumes EEHRxF FHIR Documents by querying a Document Access Provider. This composite actor groups MHD Document Consumer, PDQm Patient Demographics Consumer, and IUA Authorization Client. See Document Consumer CapabilityStatement for technical requirements. |
| EEHRxF Document Publisher |
The Document Publisher actor produces EEHRxF FHIR Documents and publishes them to a Document Access Provider. This composite actor groups MHD Document Source, PDQm Patient Demographics Consumer, and IUA Authorization Client. See Document Publisher CapabilityStatement for technical requirements. |
| EEHRxF Grouped Document Publisher/Access Provider |
The grouped Document Publisher/Access Provider actor represents a deployment where document production and access provision are co-located in the same system. In this configuration, document submission (ITI-105) is internal and only document query/retrieval (ITI-67, ITI-68) is exposed externally. This is common for hospital EHR systems that produce and serve their own documents. See Grouped Document Publisher/Access Provider CapabilityStatement for technical requirements. |
| EEHRxF Resource Access Provider |
The Resource Access Provider actor provides access to FHIR resources following IPA and QEDm patterns. This enables direct resource access complementing document-based exchange. This composite actor groups QEDm Clinical Data Source, IPA Server, PDQm Patient Demographics Supplier, and IUA Authorization Server/Resource Server. See Resource Access Provider CapabilityStatement for technical requirements. |
| EEHRxF Resource Consumer |
The Resource Consumer actor queries for clinical data resources from a Resource Access Provider following IPA and QEDm patterns. This composite actor groups QEDm Clinical Data Consumer, IPA Client, PDQm Patient Demographics Consumer, and IUA Authorization Client. See Resource Consumer CapabilityStatement for technical requirements. |
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
| EEHRxF Document Access Provider - Document Submission Option |
CapabilityStatement for the Document Submission Option on the EEHRxF Document Access Provider. This option enables the Access Provider to receive documents from external Document Publishers via ITI-105 Simplified Publish. Systems implementing this option:
This option is REQUIRED when acting as a delegated access provider for external Document Publishers (e.g., integration engines, national infrastructure). Actor GroupingAdds to base Document Access Provider:
Transaction
SecuritySystems SHALL support SMART Backend Services authorization for document submission. |
|||||||||||||||
| EEHRxF Document Access Provider CapabilityStatement |
CapabilityStatement for the EEHRxF Document Access Provider actor. This composite actor provides access to EEHRxF FHIR Documents by serving them to Document Consumers via query APIs. Actor GroupingThis composite actor groups the following IHE actors:
Transactions
SecuritySystems SHALL support SMART Backend Services authorization for all transactions. Document Submission OptionTo accept document publication from external Document Publishers, implement the Document Submission Option. DeploymentThe Document Access Provider may be grouped with Document Publisher, in which case document publication is internal. See the grouped Document Publisher/Access Provider CapabilityStatement for this deployment pattern. |
|||||||||||||||
| EEHRxF Document Consumer CapabilityStatement |
CapabilityStatement for the EEHRxF Document Consumer actor. This composite actor consumes EEHRxF FHIR Documents by querying a Document Access Provider. Actor GroupingThis composite actor groups the following IHE actors: Transactions
SecuritySystems SHALL support SMART Backend Services authorization for all transactions. |
|||||||||||||||
| EEHRxF Document Publisher CapabilityStatement |
CapabilityStatement for the EEHRxF Document Publisher actor. This composite actor produces EEHRxF FHIR Documents and publishes them to a Document Access Provider. Actor GroupingThis composite actor groups the following IHE actors: Transactions
SecuritySystems SHALL support SMART Backend Services authorization for all transactions. DeploymentThe Document Publisher may be grouped with Document Access Provider, in which case the ITI-105 transaction becomes internal and is not exposed externally. See the grouped Document Publisher/Access Provider CapabilityStatement for this deployment pattern. |
|||||||||||||||
| EEHRxF Grouped Document Publisher/Access Provider CapabilityStatement |
CapabilityStatement for the grouped EEHRxF Document Publisher and Document Access Provider actors. This represents a deployment where document production and access provision are co-located in the same system. Deployment PatternThis CapabilityStatement applies when:
In this grouped deployment, document publication is internal to the system and not exposed externally. The external API provides only document discovery (ITI-67) and retrieval (ITI-68) capabilities. Actor GroupingThis grouped actor combines:
The underlying IHE actors are:
Note: MHD Document Recipient is not listed because publication is internal. External Transactions
SecuritySystems SHALL support SMART Backend Services authorization for all transactions. When to Use This CapabilityStatementUse this CapabilityStatement when implementing:
For systems that need to receive documents from external sources, use the Document Access Provider with Document Submission Option. |
|||||||||||||||
| EEHRxF Resource Access Provider CapabilityStatement |
CapabilityStatement for the EEHRxF Resource Access Provider actor. This actor serves clinical data resources following the International Patient Access (IPA) patterns and IHE QEDm Clinical Data Source capabilities. This CapabilityStatement defines the capabilities for systems providing direct resource access (beyond document-based exchange) in the EU EHR Exchange Format (EEHRxF) ecosystem. It inherits patterns from:
Resource Flexibility (IPA Alignment)Following IPA's approach, servers are not required to support all clinical resources listed below. Servers MAY choose which resources to implement based on their capabilities and use cases. The only required resource is Patient (for lookup context). This flexibility encourages partial implementations, allowing more servers to participate even if they only support EU Core for certain resource types. Required: Patient (for lookup context) Recommended (choose based on capabilities):
The server's CapabilityStatement declares which resources are actually supported. SecuritySystems SHALL support SMART Backend Services authorization for all transactions. Profile InheritanceResources SHOULD conform to EU Core profiles where available. |
|||||||||||||||
| EEHRxF Resource Consumer CapabilityStatement |
CapabilityStatement for the EEHRxF Resource Consumer actor. This actor queries for clinical data resources following the International Patient Access (IPA) patterns and IHE QEDm Clinical Data Consumer capabilities. This CapabilityStatement defines the requirements for systems consuming direct resource access (beyond document-based exchange) in the EU EHR Exchange Format (EEHRxF) ecosystem. It inherits patterns from:
Resource Flexibility (IPA Alignment)Following IPA's approach, clients are not required to consume all clinical resources listed below. Clients MAY choose which resources to query based on their needs and the server's declared capabilities. The only required capability is Patient lookup. This flexibility allows clients to implement targeted use cases without requiring support for all resource types. Required: Patient (for lookup context) Optional (request based on needs and server support):
Clients should check the server's CapabilityStatement to discover which resources are available. SecuritySystems SHALL support SMART Backend Services authorization for all transactions. Profile InheritanceConsumers SHOULD expect resources conforming to EU Core profiles where available. |
These define constraints on FHIR resources for systems conforming to this implementation guide.
| EEHRxF MHD DocumentReference Profile |
Profile for DocumentReference resources used in the EEHRxF context, based on the IHE MHD Minimal DocumentReference profile. Search Strategy:
See Document Exchange for query examples. |
These define constraints on FHIR data types for systems conforming to this implementation guide.
| Extension: SupportedIdentifier |
This extension indicates that a specific identifier system is supported by the server for a given resource type and parties querying for corresponding resources (i.e. Patients,…) are recommended searching for this identifier. |
These define sets of codes used by systems conforming to this implementation guide.
| EEHRxF Document Priority Category ValueSet |
ValueSet for priority document categories in EEHRxF as the document categories as defined in the EHDS regulation. See EEHRxFDocumentPriorityCategoryCS for the complete list and background. |
| EEHRxF Document Type ValueSet |
Document type codes for clinical precision in document identification. This ValueSet contains LOINC codes for specific document types used in DocumentReference.type. Unlike category (coarse search), type provides clinical precision for identifying exact document kinds. Usage Pattern:
MVP Document Types (Priority Categories):
Note: This list will expand as additional priority categories are implemented. JFM: This ValueSet should be made up of other ValueSets, with each of them assigned to one of the priority categories. Thus it is clear what document types are within each category. Is this the place to find all of them? https://confluence.hl7.org/spaces/HEU/pages/358255737/Implementation+Guides |
These define new code systems used by systems conforming to this implementation guide.
| EEHRxF Document Priority Category CodeSystem |
CodeSystem for priority document categories in EEHRxF as the document categories as defined in the EHDS regulation. The codes defined here are directly linked to the Priority Categories defined in the EHDS regulation. The meaning of these codes is directly linked to the meaning given to the concepts in the EHDS regulation. 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. 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). EHDS empowers the EU Commission to make changes to the list of priority categories at any point in time by means of a Delegated Act (Article 14(2)). There will be a minimum 1-year lead time between the decision to add a new priority category and the initial date when support ahs to be implemented. The definitions of the priority categories comes from ANNEX I of the EHDS Regulation. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| Example - European Patient Summary DocumentReference |
Example DocumentReference showing an EPS document with EEHRxF category coding. This example demonstrates the recommended search strategy:
Example query to find this document: |