An interoperability layer is a system that enables simpler interoperability between disparate information systems. In an OpenHIE context, these are Health Information Systems (HISs) such as a client registry, provider registry, facility registry and shared health record.


An Interoperability Layer receives transactions from client systems, coordinates interaction between the different components of the HIE and provides common core functionality to simplify the data exchange between systems.

Use Case overview

The interoperability layer enables interoperability between the disparate system within an HIE. Its main function is to allow disparate health information systems to share information more easily. This means that it should handle the common, mundane tasks such as logging and security and performs message transformations such that systems may communicate with it in a native messaging format.

At its core the Interoperability Layer should provide a single point of entry into the services of the HIE. It should centralise the logging/auditing of messages; the handling of authentication and authorization and the routing of message to the correct service provider. In addition it MAY provide additional mediation functions for transactions within the HIE in an attempt to simplify the business logic required by service consumer systems to interact with the HIE. These function may include mediation tasks such as transformation of messages and message orchestration.

Who are our “customers”?

It is important to consider who will make us of a HIE to guide our thinking of what an interoperability layer needs to do. Below are some descriptions of the types of stakeholders that would be interested in an interoperability layer. Note, that may be more widely applicable than to just the stakeholders listed here.

A medium-sized country with:

A large NGO with:

A small country with:


These three "customers" types might want to interact with OpenHIE in different ways:



Functional Requirements

Non-functional Requirements

Transaction Mediation

Transaction mediation function are needed to simplify and enable existing systems to connect to the HIE through the use of transformation services. However, it is recognised that the need for normalization and de-normalization of messages should be minimised. Rather, the use of standard messaging formats should be encouraged within services consumers and service providers so that this functionality is not needed. However, in real world terms transformations from customs format to standard format as well as transformations to remove the imperfections from standards message formats will be required to some degree. Thus, this functionality should be supported for these cases.

What core transactions should be provided?

In this section we identify some of the key transactions that an Interoperability Layer could support to facilitate the sharing of health information. These items are to assist in showing the main transactions of focus for an interoperability layer, however this list is not exhaustive and we can expect actual services to be required will vary depending on the implementation needs.

The actual services will be provide by service providers such as a client registry, provider registry, facility or shared health record, however the interoperability layer will facilitate these sorts of transaction through mediation.


What core services should an interoperability layer provide?

The following is a summary of the key capabilities that an Interoperability Layer should provide. These some of these relate to the services mentioned above and describe if they are envisioned to touch single or multiple registries. Cross-registry capabilities have a good chance of requiring orchestration.

Transparent services

Mediation Services

Cross-registry capabilities

Single-registry capabilities

Low Resource Settings

We define low resource settings, when applied to information systems, as geographical areas where there is poor infrastructure due to limited funds dedicated to this area.

When looking at low resource setting from a technological perspective this could mean that one or more of the following is true: electrical power may be inconsistent and unpredictable; access to the Internet may be poor both in latency and in speed while also being inconsistent and unpredictable; users of systems are not sufficiently computer literate; and hardware is poorly maintained and fails more frequently. In systems terms the key issue for us to solve is that the system must be fault tolerant. This system would also be installed a datacenter where these problem are minimised, however, can still likely occur.