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/bvdh/jwg-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
  • IHE IUA - Defines authorization and access control actors and mechanisms. We use the actors and transactions model.
  • HL7 SMART Backend Services - Defines authorization in FHIR. We use the SMART Backend Services profile for system-system authnz, and FHIR scopes.
• 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. (note: no XDS dependencies)
• 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 - Defines secure communication and audit logging requirements for healthcare systems.
    • RESTful ATNA - Defines the use of FHIR AuditEvent rather than the legacy audit log format.

Document Exchange

Document exchange is defined with 3 actors:

1. Document Producer (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 an API which Document Consumer clients can query. Receives Documents from Document Producer (If not grouped with Document Producer).

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 Producer

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

Document Access Provider

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

Open Issue #6: Should the Authorization Server be assumed as part of the Document Access Provider? See Authorization Server Deployment for discussion.

Document Consumer

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

This leads to the following required transactions between these actors:

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 Producer, a Patient Summary Document Consumer, or a Imaging Manifest Document Access Provider. See Content Library

Resource Exchange

It is also useful in many cases to transact with individual FHIR resources (note: ref other page). 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 Authorization Server
• IUA Resource Server
• 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:

Example Groupings