Architectural concepts (original)

Introduction

This page provides a general description of key services that are likely to be required in environments using openEHR solutions.The intention of defining these interfaces is so that:

• openEHR application developers can safely assume a 'standard' API, regardless of which implementation they use (with the usual caveats to do with particular unavoidable peculiarities of each type of implementation technology, i.e. java / .Net / other);
• back-end system implementers know what interfaces they need to expose in order to enable middleware and application developers;
• healthcare enterprises engaged in system procurement can rely on a standardised middleware 'bus' definition when purchasing, ensuring the environment they build is always open.

Proposed Development Process

It is expected that the service and API definitions eventually agreed as openEHR specifications will be initially inspired by service interfaces used in real openEHR implementations, and will evolve as a result of direct community input.

Relationship to published Standards and Specifications

It is a priority within openEHR to ensure that all artefacts without exception are mutually consistent, and this includes services interfaces. Another priority is good design. While respecting these ideals, it is clearly useful and important to a) be able to support services in wide use elsewhere, and b) to re-use good design features of previously defined standards. Where possible, a de jure standard would be re-engineered in the most minimal possible way for use within openEHR. Doing this has two effects: it provides a service that is guaranteed to work properly within an openEHR environment, and it also provides a definition that can be easily wrapped by a thin layer to provide compliance to the original standard. Things that would typically change across this layer would include data types and other low level details.

So far not much work has been done on evaluating extant standards with respect to openEHR needs, however based on current knowledge, it is expected that the following standards would be candidates for re-use in openEHR:

• Terminology: HL7/OMG CTS II. This emerging standard does not distinguish between operational environment deployments of terminology, where the terminologies are required to be read-only and be high-availability / QoS, and authoring environments, where creation, modification and other authoring functions are required.
• Demographics / identity: IHE PIX, PDQ; HL7/OMG EIS.
• Security: IHE ATNA and others.
• EHR: HL7/OMG RLUS.

The IHE technical specifications can be found here. The IHE approach is to define 'profiles' for specific interaction use cases, and then define messages based on one or more existing standards. If and where such profiles were to be used in openEHR, the approach would be to develop a new profile that fits the general IHE design intention, where the latter makes sense for openEHR. Note that in general, no published standards properly support the idea of knowledge-enabled information, although the HL7/RLUS standard does include a 'semantic signifier' concept which may be mappable to openEHR archetypes.

Another useful source of architectural concepts can be found in the Microsoft Connected Health Framework (CHF) 2nd edition, which describes a service oriented health computing framework. Aspects of this are included as candidates in various places in these pages.

Service Architecture

General Structure

There is no single overall service architecture for a given deployment environment. Any final deployment is heavily dependent on usage requirements, distribution architecture and so on. The general approach to service definition in e-health tends to reflect two dimensions strongly:

• levels of distribution / federation - enterprise, cross-enterprise, regional, .....
• levels of business abstraction, from information to business process

These dimensions can be illustrated as follows:

Operational Environment

We can distinguish among a number of broad environment types in which services could be deployed. The first is the 'operational health information environment', in which all services are oriented toward management of health information (health records and related) within a typical clinical environment. The following diagram depicts a set of openEHR-related services for such an environment. These are clearly a subset of all possible services that might be found within a realistic HIS environment. The services are in three categories, plus a middleware API that provides access for an application. The service groups are:

• EHR & demographics services: services providing core health information;
• infrastructure services: connections to key parts of the computing infrastrructure, including security and identity;
• knowledge services: shown on the right hand side - these services are for deploying terminology, archetypes, templates and other knowledge artefacts within the runtime environment (cf knowledge services within an authoring environment, which are designed to enable authors to modify the knowledge assets).

Knowledge engineering environment

Within knowledge authoring environments, the concerns are different, and accordingly, the services reflect this. The following diagram shows some of the services relevant to openEHR in such an environment.

Within this environment, we distinguish the service types:

