The Document Access Provider actor provides access to EEHRxF FHIR Documents by receiving documents from Document Producers and serving them to Document Consumers. This composite actor groups MHD Document Recipient, MHD Document Responder, PDQm Patient Demographics Supplier, and IUA Authorization Server/Resource Server.

See Document Access Provider CapabilityStatement for technical requirements.

The Document Consumer actor consumes EEHRxF FHIR Documents by querying a Document Access Provider. This composite actor groups MHD Document Consumer, PDQm Patient Demographics Consumer, and IUA Authorization Client.

See Document Consumer CapabilityStatement for technical requirements.

The Document Producer actor produces EEHRxF FHIR Documents and publishes them to a Document Access Provider. This composite actor groups MHD Document Source, PDQm Patient Demographics Consumer, and IUA Authorization Client.

See Document Producer CapabilityStatement for technical requirements.

The grouped Document Producer/Access Provider actor represents a deployment where document production and access provision are co-located in the same system. In this configuration, document submission (ITI-65) is internal and only document query/retrieval (ITI-67, ITI-68) is exposed externally.

This is common for hospital EHR systems that produce and serve their own documents.

See Grouped Document Producer/Access Provider CapabilityStatement for technical requirements.

The Resource Access Provider actor provides access to FHIR resources following IPA and QEDm patterns. This enables direct resource access complementing document-based exchange. This composite actor groups QEDm Clinical Data Source, IPA Server, PDQm Patient Demographics Supplier, and IUA Authorization Server/Resource Server.

See Resource Access Provider CapabilityStatement for technical requirements.

The Resource Consumer actor queries for clinical data resources from a Resource Access Provider following IPA and QEDm patterns. This composite actor groups QEDm Clinical Data Consumer, IPA Client, PDQm Patient Demographics Consumer, and IUA Authorization Client.

See Resource Consumer CapabilityStatement for technical requirements.

CapabilityStatement for the EEHRxF Document Access Provider actor. This composite actor provides access to EEHRxF FHIR Documents by receiving documents from Document Producers and serving them to Document Consumers.

Actor Grouping

This composite actor groups the following IHE actors:

• IUA Authorization Server
• IUA Resource Server
• PDQm Patient Demographics Supplier
• MHD Document Recipient
• MHD Document Responder

Transactions

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Deployment

The Document Access Provider may be grouped with Document Producer, in which case the ITI-65 transaction becomes internal. See the grouped Document Producer/Access Provider CapabilityStatement for this deployment pattern.

CapabilityStatement for the EEHRxF Document Consumer actor. This composite actor consumes EEHRxF FHIR Documents by querying a Document Access Provider.

Actor Grouping

This composite actor groups the following IHE actors:

• IUA Authorization Client
• PDQm Patient Demographics Consumer
• MHD Document Consumer

Transactions

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

CapabilityStatement for the EEHRxF Document Producer actor. This composite actor produces EEHRxF FHIR Documents and publishes them to a Document Access Provider.

Actor Grouping

This composite actor groups the following IHE actors:

• IUA Authorization Client
• PDQm Patient Demographics Consumer
• MHD Document Source

Transactions

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Deployment

The Document Producer may be grouped with Document Access Provider, in which case the ITI-65 transaction becomes internal and is not exposed externally. See the grouped Document Producer/Access Provider CapabilityStatement for this deployment pattern.

CapabilityStatement for the grouped EEHRxF Document Producer and Document Access Provider actors. This represents a deployment where document production and access provision are co-located in the same system.

Deployment Pattern

This CapabilityStatement applies when:

• An EHR system both produces documents AND provides access to them
• Document submission (ITI-65) is handled internally
• External clients only need to query and retrieve documents

In this grouped deployment, the ITI-65 Provide Document Bundle transaction is internal to the system and not exposed externally. The external API provides only document discovery (ITI-67) and retrieval (ITI-68) capabilities.

Actor Grouping

This grouped actor combines:

• Document Producer (internal) - Produces and stores documents internally
• Document Access Provider (external-facing) - Serves documents to Document Consumers

The underlying IHE actors are:

• IUA Authorization Server
• IUA Resource Server
• PDQm Patient Demographics Supplier
• MHD Document Responder

Note: MHD Document Recipient is not listed because ITI-65 is internal.

External Transactions

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

When to Use This CapabilityStatement

Use this CapabilityStatement when implementing:

• Hospital EHR systems that produce and serve their own documents
• Regional health information exchanges with integrated document repositories
• Any system where document creation and access are tightly coupled

For systems that need to receive documents from external sources, use the separate Document Access Provider CapabilityStatement which includes ITI-65 support.

CapabilityStatement for the EEHRxF Resource Access Provider actor. This actor serves clinical data resources following the International Patient Access (IPA) patterns and IHE QEDm Clinical Data Source capabilities.

