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

Provider-Internal Exchange

Overview

Provider-internal exchange describes how a healthcare provider can use the same Interoperability Component capabilities within its own environment.

This page is informative. EHDS does not dictate how a provider exchanges data internally. Healthcare providers already use many interoperability standards and local integration patterns that are not covered here. This page does not model all provider-internal exchange; it focuses on where the Interoperability Component capabilities defined in this IG can be used within a healthcare provider environment to support internal exchange.

A healthcare provider commonly deploys multiple EHR systems. Those systems may expose document or resource access directly, or the provider may use a gateway, facade, aggregator, or registry-style deployment to present a single EHR system boundary. See EHR System Composition Patterns.

In provider-internal exchange, EHR systems may also act as Document Consumers or Resource Consumers when retrieving EEHRxF data from another internal system or a provider-level gateway.

When the provider connects to national infrastructure, the gateway-facing EHR system is responsible for making provider data available through the API surface expected by the Member State. Provider-internal exchange and national exchange can use the same Interoperability Component capabilities, but they are separate deployment contexts with separate requirements.

Participants

• EHR systems — systems within the healthcare provider. They can act as Document Consumers, Resource Consumers, Document Access Providers, Resource Access Providers, and/or Document Publishers.
• Gateway, facade, aggregator, or registry — an implementation pattern used to expose provider data through a single EHR system boundary. See EHR System Composition Patterns.
• Healthcare professionals — users within the healthcare provider who may access EEHRxF information through local EHR workflows. User-facing workflow requirements are outside this IG.
• National infrastructure — external infrastructure that may consume provider data for cross-organization exchange, access services, or cross-border exchange.

Environment-Specific Considerations

Considerations related to this environment include:

• Regulatory
  • The EHDS regulation does not contain specific provider-internal exchange requirements.
  • Provider-internal exchange can support Member State obligations by making provider data available for national infrastructure, access services, or MyHealth@EU.
• Access patterns
  • EHR systems may support resource and/or document based access.
  • Registry-style deployments require a registry or repository component that can provide access to published EEHRxF documents.
  • Registry or repository deployments define which component retains published EEHRxF document versions and makes them available for later access.
• Authorization
  • EHR systems acting as Document/Resource Access providers may contain their own authorization server, or use an organization-level authorization server to control API access.
  • EHR systems are not required to use eIDAS wallet-based authorization for provider-internal exchange.
• Patient Identity
  • Healthcare providers may have an Enterprise Master Patient Index (EMPI) that identifies patients known to the organization and shares this patient identity with other EHR systems in the organization.
  • A gateway-facing EHR system is responsible for ensuring that data provided to national infrastructure includes the required national and European identifiers.