Notice C

Promoting the collaborative development of proposals for investments in digital health global goods

Digital Square supports investments in digital health global goods, which are tools that are adaptable to different countries and contexts. Mature digital health global good software is software that is (usually) Free and Open Source (FOSS), is supported by a strong community, has a clear governance structure, is funded by multiple sources, has been deployed at significant scale, is used across multiple countries, has demonstrated effectiveness, is designed to be interoperable, and is an emergent standard application.

We are using an open proposal process. Your concept notes and proposals will be publicly posted, giving you and other submitters the opportunity to find collaborators and provide and receive feedback from your peers.

Concept-Notes (48 total)

Displaying 26 - 30

Integration of the OpenELIS Open-Source Laboratory Information System with Leading Clinical and Logistics Information Systems

Notice C Opportunity: 
Announcement C0: Global Good Software Development and Support

Executive Summary

Laboratory information systems (LIS) are a critical component of national health information systems architectures. Clinicians, lab professionals, national health sector leaders, and the donor community look to lab data to improve patient care and treatment, assist laboratories in achieving accreditation, support disease surveillance efforts, and inform outbreak responses. As low and middle income countries progress in development of coordinated eHealth investments, LIS can be leveraged to integrate with other clinical information systems and with disease surveillance and reporting systems to meet public health goals.

