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

EHR System Composition Patterns

This page describes common patterns for constructing an EHR system boundary that exposes the Interoperability Component API surface defined in this IG. These are implementation patterns, not separate conformance targets.

The exposed protected API has the Health Data API Resource Server role and uses the protocol-specific IUA or SMART Resource Server role selected for its environment. Its clients use the Health Data API Authorization Client role; the Health Data API Authorization Server remains distinct and MAY be co-located as a deployment choice. See Authorization for protocol details.

The Authentication Service may separately be grouped with the Authorization Server or independently deployed. That choice does not determine the EHR system boundary or require a central identity service; see authentication and authorization groupings.

Direct implementation

In a direct implementation, the EHR system exposes the API surface without relying on another component.

Functionally this is equivalent to the options below, although the internal implementation differs.

Facade

A facade can expose the API surface in front of a base EHR system.

In this approach, the base EHR system is not updated. The facade uses proprietary APIs or internal integration points to provide the Interoperability Component API surface. The boundary of the EHR system is still the grey box, so the facade is treated as part of the deployed EHR system.

Aggregator

An aggregator can provide the API surface for multiple underlying systems.

In this approach, the exposed EHR system boundary is the combination of the underlying systems. Testing and conformance are assessed at that combined boundary, not separately for each underlying system.

Registry

A registry-style deployment publishes documents to a registry or repository component.

In this approach, source EHR systems publish documents, and the registry or repository component provides access to that content. This can make the registry or repository a separate system boundary.