Overview

This document will describe the architectural design of an Interoperability Layer for use within the OpenHIE project. It describes the key components that should make up an interoperability layer and how this relates to the other service that are used in OpenHIE.

The interoperability layer considers of 2 separate sets of components:

1. The core (thin proxy) component
2. Orchestrators and adapter services

Together these 2 sets of components make up an interoperability layer. These can be seen in the diagram below. In the following section we will describe each of these in more details.

Key Requirements

The full requirements that the Interoperability Layer community have identified can be found here: What is an Interoperability Layer?

Here are the key list of requirements that are seen as beneficial for an interoperability layer:

• Provide a central point for authentication and authorization to the HIE services
• Log, audit and monitor communication with the components of the HIE
• Provide error management and transaction monitoring information to the manager of the HIE
• Provide transaction orchestration service and adapters to transform between message formats

The architecture

The core (thin proxy) component

This component can be through of as the entry point into the HIE. In provides some common mundane services so that other domain services don't have to implement these. This component basically just acts as a web service proxy while performing some additional functions on the incoming requests. The functions that this component should perform are as follow:

• Each message that is received from a client should be logged (stored in its entirely with metadata) and audited (store key information about that transaction and who ran it).
• Authentication and authorization services for the transaction within the HIE should be handled here.
• Displaying and monitoring errors that occur between the services, making use of the logging function to do this.
• A routing mechanism that routes request received to the correct upstream service.

This component makes use of several other services in order to perform the functions mentioned above. These can be external services and we can likely use existing software components to fulfil these functions. The required services are explained below:

• Log service - This service stores each message in its entirety along with metadata about the message such as time and data the message was received and the response that the service returned.
• Audit service - This service audits each message received by storing an audit log. This log contains certain key information such as who sent the message, what information was requested and when the information was requested.
• Authorization and Authentication service - This service ensures that the person requesting or submitting information is know to the HIE and has the correct privileges to do so.

The interoperability layer core component contacts each one of these services when it receives a message to ensure the appropriate information is stored. It then passes the message on to the router where it is sent to the correct upstream service. The routers make use of a publish and subscribe pattern so that messages can be routed to multiple interested parties. This allows for secondary use of the messages received by the HIE. For example, encounter message could be routed to the SHR as well as a agggregation service where they could be aggregated and submitted to an aggregate data store such as DHIS. There are 2 types of routers:

1. A synchronous router - where immediate requests will be handled where the client is expecting an immediate response.
2. An asynchronous router  - where long running request are sent. They can be added to a queue that workers could draw from and perform intensive tasks.

The orchestrator and adapter services

This set of components provides services that manipulate the request that are sent to them. They are often implementation specific so they will change as the use cases that the HIE supports change. Each of these components are separate services that perform a specific function following the micro services architecture (http://yobriefca.se/blog/2013/04/29/micro-service-architecture/). There are 2 major types of these services:

1. Orchestrators - This service type enables a business process to be executed, this normally involved one or more additional service being invoked to process the required transaction.
2. Adapters – This service type adapts a incoming request to a form that the intended recipient of the request can understand.

These services are invoked whenever there is a need to orchestrate or adapt a certain transaction. If they are not needed the core interoperability layer component will just call the domain service directly. Designing these as independent services allows additional logic or business processes to be included in the HIE as the need arises. This allows the architecture to grow as the environment changes.