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.
Objective
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 population of ~40 million
> 5 official languages
potential international donor support for eHealth programs
a health system where NGOs and private institutions complement government facilities
internal software development and hosting capability
A large NGO with:
a presence in multiple countries in a region
many long-term projects aimed at producing positive health outcomes
various software applications, developed in-house
A small country with:
a population of ~10 million
2 official languages
a centralised health system
little in-house software development or hosting capability
These three "customers" types might want to interact with OpenHIE in different ways:
The medium-sized country might want to significantly customise OpenHIE, discarding the default orchestration for their own software that might implement workflows very specific to that government and incorporate data from other systems. This means that the Interoperability layer should support customization and extension to perform new use cases.
The NGO wish to use a subset of OpenHIE components to track health outcomes over time e.g. the provider registry and the SHR but not the facility registry. The Interoperability Layer should be able to be included transparently without changing the existing interaction between components if it is desired at a later stage. This will allow it to add value by providing common core services.
The small country might want to adopt OpenHIE wholesale, without customisation. The Interoperability Layer should be able to support some key transaction that enable OpenHIE to be useful out of the box.
Requirements
Functional Requirements
Core functions
FR02 - Provides a central point of access for the services of the HIE. For example this interface will provide access to the CR, PR, FR and SHR. This central point of access simplifies security management and provides a single entry point into the HIE.
FR12 - Provides routing functions that allow messages to be routed to the correct service provider systems within the HIE
FR01 - Provides a central logging mechanism for the messages sent through the exchange. This function should log copies of the messages that travel through the interoperability layer for audit and reporting purposes.
Mediation functions (See Transaction Mediation section for additional information)
FR03 - Should support transformation of messages that travel to the interoperability layer from service consumer systems and vice versa if the service consumer is not able communicate in the required format, i.e. the interoperability layer should provide implementation specific adapters to transform message from the interoperability layer’s internal form to a form that the service consumer expects (e.g. A clinic’s EMR)
FR04 - Should support transformation of messages that travel from the interoperability layer to service provider systems and vice versa if the service provider is not able communicate in the required format, i.e. provides implementation specific adapters to transform messages from the interoperability layer’s internal form to a form that the service provider expects (eg. SHR, CR, PR etc.)
FR07 - Is able to perform orchestration tasks for complex transactions to take the burden off client systems. This orchestration may contact multiple service provider within the HIE on a client’s behalf and compile an appropriate response to return to the client. Examples of orchestration could be the execution of a care plan or the validation of elements (such as identifiers or codes) in a message against other service providers within the HIE (e.g. PR, CR, FR, TS). Orchestration tasks are those that are required to complete the current transaction and therefore must be executed timeously as the transaction cannot continue without these steps.
FR14 - The systems must include an interface into which a workflow engine can be connected. This workflow engine could be able to keep track of long running state of a patient care and it would be able to perform action based on this context (such as sending alerts) to improve a patient care. This workflow engine is out of scope for an Interoperability Layer, however, the Interoperability Layer is expected to expose an interface to allow this sort of systems to be implemented.
FR08 - The system can be extended by allowing additional mediation functions to be added or remove as they are needed
Error Management functions
FR05 - Must provide a mechanism for error management and tracking, e.g. a console for viewing failed transactions
FR11 - Must allow for failed transactions to be grouped by error type and reason so errors can be rectified efficiently by finding the root cause of the error, fixing the problem and re-running those transactions
FR06 - Allows the user to re-run errored transactions through the HIE once the reason for their failure has been rectified.
FR13 - Must provide a view of metrics for monitoring the flow of messages through the HIE
Non-functional Requirements
NR01 - Must have acceptable performance at a district level and the ability to scale to a national level.
Is secure:
NR02: Supports Authentication and Authorization
NR07: Supports encryption of data in flight (when not on a physically secured network) and at rest (whenever data is stored, e.g. when transaction are stored for logging (FR01))
NR03 - Adheres to standards: makes use of current accepted standards where appropriate
NR04 - Takes into account the IT infrastructure of low resource settings, see “low resource setting” section below
NR05 - Services should be durable. This means the services should be able to recover from failures or interruption by automatically resuming or restarting the service.
NR06 - Reliably delivers messages e.g. messages effects cannot be executed more than once, messages can therefore be retried as needed.
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.
Transactions to save a patient's clinical encounter to a shared health record
Transactions to receive reporting information and send this to an aggregate datastore
Transactions to manage health providers
Transactions to manage health facilities
Transactions to manage patient demographics and identity
Transactions that retrieve relevant information about patient encounters and care
Transactions to notify providers/physicians with clinical alerts related to a patient
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
Authorise - Ensure that the service requester is authorized to perform the request
Decrypt - Be able to decrypt incoming messages to pass on to service providers
Route - Be able to route messages to the correct service provider system
Mediation Services
Normalise - Transform messages into a well understood intermediate form (canonical form)
Orchestration - Execute a set of steps to perform a business function, this often can include requesting services from multiple service providers
De-normalise - Transform messages into a form that a specific service provider can understand
Cross-registry capabilities
Orchestrate of transaction
Workflow management
Register encounter
Lookup health record
Single-registry capabilities
Lookup patient
Register patient
Lookup provider
Lookup facility
Lookup terminology
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.