...
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 services that are used in OpenHIE.
...
The full requirements that the Interoperability Layer community have identified can be found here: What is an Interoperability Layer ?- Use Cases and Requirements
The following is a Here is list of key requirements that are seen as beneficial necessary for an interoperability layer:
- Provide a central point for authentication and authorization to the HIE services.
- Log, audit and monitor communications with for the components of the HIE.
- Provide error management and transaction monitoring information to the administrators of the HIE.
- Provide transaction orchestration services as well as adapter services to transform message between different message formats.
The architecture
Below, the architecture
...
of the Interoperability Layer is shown in the context of the other expected services and registries. The Interoperability Layer components are show in blue, the domain services (registries) are shown in red and the clients are shown in green.
The core (thin proxy) component
...
- 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 requests received to the correct upstream service.
...
- Log service - This service stores each message in its entirety along with metadata about the message such as time and data date the message was received and the response that the service returned.
- Audit service - This service audits each message received by storing an audit log entry. This log entry 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 known 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 router makes 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 an aggregation service where they could be aggregated and submitted to an aggregate data store such as DHISa data warehouse.
The orchestrator and adapter services
...
- Orchestrators - This service type enables a business process to be executed, this normally involves one or more additional service services being invoked to process the required transaction.
- Adapters – This service type adapts a an 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 Orchestrators may use other adapters to send messages to other services. Designing these orchestrators and adapters as independent services allows for additional logic or business processes to be added to the HIE as the need arises. This allows the architecture to grow as the environment changes.
Adapters are used in 2 cases:
- To simplify communication with the Domain services (for orchestrator use)
To adapt a standard-based interface to a custom domain service interface
Both the orchestrator and adapter services are also expected to log and audit messages that they send out to the domain services.
How authentication and authorization is handled within OpenHIE
The interoperability layer and system that it connects to will make use of the IHE ATNA profile's node authentication section for authentication. For authorization the provider registry will maintain a list of provider authorities and the interoperability layer will check these during orchestration of each transaction.
Derek Ritz has put together a great slideshow to show how authorization and authentication will be handled within OpenHIE. Please see this resource here: authentication and authorization slideshow.
Features of a central component
...