This CapabilityStatement defines the capabilities for systems providing direct resource access (beyond document-based exchange) in the EU EHR Exchange Format (EEHRxF) ecosystem. It inherits patterns from:

• IPA (International Patient Access): Resource profiles and search parameter patterns
• IHE QEDm (Query for Existing Data for Mobile): Clinical Data Source actor capabilities

Supported Resources

• Patient: Lookup only (search by identifier, read by ID)
• Practitioner: Read access for clinical context
• Organization: Read access for organizational context
• Condition: Problems and diagnoses
• AllergyIntolerance: Allergy and intolerance records
• Observation: Clinical observations (vital signs, lab results, etc.)
• DiagnosticReport: Laboratory and imaging reports
• MedicationRequest: Medication orders and prescriptions
• MedicationDispense: Medication dispensing records
• Encounter: Patient encounters

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Profile Inheritance

Resources SHOULD conform to EU Core profiles where available.

CapabilityStatement for the EEHRxF Resource Consumer actor. This actor queries for clinical data resources following the International Patient Access (IPA) patterns and IHE QEDm Clinical Data Consumer capabilities.

This CapabilityStatement defines the requirements for systems consuming direct resource access (beyond document-based exchange) in the EU EHR Exchange Format (EEHRxF) ecosystem. It inherits patterns from:

• IPA (International Patient Access): Resource profiles and search parameter patterns
• IHE QEDm (Query for Existing Data for Mobile): Clinical Data Consumer actor capabilities

Supported Resources

• Patient: Lookup only (search by identifier, read by ID)
• Practitioner: Read access for clinical context
• Organization: Read access for organizational context
• Condition: Problems and diagnoses
• AllergyIntolerance: Allergy and intolerance records
• Observation: Clinical observations (vital signs, lab results, etc.)
• DiagnosticReport: Laboratory and imaging reports
• MedicationRequest: Medication orders and prescriptions
• MedicationDispense: Medication dispensing records
• Encounter: Patient encounters

Security

Systems SHALL support SMART Backend Services authorization for all transactions.

Profile Inheritance

Consumers SHOULD expect resources conforming to EU Core profiles where available.

Profile for DocumentReference resources used in the EEHRxF context, based on the IHE MHD Minimal DocumentReference profile.

Search Strategy:

• category: Use ValueSet EEHRxF Document Priority Category ValueSet (EHDS Priority Categories) for coarse document filtering (Patient Summaries, Discharge Reports, etc.)
• type: Use EEHRxFDocumentTypeVS (LOINC) for clinical precision (specific document types)
• context.practiceSetting: SHOULD be used to differentiate lab vs imaging reports when category=REPORTS

See Document Exchange for query examples.

This extension indicates that a specific identifier system is supported by the server for a given resource type and parties querying for corresponding resources (i.e. Patients,…) are recommended searching for this identifier.

ValueSet for priority document categories in EEHRxF as the document categories as defined in the EHDS regulation. See EEHRxFDocumentPriorityCategoryCS for the complete list and background.

Document type codes for clinical precision in document identification.

This ValueSet contains LOINC codes for specific document types used in DocumentReference.type. Unlike category (coarse search), type provides clinical precision for identifying exact document kinds.

Usage Pattern:

• type is primarily used for client-side filtering after a broad category search
• type MAY be used as a search parameter when the specific document type is known
• Multiple type codes may apply to a single document (e.g., a discharge summary that is also a patient summary)

MVP Document Types (Priority Categories):

• Patient Summary (IPS)
• Discharge Summary (HDR)
• Laboratory Report
• Diagnostic Imaging Report

Note: This list will expand as additional priority categories are implemented.

JFM: This ValueSet should be made up of other ValueSets, with each of them assigned to one of the priority categories. Thus it is clear what document types are within each category. Is this the place to find all of them? https://confluence.hl7.org/spaces/HEU/pages/358255737/Implementation+Guides

CodeSystem for priority document categories in EEHRxF as the document categories as defined in the EHDS regulation.

The codes defined here are directly linked to the Priority Categories defined in the EHDS regulation. The meaning of these codes is directly linked to the meaning given to the concepts in the EHDS regulation.

The EHDS Regulation initially defines six priority categories of electronic health data that all Member States must support first for cross-border primary use. These categories are explicitly listed in Article 14 of Regulation (EU) 2025/327.

Article 105 specifies the date when support for these priority categories is required: 26 March 2029 for categories (a), (b) and (c); 28 March 2031 for (d), (e) and (f).

EHDS empowers the EU Commission to make changes to the list of priority categories at any point in time by means of a Delegated Act (Article 14(2)). There will be a minimum 1-year lead time between the decision to add a new priority category and the initial date when support ahs to be implemented.

The definitions of the priority categories comes from ANNEX I of the EHDS Regulation.