What is the HIM?

The Health Information Mediator (HIM) is a middleware component that sits between all of the other components of the RHEA architecture. It allow these other components to interoperate with each other easily and effectively. It is the backbone of the entire RHEA architecture. Without the HIM, the RHEA architecture would not be able to function at all.

How does the HIM fit into the RHEA architecture?

The HIM is responsible for connecting all of the infrastructure services and client applications together. It enables interoperability between the various components of the architecture.

Shared Health Record
This system persists and responds to queries for an appropriate subset of the patient's longitudinal, patient-centric medical record.
Client Registry
This system persists and responds to queries for a patient's demographic and identifying information used to uniquely identify patients.
Facility Registry
This system persists and responds to queries for data of the facilities participating in the information exchange. This is primarily used to maintain current and valid facility codes required in transactions.
Professional Registry
This system persists and responds to queries for information about health care professionals who work at participating health care facilities in the information exchange. This is primarily used to uniquely identify health care professionals within the HIE.
Terminology Service
This system stores all the clinical code systems (eg. LOINC, ICD10 and country specific code systems) that will be used within the HIE and facilitates verification and mapping between codes. It exposes endpoints that allow codes to be verified against the stored code systems.

But, what does the HIM do?

The core functions that it provides to allow this to happen are explained below.

Allow interoperability between many, different systems
Adapt and scale within a changing environment
Ensure systems can be developed independently and not affect the functioning of the other systems in the HIE.
Provide a low barrier to entry to connect new and legacy systems

To accomplish these functions it does the following things:

It exposes a simple API that allows transaction to be performed against the infrastructure services without the client application having to know the complexities of the service's API.
It provides Normalization and De-Normalization functions that allow the messages to be transformed into formats that the service requesters (eg. OpenMRS and RapidSMS) and the service providers (eg. CR, PR, SHR and TS) can understand.
It orchestrates the transaction. This means it makes the calls to all the service providers that need to participate in this transaction.

Ok, so what does this mean for RHEA?

The core of what we are trying to do within the RHEA project is enable interoperability between systems. To enable this the HIM allows us to define specific transactions that allow us to achieve the interoperability that we need.

For RHEA we have identified and defined a number of transactions. The overall goal of RHEA is to enable different health facilities to share clinical and demographics information between each other. So, each of the transactions that we have defined helps to achieve this goal is some way. You can view a list of the transactions that have been defined here: RHEA Transactions