• Publisher Knowledge Manager Service: a service for managing openEHR knowledge artefacts, including archetypes, templates, terminology ref-sets, and queries.
• Terminology authoring service: a service oriented to supporting the many functions required to build and maintain a terminology, such as SNOMED CT, ICDx, LOINC, ICPC and others.

Other environments

Other environments for which specific services are likely to be required include clinical study and reporting, and other secondary use situations; ICU and other specialist acute care environments and so on.

Virtual EHR API (vEHR)

The 'virtual EHR' is a service layer designed for application use - it is the primary way an application connects to back-end services. It abstracts away specific locations and other details of service deployment, and makes use of other services to perform various requests on behalf of an application.

Key function groups within this service include:

• Session management: obtaining a secure session;
• Data Creation and update: functions to allow the creation and modification of health records, Compositions within health records;
• Data Retrieval: functions related to retrieval of existing data
  • by trait / index
  • query
  • population query.

CRUD models and Performance

The following figure shows the difference between the application / vEHR interaction, and vEHR / EHR interaction.

Demographic Resolution

One of the functions of the vEHR middleware is to enable demographic and EHR information to be seamlessly be brought together, typically via the used of the EHR/subject x-ref service, as shown in the following figure:

Specifications

This page contains the emerging openEHR specifications for the vEHR. They are based on work done by commercial and non-commercial implementers.

EHR and Related Services

EHR Service

The openEHR EHR service is a true back-end service via which patient EHRs can be stored, retrieved and queried. It has a coarse-grained data access interface, consisting of functions like commit_contribution(), get_composition() and so on. An openEHR service supports versioning, and can be thought of as being like an intelligent versioned EHR form of a typical version management repository such as Subversion, GIT etc.

Demographic Service

This openEHR service provides access to versioned demographic data based on the openEHR demographic model. This service can be deployed in at least two ways. The first is where there is an existing Master Patient Index (MPI) or other similar demographics service, and the openEHR demographics service acts as a facade whose data are created by importation from the MPI.In this mode, the key service functions are to do with batch-loading data, retrieval and querying.

The second mode is standalone, where the service functions for data creation and modification are also required.

The function of this service is similar to the EHR service, except that its data is demographic rather than EHRs.

In some environments, this service will not be required, since openEHR EHRs can carry direct references to demographic entities via the PARTY_PROXY.external_ref attribute.

EHR / Subject Cross-reference Service

This service provides a mapping from EHR identifiers (openEHR ehr_id) to one or more subject identifiers. It can be used to avoid any subject identifiers appearing in EHRs managed in the EHR service, as well as to manage correlations across identification systems.

Audit Log Service

This service provides a way to persist an indelible, non-repudiable log of all read and write accesses to EHR and demographic information.

Distributed EHR Location

In a distributed environment where EHRs for a given person might exist in multiple EHR services, or in one of a number of servers. The EHR/subject X-ref service can be used to register location information, enabling applications using the vEHR layer to obtain patient records regardless of where they exist. This could be used to support clustering environments (in other words, as a scalability solution), and also federated environments (a distributed deployment). The following figure illustrates this use of the X-ref service.

Operational Knowledge Services

Enterprise Knowledge Service

This service provides access to openEHR templates and archetypes, in operational and potentially in source form. These artefacts are available in identified releases, enabling controlled access to specific releases of archetypes and templates.

Terminology Service

The terminology service deployed in the enterprise is concerned with providing high-availability access to terminologies and terminology ref-sets. Terminologies include the large terminologies such as SNOMED CT, ICDx, ICPC, LOINC, as well as local institutional terminologies. Terminology ref-sets can be built against any terminology. The versions both of any terminology and any ref-set can be specified, with the default being the latest.

Integration Services

EHR Extract Service

Infrastructure Services

Identity Service

This service interfaces with the environment's user identification facilities, allowing applications to find out about users.

Security Service

This service provides a standard way for openEHR applications to interact with various security services, in order for applications to authenticate and gain authorisation for various kinds of access.

Knowledge Authoring & Publishing Services

Knowledge Manager Service

Terminology Service

Related Standards and Specifications

  EN ISO 12967 (Health Informatics- Service Architecture)