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
  • The Healthcare Provider environment's authorization mapping is defined in Authorization. For a gateway's pre-authorized system-to-system upload, the consuming system is the Health Data API Authorization Client, realized as a SMART Backend Service; the protected endpoint is the Health Data API Resource Server, realized as a SMART FHIR Resource Server; and the token issuer is the distinct SMART Authorization Server. This flow applies only when its pre-authorization, asymmetric confidential-client authentication, and no-runtime-user-authorization prerequisites are met. See SMART Backend Services and Authorization for the profile requirements and scopes.
  • For interactive clinician access using SMART App Launch, the client is a SMART App, the protected endpoint is a SMART FHIR Resource Server, and the Health Data API Authorization Server remains a distinct participant. The Authentication Service authenticates the professional; a SMART Launching System also participates for EHR Launch. Identify the target FHIR base and registered app, then use the endpoint's SMART discovery metadata and how the app is started to select Clinician Access for EHR Launch or Clinician Access for Standalone; the Authorization page owns the flow requirements.
  • Applicable user-identification requirements are described in Authorization; this provider-internal scenario does not define a separate Wallet authorization flow.
• 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.