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

Document Exchange

Overview

Document exchange using IHE MHD (Mobile Health Documents) transactions. This IG inherits MHD transactions as-is, with constraints specific to EEHRxF content.

Actors and Transactions

This IG defines three document exchange actors. See Actors for detailed actor groupings.

Document Consumption

The primary workflow is query and retrieve: Document Consumers find documents via ITI-67, then retrieve content via ITI-68.

Sequence Diagram

sequenceDiagram
    participant Consumer as Document Consumer
    participant Provider as Document Access Provider

    rect rgb(240, 248, 255)
    Note over Consumer,Provider: Find Document References (ITI-67)
    Consumer->>Provider: GET /DocumentReference?patient=...&type=...
    Provider-->>Consumer: Bundle of DocumentReferences
    end

    rect rgb(240, 255, 240)
    Note over Consumer,Provider: Retrieve Document (ITI-68)
    Consumer->>Provider: GET [attachment.url from DocumentReference]
    Provider-->>Consumer: FHIR Document Bundle
    end

    alt Imaging Manifest (DICOM KOS)
    Note over Consumer,Provider: See IHE MADO / Imaging Manifest
    Consumer->>Provider: GET [attachment.url from KOS DocumentReference]
    Provider-->>Consumer: DICOM KOS
    end

Document Content

ITI-68 retrieves the document from the URL in DocumentReference.content.attachment.url. Consumers identify the content using two DocumentReference elements:

• type (LOINC code) — identifies the clinical document type and which content IG applies.
• attachment.contentType — identifies the technical format.

Together, these tell the consumer what the retrieved document contains.

Servers SHALL return content conforming to FHIR Document content profiles as a native FHIR Document Bundle, not wrapped in Binary. For DICOM KOS imaging manifests (IHE MADO), standard MHD behavior applies.

attachment.url is an opaque retrieval URL — its format is unconstrained. Servers host content at any endpoint they choose. The examples above (/Bundle/[id], /Binary/[id]) illustrate common patterns, not requirements.

Human-readable representations (e.g. PDF narrative) are part of the FHIR Document as defined by the relevant content IG — not exposed at metadata level as separate DocumentReferences.

Document Search Strategy

IHE Document Sharing distinguishes type (specific document types, typically LOINC codes) from category (broad classification) on DocumentReference. This IG constrains type for document discovery but leaves category to content IGs and implementations.

EHDS Priority Categories and Type Codes

Article 14 of the EHDS regulation defines six priority categories of electronic health data. EEHRxFDocumentPriorityCategoryCS provides informative codes for these categories, organizing them by the LOINC type codes consumers use for document search.

Each priority category has a ValueSet of known LOINC type codes:

• Patient-Summaries → EEHRxFDocumentTypePatientSummaryVS
• Discharge-Reports → EEHRxFDocumentTypeDischargeReportVS
• Laboratory-Reports → EEHRxFDocumentTypeLaboratoryReportVS
• Medical-Imaging → EEHRxFDocumentTypeMedicalImagingVS Electronic-Prescriptions and Electronic-Dispensations fall outside the document exchange model and have no type codes.

EEHRxFDocumentTypeVS aggregates all per-category type codes into a single ValueSet bound to DocumentReference.type. A ConceptMap provides the same mapping in machine-readable form.

Search Examples

Search by type (LOINC) for the most accurate results. To find the relevant type codes for a priority category, consult the per-category ValueSet or the ConceptMap. When multiple type codes apply, include all of them.

These examples assume the consumer has resolved the patient to a FHIR reference (e.g., Patient/123) via Patient Matching. Alternatively, use chained identifier search (e.g., patient.identifier=[system]|[value]).

Patient Summary

By type (LOINC):

GET [base]/DocumentReference?patient=Patient/123&type=http://loinc.org|60591-5&status=current

Medical Test Results (Laboratory)

By type (LOINC):

GET [base]/DocumentReference?patient=Patient/123&type=http://loinc.org|11502-2&status=current

Imaging Reports and Manifests

By type (LOINC — imaging reports):

GET [base]/DocumentReference?patient=Patient/123&type=http://loinc.org|85430-7&status=current

By type (LOINC — imaging study manifests):

GET [base]/DocumentReference?patient=Patient/123&type=http://loinc.org|18748-4&status=current

Imaging manifests may use the dual-DocumentReference pattern: two DocumentReferences (FHIR and DICOM KOS) linked via relatesTo.transforms. Consumers select the representation they support based on contentType.

Hospital Discharge Reports

By type (LOINC):

GET [base]/DocumentReference?patient=Patient/123&type=http://loinc.org|18842-5,http://loinc.org|100719-4&status=current

Document Publication

When Document Publisher and Document Access Provider are separate systems, the Publisher submits documents using ITI-105 Simplified Publish per the MHD Simplified Publish Option. When they are grouped (co-located), publication is internal.

Document Submission Option

The Document Access Provider MAY support receiving documents from external Publishers by implementing the MHD Simplified Publish Option. This is the Document Submission Option.

Systems implementing this option declare it via EEHRxF-DocumentAccessProvider-SubmissionOption. See Actors - Document Submission Option for actor groupings.

ITI-105 Simplified Publish

POST [base]/DocumentReference
Content-Type: application/fhir+json

{
  "resourceType": "DocumentReference",
  "status": "current",
  "type": { ... },
  "subject": { "reference": "Patient/123" },
  "content": [{
    "attachment": {
      "contentType": "application/fhir+json",
      "data": "[base64-encoded document]"
    }
  }]
}

The server validates, extracts, and persists the document, returning the created DocumentReference with server-assigned IDs. See IHE MHD ITI-105 for details.

Document content: Per MHD ITI-105, the server extracts the document from attachment.data and persists it so that consumers can retrieve it via attachment.url. This IG requires that servers SHALL return FHIR Documents as native FHIR Document Bundles — not wrapped in Binary. The attachment.url format is unconstrained; servers host documents at any endpoint they choose.

Other Publication Transactions

This IG specifies ITI-105 as the publication mechanism for Document Publishers that submit to external Access Providers. ITI-105 gives publishers a single publication pattern for content conforming to EHDS priority category content profiles. The Document Access Provider handles persistence on ingest, so consumers retrieve documents in their native format via ITI-67/ITI-68.

Member states or local deployments MAY additionally support:

• ITI-65 Provide Document Bundle: For XDS-centric ecosystems requiring explicit SubmissionSet metadata or multi-document submission.
• ITI-106 Generate Metadata: For structured document publishers wanting server-generated DocumentReference.

These are not required for conformance to the actors within the scope of this implementation guide.

Patient Identity in Document Publication

This specification does not require a patient lookup step before publication — how the publisher obtains the patient identifier is up to the implementer. Per MHD ITI-105 §Patient Identity:

A Patient Reference to a commonly accessible server may be obtained through use of PDQm, PIXm, PMIR, or by some other means. A commonly accessible logical reference using Patient Identifier, instead of a literal reference, may be acceptable where there is a common Identifier, such as a national individual identifier.

References

• IHE MHD Specification
• IHE Document Sharing
• Actors and Transactions