The primary open-source product which fills the distinct use cases and workflows of reference labs is OpenELIS (https://sites.google.com/site/openelisglobal/). OpenELIS was originally developed in several state public health laboratories within the US, and has since been adapted and deployed in Vietnam, Haiti, and Cote d’Ivoire at wide scale, and has also been integrated into and deployed with the leading OpenMRS distribution, Bahmni. Key features available within OpenELIS include: flexible test catalogue management; batch processing of bio-samples; barcode generation and printing capability; “plug and play” integration with automated analyzers covering a wide range of test types; integration with a data visualization dashboard to display indicators for national surveillance; generation of CSV file exports to facilitate flexible indicator reporting to a variety of stakeholders; and language localization in English and French.

This proposal will integrate the OpenELIS open-source LIS (https://sites.google.com/site/openelisglobal/) with the OpenMRS electronic medical record (EMR) (https://openmrs.org/), with the integrated Bahmni clinical information system package (https://www.bahmni.org/), as well as with the OpenLMIS logistics management information system (LMIS) (http://openlmis.org/). The project will advance interoperability of OpenELIS with other systems in the context of both direct bridges as well as linkage through heatlh information exchange (HIE), modeled on the OpenHIE framework (https://ohie.org/). The proposed project will significantly advance flexible, standardized, deployable solutions for interoperability of OpenELIS with leading EMR and LMIS products, thereby improving the ability of the laboratory sector in LMICs to support laboratory monitoring for patient care and outbreak detection.

Consortium Team

The consortium team is led by the University of Washington (UW) and includes Village Reach, and Bahmni Coalition. There are two groups from UW which will come together to carry out this proposal: I-TECH (https://www.go2itech.org/) and the UW Clinical Informatics Research Group (CIRG) (http://cirg.washington.edu/). I-TECH is a Center within the UW Department of Global Health (DGH) that leads health systems strengthening initiatives in more than 20 countries.  I-TECH has led OpenELIS development and implementation in Haiti and Cote d’Ivoire since 2009 and 2010 respectively. In Haiti and Cote d’Ivoire, I-TECH has supported implementation of OpenELIS in more than 75 national public health reference labs as well as in large-volume clinical laboratories. As a part of the Haiti project, I-TECH’s Haiti-based software development and implementation team has collaborated with the international IT firm Soldevelo (https://www.soldevelo.com/) to establish integration between OpenELIS and OpenMRS, as well as an OpenHIE-based interoperability layer which is suitable for supporting data exchange between LIS and EMRs as well as between LIS and the DHIS2-based national aggregate data reporting system.

As of October 2018, I-TECH is supporting the launch of a unified Global Health Information Systems (GHIS) Unit, which will serve as a central hub within I-TECH and the UW DGH for health informatics expertise, under the leadership of faculty member Dr. Nancy Puttkammer. The GHIS Unit brings together experienced I-TECH staff from separate country teams with a range of expertise relevant for health informatics in global settings, including in requirements gathering and technical design, software development, implementation planning, technology project management, human capacity building and training, data analytics, and assessment and evaluation of digital health solutions.  The GHIS Unit is set up as a distinct business unit with a flexible mechanism for contracting technical assistance services to serve digital health project needs for Principal Investigators (PIs) from across UW, or to serve clients outside of UW.  This mechanism offers the potential to harness expertise from faculty, staff, and students from the UW’s Schools and Departments including Health Sciences, Computer Science and Engineering, Bioengineering, Information Sciences, Business and others.

I-TECH also brings to the project the expertise in laboratory systems in LMIC, through our Laboratory Systems Strengthening (LSS) Team. Led by Dr. Lucy Perrone, a public health laboratory advisor specializing in infectious disease diagnosis, surveillance and response, and laboratory capacity building in LMICs, the team leverages partnerships within UW and with external collaborators globally on supporting laboratory capacity building. The team’s mission is to improve laboratory operations for optimal patient care and treatment, disease surveillance and response, and biosecurity. The team has conducted training and mentoring in laboratory leadership and management, supported policy development for laboratories, and worked with reference and clinical laboratories on advancement toward accreditation.  As part of reinforcing good laboratory practice, the team has also supported customization and implementation of LIS for improved information management within the laboratory.  The LSS team is available to contribute expertise in the fit between LIS and laboratory workflows and systems to the proposed project.

As noted, the UW team also includes CIRG, under leadership from Jan Flowers. CIRG designs, develops, builds, and operates information systems that securely manage health information for projects in clinical, public, and global health settings. CIRG has led numerous lab informatics projects involving OpenELIS and BLIS, founded OpenLabConnect, and developed LIS interoperability projects, and has worked in Haiti, Cote d’Ivoire, Kenya, Mozambique, Cameroon, Namibia, and Vietnam. Ms. Flowers serves on the board of directors for both OpenELIS Foundation and OpenMRS, and are the founders and leads the OpenHIE LIS Community of Practice (hereafter referred to as the “LIS COP”), which was funded under Digital Square Notice B to develop and share common standards and best practices amongst the open-source LIS community.

Village Reach (http://www.villagereach.org) works with Ministries of Health to solve healthcare delivery challenges in low-resource environments. To do this, it focuses on being is a global health informatics innovator in logistics management that develops, tests, implements and scales new solutions to critical health system challenges in low-resource environments. Village Reach leads the development of the founders and leaders of OpenLMIS, the leading logistics management information system in LMIC. Mary Jo Kochendorfer will be the point person representing OpenLMIS in this project.

The Bahmni Coalition (https://www.bahmni.org/bahmni-coalition/) is a group of organizations leading and governing the Bahmni software, an OpenMRS distribution that specifically addresses the use case of hospital management. The Coalition includes organizations which use Bahmni, contribute to Bahmni development or implementation, or offer services around Bahmni.

Resumes for key staff from I-TECH’s GHIS Unit, CIRG, VillageReach, and Bahmni are included as attachments to the final proposal.

Project Description

Problem Statement

Strong laboratory systems are integral for diverse public health purposes such as monitoring suppression of HIV viral load among patients receiving antiretroviral treatment, measuring antimicrobial resistance of pathogens, and detecting outbreaks of cholera and other infectious diseases. LIS systems can support good laboratory practice. Interoperability between LIS, EMR, and LMIS can advance global public health goals; however, there are not currently standards-based integrations between leading open-source products for each of these system types. LIS and EMR interoperability can substantially impact patient care by improving the accuracy of orders and results, reduce effort of clinical and lab staff in data entry, and reduce turnaround times for providing test results to clinicians, patients, and public health decision makers. LIS and LMIS interoperability can improve quantification estimates for lab reagents, test kits, and other consumables within national supply chains, as well as improve decision making by laboratory personnel about which tests should be run at which laboratories, based on stock levels for key lab commodities. HIS ecosystems in low- and middle-income countries can be substantially strengthened by improved integration of leading LIS, EMR, and LMIS products.

Demonstrated Need and Potential for Health Impact

LIS are a critical component of national health information systems architectures. Clinicians, laboratory professionals, national health sector leaders, and the donor community look to laboratory data to improve patient care and treatment, assist laboratories in achieving accreditation, and support disease surveillance efforts and inform outbreak responses. First, LIS play an integral role in laboratory quality management (ISO 15189) by improving organization and management of bio-samples and testing queues, by reducing transcription errors in laboratory results, and by reducing turnaround-time for diagnostic test results.  Second, LIS can facilitate a critical link between the laboratory and clinical services, so that patients can be appropriately diagnosed and managed in light of accurate and timely laboratory test results.  Finally, LIS can contribute to disease surveillance by improving the availability of laboratory data at regional and national levels.  As low and middle income countries progress in development of coordinated eHealth investments, LIS can be leveraged to integrate with other clinical information systems and with disease surveillance and reporting systems.

Presently, OpenELIS is a leading open-source product with particular value for use in high-volume reference laboratories. Effective national laboratory systems typically include clinical laboratories as well as reference laboratories at regional or national levels. Reference laboratories have distinct information management needs, such as the need to manage a large catalogue of test options, to handle batch processing of samples, to run test samples for quality control, and to receive orders and dispatch results to lower-level laboratories at high volume.

There are several existing open-source LIS products focused on smaller clinical laboratories, such as Basic Laboratory Information System (BLIS) and SENAITE Labs (formerly Bika Labs). These systems are optimized for the workflows of basic clinical labs operating within clinics and smaller hospitals, where a limited array of laboratory test types and a limited volume of tests are run. These systems can play complementary roles to OpenELIS within national laboratory systems.

In contrast, OpenELIS fills the distinct use cases and workflows of reference labs. OpenELIS features such as batch processing, barcode generation, and analyzer integration provide laboratories processing high sample volumes with a means of reducing turnaround time. The value of OpenELIS in LMICs is demonstrated by the persistent use of the product in more than 20 high-volume regional laboratories in Haiti more than 18 months after withdrawal of external donor funding. It is also illustrated in Cote d’Ivoire, where the Ministry of Health has shown its commitment to the OpenELIS product by expanding its use in regional labs over an alternative open-source LIS.

The proposed project will significantly advance flexible, standardized, deployable solutions for interoperability of OpenELIS with leading EMR and LMIS products, thereby improving the ability of the laboratory sector in LMICs to support laboratory monitoring for patient care and outbreak detection.

Technical Approach

Work Stream 1: Integrating OpenELIS and OpenMRS

OpenELIS and OpenMRS are the two leading open-source systems in the LIS/EMR technology space for LMIC, and as such, cover a significant portion of implementations.  The consortium team will seek to design and develop minimum viable products (MVPs) for two strategies for linking OpenELIS and OpenMRS using the following two approaches:

  • Direct Bridge:  This assumes that the systems are hosted on a co-located server and involves a direct exchange of laboratory orders and laboratory results data between the systems for a single health facility.  This solution would be specifically for implementers who had no ability to support or need for a larger architecture to address additional or more advanced interoperability use cases. A technical description of this strategy is shown in Figure 1 and a schematic is shown in Figure 2.

Figure 1: Technical Description of OpenELIS – OpenMRS Direct Bridge

Figure 2: System Architecture for OpenELIS - OpenMRS Interoperability*

*Note: “iSantéPlus” is Haiti’s national electronic medical record system, built on the OpenMRS platform


  • Health Information Exchange (HIE) Bridge, modeled on OpenHIE:  More complex than a direct bridge between OpenMRS and OpenELIS, this requires multiple pieces of a national eHealth architecture to be in place and supported. This solution offers flexibility for addressing additional and more advanced use cases for data exchange between OpenELIS, OpenMRS, and other systems, such as a national aggregate health indicator reporting system (e.g. DHIS2) or a master health facility list or a terminology service.  A technical description of this strategy is shown in Figure 3.

Figure 3: Technical Description of OpenELIS – OpenMRS Bridge via OpenHIE

Both strategies will build upon I-TECH’s foundational work with LIS - EMR interoperability in Haiti, having developed both a direct bridge prototype and an OpenMRS-LIS data exchange deployment using OpenHIE.  In 2017, I-TECH re-developed the Haiti national EMR, iSante, using the OpenMRS platform, gaining substantial experience with the OpenMRS development and integration with the OpenHIE interoperability framework.  The goal of redeveloping the system using the OpenMRS platform is to enhance sustainability of the system by leveraging a well-established global digital good with a broad developer and implementer community.  This proposal would expand on that goal by contributing more advanced functionality and integration for the broader global goods community.  

The current proposal will build upon the existing Haiti work to generalize the solutions such that they can be robustly implemented in other instances where OpenMRS - OpenELIS interoperability is desired, either through a direct bridge or through OpenHIE.  We specifically propose to design and develop generalized prototypes for these two solutions via the following activities:

  • Activity 1.1:  Document functional and technical specifications for OpenELIS-OpenMRS workflows, including patient identification and registration, lab test orders, and lab test results;
  • Activity 1.2: Generalize the technical designs for both the direct bridge and the HIE bridge type solutions;
  • Activity 1.3: Develop generalized minimum viable products (MVPs), provide testing and quality assurance, and release the products;
  • Activity 1.4: Develop documentation of both implementation and technical aspects of the MVP releases;
  • Activity 1.5: Disseminate information about the MVPs with broader eHealth community through OpenMRS and OpenHIE annual meetings.

The goal of Activities 1.1 and 1.2 will be to generalize functional and technical specifications for both the direct bridge and the HIE bridge developed under I-TECH’s Haiti project, and then work with the OpenMRS community to review and refine the designs.  The team will seek to modify the existing specifications so that anyone can leverage them in a variety of contexts and eHealth architectures. During the product development Activity 1.3, the UW team, with participation from both I-TECH and CIRG, will assign staff software developer who is familiar with OpenMRS and OpenELIS to meet the consensus specification for both the bridge and OpenHIE solutions.  This work will result in two MVPs which can be tested in a demonstration environment and suitable for implementation. 

In Activities 1.4 and 1.5, the UW team will develop documentation of the releases which could be shared with developers, implementers, and decision makers.  Documentation will describe the technical architecture and codebase as well as the requirements and workflows for successful implementation.  To ensure that the work is widely shared and disseminated, we propose to present at least 2 webinars on the work and also to travel to attend the annual OpenMRS and OpenHIE implementers meetings in 2019 to present and build support for the work. Presence at these forums will be instrumental in developing momentum toward wider deployment, gathering of lessons learned, and progressive future improvement upon the MVPs.

As a final step within the scope of the presently proposed project, the consortium team will seek to identify implementation sites and partners which would be suitable to deploy the beta releases and gather feedback.  Carrying out production-level deployment of the two solutions in clinical and laboratory settings is beyond the scope of this proposal but could be undertaken in a future phase.  Also part of future phase activity would be publishing and sharing a prioritized roadmap in the OpenMRS, OpenLIS, and OpenHIE communities of practice for improvements and additional features, based upon what is learned during one or more future deployments.

Workstream 2: Merging the OpenELIS Global and Bahmni OpenELIS Code Bases

The Bahmni software is a distinct distribution of the OpenMRS platform for hospital management, which includes an early fork of OpenELIS v3.1 from 2013. The Bahmni version of OpenELIS includes the basic functionality of lab management, but was customized through 2015 with additional solutions to lab workflows and non-standard interoperability with the other components within Bahmni. The main branch of the global OpenELIS codebase now includes much more advanced functionality for managing laboratory workflows and the information within, which have not been merged into the Bahmni codebase.  

An example of some features presently available in OpenELIS Global which are not present in Bahmni include:

  • Module for real-time UI based test catalog management module for modifying tests and test panel configurations; which ITECH has found to be a critical level of control for laboratory leadership to successfully implement and sustain OpenELIS in LMIC laboratories.
  • Barcode label generation and batch entry capability to make it easier to process a high volume of orders.
  • HIV viral load dashboard for visualization of population-level health outcomes.
  • Easy install process, including a default test catalog.

For several years, the Bahmni developers have expressed a strong desire to move to the current OpenELIS Global code base to leverage the more advanced features, contribute to a community product, and to collaborate on shared roadmap features.  However, Bahmni OpenELIS customizations have prevented the work from being addressed.  Merging the two code bases within Bahmni will help to unify the OpenELIS community around an optimized software product and will support broader engagement of teams across the OpenELIS community who can then work on a forward-looking shared roadmap, ensure technology upgrades, and improve upon OpenELIS system features within Bahmni. In short, a shared code base will support long-term sustainability of the OpenELIS product by broadening the pool of developers to collaborate. For Bahmni, merging back into the main OpenELIS Global code base will allow Bahmni to leverage existing improvements as well as ongoing work happening under the OpenHIE LIS COP to strengthen OpenELIS.

The specific activities to be carried out by the consortium include:

  • Activity 2.1:  Assess differences between the two code bases, in both functional and technical aspects;
  • Activity 2.2:  Document functional and technical specifications for the software development team to merge the code bases;
  • Activity 2.3:  With the Bahmni Coalition, develop a roadmap to address the tasks for merging the code bases.

The roadmap for merging will identify high-priority, must-have development and will include steps for testing, quality assurance, and release.  The UW team will collaborate with the Bahmni Coalition to develop and prioritize the OpenELIS roadmap via an in-person week long workshop and on-going virtual community collaboration.  The workshop will include both design meetings as well as a developer hackathon to test and prototype portions of the code merging strategy.  The UW team will then summarize the results of the workshop as a roadmap document which could be reviewed and commented by a broader set of Bahmni coalition members and members of the OpenHIE LIS COP before finalization.

Following completion of Activities 2.1-2.3, the OpenELIS community will collaborate with the Bahmni consortium to identify future resources and strategies to carry out the software development work.  Other than preliminary test and prototype activities for designing the merge strategy, the software development actually addressing the merge will not be a part of this funding.

Workstream 3: OpenELIS and OpenLMIS Integration

Several countries, such as Cote d’Ivoire, Malawi, Tanzania, and Zambia, are implementing the OpenLMIS system to improve logistics data management and use. There are multiple use cases for integration of OpenLMIS and OpenELIS (see below) and such integration is of strong interest to VillageReach and I-TECH/UW.  In collaboration with Village Reach, I-TECH plans to pursue integration of OpenELIS and OpenLMIS by mapping priorities for functional integration and by defining detailed specifications for product development.

Specific activities include:

  • Activity 3.1:  Review OpenLMIS and OpenELIS to identify preliminary user stories and use cases for integration of the products;
  • Activity 3.2: Meet with lab professionals and other stakeholders from Haiti, Cote d’Ivoire, Vietnam, Cameroon, or other LMIC to gain input on use cases and functionality for LIS and LMIS interoperability;
  • Activity 3.3: Define detailed specifications for interoperability to guide development, and develop proposal for level of effort and strategy necessary to achieve the work.

Activity 3.1 involves a discovery phase of collaboration between UW and VillageReach.  As both organizations have active engagements with their user bases, we will seek to opportunistically leverage client input during the discovery phase.  The outcome of this activity will be draft user stories and use cases, and draft high-level functional and technical specifications for LIS-LMIS interoperability.  Then during Activity 3.2, UW and VillageReach will plan, organize, and sponsor a two-day workshop in order to obtain focused input from laboratory professionals from LMIC on the draft specifications.  We will seek to convene a satellite workshop linked to the Global Digital Health Forum or OpenHIE Implementers meeting, and will sponsor laboratory professionals from at least two LMIC to attend the satellite workshop.  The workshop will also be open to other interested attendees of the conference. 

Following the participatory workshop, as part of Activity 3.3, the UW and VillageReach teams will use the input to refine and flesh out detailed functional and technical specifications.  It is anticipated that the workshop will generate interest in executing the technical work necessary to achieve interoperability between OpenELIS and OpenLMIS, and may help to identify resources and resource persons for completing the work. However, the software development work goes beyond the current proposal and could be part of a later phase of work.

Use of Digital Health Technologies

Across the three workstreams, the UW team will collaborate with OpenMRS and OpenLMIS developers and implementers, including the OpenMRS community, the Bahmni Coalition, and VillageReach.  Technologies which will be used during the proposed work include: OpenELIS Global v8.4 (https://github.com/openelisglobal/openelisglobal-core), OpenMRS, Bahmni (https://github.com/Bahmni/OpenElis), OpenLMIS (https://github.com/OpenLMIS), OpenHIE (https://ohie.org/), and Github.  

OpenELIS is a standards-based open source laboratory information system that was initially developed by state public health laboratories in Iowa and Minnesota to support standard laboratory business processes as defined by the Association of Public Health Laboratories (APHL).  It was forked and adapted into OpenELIS Global in 2009 by I-TECH and CIRG at UW to support both the basic and advanced clinical laboratory workflows in low-and-middle income countries.  Since then, it has been continuously improved upon by multiple organizations to meet both a broader set of LMIC laboratory use cases and needs, and adapted by implementers for specific local and regional context.  It has been implemented in Haiti, Cote d’Ivoire, Vietnam, Kenya as part of the national eHealth architectures, and is integrated as part of the core offering of the Bahmni HMIS distribution, used across multiple countries.  In recent years, I-TECH has led software development and implementation of the global fork of OpenELIS, now in version 8.3. OpenELIS is built on a platform using Java, PostgreSQL, Tomcat, Struts, and Ubuntu 16, and I-TECH has plans to update the core product by moving from Struts to Spring (https://spring.io) in 2018-19 in order to ensure compliance with data security frameworks required in US government-supported laboratories.

OpenHIE is a community of practice which is dedicated to improve the health of the underserved through open and collaborative, development and support of country driven, large scale health information sharing architectures.  The OpenHIE community seeks to enable large scale health information interoperability, offers freely available standards-based approaches and reference technologies, and supports community needs through peer technical assistance.

OpenHIE LIS Community of Practice (LIS COP) is a new open source sub-community of practice under OpenHIE that serves to coordinate efforts on several widely-used mature open source LIS products - OpenELIS Global, BLIS, Senaite (formerly Bika) an open source independent lab instrument interface software called OpenLabConnect, and the integration of these technologies into the broader facility-level and upper-level HIS ecosystem. Created in 2013, the OpenHIE collaborative has defined a comprehensive design pattern for the national eHealth architecture in low-and-middle income countries.  The collaborative offers example reference applications, and health information standards to serve as the component or external system functions, with published implementation guides, defined standards, and other resources available. 

OpenMRS is the most widely usedopen-source electronic medical record (EMR) system globally. It offers an open-source platform for building one’s own EMR, as well as a reference application for a “starter EMR.” The OpenMRS community has supported EMR implementations in thousands of health facilities globally, and brings together practitioners with different backgrounds including technology, healthcare, and international development.

Bahmni is a reference hospital information management system built as a distribution of the OpenMRS platform.  It integrates the OpenELIS laboratory information system and Odoo ERP system.  It includes modules for patient registration, clinical services, laboratory services, inpatient management, PACS integration for radiology services, stock management, billing management, and reporting.  

Workplan and Schedule

The project is planned for a 12 month period.  The workplan below lists tasks for each workstream and activity, and identifies who will be responsible (R), accountable (A), consulted (C), or informed (I).  The workplan also shows the due dates for each deliverable as noted with “X”.

Project Deliverables

Workstream 1

  • Generalized, standards-based functional and technical requirements for OpenELIS-OpenMRS workflows including: ordering a new laboratory test, canceling a laboratory test, sending a result, viewing a result, and reporting on tests ordered, tests canceled, pending tests, and results transmitted
  • Minimum viable product for OpenELIS-OpenMRS direct bridge, which has been tested and documented and released via Github
  • Minimum viable product for OpenELIS-OpenMRS direct bridge, which has been tested and documented and released via Github
  • Presentation delivered at OpenMRS or OpenHIE annual meeting
  • Blog postings within OpenMRS community and OpenLIS COP documenting design process, decision-making, and release

Workstream 2

  • Documentation on differences in OpenELIS and Bahmi code bases
  • Agenda for code integration workshop
  • Vetted roadmap for merging code base for OpenELIS Global within the Bahmni product
  • Resourced work plan for achieving the specifications for OpenELIS -- Bahmni integration, suitable for use in funding proposal
  • Blog postings within Bahmni website and OpenLIS COP documenting design process, decision-making, and release

Workstream 3

  • Preliminary use cases and specifications for OpenELIS and OpenLMIS integration
  • Agenda for workshop with lab professionals from LMIC
  • Detailed use cases and specifications for OpenELIS and OpenLMIS integration, reflecting input from lab professionals from LMIC
  • Resourced work plan for achieving the specifications for OpenELIS and OpenLMIS integration

Digital Health Atlas

OpenELIS is registered as a project within the Digital Health Atlas.

Overview Summary

This set of global goods includes technologies for two-way data exchange between a leading open-source laboratory information system (OpenELIS) and two leading electronic medical record platforms (OpenMRS and Bahmni) as well as one logistics management information system (OpenLMIS,) so that diagnostic data for patient care and public health surveillance becomes more timely and accurate and laboratory systems function with minimum disruption in critical supplies.  The requested investment from Digital Square will fund generalizable designs for message transfer between software products, deployment-ready products for linking LIS and EMRs, documentation and communication about the products and technologies.

Community Feedback

For Workstream 1, the UW team will elicit input from the OpenMRS community by posting to the talk forum, doing design forum sessions (leveraging the existing twice weekly design forum meetings), and building consensus with OpenMRS core developers on technical approaches, such as around handling the rest API. The project team will also collaborate within the OpenHIE LIS Community of Practice (COP) to ensure that the work is broadly relevant to LIS-EMR interoperability, and can be leveraged by development teams working with other LIS and EMR software products.

The UW team will support the activities of Workstream 2 by convening a face-to-face workshop focused on code merging, to include at least two developers identified from the Bahmni Coalition (possibly one from Leapfrog and one international developer).  The UW team will also use video conference meetings and online chat channels such as Slack or Skype for daily to monthly communication with members of the Bahmni Coalition.

For Workstream 3, the UW and VillageReach teams, which are co-located in Seattle, will seek to work together through a series of half-day or day-long work sessions.  As described above, the organizations will also collaborate to host a working meeting with laboratory-sector representatives from LMIC, as a satellite to a conference like the Global Digital Health Forum conference.

Use Cases and User Stories

Work Stream 1: Integrating OpenELIS and OpenMRS

Use Case 1:  Clinicians need the ability to interface their EMR systems with LIS systems to automate many of the processes that deal with laboratory testing.  This will reduce time and errors in testing and reporting.  Clinicians need the ability to order and cancel tests from the EMR system and have those requests sent directly to the LIS.  The LIS needs the ability to return test results and status to the EMR system.  By integrating the LIS and EMR systems, these processes will be automated and will be available for viewing in both systems. This will decrease waiting time and increase efficiency and lead to better patient care.

Scenario:  A Clinician is seeing a patient.  She decides to order a lab test to diagnosis the patient’s medical condition.  While in the OpenMRS system he creates a test request.  This request is automatically transmitted to the OpenELIS system, which is deployed on a shared server within the clinic.  The lab technician views the request and is notified by OpenELIS that the lab is out of the needed supplies to perform the test.   An automatic notification is sent from OpenELIS to the OpenMRS about the stock out.  The clinician requests the test be sent to another lab, the request is returned automatically to OpenELIS system.

Use Case 2:  Many facilities require the same automated functionality around lab testing between their EMR and an offsite reference laboratory where the EMR and LIS systems are no co-located.  In order to meet this need an automated linkage can be developed via the HIE.  The tools will be developed that will allow the EMR and LIS to exchange message types via a third software interface that sorts and queues the messages and relays messages to both the LIS and EMR.

Scenario:  A smaller hospital is using an EMR system but relies upon an external reference laboratory for certain advanced diagnostics, such as PCR-based tests.  The lab orders and bio-samples are sent to the regional reference laboratory.  Since the systems are not connected, this is a manual process for requests and outcomes.  Using the linkage to the HIE, clinicians in the hospital now have a direct information sharing link to the regional reference hospital.  As test requests are entered into the EMR system they are managed through the HIE interface and then delivered to the LIS system in the regional reference laboratory.  Results are returned the same way, thus increasing efficiency and accuracy.

 

Workstream 2: Merging the OpenELIS Global and Bahmni OpenELIS Code Bases

Use Case 3:  Hospitals across the globe are using the Bahmni package that includes an outdated version of OpenELIS.  For ease of installation, better security, and more robust features these facilities would benefit from incorporating the latest features of OpenELIS Global v8 developed at UW.  With the integration of OpenELIS v8 into the Bahmni platform the package will contain a robust and secure LIS system.  This will allow greater flexibility in test management and reporting in laboratories.  The integration will also increase cooperative work between the UW and the larger OpenELIS Global community.  This will lead to greater efficiencies as a single code base will be in use and development will not be duplicated across multiple versions.

Scenario:  A new facility is installing the Bahmni platform.  They are opting for the full package that includes OpenELIS.  They can be assured that they have the latest version of OpenELIS that meets current security and coding standards.

Use Case 4:  There are currently multiple options around integration of LIS, EMR, and LMIS.  By uniting the LIS COP, standards can be developed to create more streamlined documentation and installations.  Standard and more detailed work plans around integration and use case scenarios will be developed and assist in the ease of adopting these systems on a larger scale.

Scenario:  A regional hospital is installing OpenELIS as part of Bahmni.  Installation is streamlined as there is one set of standards and procedures for installations.  The technology team can easily find the latest version of the code base and the latest installation package, leading to a user-friendly implementation experience.

Workstream 3: OpenELIS and OpenLMIS Integration

Use Case 5: Without reagents, laboratory analyzers cannot process samples. When alerted to a reagent or test kit stock out, laboratory technicians can decide whether to perform the test using a different technique for which there are supplies or to refer the test order and sample to another laboratory which does have necessary commodities in stock.  To be able to receive this alert the laboratory staff will need to be alerted in their LIS system of stock outs that are tracked by the LMIS system.  Users will be able to order a test on a specimen that arrives in the lab, once the order is placed via the LIS system the lab staff would be notified by the LMIS system if there is a stock out of the needed supplies to perform the test.  This will allow technicians to make a timely decision about what to do next.  With this information they can determine if the test order should go to another facility or if the test can be performed using other items that are in stock.

Scenario: A clinician orders a test for a patient.  The request is sent to the lab.  The lab technician is immediately notified by the LMIS system that there is a stock-out of the needed supplies to test the specimen.  The technician can notify the clinician that the lab does not have the needed supplies, the clinician can order a different test or ask for the test to be ran at a different lab.  This will save valuable time in diagnosis

Use Case 6: Having granular data on usage of commodities at peripheral levels can help with forecasting and stock management at higher levels, to reduce both wastage and stock outs.  When receiving commodity usage information for laboratory reagents and other commodities from laboratories in real time, it is possible to improve product tracking and forecasting within the national LMIS.  Having this level of data will assist managers in understanding the demand at particular facilities and determine modify stock delivery based on demand.

Scenario:  A regional commodities manager is noticing that a lab is consistently out of stock on supplies needed for a specific test.  He can further see that a nearby lab is overstocked on the same supplies.  The distribution system can be modified to reduce stock at one lab and increase stock at the other.  This can be done in real time which will benefit both labs.


Self-Assessment on the Global Goods Maturity Model

A self-assessment of the OpenELIS software product is included as an Appendix.


Tags

  • Laboratory information systems
  • LIS
  • interoperability
  • OpenHIE
  • Logistics Management Information System
  • LIMS
  • OpenLMIS
  • Bahmni
  • OpenMRS

 

Must be an existing global good as defined by

Must be deployed in at least three middle-income countries. (Please list the countries)

  • Haiti, Cote d'Ivoire, Vietnam, Kenya, + Bahmni HMIS Distribution Implementations
Is it made available under Open Source Initiative approved software license

The software has been applied to a health domain?

  • Yes
 
Application Status: 
Not Governing Board Approved

Lorem Ipsum for Digital Health

Notice C Opportunity: 
Announcement C0: Global Good Software Development and Support

I. Executive Summary

When developing new software functionality or better dashboards, or exploring new approaches like machine learning, software developers use “synthetic data”—fictional data built of anonymized data that is realistic but not real. For the United States and a few other medically advanced countries, the Synthea Data Generator is a widely used open source tool to create hundreds of millions of realistic but fake patients. However, there isn’t a synthetic data generator for any developing country.

This means that developers who wish to design new services, or improve existing global goods like OpenMRS, iHRIS, or DHIS 2, use existing demonstration data made specifically for each tool. As a result of this synthetic data constraint, solutions for each global good tend to be:

  • Limited—only able to work within the specific context of that solution

  • Siloed—missing key data references and indicators from other solutions

  • Biased—not representative of patients’ full health service interactions.

Lorem Ipsum for Digital Health will create a harmonized synthetic data generator for malaria or HIV/AIDS that can be used by software developers, policy-makers, and researchers to improve the functionality and data analysis capabilities of DHIS 2, OpenMRS, iHRIS, and related services like OpenInfoMan, Global Open Facility Registry, and more. This new data will be statistically similar to country-level realities yet totally safe for public usage across the global digital health community, including:

  • Testing end-to-end workflows for data analytics and aggregations across iHRIS, OpenMRS, and DHIS 2

  • Refining statistical models and data visualizations for students, academia, and policy-makers

  • Developing algorithms, machine learning applications, and other future feature development.

The new module will revolutionize the way digital health software is developed and will speed up innovations in data visualization and machine learning.

II. Consortium Team

For 39 years in 100 countries, IntraHealth International has partnered with local communities to make sure health workers are present where they’re needed most, ready to do the job, connected to the technology they need, and safe to do their very best work. IntraHealth has a long history in developing successful data tools for digital health applications. From mobile apps to management software to multi-language interactive voice response, we offer health workers and managers the tools and technology they need to do their very best work.

We develop solutions that are open source, data-driven, sustainable, and collaborative. And as a pioneer in the field of health workforce informatics, we’re committed to using technology, information, and analytical approaches to support the people at the center of our health systems.

This intervention will be led by the following IntraHealth staff and backed-up by a full range of health experts, project managers, and software developers.

  • Richard Stanley, Senior Technical Advisor, has over 20 years of experience in information and communication technologies, including high-quality research and rapid data analytics for monitoring and evaluations in Somalia, South Sudan, Uganda, Egypt, and Sudan. He holds a PhD from the University of Oxford, UK.

  • Luke Duncan, Digital Health Assistant Director, has over 20 years of experience in software development, including leading the developing of iHRIS, the flagship human resources solution for global health, and multiple data interoperability standards and reference designs to connect iHRIS, DHIS2, and OpenMRS.

  • Ally Shaban, Global Health Workforce Technologist, has over 7 years of experience in software analysis, design, development, and implementation in both East and West Africa, and is an expert in open source health software including mHero, iHRIS, OpenHIE, OpenInfoMan, OpenHIM, and RapidPro.  

  • Dana Acciavatti, Senior Portfolio Manager, has 17 years of experience strengthening the systems that support health workers globally and currently manages IntraHealth’s portfolio of digital health activities and projects. 

Jembi is an African non-profit company, headquartered in South Africa, and specializing in digital health and open source software development and implementation. Jembi has a successful track record developing and implementing open source software in the health sector including a number of African countries.

It has contributed to many open source software development projects, including OpenMRS, OpenHIM and OpenHIE. Jembi curates the reference technology for the interoperability layer (www.openhim.org) of theOpenHIE and related reference profiles likeHearth.

The following Jembi staff will support this initiative:

  • Carl Fourie, Senior Program Manager, has ten years of experience providing insight and guidance to architectural teams and currently leads Jembi's OpenHIE activities.

  • Pierre Dane, Director of Technology, has over 15 years of technical experience and leads Jembi’s technical division with a strong focus on systems development and interoperability.

III. Project Description

Problem Statement

When developing new software functionality or better dashboards, or exploring new approaches like machine learning, software developers use “synthetic data”—fictional data built of anonymized data that is realistic but not real. Synthetic data ensures complete patient confidentiality because the personal information is totally fake, yet because it preserves real health records and trends, it can be used to develop algorithms and other tools that are immediately functional with real patient data.

For the United States and a few other medically advanced countries, the Synthea Data Generator (https://synthetichealth.github.io/synthea/) is a widely used open source tool to create hundreds of millions of realistic but fake patients, including their associated health care records, and outputs data in interoperable formats like FHIR. The data is widely used for building new services in these countries.

However, there isn’t a synthetic data generator for any developing country. This means that developers who wish to design new services, or improve existing global goods like OpenMRS, iHRIS, or DHIS 2, use existing demonstration data made specifically for each tool. This data is fragmented across the digital health landscape with no common health facilities, administrative units, or patients, and is often years old and missing current health activities and trends.

As a result of this synthetic data constraint, solutions for each global good tend to be:

  • Limited—only able to work within the specific context of that solution

  • Siloed—missing key data references and indicators from other solutions

  • Biased—not representative of patients’ full health service interactions.

Lorem Ipsum for Digital Health will create a harmonized synthetic data generator for malaria or HIV/AIDS based on actual low- and middle-income country (LMIC) disease burden trends and patient/health system activity that can be used by software developers and researchers to improve the functionality and data analysis capabilities of DHIS 2, OpenMRS, iHRIS, and OpenInfoMan— all existing global goods deployed in the health sector in multiple low- and middle-income countries and available under Open Source Initiative approved software licenses.

The module will have three main areas of functionality. Adding LMIC health services context and creating demographic models based on actual LMIC demographics and disease burdens are the first two areas. These areas are needed to develop the third function, adding a malaria or HIV module to the Synthea Generic Module Framework to create models of health events in patients’ lives. We will decide on either malaria or HIV/AIDS based on guidance from Digital Square and feedback from OpenHIE and Global Digital Health Network communities.

The new module will revolutionize the way digital health software is developed and will speed up innovations in data visualization and machine learning.

Technical Approach

This proposal will add features to Synthea, via a new module, so it can generate data for LMICs where the health services context, disease burden, and demographics are markedly different from advanced economies. This new data will be statistically similar to country-level realities yet totally safe for public usage across the global digital health community, including:

  • Testing end-to-end workflows for data analytics and aggregations across iHRIS, OpenMRS, and DHIS2

  • Refining statistical models for students, academia, and policy-makers

  • Developing algorithms, machine learning applications, and other future feature development.

We envision our efforts would create a Synthea module with three main areas of new functionality:

  • Adding the LMIC health services context, which is markedly different than in medically advanced countries. For example, most LMICs focus on large government-run primary health care-based health systems, where health insurance is rare.

  • Creating demographic models based on actual LMIC demographics and disease burdens, including relatively young populations, with high communicable disease and maternal and child care interventions.

  • Adding a malaria or HIV module to the Synthea Generic Module Framework to create models of health events in patients’ lives. Similar modules already exist but they reflect the disease burden in the United States. Building the module will require substantial research with our country programs to develop model parameters based on realistic malaria or HIV patient, health worker, and facility activity.

We will base implementation for the either the malaria or HIV module primarily on Uganda, using its patient demographics, locations, factual data on the disease burden, and infection statistics. We will consult with our country program in Uganda and experts in the country on the parameters needed for the model. This will include a field visit and open community discussions on our modeling. At the same time, the model will be extendable to allow for others to customize the model for other countries and contexts.

We will document our activities so other global health practitioners can learn how to work with the open source Synthea project and generate further modules to be added based on other LMIC use cases.

Use of Digital Health Technologies

We anticipate that this activity will utilize the following digital health tools, technologies, and standards:

Work Plan, Schedule, and Deliverables

Month 1-2: Phase 1 - Existing Dataset and Patient Generation Software Research

  • IntraHealth: Landscape analysis and community engagement of the existing demonstration datasets in DHIS 2, OpenMRS, iHRIS, a FHIR server, CSD, and OpenLMIS.

  • IntraHealth: Incorporate feedback from the relevant product owners and communities on their existing roadmap plans for demo data and harmonize as appropriate.

  • IntraHealth: Understand the alignment needed of the existing data on facilities, health practitioners, organizations, countries that are not included in patient generation software but would need to align.

  • IntraHealth: Landscape analysis of patient generators in use especially Synthea and document the feasibility of adapting those generators to LMIC.

  • IntraHealth: Community engagement with the patient generator software communities as necessary.

  • IntraHealth Deliverable: Landscape analysis of existing demonstration datasets and patient generators.

Month 3-6: Phase 2 - Selection and Adaptation of Existing Synthetic Patient Generation Software for LMIC Use Cases

  • IntraHealth: Align the existing demo data on facilities, health practitioners, organizations, countries that are not included in patient generation software.

  • Jembi: Add features to adapt the chosen patient generator to the LMIC context, including, as necessary, realistic but fake facility lists, administrative areas, organizations, and practitioners. (Note: This does not add disease modules or other customizations, it only adapts underlying demo datasets structures like facilities.)

  • Jembi: Publish all source code under a permissible open source license.

  • Jembi: Produce and distribute synthetic patients for LMICs and engage with the relevant communities for assistance in testing patient generation for DHIS 2, OpenMRS, OpenLMIS, iHRIS, CSD, and a FHIR server.

  • Jembi: Document usage of the datasets, how to produce them, and demonstrate their usage.

  • Jembi Deliverable: Initial patient generator source code and documentation published.

Month 7-9: Phase 3 - Disease Module Iterative Prototype Build

  • Jembi, IntraHealth: Conduct research with country experts on malaria or HIV/AIDS epidemiology and manifestation as represented in electronic/paper health records.

  • Jembi, IntraHealth: Hold an in-country workshop in Uganda to identify and report on the key aspects of the epidemic that will be represented in health records and align with national statistics.

  • Jembi, IntraHealth: Develop a prototype module aligned with producing observations, lab results, encounters, observations, and other aspects of fake but realistic patients experiencing illness caused by the chosen disease.

  • Jembi, IntraHealth: Publish alpha version of the disease module.

  • Jembi, IntraHealth: Engage relevant communities in feedback on the disease module.

  • Jembi, IntraHealth Deliverable: Published alpha version of the disease module.

Month 10-12: Phase 4 - Disease Module Beta Version

  • Jembi, IntraHealth: Incorporate feedback on alpha version of the disease module into the beta version of the module.

  • Jembi, IntraHealth: Publish beta version of the disease module.

  • Jembi, IntraHealth: Engage relevant communities in testing of the module.

  • Jembi, IntraHealth: Document all assumptions, technological decisions and any relevant aspects of the module to ensure transparency and maintenance of it long-term.

  • Jembi, IntraHealth Deliverable: Published beta version of the disease module.

Month 13-15: Phase 5 - Disease Module Initial Large-Scale Testing and Debugging

  • Jembi, IntraHealth: Engage the greater global health community in a thorough testing of the module and the data it produces, to ensure it is producing applicable and adoptable datasets that achieve the three original goals of the project.

  • Jembi, IntraHealth Deliverable: Produce a user-tested release candidate version of the Synthea module.

Month 16: Phase 6 - Full Public Release and Marketing

  • Jembi, IntraHealth: Roll out a targeted marketing campaign to publicize the availability of the synthetic data generation and diseases modules to the global health community, with a focus on reaching software developers and policy-makers in LMICs and presenting outcomes at relevant conferences.

  • Jembi, IntraHealth Deliverable: an executed marketing campaign

A GANTT chart of the project can be found at https://docs.google.com/spreadsheets/d/1nsu3kQ6XIaUM7r-ryTS25v73ZSvEZtep0kNBYrHJ3NQ/edit?usp=sharing

Digital Health Atlas

DHIS 2 Registration: https://digitalhealthatlas.org/public/87/assessment

OpenMRS Registration: https://digitalhealthatlas.org/public/10/assessment

iHRIS Registration: https://digitalhealthatlas.org/public/141/assessment

Lorem Ipsum Registration: https://digitalhealthatlas.org/public/151/assessment

Monitoring and Evaluation

IntraHealth International and Jembi have robust monitoring and evaluation processes to ensure project compliance and success.

We will start this engagement with a deep discussion with representative software developers and policy-makers who will form an advisory group to confirm our initial needs assessment and create a clear future vision, with documented success criteria.

As we proceed through the module development process, we will monitor our progress with regular check-ins with the advisory group to make sure that we are still building toward our future vision. We will also bring in other global health community members to ensure our module has the greatest overall utility.

Once the module is developed and we begin publicizing its utility, we’ll evaluate our overall efforts to measure how well we’ve met our initial objectives and the extent to which the new module is changing the way software developers and policy-makers approach digital health data.

IV. Two-Sentence Overview

Lorem Ipsum for Digital Health will create a harmonized synthetic data generator that can be used by software developers, policy-makers, and researchers to improve the functionality and data analysis capabilities of digital health solutions without compromising confidential patient records

Digital Square will be funding the extension of an existing synthetic data generator, so that it can create realistic and comprehensive health data that is statistically similar to developing country realities yet totally safe for public usage, revolutionizing how digital health systems are developed and tested.

V. Community Feedback

Our key engagement point with the broader digital health community will be through our advisory group, made up of representative software developers and policy-makers. This group will be initially populated from the Ugandan context, as that’s the origination point for our initial use cases. We’ll aim to quickly expand this group by bringing in epidemiological experts and health researchers from their respective communities and health policy experts from the Global Digital Health Network, and similar technology and policy communities.

We expect this advisory group to give regular input and guidance on the technology solution design and the context in which it will work, including:

  • Use cases to inform software development and testing

  • Data modeling and testing to ensure fidelity to real health data

  • Software architecture to ensure interoperability with existing systems

As we proceed through the development process, we engage with the advisory group with regular check-ins at the start and end of each phase, to make sure that we are still building toward our future vision. We will also bring in stakeholders from across the greater digital health community at the end of each phase to ensure our data generator has the greatest overall utility across multiple countries.

VI. Use Cases

HMIS Software Developer

Software developers in ministries of health can use synthetic data to build demonstrations of new data analysis and visualization systems to get peer and leadership buy-in, and validate existing systems and workflows for reporting health data to senior officials.

Software Developer New to OpenHIE

Skilled software developers who are new to the OpenHIE architecture can use synthetic data to explore the application programming interfaces (APIs) for DHIS 2, OpenMRS, iHRIS, and other systems.

HMIS System Architect

Skilled HMIS software developers can use synthetic data to develop new workflows and functionality, and test end-to-end validity of existing health information exchange solutions.

Health Policy-Maker

A senior health-policy maker can use synthetic data to build and test DHIS 2 aggregation systems for health indicators, like HIV data for PEPFAR, or to build and test custom reports and views in third-party solutions like Excel, Tableau, and Power BI.

Health Researcher

Health researchers can use synthetic data to build new machine learning models and understand the inherent opportunities and constraints in their algorithms.

Health Educators

Health systems educators can use synthetic data to show students how to explore and test data with realistic disease profiles without compromising real patient records.

VII. Self-Assessment on the Global Goods Maturity Model

DHIS 2, iHRIS, and OpenMRS are benchmarked against the Global Goods Maturity Model through a self-assessment process and have similar levels of global utility and community.

Synthea Patient Generator

https://docs.google.com/spreadsheets/d/1N-dK_OqeXP98PnAFLabWQvNtKVcH7kEx0v7hOCpvPAs/edit?usp=sharing

DHIS 2

https://docs.google.com/spreadsheets/d/1Blc8IN2JuzZ07HU8ooPfxDLtk4wmV7MrEuwEbwENeNU/edit#gid=249752520

iHRIS

https://docs.google.com/spreadsheets/d/1rO_Lu3sSYriJ4Su2clPiiQfebGEv2fhUC0LX5uT-s30/edit#gid=249752520

 

OpenMRS

https://docs.google.com/spreadsheets/d/1SU1Ngn7nxLRurNTxmzm_Oiv6vTM81OQITbxHawaIT7k/edit#gid=249752520

 

VIII. Tagging

  • Data services
  • Data collection
  • Data management
  • Data coding
  • Location mapping
  • Data interoperability
  • FHIR
  • Synthetic data
Application Status: 
Approved – Contingent on Funding

Making the most widely-deployed ODK tools better Global Goods

Notice C Opportunity: 
Announcement C0: Global Good Software Development and Support

Executive Summary

The Open Data Kit (ODK) community produces free and open-source software for collecting, managing, and using data in resource-constrained environments. The tools are primarily used by health organizations to collect data quickly, accurately, offline, and at scale. This effort focuses on the ODK 1 suite of tools (Collect, Aggregate, Central, XLSForm, Build, JavaRosa) which are widely-deployed global goods that have been used to collect billions of data points. Example projects include:

  • For governments working to end polio, access to accurate and timely information makes a world of difference. ODK is used in Jordan, Afghanistan, Pakistan, Somalia, and South Sudan as a key tool in mass polio vaccination campaign quality control. https://www.youtube.com/watch?v=zROyvrvt-zk
  • PMA2020 uses ODK to collect a nationally representative sample of data from households and service delivery points in selected sentinel sites. The data is used to estimate health indicators on an annual basis in 11 pledging FP2020 countries. https://pma2020.org/what-we-do

ODK has been designed for novice users in challenging environments and its robustness in these environments has driven the platform’s adoption and evolution. Additionally, the choice to build an active open-source community around ODK has allowed it to benefit from users, implementers, and developers.

Over the last year, the ODK project has transitioned from a single “owner” to community governance, and under the leadership of the ODK 1 Technical Steering Committee (TSC), the ODK 1 user base has experienced extraordinary growth during that time (forum has grown 166% to almost 8K users), mobile client actives have grown 140% to 170K users). We wish to build on that growth and deliver improvements to ODK Collect (mobile app) and ODK Aggregate (server), and our user documentation.

Consortium Team

Nafundi is a software company started by the founders of ODK. Nafundi’s leadership, Dr. Yaw Anokwa and Ms. Hélène Martin, lead much of the software development and community activities on the ODK 1 tools. Nafundi will be the lead organization and will provide project management and software development.

eHealth Africa (eHA) builds stronger health systems through data-driven solutions. Adam Butler is the Technical Team Lead at eHA and has experience building solutions from platforms like ODK, CKAN, OpenHIE, DHIS2, and OSM. eHA will provide project management and software development.

Biostat Global Consulting offers a broad array of services in survey sampling, study design, data management and cleaning, statistical analysis, and conveying results clearly to technical and non-technical audiences. Dale Rhoda from Biostat is deeply familiar with ODK Collect and the challenges of data entry errors.

Nafundi and eHA participate on the ODK 1 TSC and have used an open and collaborative roadmapping process to improve ODK 1 tools over the last year. Dale Rhoda, a principal at Biostat has worked with both Nafundi and eHA on reducing data entry errors in ODK Collect.


Project Description

The consortium, with consultation from the ODK 1 TSC, has identified four work packages where support from Digital Square would enable the ODK 1 community to address well-articulated, but under-resourced needs.

Per ODK 1’s governance at https://github.com/opendatakit/governance/tree/master/TSC1, our proposed activities are sourced from community discussions at http://forum.opendatakit.org and filed issues on https://github.com/opendatakit.

For each software development activity, the consortium will add detail to each filed issue to enable it to be closable by a pull request (a code submission). Each pull request will be reviewed by another core contributor and tested by the existing test team. Once reviewed and tested, the code will be merged. For software artifacts, a beta build will be shared with the community, and if no issues are found, a production build will be released. Non-software artifacts (e.g., docs) are released continually.

For each activity, we will publish a tentative plan and a call for contributors on our community forum and social media. The consortium will facilitate those contributors and serve as backstops to ensure ongoing and consistent process.

Work Package 1: Improving ODK Collect for disease surveillance

ODK Collect has seen 140% increase of its user base over the last year and now processes millions of submissions a month. Nafundi has led this core software development and the ODK 1 TSC would like to take this funding opportunity to broaden the core contributor base by resourcing another organization to deepen its contributions while improving ODK Collect’s functionality in disease surveillance.

Our approach for this work package is to take on complex features that require deep changes to ODK Collect, ODK JavaRosa, and the XForms specification. To ensure completion, we wish to resource a committed and experienced developer from eHA to implement these features:

  • Fields dependent on earlier field not updated
  • Remember previously entered value
  • Group related text or numeric inputs into a grid
  • Refinements to repeat group navigation
  • Specification for lightweight case-management
  • Addressing data accuracy issues identified in Work Package 2

eHA will be responsible for delivering these changes with Nafundi assisting.

Work Package 2: Improve data entry accuracy across all ODK Collect widgets

In 2016, Biostat Global conducted a data entry experiment with eHA in Nigeria on ODK Collect. The study characterized data entry error rates for entering 10,000 known dates using a combination of factors. The experiment showed high data entry error rates for the common date interfaces in ODK Collect. A presentation on methods and results is available here. Shortly after the results were released, Nafundi, with guidance from Biostat Global, led the community in improving the date interfaces.

We would like to use this work package to extend the data entry work to rigorously study:

  • Changes that the ODK community made to date widgets - Did they improve error rates?
  • Other question types of high importance - Dates are the most important element in some types of surveys, but other surveys rely on other question types to calculate the main outcomes. We will use use subsets of questions from the UNHCR Standardized Expanded Nutrition Survey (SENS) and PMA 2020 (and hopefully use data collectors from those projects) to enter many thousands of known responses and assess entry error rates.
  • How do error rates vary teams and team members across several data collection countries?

Biostat Global will design the experiments and work with data collection teams from several countries to deliver results, publish recommendations for design changes that the ODK community should make, and work with eHA’s developers from Work Package 1 to address the most serious drivers of data errors.

Work Package 3: Making ODK Aggregate more maintainable

There are high-value changes to ODK Aggregate that would enable maintainers to better understand usage patterns and address many of the common problems that users encounter when using the software. For this work package, we will deliver the following:

  • Usage analytics to better inform maintainers about usage patterns
  • Improved error messages that point to common resolutions to reduce support burden
  • Removed all deprecated functionality (e.g., Google Accounts, ODK2)
  • Reworked help system that leverages new docs website

Our anticipated outcomes are greater insights into which features of Aggregate are important to improve and which could be deprecated. We also expect to dramatically reduce the support questions around Aggregate.

Nafundi will be responsible for delivering these changes.

Work Package 4: Improving user documentation and docs process

We measure the effectiveness of our user documentation by the support questions that could be answered with a link to the documentation. Maintainers file issues against the docs when community members are not able to answer support questions with a link to the docs.

While we have made great strides over the last year by launching a new ODK documentation website at http://docs.opendatakit.org, there are gaps around docs that require deeper knowledge of the tools than is typically readily available in our community. For this work package, we will deliver the following documents:

  • How form versioning works
  • Explain external data tradeoffs
  • Google Drive/Sheets as a lightweight server

We will also seek to make our documentation easier to contribute to by reworking our contribution process and addressing the docs backlog.

eHA will be responsible for delivering these changes with Nafundi assisting.


Use Cases, User Stories

Work Package 1: Improving ODK Collect for disease surveillance

This work package is motivated by problems seen when deploying ODK Collect for disease surveillance. Our high-level user goals are to solve long-standing issues that increase data accuracy by providing enumerators with important context during data entry, reducing fatigue by automating repetitive or manual tasks, grouping related questions in more natural grid views and improving navigation and management of repeating elements.

“Fields dependent on earlier field not updated” is described in more detail at https://github.com/opendatakit/collect/issues/378. Resolving this issue will:

  • Help enumerators understand better what dependent questions are asking by placing the questions on the same screen
  • Help enumerators reduce data loss when questions appear and disappear for no apparent reason
  • Help managers reduce training by relying on behavior that is very common across other data collection tools in the ODK ecosystem

“Remember previously entered value” is fully described in more detail at https://forum.opendatakit.org/t/9116. Resolving this issue will:

  • Help enumerators reduce fatigue by not having to enter the same data multiple times
  • Help managers reduce data variation by ensuring data is only entered once
  • Provide designers with a light-weight mechanism to share data across multiple forms

“Group related text or numeric inputs into a grid” is described in more detail at https://forum.opendatakit.org/t/13398. Resolving this issue will:

  • Ensure enumerators can more easily collect several values of the same kind
  • Reduce the need for designers to design complex and hard to maintain forms
  • Lay the groundwork for designers to add numeric or textual entry with units

“Refinements to repeat group navigation” is described in more detail at https://forum.opendatakit.org/t/11792. Resolving this issue will:

  • Provide enumerators with a more intuitive navigation and management of repeated form elements
  • Help managers reduce training around use of repeating form elements
  • Provide designers with a lightweight mechanism to gain case-management without designing multiple forms

“Specification for lightweight case-management” is described in more detail at https://forum.opendatakit.org/t/6827. Resolving this high-risk but valuable issue will:

  • Communicate a clear vision to the community about how lightweight case-management will be handled
  • Provide a specification and plan for implementation that does not disrupt the existing ecosystem
  • If possible, an initial implementation.

Work Package 2: Improve data entry accuracy across all ODK Collect widgets

Survey implementers, including eHA in Nigeria and Data Management Aid in Bangladesh sometimes implement World Health Organization Vaccination Coverage Cluster Surveys using ODK.

One key element of those surveys is to record the child’s date-of-birth and every date on which they were vaccinated. These dates are usually copied from either a home-based or facility-based health record. The survey analysis uses dates to compute the ages at which children receive each dose and compares the distribution of ages as observed with the recommended age from that country’s vaccination schedule.

The data help program managers assess whether doses are commonly being administered too early or too late and whether providers are giving all of the doses that the child is eligible for on every visit. Identifying facilities and regions that frequently experience so-called “missed opportunities” for simultaneous vaccination can represent low-hanging fruit for improving vaccination coverage. If the workers there can be trained to identify all of the doses that the child is eligible for, they can easily be administered: after all, the largest hurdle has already been cleared...the child is present at the vaccination facility...they have received at least one dose...let’s be sure that they receive all of the doses that they are eligible for today.

But the missed opportunities indicator is very sensitive to data entry errors. If a vaccination date is mis-entered, then it will look to analysts as though the child visited a facility and received only one dose on a day, when in fact they may have also received several others whose dates were entered correctly. Entry errors in the dose dates are bad, but errors in the date-of-birth are even more consequential. If that date is wrong, then all the calculations about the child’s age when they received every dose will be wrong. So to draw correct conclusions about how a country’s vaccination delivery system is performing, in terms of timeliness and simultaneity of administering doses, it is crucial that field data collectors be able to enter dates correctly.

When data are collected on paper forms or photographs it is common for data entry firms to guarantee error rates smaller than one error in every hundred data elements when they perform double-data entry using keyboards. By contrast, in the Biostat Global / eHA experiment in Nigeria, errors were observed in 10% of dates entered in the configuration that most closely matched those commonly used in practice.

For vaccination program managers around the world to trust the results of date-based analyses, we need to confirm that improvements to the interfaces, and maybe instructions, can yield error rates as low as those available with keyboard data entry.

So this work package is informed by problems seen when studying error rates in ODK Collect. Our high-level user goals are to ensure that the various user interfaces choices have not introduced data accuracy problems.

As part of this Work Package, we will have documented, for the first time using an experimentally rigorous design and large sample size, baseline error rates for a set of fundamental and common ODK question types, using a variety of participants across a variety of teams. The results will be helpful to the ODK community to know whether to invest precious resources into additional measures to mitigate data entry errors.

We will share the resulting dataset and error rates, published and shared in an open forum so other investigators who use ODK can run simulations with their own data to understand the implications of entry errors in their own work.

We will have generated a set of experimental artifacts (XLSForms, PDFs of faux respondent responses, computer code for scoring the errors) that can be easily used or modified to repeat or extend the experiment with other data collection partners.

The data collected here can help inform the design of future experiments, if this experiment shows that additional work is needed to improve interfaces, or instructions or incentives. If additional work is needed, then future experiments will be needed, and the error rates and their correlation structure across participants and teams will be very helpful for planning the size of those endeavors.

Work Package 3: Making ODK Aggregate more maintainable

This work package is informed by problems seen while maintaining ODK Aggregate. Our goals are to reduce the maintenance burden so the developer community can more quickly and more confidently make changes that will provide the most value to the hundreds of thousands of users who have downloaded ODK Aggregate.

“Usage analytics to better inform maintainers” is described in more detail at https://github.com/opendatakit/aggregate/issues/309. Resolving this issue will:

  • Provide project leadership with a privacy-preserving mechanism of measuring usage and impact
  • Increase developer confidence about which features should be added, removed, or changed

“Improved error messages” is described in more detail at https://github.com/opendatakit/aggregate/issues/244 and https://github.com/opendatakit/aggregate/issues/248. Resolving these issues will:

  • Reduce implementer frustration by providing immediate solutions to common problems
  • Reduce community support burden by ensuring implementers can solve own problems

“Removed all deprecated functionality” is described in more detail at https://github.com/opendatakit/aggregate/issues/286 and https://github.com/opendatakit/aggregate/issues/287. Resolving these issues will:

  • Reduce implementer frustration from features which are not functional or supported
  • Reduce implementer security risk from unmaintained and untested code

“Reworked help system that leverages docs” is described in more detail at https://github.com/opendatakit/aggregate/issues/311. Resolving this issue will:

  • Enable implementers to have access to the most up-to-date documentation
  • Enable contributors to add to documentation without being a Java developer

Work Package 4: User documentation

This work package is informed by gaps in documentation for complex workflows that ODK users are likely to run into. Rather than only writing the documentation, we wish to use this Work Package to improve the contribution process and enable more of the community to contribute documentation.

“Reworking contribution process” is described in more detail at https://github.com/opendatakit/docs/issues/823. The community has shown a desire to contribute documentation, but has been discouraged by the difficulty of the contribution process. Resolving this issue will reduce the work required for non-technical contributors to contribute to ODK’s docs.

“Reducing the backlog” is described in more detail at https://forum.opendatakit.org/t/14654/3 . The community has shown a desire to reduce the back log documentation, but there has not been staff to drive a concerted effort. Resolving this issue will help users make the most out of ODK.

“How form versioning works” is described in more detail at https://github.com/opendatakit/docs/issues/645. Resolving this issue will explain to implementers to how to safely and quickly add or remove questions from forms.

“Explain external data tradeoffs” is described in more detail at https://github.com/opendatakit/docs/issues/73. Resolving this issue will enable implementers to understand what the various external data mechanisms are, why they came to exist, and the tradeoffs of each.

“Google Drive/Sheets as a lightweight server” is described in more detail at https://github.com/opendatakit/docs/issues/748. Resolving this issue will enable implementers to set up a lightweight backend that does not require the relatively heavy infrastructure of ODK Aggregate or ODK Central.


Digital Health Technologies

The key digital health tool the project will be investing in is ODK and its ecosystem. ODK 1 tools have become the standard for non-routine data collection and management and for this effort, we’ll be focused on the ODK suite’s most popular tools, ODK Collect and ODK Aggregate.

User facing tools

  • ODK Collect is an Android Java app that renders forms that comply with the ODK XForms spec. It is powered by ODK JavaRosa and is a client to ODK servers.
  • ODK Aggregate is Java server that can be deployed on Tomcat or Google App Engine. It can be backed by PostgreSQL, MySQL, MS SQL Server, or Google Cloud Data Store.

Libraries and specifications

  • OpenRosa, APIs for how ODK clients communicate with ODK servers.
  • ODK XForms spec, a subset of the W3C XForms specification, for use in the ODK ecosystem.
  • ODK JavaRosa, a Java library that renders forms complying with ODK XForms.
  • XLSForm spec, a high-level Excel-based form specification.
  • pyxform, a Python library that converts XLSForms into ODK XForms.


Community Feedback

The ODK forum has almost 8,000 members who are familiar with our public feature development process. The consortium will use the forum to engage with the broader community.

For each feature, the consortium will describe the background, goal, non-goals, user stories, and user interaction on the community forum and solicit and facilitate feedback. This feedback will be gathered on an ongoing basis until the feature is ready to be specified. The consortium will leverage its existing relationships and social media to ensure end users are aware of this process.

Once a feature is ready to be specced, it will be moved to the relevant GitHub repository where it will receive feedback from our more technical community members, including the ODK’s technical leadership. As the feature is being built, the consortium will encourage feedback and review from the broader developer community. This feedback will be gathered on an ongoing basis until the feature is ready to be built.

One to two weeks before a tool release, a beta release will be announced on the ODK forum and via social media. Hundreds of users typically participate in betas and the consortium will gather their feedback. Alphas and betas happen monthly and adjustments are made until users report no problems.

To gather ongoing feedback during this process, the consortium will rely on our existing meetings. During our monthly developer meetings, the consortium will invite developers from the broader community to provide feedback. During our biweekly TSC meetings, the consortium will include an agenda item to provide detailed technical feedback ongoing work on this effort.


Self-Assessment on the Global Goods Maturity Model

Our self assessment (with rationale) is available at https://docs.google.com/spreadsheets/d/1jixQ-42cfwGRNQb7XI4PAy6I4FhZTRcZy05rVQH9Rxw and the results are below.

 

Digital Health Atlas

The consortium lead has selected three polio projects in three countries. These projects showcase the use of the core ODK 1 technologies in data collection and management for polio surveillance.


Workplan and Schedule

Our workplan and schedule for each Work Package is shown below.

 

ResponsibleM1M2M3M4M5M6M7M8M9M10M11M12
 
 Work Package 1: Improving ODK Collect for disease surveillance
Tech Lead (eHA)Identify and recruit Android Developer           
Tech Lead (eHA)Work with ODK TSC to produce syntax spec for grid layouts          
Tech Lead (eHA) Work with ODK TSC to evaluate possible approaches to updating of dependent fields         
Tech Lead (eHA)  Work with ODK TSC to finalize spec for remembering values        
Tech Lead (eHA)Iterate on case management specification with ODK TSC    
Tech Lead (eHA)     Work with BioStat to specify changes based on outputs of WP2     
Tech Lead (Nafundi)Provide technical guidance on specification and implemention
Android Developer (eHA) Group related text or numeric inputs into a grid         
Android Developer (eHA)   Fields dependent on earlier field not updated       
Android Developer (eHA)    Remember previously entered value      
Android Developer (eHA)       Lightweight case-management
Android Developer (eHA)      Addressing data accuracy issues (based on outputs of WP2)    
Android Developer (Nafundi) Refinements to repeat group navigation        

 

 

 

ResponsibleM1M2M3M4M5M6M7M8M9M10M11M12
 
 Work Package 2: Improve data entry accuracy across all ODK Collect widgets
Technical Lead (Biostat)Make questionnaire           
Mid-level statistician (Biostat)Make respondents set           
Technical Lead (Biostat)Make experiment design           
Mid-level statistician (Biostat)Compile experiment responses           
Senior statistician (Biostat)Make XLSForm and set up server          
Technical Lead (Biostat)Recruit up to 8 teams to conduct the first round          
Mid-level statistician (Biostat) Materials to train coordinators          
Mid-level statistician (Biostat) Materials to orient participants          
Technical Lead (Biostat) Train onsite coordinators        
Onsite coordinators  Coordinators recruit participant and proctor experiment        
Senior statistician (Biostat)   Pull data and compare with expectations       
Senior statistician (Biostat)    Document observed error rate and variability      
Technical Lead (Biostat)     Prioritize changes with devs      
Technical Lead (Nafundi)      Make changes to the top priority widgets    
Mid-level statistician (Biostat)        Generate PDFs for next round   
Onsite coordinators        Repeat fieldwork  
Senior statistician (Biostat)         Repeat coordinator clarification  
Senior statistician (Biostat)         Repeat analysis 
Technical Lead (Biostat)          Document for sponsor review and publication

 

ResponsibleM1M2M3M4M5M6M7M8M9M10M11M12
 
 Work Package 3: Making ODK Aggregate more maintainable
Tech Lead (Nafundi)Work with ODK TSC to evaluate approaches on analytics, error messages, and deprecations.  Work with ODK TSC to evaluate approaches on removing help system      
Java Developer (Nafundi)  Usage analytics to better inform maintainers        
Java Developer (Nafundi)  Improved error messages        
Java Developer (Nafundi)  Remove all deprecated functionality        
Java Developer (Nafundi)      Reworked help system that leverages docs    

 

ResponsibleM1M2M3M4M5M6M7M8M9M10M11M12
 
 Work Package 4: Improving user documentation and docs process
Docs Lead (Nafundi)Reworking the contribution process          
Docs Lead (eHA)Reducing the backlog    
Tech Lead (Nafundi)Provide technical guidance on back log issues    
Docs Lead (eHA)  How form versioning works        
Docs Lead (Nafundi)  Explain external data tradeoffs        
Docs Lead (Nafundi)  Google Drive/Sheets as a lightweight server        


Project Deliverables and Timeframe

Below are our deliverables grouped by work package and partner. We provide estimated timeframe for delivery based on complexity of the deliverable and scheduling into ongoing work.

 LeadQ1Q2Q3Q4
WP1: Fields dependent on earlier field not updatedeHA   
WP1: Remember previously entered valueeHA   
WP1: Group related text or numeric inputs into a grideHA   
WP1: Refinements to repeat group navigationNafundi   
WP1: Addressing data accuracy issueseHA   
WP1: Lightweight case-managementeHA   
WP2: Experimental materialsBiostat   
WP2: Form designs and server setupsNafundi   
WP2: Experiment results made availableBioStat   
WP2: Follow-up experiment results made availableBioStat   
WP3: Usage analytics to better inform maintainersNafundi   
WP3: Improved error messagesNafundi   
WP3: Removed all deprecated functionalityNafundi   
WP3: Reworked help system that leverages docsNafundi   
WP4: Reworking contribution processNafundi   
WP4: Reducing the backlogeHA   
WP4: How form versioning workseHA   
WP4: Explain external data tradeoffsNafundi   
WP4: Google Drive/Sheets as a lightweight serverNafundi   


Tagging

“data collection, management, and use”, “ODK”, “Open Data Kit”, “data accuracy”, “documentation”, “usability”


2 sentence overview

Open Data Kit replaces paper forms and surveys with smartphones and tablets. It helps field workers collect data accurately and report results instantly.

This investment from Digital Square will be used to sustainably address long-standing issues with the most widely-deployed ODK tools and documentation.


Application Status: 
Approved - partially funded

Open Analytics on FHIR for Global Goods

Notice C Opportunity: 
Announcement C0: Global Good Software Development and Support

I. Executive Summary

Current global digital health goods like DHIS2, OpenMRS, and iHRIS have their own siloed reporting systems, which are functional for viewing each system’s data independently but prevent comprehensive reporting and data analysis across systems. In addition, software developers need to continuously recreate specific dashboards for each system as users seek new ways to analyze data. This inability to create unified data analysis and dashboards impacts all levels of health care systems.

Open standards like the FHIR (Fast Healthcare Interoperability Resources) specification for exchanging health care information make is possible to develop health system analytics and dashboards that can be written once and run anywhere. There is support for FHIR in OpenMRS, iHRIS, and OpenInfoMan, and we can use their data based on FHIR in reusable applications across these and other global digital health goods.

Open Analytics on FHIR for Global Goods will create open source, shareable analytics tools for patient and health workforce data in the FHIR format that will strengthen and support existing global goods. The interactive “notebooks,” based on Jupyter Notebooks, will enable software developers and even non-technical staff to analyze FHIR data from multiple sources, such as patient records, health worker registries, and aggregated health trends, in one easy and convenient format.

II. Consortium Team

IntraHealth International has a long history in developing successful data tools for digital health applications. From mobile apps to management software to multi-language interactive voice response, we offer health workers and managers the tools and technology they need to do their very best work.

We develop solutions that are open source, data-driven, sustainable, and collaborative. And as a pioneer in the field of health workforce informatics, we’re committed to using technology, information, and analytical approaches to support the people at the center of our health systems.

This intervention will be led by the following IntraHealth staff and supported by a full range of health experts, project managers, and software developers.

  • Richard Stanley, Digital Health Product Manager, has over 20 years of experience in information and communication technologies, including high quality research and rapid data analytics for monitoring and evaluations in Afghanistan, Somalia, South Sudan, Uganda, and Sudan. He holds a PhD from the University of Oxford, UK.
  • Luke Duncan, Digital Health Assistant Director, has over 20 years of experience in software development, including leading the developing of iHIRS, the flagship human resources solution for global health, and multiple data interoperability standards and reference designs to connect iHRIS, DHIS2, and OpenMRS.

DAI combines 40-plus years of experience in global health with the latest data management and visualization tools to deliver comprehensive health solutions while responding to issues ranging from emerging pandemic threats to HIV/AIDS to waterborne diseases.

IntraHealth International and DAI formed a strategic affiliation in 2017 to offer new combinations of integrated health and development services while retaining their respective name, distinct identity, and legal status. DAI will directly contribute to this effort with the following staff:

  • Greg Maly, Principle Data Scientist, has over 13 years experience in data management, analysis, and visualization with R, Python, and QGIS, and trained international development staff on data analysis and geospatial technologies.

III. Project Description

Problem Statement

Current global digital health goods like DHIS2, OpenMRS, and iHRIS have their own siloed reporting systems, which are functional for viewing each system’s data independently but prevent comprehensive reporting and data analysis across systems. In addition, software developers need to continuously recreate specific dashboards for each system as users seek new ways to analyze data. This inability to create unified data analysis and dashboards impacts all levels of health care systems:

  • Clinic staff cannot see a comprehensive view of how their specific efforts impact national indicators.
  • Health care managers cannot link staffing levels with patient activity or health outcomes.
  • National policy-makers are frustrated by siloed data and manual workarounds to produce key reports.
  • Software developers waste valuable resources creating parallel systems to generate needed data flows and customizing dashboards for multiple systems.

The net result is overall disappointment in health data systems and a major barrier to expanding the culture of data-based decision-making across ministries of health.

Open standards like the FHIR (Fast Healthcare Interoperability Resources) specification for exchanging health care information make is possible to develop health system analytics and dashboards that can be written once and run anywhere. There is support for FHIR in OpenMRS, iHRIS, and OpenInfoMan, and we can use their data based on FHIR in reusable applications across these and other global digital health goods.

DHIS2, OpenMRS, iHRIS, and OpenInfoMan are existing global goods as they are deployed in multiple low and middle income countries, in the health sector, and are made available under Open Source Initiative approved software licenses.

Although FHIR is an open standard, there are only a few free or open source analytics tools available. Most FHIR analytics tools are proprietary, sold for use inside specific software and packaged for commercial use as FHIR is a new and complicated standard. Additionally, these analytics tools lack privacy protections required when using patient-level health care data.

Open Analytics on FHIR for Global Goods will create open source, shareable analytics tools for patient and health workforce data in the FHIR format that will strengthen and support existing global goods. The interactive “notebooks,” based on Jupyter Notebooks, will enable software developers and even non-technical staff to analyze FHIR data from multiple sources, such as patient records, health worker registries, and aggregated health trends, in one easy and convenient format.

The data analysis tools will also include processes to remove user-owned content and personally identifiable information to meet both required and expected privacy protections, and allow for users to experiment with introductory machine learning tasks currently beyond the abilities of existing global digital health goods.

Technical Approach

We will start this project with a detailed assessment of the current state of DHIS2, OpenMRS, and iHRIS compliance with FHIR. At this time:

  • DHIS2 doesn't support FHIR yet, but there is strong interest in supporting FHIR for indicators, facilities, and administrative units.
  • OpenInfoMan can be used to export facility and provider-level data.
  • OpenMRS has comprehensive support for FHIR import and export.
  • iHRIS supports FHIR data export.
  • OpenInfoMan has core support for FHIR export.

Then we will engage the global health community to develop data use cases and reporting needs across all three global goods to develop initial reporting needs and dashboards.

With a representative set of use cases, we’ll use the Python software language, which emphasizes code readability, and iterative agile software development processes to develop analytical tools like Jupyter Notebook, an open source web application that can contain live code, equations, visualizations, and narrative text.

The data analysis tools will include functionality like data anonymization, cleaning and transformation, numerical simulation, statistical modeling, data visualization, and machine learning. FHIR data can also be exported from the tools in CSV and similar formats for importing in DHIS2, Tableau, PowerBI, and other analytical tools.

We will engage the global health community to help us test and debug the data analysis tools, with a focus on software developers and policy-makers in low- and middle-income countries. Our goal will be an initial set of data analysis tools that are immediately relevant and useful to health data system managers, and provide motivation for key stakeholders to develop their own FHIR-based reports and dashboards.

We’ll support this initial interest with extensive documentation, including tutorials on FHIR profiles, FHIR servers, visualization production, and basic machine learning, to lower barriers of entry to producing other data analysis tools. We’ll also launch a targeted marketing campaign to publicize the availability of the data analysis tools and the ease of creating new ones using approaches like the Jupyter Notebook framework.

Anticipated Timeline

Month 0-2: Phase 1 - FHIR and Report Research. Confirm the FHIR standard compatibility of DHIS2, OpenMRS, and iHRIS, and the ability of OpenInfoMan and other tools to create FHIR-compliant data streams, and develop the initial needs and use cases for data analysis and reporting. Deliverable: initial set of application data flows and reporting use cases.

Month 3-6: Phase 2 - Iterative Prototype Build. Using iterative Agile software development processes and following Open Source software best practices, develop prototype interactive data analysis tools and reporting dashboards. Deliverable: beta data analysis tools published to Github.

Month 7-8: Phase 3 - Initial Large-Scale Testing and Debugging. Engage the greater global health community in a thorough testing of the data analysis tools and the reporting dashboards they produce to ensure usable analytics. Deliverable: user-tested data analysis tools suitable for public use.

Month 9: Phase 4 - Documentation and Marketing. Publish documentation, including tutorials on FHIR profiles, FHIR servers, visualization production, and basic machine learning, and launch a targeted marketing campaign to publicize the availability of the data analysis tools to the global health community. Deliverable: usable documentation and an executed marketing campaign.

Monitoring and Evaluation

IntraHealth International and DAI have robust monitoring and evaluation processes to ensure project compliance and success.

We will start this engagement with a deep discussion with representative software developers and policy-makers who will form an advisory group to confirm our initial needs assessment and create a clear future vision, with documented success criteria.

As we proceed through the data analysis tool development process, we will monitor our progress with regular check-ins with the advisory group to make sure that we are still building toward our future vision. We will also bring in other global health community members to ensure our data analysis tools have the greatest overall utility.

Once the data analysis tools are developed and we begin publicizing their utility, we'll evaluate our overall efforts to measure how well we've met our initial objectives and the extent to which the new tools are changing the way software developers and policy-makers approach digital health data.

IV. Tagging

  • Analytics
  • Interoperability
  • FHIR
  • Data Analysis
  • Data
  • OpenMRS
  • iHRIS
  • DHIS2
Application Status: 
Incomplete

Open call for global goods

Notice C Opportunity: 
Announcement C0: Global Good Software Development and Support

Project description

 Problem statement

Taking into account the known problems in the health sector in Senegal, in particular with the patient medical file and data, the objective is to provide Government, patients and health carers anywhere in the world -with a comprehensive solution to:

-       Access comprehensive, accurate and reliable Patient medical data in an easily accessible format, usable anywhere in the world, be it  a simple PC or a highly sophisticated hospital or Clinic equipment, with or without internet .

-       Break siloed information and ensure data bridges between various systems without disrupting existing infrastructure.

-       Enable better care delivery, decision making and diagnosis by closing current gaps in information at the point of care.

-       Inform policy makers, investment planning, research, and broader use by providing access to data with appropriate privacy and legal constraint.

-       Ensure data protection (CNIL and RGPD European rules and regulations)

-       Provide sustainable and environmental friendly solution.

-       Ensure full know how transfer: training local staff and medical personnel is essential.

-       Avoid unnecessary heavy investment and reduce hospitals and health centers operational costs.

-       Respect environment ( green IT)

Ultimately PHYLAXIA will enable anational health ecosystem to emerge that accelerates innovation by breaking down information silos and supporting new types of information exchange.

Project General Technical description

 PHYLAXIA aims at solving the shortcomings associated with poor infrastructure and a lack of accurate or timely medical patient information which may result in serious problems for patients and also generate financial and economic problems such as unnecessary duplication of exams, patient identity problems, no possibility for epidemiology etc..PHULAXAI does not require any heavy infrastructure investment.

General product description

 The PHYLAXIA medical card contains two levels of data:

Level 1 is accessible when the card is opened and contains general customized information of “unclassified” basic information that the Patient and his Doctor agree to input such as, but not limited to:

Age,Blood type,Allergies,General prescriptions,emergency contacts etc. A specific secured tag is also available  in terms of patent ID and ,Security information tag (ID, specific information etc).

Level 2 contains detailed medical data of the patient, all exams, scans, x-rays, prescriptions and can only be accessed with patient’s password. However, in an emergency, authorized personnel can access all data. Existing medical data on the card cannot be altered but data can always be input.

Application Status: 
Incomplete

Pages