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