Notice E0 Phase 1 Shelf Readiness

Notice E for promoting investments in digital health global goods

Improving Shelf-Readiness by Sharing Patient Data Across Systems: OpenMRS, MobileWACh, an SHR, and OpenHIE

Two-sentence overview: 

Both OpenMRS and Mobile WACh are critical components in providing care to patients, and collect data at different points in the healthcare system that should be shared with each other through a Shared Health Record (SHR) to improve decision making and patient outcomes. This project aims to 1) build FHIR support and OpenHIM mediators to send and receive data from both OpenMRS and Mobile WACh with the SHR, 2) test the resulting code in the Instant OpenHIE project, and 3) disseminate code and OpenHIE implementation guides for the broader global goods community.

Executive summary: 

Patient centered care (PCC) is defined as “providing care that is respectful of and responsive to individual patient preferences, needs, and values and ensuring that patient values guide all clinical decisions”, and was identified by the Institute of Medicine as a critical gap in achieving high quality healthcare and improving patient outcomes.[1] Evidence shows that a shift to PCC in the US significantly improved patient outcomes and reduced costs, but global health has yet to make this shift, partly due to information silos. Digital health tools can serve to support PCC, but just having tools that involve patients does not equal PCC. Those tools must also be properly integrated across the ecosystem, making information about patients’ evolving needs, preferences and contexts accessible and usable across the longitudinal record to inform shared decision making by providers and patients.

This proposal identifies a specific use case to improve shelf-readiness of digital health tooling that can better support the shift towards PCC in LMIC. Our use case builds upon a provider-centered EMR, a patient-centered technology (PCT), and the longitudinal shared health record (SHR) that integrates the data and informs the patients’ needs, preferences, and contexts. Our provider-centered EMR, OpenMRS, is a high quality, open source platform used in over 5,500 health facilities in 64 countries, and is a founding block to the data needs across a health program.  We will improve the OpenMRS interoperability capabilities by expanding the FHIR module to interact with a Shared Health Record using the OpenHIE architecture.

Our patient-centered technology, Mobile WACh, is a recognized digital health global good supporting patient centered care through bidirectional mobile messaging between clinic health care workers (HCW) and patient consumers. It is used for managing urgent, episodic, and chronic health conditions (e.g. MCH, mental health, HIV). Mobile WACh provides patients real-time personalized education, support, advice and referrals. Although Mobile WACh has successfully supported care within a siloed program, in order to be shelf-ready for maximally effective care and treatment in broader implementations, and to provide tailored support and guidance for patient decision-making about their health, Mobile WACh will need longitudinal data for a patient. In return, Mobile WACh collects critical patient-reported data, such as significant events, symptoms and concerns, that should be shared back to other care providers and the health record. We will improve the shelf-readiness of Mobile WACh by adding FHIR-support for interoperability with a Shared Health Record using the OpenHIE architecture.

The results contribute to a more complete longitudinal patient record that can be utilized within national implementations for improved continuity of care, and supports the shift towards PCC. Both products will also be able to be used by Instant OpenHIE for rapid deployment. The project includes leadership from University of Washington and Kenyatta National Hospital collaborating with OpenMRS, Mobile WACh, and OpenHIE communities; and leverages existing country-level projects in Haiti and Kenya to contribute to the requirements and ensure real-world applicability and implementability.


[1] Institute of Medicine (US) Committee on Quality of Health Care in America. Crossing the Quality Chasm: A New Health System for the 21st Century. Washington DC: National Academies Press (US); 2001.

Consortium Team: 

The Digital Initiatives Group at I-TECH (DIGI), University of Washington (UW) is composed of health informatics experts, digital health developers and implementers, data scientists, and digital health training specialists. DIGI faculty and staff lead multiple global goods communities of practice, have led national implementations of OpenMRS in multiple countries; and have extensive experience developing and implementing national eHealth architectures, including those leveraging the OpenHIE architecture and reference applications. 

The Mobile WACh team is a multidisciplinary collaboration between researchers at UW and Kenyatta National Hospital (KNH) in Kenya. The team includes Ob-gyns and pediatricians at UW and KNH, nurses at KNH, and epidemiologists and digital health researchers at UW. Since 2012, the team has developed and implemented 7 projects using Mobile WACh to support maternal-child, HIV and reproductive health in Kenya, including 5 randomized controlled trials.

Digital Health Atlas: 

Please see attachments.

WHO Classification: 
Electronic medical record
Application Status: 
Not Approved
Application Tags: 
shared health record


Hi Michelle,

Thank you for submitting a concept note for Notice E0. For the deliverables & schedule section in the concept note template attachment, please add an anticipated timeline to meet deliverables. Final concept notes are due May 22 at 5pm EDT.



Over the years, folks have used OpenFn "jobs" (little automation scripts) to coerce data from generic APIs so that it adheres to FHIR standards, and then to securely send that data between various applications (e.g., ODK, CommCare, OpenMRS, OpenHIM, DHIS2, etc.) These scripts can run in real-time (i.e., they can be "event based"), on timers (e.g., every 30 seconds), or on the success or failure of other scripts (i.e., in complex, branching process flows).

Recently, we've been in discussions with the team at Jembi, the maintainers of OpenHIM, and together we are looking for an opportunity to explore the relationship between OpenHIM "mediators" and OpenFn "jobs". There are likely certain situations in which it makes more sense to (a) modify or extend an application's own API, (b) to build a "mediator", (c) to write a "job", or (d) to implement some combination of the approaches.

Given that you've got a very clear use-case in mind around OpenMRS and MobileWACh, it might be incredibly valuable to test out the different pathways so that, as a community, we can learn more about when and why the approaches should be used, and exactly how they differ in terms of costs and capabilities. This would require slightly more funding from DS, of course, but it's the kind of upfront investment that could unlock really big savings down the line for future ICT4D projects.

Please reach out if you're interested and want to explore this a bit more. I can't speak for their capacity to engage right now, but I suspect that Daniel and the Jembi folks would be keen to help as well.

Hi Taylor - It would be great to understand more about OpenFn and how we might use it in a specific use case like this.  Maybe we can set up a call in a week or so?  You can find me on the DS slack org and DM me.

Hi Michelle

This is an interesting idea, particularly the linking to an SHR. Could you please unpack how you will address the identification of the patient for SHR data query from both systems? Interesting to understand the client identification / registry links that you see in this work.


Good question Carl.  For the purpose of this particular project, we plan to designate the SHR as the index, even though that may not be true in a real-world application.  In a bigger project, we would think about ways we could look towards interop with a designated best fit-for-purpose MPI/CR; however, the basic foundation laid here in the data exchange could be leveraged for that work.  I would be interested in hearing your thoughts on this though, and if you saw some other potential pathways here for us with patient identification.