EU Health Data API
1.0.0-ballot - ballot 150

EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot 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

CapabilityStatement: EEHRxF Document Publisher CapabilityStatement

Official URL: http://hl7.eu/fhir/health-data-api/CapabilityStatement/document-publisher-eu-api Version: 1.0.0-ballot
Active as of 2026-01-26 Computable Name: DocumentPublisherEuApi

Copyright/Legal: Copyright HL7 Europe. Licensed under Creative Commons public domain (CC0 1.0).

Requirements for an EEHRxF Document Publisher that submits FHIR Documents to a Document Access Provider.

This CapabilityStatement defines the requirements for the EEHRxF Document Publisher actor. The actor produces EEHRxF FHIR Documents and publishes them to a Document Access Provider.

Actor Grouping

This composite actor groups the following roles:

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

This requirements CapabilityStatement supports the IUA or SMART client role selected by the environment and use case. A deployment instance advertises only its selected protocol; see Authorization.

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.

Raw OpenAPI-Swagger Definition file | Download

Language: en

EEHRxF Document Publisher CapabilityStatement

  • Implementation Guide Version: 1.0.0-ballot
  • FHIR Version: 4.0.1
  • Supported Formats: json, xml
  • Published on: 2026-01-26
  • Published by: HL7 Europe

Note to Implementers: FHIR Capabilities

Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

FHIR RESTful Capabilities

Mode: client

The Document Publisher actor initiates transactions to publish documents and query for patient context. It groups with the selected IUA Authorization Client, SMART App, or SMART Backend Service role. The Authorization Server is a separate participant.

Security

This abstract requirements statement does not advertise a fixed security service. A concrete deployment SHALL declare exactly one security-service coding from the EU Health Data API Authorization Security Service ValueSet, selected for its environment. It SHALL NOT advertise both services unless a future profile defines dual conformance.

IHE IUA

The publisher groups with the IUA Authorization Client. ITI-105 and PDQm ITI-78 have no IUA MHD transaction scope; the deployment applies the IUA authorization policy defined for its environment.

SMART Backend Services

For a pre-authorized system-to-system use case, the publisher groups with the SMART Backend Service, uses client_credentials and private_key_jwt, and requests:

  • system/DocumentReference.c (create DocumentReference - ITI-105)
  • system/Patient.rs (read + search Patient - ITI-78)

Interactive SMART

Where an interactive use case applies, the publisher groups with the SMART App, uses authorization code with PKCE, and replaces the system/ prefix above with the applicable patient/ or user/ scope prefix.

All modes use TLS 1.2 or higher. See Authorization for the selected capability set, discovery, token, and scope rules.

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCSearches_include_revincludeOperations
DocumentReferenceSupported Profiles
  MHD DocumentReference for Simplified Publish
  MHD DocumentReference Minimal		Y
PatientSupported Profiles
  Patient (EU core)		YYidentifier, _id, active, family, given, telecom, birthdate, address, address-city, address-country, address-postalcode, address-state, gender
Core FHIR Resource
DocumentReference
Reference Policy
Interaction summary
  • SHALL support
    create

    Create DocumentReference with embedded document (ITI-105 Simplified Publish)

Supported Profiles

MHD DocumentReference for Simplified Publish
MHD DocumentReference Minimal

Documentation

DocumentReference resources are submitted via ITI-105 Simplified Publish with embedded document content in the attachment to publish documents to the Document Access Provider. The SimplifiedPublish profile requires content.attachment.data to be populated.

Core FHIR Resource
Patient
Reference Policy
Interaction summary
  • SHALL support
    read

    Read Patient by logical ID

    search-type

    Search for patients (PDQm ITI-78)

Supported Profiles

Patient (EU core)

Documentation

Patient resources are queried using PDQm [ITI-78] to establish patient context before submitting documents. The identifier search parameter is required.

Search Parameters
ConformanceParameterTypeDocumentation
SHALLidentifiertoken

Patient identifier (e.g., national ID, MRN) - required for patient lookup

SHOULD_idtoken

Patient logical ID

SHOULDactivetoken

Whether the patient record is active

SHOULDfamilystring

Patient family name

SHOULDgivenstring

Patient given name

SHOULDtelecomtoken

Telecom details of the patient

SHOULDbirthdatedate

Patient date of birth

SHOULDaddressstring

A server defined search that may match any of the string fields in the Address, including line, city, district, state, country, postalCode, and/or text

SHOULDaddress-citystring

A city specified in an address

SHOULDaddress-countrystring

A country specified in an address

SHOULDaddress-postalcodestring

A postal code specified in an address

SHOULDaddress-statestring

A state specified in an address

SHOULDgendertoken

Administrative gender of the patient