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

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Requirements: Actor Definitions

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.

Behavior: Capability Statements

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:

  • SHALL also implement the base Document Access Provider capabilities
  • SHALL accept ITI-105 transactions from authorized Document Publishers
  • SHALL make received documents available via ITI-67 and ITI-68
  • SHALL validate documents against EEHRxF content profiles

This option is REQUIRED when acting as a delegated access provider for external Document Publishers (e.g., integration engines, national infrastructure).

Actor Grouping

Adds to base Document Access Provider:

Transaction

Transaction Description Optionality
ITI-105 Simplified Publish Accept document publication from Document Publishers R

Security

Systems 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 Grouping

This composite actor groups the following IHE actors:

Transactions

Transaction Description Optionality
ITI-67 Find Document References Respond to document metadata queries from Document Consumers R
ITI-68 Retrieve Document Serve document content to Document Consumers R
ITI-78 Patient Demographics Query Respond to patient demographics queries R
Get Access Token Issue authorization tokens to clients R

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Document Submission Option

To accept document publication from external Document Publishers, implement the Document Submission Option.

Deployment

The 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 Grouping

This composite actor groups the following IHE actors:

Transactions

Transaction Description Optionality
ITI-67 Find Document References Query for document metadata from Document Access Provider R
ITI-68 Retrieve Document Retrieve document content from Document Access Provider R
ITI-78 Patient Demographics Query Query for patient demographics to establish patient context R
Get Access Token Obtain authorization token for API access R

Security

Systems 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 Grouping

This composite actor groups the following IHE actors:

Transactions

Transaction Description Optionality
ITI-105 Simplified Publish Submit document with embedded content to a Document Access Provider R
ITI-78 Patient Demographics Query Query for patient demographics to establish patient context R
Get Access Token Obtain authorization token for API access R

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Deployment

The 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 Pattern

This CapabilityStatement applies when:

  • An EHR system both produces documents AND provides access to them
  • Document publication is handled internally
  • External clients only need to query and retrieve documents

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 Grouping

This grouped actor combines:

  • Document Publisher (internal) - Produces and stores documents internally
  • Document Access Provider (external-facing) - Serves documents to Document Consumers

The underlying IHE actors are:

Note: MHD Document Recipient is not listed because publication is internal.

External Transactions

Transaction Description Optionality
ITI-67 Find Document References Respond to document metadata queries from Document Consumers R
ITI-68 Retrieve Document Serve document content to Document Consumers R
ITI-78 Patient Demographics Query Respond to patient demographics queries R
Get Access Token Issue authorization tokens to clients R

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

When to Use This CapabilityStatement

Use this CapabilityStatement when implementing:

  • Hospital EHR systems that produce and serve their own documents
  • Regional health information exchanges with integrated document repositories
  • Any system where document creation and access are tightly coupled

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:

  • IPA (International Patient Access): Resource profiles and search parameter patterns
  • IHE QEDm (Query for Existing Data for Mobile): Clinical Data Source actor capabilities

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):

  • Practitioner, Organization: Reference resolution
  • Condition, AllergyIntolerance: Patient safety data
  • Observation, DiagnosticReport: Clinical results
  • MedicationRequest, MedicationDispense: Medication data
  • Encounter: Visit context

The server's CapabilityStatement declares which resources are actually supported.

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Profile Inheritance

Resources 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:

  • IPA (International Patient Access): Resource profiles and search parameter patterns
  • IHE QEDm (Query for Existing Data for Mobile): Clinical Data Consumer actor capabilities

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):

  • Practitioner, Organization: Reference resolution
  • Condition, AllergyIntolerance: Patient safety data
  • Observation, DiagnosticReport: Clinical results
  • MedicationRequest, MedicationDispense: Medication data
  • Encounter: Visit context

Clients should check the server's CapabilityStatement to discover which resources are available.

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Profile Inheritance

Consumers SHOULD expect resources conforming to EU Core profiles where available.

Structures: Resource Profiles

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:

  • category: Use ValueSet EEHRxF Document Priority Category ValueSet (EHDS Priority Categories) for coarse document filtering (Patient Summaries, Discharge Reports, etc.)
  • type: Use EEHRxFDocumentTypeVS (LOINC) for clinical precision (specific document types)
  • context.practiceSetting: SHOULD be used to differentiate lab vs imaging reports when category=REPORTS

See Document Exchange for query examples.

Structures: Extension Definitions

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.

Terminology: Value Sets

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:

  • type is primarily used for client-side filtering after a broad category search
  • type MAY be used as a search parameter when the specific document type is known
  • Multiple type codes may apply to a single document (e.g., a discharge summary that is also a patient summary)

MVP Document Types (Priority Categories):

  • Patient Summary (IPS)
  • Discharge Summary (HDR)
  • Laboratory Report
  • Diagnostic Imaging Report

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

Terminology: Code Systems

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.

Example: Example Instances

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:

  • category = Patient-Summaries (EHDS priority category for coarse filtering)
  • type = 60591-5 (LOINC code for clinical precision)

Example query to find this document:

GET [base]/DocumentReference?patient=Patient/example-patient&category=https://euridice.ec.europa.eu/fhir/eehrxf/CodeSystem/eehrxf-document-priority-category-cs|Patient-Summaries