The OpenHIM exposes the services required for sharing clinical information between the clinics in Rwanda. It provides a variety of services that enable the sharing of clinical information between clinics. These include services to:
- Register a patient's demographic information
- Query for a specific patient or for a list of patients
- Update a patient's demographic information
- Save a patient's encounters to a central health record
- Query for a list of a patient's previous encounters from the central health record
A comprehensive description of the exact use cases that OpenMRS supports for the RHIE can be found here: OpenMRS System Use Case and Design - 23-02-2012. Below the main interactions are described.
When a patient arrives for maternal care at the clinic the registration clerk first looks them up on the local OpenMRS system. If they cannot be found on the local system a query can be made to the Client Registry. The OpenMRS system makes a web service call to the OpenHIM to query for a patient matching the criteria that the registration clerk enters. The OpenHIM accepts and stores the message, it is then passed on for mediation. In this case the message is de-normalised to a form that the Client Registry can understand and no normalization or orchestration functions are required. The OpenHIM makes the call to the Client Registry, processes the response and returns a list of one or more patients to the OpenMRS system. OpenMRS displays the choices to the user to verify which record matches the patient. If the patient cannot be found in the Client Registry, the registration clerk enters the patient demographic information and this gets sent as a message to the Client Registry through the OpenHIM. This workflow can be seen in the following image.
Once the patient is registered in the local system they are ready to be seen by a clinician. The clinician looks them up in OpenMRS and is able to fill in forms capturing observations about the patient's visit. Each form that is saved triggers the OpenMRS system to invoke the save encounter transaction. This makes a call to the OpenHIM with a message containing the clinical encounter and all the observations that the clinician entered in HL7 v2 format. The OpenHIM receives this message and stores it. It is then passed on to the mediation function. This save encounter transaction has a number of orchestration steps that the OpenHIM must perform. The message is validated against the client registry, provider registry and facility registry to ensure that the identifiers used for the patient, provider and location are known in each of those registries. The message is also enriched with the patient's enterprise id that the client registry uses to uniquely identify patients and the provider's enterprise id that the provider registry uses to uniquely identify a provider within the HIE. Once that is completed each of the codes (from code systems such as LOINC or ICD-10) used within the message are checked against the terminology server to ensure that they are known and valid. If all of this orchestration occurs successfully, only then is the message sent on to the shared health record system where it is stored in the patient's shared health record or in a new record if one does not already exist. A response is sent to OpenMRS so that it can determine if the transaction was successful or not. The following image show this workflow.
When the patient arrives at another clinic their record can be pulled down to an OpenMRS system at another clinic. To do this the patient must be registered in the system as described above. The OpenMRS system can then make a call to the OpenHIM to query for previous encounters for that patient. The OpenHIM fetches the patient's health record from the Shared Health Record service provider. It then performs orchestration on the response to enrich the message with the patient's identifier and provider's identifier referenced by the local OpenMRS systems. These are obtained for the Client Registry and the Provider Registry respectively. The enriched message is returned to the OpenMRS system at the clinic where it is stored locally in the system so that it may be viewed by that clinic's clinicians. The following image shows this workflow.
