Creating a Health Information Exchange System in Rwanda
- LocationRwanda
- ImplementationPhase 1: September 2019-December 2019 & Phase 2: January 2020-June 2020
SAVICS leverages global goods to enable the Rwanda Health Information Exchange Systems (RHIES)
In September 2019 the SAVICS team, a digital social start-up who works in-country to develop and implement health information systems, started their work in Rwanda to create the Rwandan Health Information Exchange Systems (RHIES).
The main issue was that these systems communicated to each other in ways that demanded manual efforts. These systems needed automation and interoperability. The HIV case-based surveillance data needed to be digitized in collaboration with the Rwanda Biomedical Centre (RBC), Health Information System (HIS) team, and the RBC HIV program. Additionally, the data collection and exchange processes needed to be aligned with the country’s OpenHIE-based architecture and utilize an interoperability layer, the client registry, and the Facility Registry.
One of the biggest challenges the SAVICS team faced when tackling these areas was that facilities were using paper based processes to record HIV case-based surveillance cases which were then manually entered into DHIS2 by the data manager. This created an exceptionally heavy workload. There was also a high turnaround time to get the viral load and recent results from the laboratory (LabWare) back to the facility. Another big challenge that Rwanda was facing was health information exchange: systems which contained the data (OpenMRS, National Identification Agency (NIDA), DHIS2) had no way to share it across systems to allow for automation, updates, and reporting.
- SAVICS
- Rwanda Biomedical Centre
- Rwanda MOH
- OpenMRS
- DHIS2
- LabWare
- Rwanda Information Society Authority (RISA)
- OpenHIM
- Docker
The Impact
-
Client and Facility Registries
Both the Client Registry and the Facility Registry servers for Rwanda are up and running.
-
Interoperability
OpenHIM core for interoperability and all system mediators are up and running.
-
6 Instances of OpenMRS
Six instances of OpenMRS have been installed on the RHIES server
-
Documentation and Codebook
Documentation and codebook are stored on public GitHub:
Three OpenMRS modules, OpenMRS forms CBS, Five mediators, Client Registry, Facility Registry
-
Automation
When patients are registered into the OpenMRS EMR, the health care workers no longer need to manually enter data since it now pulls demographic information from NIDA.
Data managers no longer need to manually enter case-based surveillance details in DHIS2.
-
Further Improvements
Moving forward the Rwanda MoH has plans to make further improvements on this work:
Improve the Client Registry by improving the patient matching algorithm, extending API, make changes to the user interface
Develop a Shared Health Record
Deploy 123 OpenMRS instances on the cloud, with the potential to loop in Kubernetes
The SAVICS team learned many lessons on the way to establishing client and facility registries.
Here are the most important items they examined when thinking on future projects:
Real-world scope of projects should be defined ahead of time to establish parameters and expectations for all stakeholders involved.
Clarify the individual OpenHIE components needed for a project alongside the Ministry of Health in the country.
Clarify metadata sharing policies before starting OpenMRS customization or module developments,
Check the license before using code on GitHub while working on an open source project
It is better to use Kubernetes or swarm for Docker deployment, even where the deployment may seem simple.
Establish a team working at the HIS department of the country.
Get involved with the OpenHIE community to learn from ongoing and successful implementations.
The Approach
The first step in this process was to create an interoperability layer using OpenHIM. The team used a collaborative approach to establish the interoperability service. The interoperability layer allowed Rwanda to address the biggest challenge; data exchange between the key systems (OpenMRS, LabWare, NIDA, DHIS2).
The second step in the process was to develop the mediators: OpenMRS to DHIS2 – e-tracker, OpenMRS to NIDA, LabWare to OpenMRS – LIS NRL. A module was created to interconnect these systems and modifications were also necessary in some cases so that data could flow seamlessly.
Creating the facility registry (JSON- MongoDB) and client registry (HAPI FHIR) was the final piece of this process. Every new patient who has been added to the EMR through OpenMRS is added to the client registry workflow. Based on the Ministry of Health guidelines, the facilities that were also present in the DHIS2 were saved to the facility registry database. Both the client and facility registries are pushed automatically, on an ongoing process, to the EMR to maintain accuracy and up-to-date documentation.
The primary care patient information has now been linked into OpenMRS from the NIDA citizen demographic database.Individual patient data can now be entered into OpenMRS and LabWare results are now automatically sent to the patient’s EMR. Case-based information from the HIV Program CBS national monitoring is pushed automatically to DHIS2 and can be later linked to individual patient charts.
-
Client Registry -
Facility Registry -
Shared Health Records -
Interoperability Layer
-
OHIE CAPABILITIES
- Patient identity management across systems
- Disease surveillance and reporting
- Facility planning and management, including unique identification of facilities
-
HEALTH ISSUES ADDRESSED
- Individual Patient Care (Clinical) – HIV disease management
- Healthcare Administration – Facilities
-
OHIE WORKFLOWS
- Validate and save aggregate data
- Query health worker and/or facility records workflow
- Query care services workflow
- Search care services workflow
- Create patient demographic workflow update
- Save patient-level clinical data workflow
- Query patient-level clinical data workflow