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

Actors and Transactions

The actor model defined here is an orchestration of existing IHE actors and specifications, combined together into high-level composite actors. Actors and transactions are inherited from dependent IHE profiles, and those actors are stacked, constrained and potentially modified.

This is similar to the approach taken in the MHDS specification, but with a more narrow subset of specifications fit to the European situation.

Relevant Specifications:

• Authorization
  • HL7 SMART Backend Services - Defines authorization in FHIR. We use the SMART Backend Services profile for system-system authorization, and FHIR scopes.
  • IHE IUA - Defines authorization and access control actors and mechanisms. We use the actors and transactions model.
• Patient Identity Matching
  • IHE PDQm - Defines how a client can perform patient lookup given demographics against a server.
• Document Exchange
  • IHE MHD - Defines exchange of Documents, which we use to exchange FHIR document content.
• Resource Exchange
  • HL7 International Patient Access (IPA) - Defines how an application can access FHIR information using SMART authorization and resource access. IPA is the primary reference for resource access patterns.
  • IHE QEDm - Defines how a client can query for existing FHIR resources from a FHIR server. Referenced where compatible with IPA.
• Foundational
  • IHE Consistent Time - Defines the use of Network Time Protocol (NTP) to provide consistent time across systems.
  • IHE ATNA - Referenced for secure transport requirements. See the TLS 1.2 Floor Option for TLS requirements.

Document Exchange

Document exchange is defined with 3 actors:

1. Document Publisher (client) - Produces EEHRxF FHIR Documents, publishes those documents to a Document Access Provider. Can be grouped with Access Provider, in which case the publishing transactions are internalized.

1. Document Access Provider (server) - Provides access to EEHRxF FHIR Documents by offering query APIs to Document Consumers. See Document Submission Option below for systems that accept document publication from external producers.

1. Document Consumer (client) - Consumes EEHRxF FHIR documents by querying a Document Access Provider.

These composite actors inherit existing actors from the IUA, PDQm, and MHD specifications:

Document Publisher

• IUA Authorization Client
• PDQm Patient Demographics Consumer (CapabilityStatement)
• MHD Document Source with Simplified Publish Option (CapabilityStatement)

Document Access Provider

• IUA Resource Server - Required
• IUA Authorization Server - Required if authorization is handled internally; not required if using external authorization infrastructure. See Authorization Server Deployment.
• PDQm Patient Demographics Supplier (CapabilityStatement)
• MHD Document Responder (CapabilityStatement)

Document Submission Option (when accepting external publication):

• MHD Document Recipient with Simplified Publish Option (CapabilityStatement)

Document Consumer

• IUA Authorization Client
• PDQm Patient Demographics Consumer (CapabilityStatement)
• MHD Document Consumer (CapabilityStatement)

This leads to the following required transactions between these actors:

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

    Publisher->>Provider: Get Access Token (IUA ITI-71)
    Provider-->>Publisher: access_token
    Publisher->>Provider: Patient Lookup (PDQm ITI-78)
    Provider-->>Publisher: Patient Bundle
    Publisher->>Provider: Simplified Publish (MHD ITI-105)
    Provider-->>Publisher: Response

    Consumer->>Provider: Get Access Token (IUA ITI-71)
    Provider-->>Consumer: access_token
    Consumer->>Provider: Patient Lookup (PDQm ITI-78)
    Provider-->>Consumer: Patient Bundle
    Consumer->>Provider: Find Document References (MHD ITI-67)
    Provider-->>Consumer: DocumentReference Bundle
    Consumer->>Provider: Retrieve Document (MHD ITI-68)
    Provider-->>Consumer: Document Content

See the following functional pages for detailed transaction information:

• Authorization - Authentication and authorization flows
• Patient Match - Patient identification transactions
• Document Exchange - Document query and retrieval transactions

This can be combined with content profiles define by each EHDS Priority Category, for those categories that are primarily represented as a FHIR Document. For example, a system can be a Lab Result Document Publisher, a Patient Summary Document Consumer, or a Imaging Manifest Document Access Provider.

Resource Exchange

It is also useful in many cases to transact with individual FHIR resources. For this purpose, two resource-based actors are defined:

1. Resource Access Provider (server) - A FHIR server providing access to FHIR resources by hosting search + read query API's.

1. Resource Consumer (client) - A FHIR client that consumes external FHIR resources by querying a Resource Access Provider.

Note: What about Resource Producer? Click for more

Resource exchange is more complex than document publication, and in many cases has resource and use-case specific considerations. Within the scope of this version of the IG, we assume a precondition that the Resource Access Provider has access to resources and focus on defining how the Resource Access Provider enables a consumer to search and read those resources. For more details and possible approaches, see the Resource Exchange page.

These composite actors inherit existing actors from the IUA, PDQm, and IPA specifications (with QEDm alignment where compatible):

Resource Access Provider

• IUA Resource Server - Required
• IUA Authorization Server - Required if authorization is handled internally; not required if using external authorization infrastructure. See Authorization Server Deployment.
• PDQm Patient Demographics Supplier (CapabilityStatement)
• Resource Access
  • HL7 International Patient Access Server (CapabilityStatement)
  • QEDm Clinical Data Source (CapabilityStatement) - where compatible with IPA

Resource Consumer

• IUA Authorization Client
• PDQm Patient Demographics Consumer (CapabilityStatement)
• Resource Access
  • HL7 International Patient Access Client (CapabilityStatement)
  • QEDm Clinical Data Consumer (CapabilityStatement) - where compatible with IPA

This leads to the following required transactions between these actors:

sequenceDiagram
    participant Provider as Resource Access Provider
    participant Consumer as Resource Consumer

    Consumer->>Provider: Get Access Token (IUA ITI-71)
    Provider-->>Consumer: access_token
    Consumer->>Provider: Patient Lookup (PDQm ITI-78)
    Provider-->>Consumer: Patient Bundle
    Consumer->>Provider: Resource Query (IPA / QEDm PCC-44)
    Provider-->>Consumer: Resource Bundle

Note: This diagram assumes a bundled Authorization Server. When using external authorization infrastructure (hospital, regional, or national level), the authorization flow differs. See Authorization Server Deployment for details.

Example Groupings