Overview

Within the OpenHIE project there are a few major functions that a Interoperability Layer should perform:

• Provides a central point of access for the services of the HIE

• Provides routing functions

• Provides a central logging for auditing and debugging purposes

• Provide orchestration/mediation mechanisms to co-ordinate requests

Standards and Workflows

To be OHIE IOL component, the IOL application must be able to support the OHIE workflows listed below.  Implementations may support only the workflows needed to support their use case:

• ATNA - this is split into two logical parts
  • AT (Audit Trail) - Which describes how audit messages can be sent and stored in a central repository which in this case would be the IOL
  • NA (Node Authentication) - Which describes how the IOL can authenticate clients (external systems) that want to send request into the exchange

The IOL is used in most OpenHIE workflows to co-ordinate requests, provide visibility into the exchange for debugging purposes and to authorise clients. Please see the list of OHIE workflows for additional details around how the IOL is used in each case.

Requirements

In addition to the above an IOL should closely match the requirements defined by OpenHIE as can be found here.

Support of OpenHIE Non-functional Requirements 

An OpenHIE component should consider the following OpenHIE Non-Functional Requirements - Draft