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

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.


Issue 1: Document Search and Priority Category Differentiation

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

  1. 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?

  2. 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?

  3. 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

  • Does the category/type/practiceSetting approach align with implementer expectations?
  • What search patterns do Member States currently use for document discovery?
  • Should we create a priority-category-specific value set, or rely on existing XDS/LOINC codes?

Issue 2: Patient Lookup Strategy

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:

  1. [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.

  2. [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

  • Should CapabilityStatement advertise which national ID systems are supported for lookup?
  • We should inherit Patient from EU Core. Does this change anything about the transaction definitions?

Seeking Input On

  • Does the two-option approach (ITI-78 with identifier required + ITI-119 $match) cover European use cases?
  • Are there scenarios where identifier-based lookup is insufficient and $match is not appropriate?

Issue 3: MHD Publication Transaction Options

GitHub Issue Status: Resolved

Resolution:

Document publication uses ITI-105 Simplified Publish as the baseline.

Key decisions:

  1. ITI-105 is the supported publication mechanism (simpler, server handles complexity)
  2. Publication is NOT part of base Document Access Provider requirements
  3. Document Submission Option is available for Access Providers that accept external publication
  4. When Document Publisher and Document Access Provider are grouped, publication is internal

This approach:

  • Reduces optionality (single publication transaction)
  • Avoids XDS SubmissionSet constructs
  • Aligns with FHIR-native servers
  • Moves complexity from client to server

See Actors - Document Submission Option for conformance guidance.


Issue 4: Resource Access and Inheritance

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

  • Data Models: Inherit from EU Core profiles
  • Search Parameters: From IPA (required parameters listed in Resource Access)
  • CapabilityStatements: Instantiate IPA Server/Client
  • QEDm: Referenced where compatible with IPA. QEDm has a stated goal of aligning with IPA.

A separate issue (Issue 9) tracks validation of the core resource set.

Seeking Input On

  • Do the implemented IPA search parameters work for Europe's needs?
  • What are the differences compared to QEDm, and how should those be handled?

Issue 5: CapabilityStatement and Priority Category Declaration

GitHub Issue Priority: Medium

Should servers declare which EHDS Priority Categories they support? How? Should this be in CapabilityStatement?

Options

  1. CapabilityStatement.instantiates - Reference priority-category-specific CapabilityStatements (these would be example instances)
  2. CapabilityStatement extensions - Custom extensions declaring supported categories
  3. Supported document type ValueSets - Declare via supported DocumentReference.type bindings

Seeking Input On

  • Is priority category declaration needed at the CapabilityStatement level?
  • Which approach best balances expressiveness with implementation simplicity?

Issue 6: Authorization Server Deployment

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:

  1. IUA Resource Server is always required for Access Providers
  2. IUA Authorization Server is required only when authorization is handled internally
  3. When AS is external, the Resource Server is responsible for:
    • Enabling discovery via .well-known/smart-configuration pointing to the external AS
    • Validating tokens (local validation or introspection via IHE IUA ITI-102)

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


Issue 7: R4/R5 Harmonization

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

  • How should we handle R5 dependencies in an R4 IG?

Issue 8: Imaging Manifest Coding

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 classification
  • format = MADO-defined formatCode for specific manifest identification
  • content.attachment.contentType for technical format

Imaging 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.


Issue 9: Core Resource Set Validation

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
  • Practitioner
  • Organization

Patient Summary

  • Condition
  • AllergyIntolerance
  • MedicationRequest
  • MedicationStatement
  • Immunization

ePrescription/eDispensation

  • MedicationRequest
  • MedicationDispense

Medical Test Results

  • Observation
  • DiagnosticReport

Imaging Results

  • DiagnosticReport
  • ImagingStudy (note: R5 resource, linked to Issue 7

Discharge Reports

  • Encounter

Seeking Input On

  • Is this resource set appropriate for the priority categories?
  • Are any resources missing that should be included?
  • Should Encounter be required?

Issue 10: FHIR Documents vs Resources Guidance

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

  • What use cases require document exchange vs resource access in your context?
  • Would you be interested in contributing this documentation?

Issue 11: MPD Workflow vs MedicationRequest Resource Access

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

  • Is this distinction clear in the current IG?
  • Are there medication-related use cases that fall between these two categories?
  • Should we handle it differently?