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
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.
We welcome your input via Github Issues, or by attending the weekly HL7 Europe API Workgroup Meetings.
| GitHub Issue | Priority: High |
How do we differentiate documents by EHDS Priority Category? Patient Summary, Imaging Results, Medical Test Results, and Hospital Discharge Reports are all FHIR Documents exposed via DocumentReference and MHD. How do we differentiate one from the other for systems that support multiple categories?
This is particularly complex for Medical Test Results and Imaging Results, which are families of many different types (cardiology studies, radiology reports, various lab panels, etc.).
Current Approach
| Parameter | Purpose | Coding System |
|---|---|---|
category |
Coarse search | EHDS Document Priority Category CodeSystem |
type |
Clinical precision | LOINC codes |
practiceSetting |
Differentiate within category | Healthcare setting codes |
Open Questions
Value Sets: Should we define local value sets for category/type, or inherit directly from IHE class codes and LOINC? What benefit does local definition provide?
Priority Category Alignment: Current LOINC codes may be one step too specific for some categories (e.g., labs have many sub-types). How should we handle this terminology gap?
DocumentReference Profiles: Should there be one shared DocumentReference profile for all priority categories, or separate profiles per priority area? (Recommendation: one shared profile with example instances)
Seeking Input On
| GitHub Issue | Priority: High |
How should patient lookup work in the European context? In most EU situations, we expect patient identifiers (MRN, national ID) to be available. Demographic-based matching is needed when identifiers are not available.
Current Approach
The IG inherits directly from IHE PDQm with two transaction options:
[ITI-78] Mobile Patient Demographics Query (Required) - Patient search with identifier as a required parameter. This constrains the standard PDQm transaction to require identifier-based lookup, covering the majority of EU use cases.
[ITI-119] Patient Demographics Match (Optional) - FHIR $match operation for fuzzy demographic matching when identifier is not available.
This simplification removes the middle option of full demographics-based search (family + given + birthdate), which is not suitable for safe clinical patient matching.
Open Questions
Seeking Input On
| GitHub Issue | Status: Resolved |
Resolution:
Document publication uses ITI-105 Simplified Publish as the baseline.
Key decisions:
This approach:
See Actors - Document Submission Option for conformance guidance.
| GitHub Issue | Priority: Medium |
Resource access (granular RESTful FHIR resource queries) could inherit from multiple specifications (IPA, QEDm). This issue tracks the inheritance approach.
Current Approach
A separate issue (Issue 9) tracks validation of the core resource set.
Seeking Input On
| GitHub Issue | Priority: Medium |
Should servers declare which EHDS Priority Categories they support? How? Should this be in CapabilityStatement?
Options
Seeking Input On
| GitHub Issue | Status: Resolved |
Resolution:
The Authorization Server may be deployed internally (bundled with the EHR) or externally (at hospital, regional, or national level).
Key decisions:
.well-known/smart-configuration pointing to the external ASThe D5.1 requirement api-provider-authProvideToken applies only to EHR systems with internal Authorization Servers. This IG does not impose requirements on external authorization infrastructure.
See Authorization Server Deployment for full details.
| GitHub Issue | Priority: Medium |
This IG targets FHIR R4, but some European specifications are R5-based. The EU Extensions package is R5, creating warnings in the R4 build. The HL7 Europe Imaging Study Manifest is also R5-based.
Seeking Input On
| GitHub Issue | Priority: Medium | Status: Resolved |
Imaging manifests (DICOM study references) are differentiated from other documents using formatCode + mimeType coding.
Resolution
The agreed approach uses:
category = Medical-Imaging (EHDS Priority Category) for coarse classificationformat = MADO-defined formatCode for specific manifest identificationcontent.attachment.contentType for technical formatImaging manifests cannot be reliably identified by category alone (Medical-Imaging includes both reports and manifests). The formatCode provides the needed specificity. See Imaging Manifest for full details.
| GitHub Issue | Priority: Medium |
The following resources are proposed as the core set for resource access (e.g. resource search entry points specifically, not all included resources). This needs validation from Priority Category owners.
Shared
Patient Summary
ePrescription/eDispensation
Medical Test Results
Imaging Results
Discharge Reports
Seeking Input On
| GitHub Issue | Priority: Low |
The IG supports both document exchange (FHIR Documents via MHD) and resource access (granular FHIR resources). A documentation page explaining when to use each pattern would be helpful.
Seeking Input On
| GitHub Issue | Priority: Medium |
The IG needs to clearly distinguish between medication resource access (in scope) and prescription workflow orchestration (out of scope, handled by MPD). Also this scope line should be reviewed with MPD Priority Category owners.
In Scope (This IG)
Resource access queries like "which medications is this patient taking?" - reading MedicationRequest, MedicationStatement, and MedicationDispense resources.
Out of Scope (MPD)
Prescription workflow orchestration like "transfer prescription authorization for dispense" - the workflow transactions for ePrescription and eDispensation are handled by IHE MPD
Seeking Input On