EU Health Data API
1.0.0-ballot - ballot 150

This page is part of the EU Health Data API (v1.0.0-ballot: STU1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Medical Imaging Manifest

This section defines the API requirements for EHR systems that provide imaging study manifests (references to DICOM imaging studies).

For detailed content profiles, see the EU Imaging Study Manifest IG.

Actors

Imaging Manifests can be accessed via document exchange.

Actor Description CapabilityStatement
Document Consumer Retrieves imaging manifests EEHRxF Document Consumer
Document Access Provider Serves imaging manifests EEHRxF Document Access Provider

Document Exchange

For document-based access, use the Document Exchange transactions.

The Imaging Manifest is differentiated via the following DocumentReference fields:

Dual-DocumentReference Pattern (MADO)

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:

DocumentReference contentType type (LOINC) Content
FHIR Manifest application/fhir+json 18748-4 FHIR ImagingStudy manifest
DICOM KOS application/dicom 18748-4 DICOM Key Object Selection

The two DocumentReferences are linked using relatesTo.code = transforms — each is a different technical representation of the same imaging study manifest. Document Consumers query by type and select the representation they can consume based on contentType.

This pattern was chosen (#50) because it works across all Document Sharing transports (MHD, XDS, XCA) without requiring content negotiation at the server.

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.

An alternative approach — a single DocumentReference with multiple content entries — has been discussed in the working group.

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.

See Example: Imaging Study Manifest — FHIR and Example: Imaging Study Manifest — DICOM KOS for instances showing the dual pattern.

Example Queries

Search for all imaging manifests (both representations):

GET [base]/DocumentReference?patient.identifier=http://example.org/national-id|123456789&type=http://loinc.org|18748-4&status=current

Search for imaging reports:

GET [base]/DocumentReference?patient.identifier=http://example.org/national-id|123456789&type=http://loinc.org|85430-7&status=current

Note: Both imaging reports and imaging manifests use the Medical-Imaging priority category. Use type to distinguish them: 85430-7 for reports, 18748-4 for manifests.

IHE MADO

DICOM image access is in scope for EHDS and is covered by the EURIDICE MADO profile. The imaging manifest (discovered via MHD) describes which studies and series are available; the actual image retrieval uses IHE RAD transactions (WADO-RS, etc.) defined within MADO and outside the scope of this IG.