I. Executive Summary

OpenMRS is a high quality, open source, integrated electronic medical records platform (EMR) aimed at resource-constrained settings where structured patient record keeping systems (specifically, electronic medical record systems) can improve health outcomes.  The Open Medical Record System (OpenMRS ) was created in 2004 in response to an identified need for efficient data and information management to support enhanced care delivery and help achieve health equity in low and middle-income countries (LMIC). OpenMRS is a scalable, modular, open-sourced platform used by institutions and nations across the globe to build customized medical record systems that can meet the needs of varied situations. Over the past decade, the OpenMRS community has become a robust organization of developers, implementers and users actively building and supporting life saving health systems worldwide. As OpenMRS continues its growth in over 80 countries to date, it increasingly is recognized as a de-facto EMR standard, supported by the OpenMRS community.

Although often seen as a technical community, the OpenMRS community would not exist but for the broad ecosystem of implementations it serves.  Despite the core mission to serve these implementations, OpenMRS falls short in dedicated resources to fully understand and track the wide variation of implementations, investigate and identify implementation best practices, and to be able to create a sustainable engagement strategy to provide the requested support from these implementers.  Our team aims to strengthen OpenMRS by gaining insight into the impact of OpenMRS on country health systems by better understanding this growing ecosystem of OpenMRS implementers and the 3,000+ implementations of the OpenMRS system.  Using these real-world cases, we propose to incorporate the identified needs of implementers and implementations into the community processes through the development of improved QA processes, publication of implementation toolkits and guidance documentation, development and dissemination of elearning components, and expanding the partnerships program to support implementers in the field. These processes, coupled with the published artifacts, should result in additional implementers and implementations - creating a long term sustainable ecosystem for OpenMRS.

II. Consortium Team

The consortium will be led by University of Washington Clinical Informatics Research Group (CIRG) (http://cirg.washington.edu) and partnering with Regenstrief Institute Global Health Informatics (RI) (https://www.regenstrief.org/areas-of-focus/global-health-informatics/).

UW CIRG is one of the premier global health informatics organizations, serving as experts in advocacy and policy; evaluation, strategy, and planning; architecture and design; engineering and development; implementation; and providing data quality and analytics expertise.  CIRG has contributed substantially to multiple open technology communities, and led and managed numerous large-scale informatics grants and programs around the world. CIRG has conducted national scale programs in Haiti, Cote d’Ivoire, Kenya, Mozambique, Cameroon, Namibia, Vietnam, and the United States. CIRG leadership serves on the Board of Directors of OpenMRS, and is part of the leadership in the OpenMRS Strategy & Operations working group.  CIRG also leads the eSaude Community in Mozambique, the OpenELIS Foundation, and the OpenHIE LIS Community of Practice.

Regenstrief Global Health Informatics (RI GHI) program brings core capability in health information technology(HIT), policy and planning, programming, standards, development and support for health care teams and learning health care systems, analytics and business intelligence, electronic measures, and technical understanding of databases and data warehousing.  RI GHI has internal capacity to assist in the development of local, tribal, regional and national leadership and management capacity to evaluate, develop and implement health information technology systems, measurements, learning and accountability policies, strategies, frameworks, guidelines and outcomes for individual and population health. RI GHI leadership currently leads both the OpenMRS and OpenHIE communities, and provides core coding contributions and capacity to the OpenMRS products and OpenHIE reference applications.

III. Project Description

Problem Statement

Our team aims to strengthen OpenMRS by gaining insight into the impact of OpenMRS on country health systems by increased understanding the growing ecosystem of OpenMRS implementers and the 3,000+ implementations of the OpenMRS system. Implementers and users in LMIC are often hard to reach and engage. These important stakeholders have not been as visible to the OpenMRS development community due to inconsistent outreach by OpenMRS, a lack of communication strategies that appeal to non-developers, and a culture that has not included implementers in the release process.  In addition, the implementer community has little documentation for conducting implementations, educational materials and guidance, and limited partners that can conduct structured and vetted training in capacity building activities. Using these real-world cases, we propose to incorporate our improved understanding of these implementations into the community culture, processes, and offerings to better engage and serve the implementers in the field. In addition, we foresee the creation of educational and support offerings to implementers (either through OpenMRS Inc or through endorsed implementers) that will be the nidus for the creation of a self-sustaining implementer ecosystem.

Technical Approach

Work Package 1: Understanding the Implementation Ecosystem

While we often had knowledge about many of the early OpenMRS implementations, as the number of implementers and implementations have accelerated, we have been hindered in our understanding of the full landscape of OpenMRS utilization.  As a result, the OpenMRS products have been developed based on a limited set of involved community members that give input their specific implementations and stakeholders need, or based on their particular expertise in the health domain.  To ensure the OpenMRS products are expanding and improving to meet the needs of the larger landscape of users of the system ( as well as new areas of concern such as NCD), OpenMRS seeks to incorporate the input and understanding from the larger community of implementations into our software development roadmap. OpenMRS needs to identify the implementations that exist, the needs of those communities, how well the system is currently meeting those needs, the usability of the system to meet those needs and any new requirements. In addition, OpenMRS needs to establish and integrate the process for the implementation community to provide input into the roadmap.

In this work package, we propose to conduct a broad landscape assessment, with in-depth implementation surveys conducted across a large representative sample within the landscape. We will predicate this work on previous landscape review work that has been done by UW and RI and OpenMRS. Our goals will be to determine the variation across implementations, to identify factors for and barriers to success for implementing OpenMRS, and to understand the challenges faced by implementers to deliver and support the OpenMRS system in the field.  In addition, we aim to identify ways in which the OpenMRS community can improve their culture and processes to better support these implementers and implementations, and to ensure their voices drive the products and offerings we provide. Lastly, we strive to understand the usability of the OpenMRS products in order to better overcome some of the development, training, adoption, and support challenges and barriers faced in implementation that prevent our products from being successfully used to their fullest potential to change health system outcomes.

To better serve this critical component of the OpenMRS community, our team proposes leading the community in the following activities under this effort:

• Activity 1.1: Conduct OpenMRS implementation landscape assessment to identify implementations, implementers, and maintainers;
• Activity 1.2: In a representative sample from activity 1.1, conduct an in-depth implementation survey and needs assessment with implementers and end users.  We would use mixed methods to collect both qualitative and quantitative data to understand how OpenMRS is being used to achieve the goals of health programs, learn what domains and health delivery challenges OpenMRS is being used to address, identify who the key users of OpenMRS are and how it is being used, capture themes of attitudes and behaviors towards OpenMRS use, and key metrics around implementation.  Furthermore, we would survey implementers on their needs and ways to engage them more effectively in community processes.
• Activity 1.3: Conduct human factors usability evaluation on the OpenMRS Reference Application and Platform to identify improvements to mitigate some training, adoption, and support challenges faced in implementations.  Work with implementers to prioritize issues found for addition to the software roadmap. Develop appropriate framing for a style guide.

Work Package 2:  Improving QA Processes for Implementer Acceptance

As part of strengthening our implementer program and improving implementer engagement, we aim to strengthen our QA process for software releases.  Currently, we provide limited QA on the technical side of the software release, but do not conduct structured and repeatable in-depth end to end testing of products.  In addition, we do not conduct structured user acceptance testing that would help ensure that we have produced a release that meets the requirements from the implementation community.

To increase trust in the quality of our products from our implementers, and to ensure products meet specified functional requirements, our team proposes to develop a more robust QA process that includes fully documented test scripts for end to end testing, with a supporting automated test framework to conduct these tests.  This test framework will be harvested and expanded from work done by UW CIRG on the eSaude OpenMRS distribution. We will generalize this work to fit with the larger community products using current automated testing technologies, such as Puppeteer and CodeceptJS.

We propose leading the following activities:

• Activity 2.1 - Develop portfolio of documented manual test scripts and anonymous data sets for testing the suite of OpenMRS products.  We will leverage the large portfolio of previously documented manual test scripts that UW has created for the OpenMRS product deployments in multiple countries, including Mozambique, Kenya, and Cameroon.  Using this portfolio, we will work with the OpenMRS community to identify and customize those standardized features and use cases should be included, and expand on the portfolio to include additional prioritized test scripts that are needed.  These will be produced with the community and stored publicly on the OpenMRS Wiki for the OpenMRS community access.
• Activity 2.2 - Develop automated End to End testing framework leveraging the OpenMRS distribution eSaude test framework developed by the UW for Mozambique.  This solid framework will be generalized to support the creation of automated testing for the common workflows and use cases that OpenMRS supports. This work will drastically improve the quality of the released products because the development team will be able to quickly and easily repeat a portfolio of test scenarios for full end-to-end testing each time.  We will work with the community to develop an Automated Test roadmap, to ensure that the test coverage continues to expand for coverage of future software product releases. In addition, we will fully document the automated test framework and work with the OpenMRS community to develop and publish the process for utilizing the framework for software releases.
• Activity 2.3 - Create and publish SOP for Implementer Acceptance Testing for software releases.  We will work with the OpenMRS implementation community identified in Work Package 1 to create and publish the process for gaining implementer acceptance testing for each of the OpenMRS product software releases.  This process will be incorporated into the community development and release process, and published on the OpenMRS Wiki for community engagement.
• Activity 2.4 - Pilot of test framework with OpenMRS release, and pilot SOP of implementer acceptance testing.  Identify an OpenMRS software release to test the automated test framework as part of the QA process. In addition, identify 1-2 implementers from the implementation community to follow the user acceptance test process as part of the software release of the identified product.  Use the results from these tests to document improvements to the framework and the acceptance test process. Work with the community to incorporate framework improvements into the product development roadmap.

Work Package 3:  Implementation Toolkit and OpenMRS eLearning Courses

OpenMRS is in dire need for additional educational materials for all cadres of the community.  There has been a noticeable increase of requests for implementation support and self-learning / training materials.   Based on the knowledge from the landscape assessment and implementation survey, our team proposes to contextualize and expand on the existing UW-created HIS implementation toolkit for publication on the OpenMRS website.  We aim to create a broad set of tools and guidance documentation detailing suggested pathways following best practices for a successful implementation.

In addition, the team will develop the framework for an online asynchronous elearning program for implementers to better understand how to implement OpenMRS.  This includes developing both the outline of the elearning program, detailing the structure of the program and the content to be included, and including the curriculum for each of the courses to be developed.  This curriculum, when provided in certain settings, could help provide a sustainable business model for the future through appropriate and reasonable tuition in certain situations.

In order to build a more sustainable and broad-reaching OpenMRS community educational program, we want to encourage multiple contributors to participate in the creation, updating, and expansion of the educational materials over time.  We also want to encourage other community members to share their expertise and lessons learned in implementation, development, and support of the OpenMRS system. In order to achieve this, the team proposes creating a process for community members or organizations to submit materials to the OpenMRS education section of the website.  This team will also develop a program framework to incentivize other contributors of educational materials. For example, gamifying the program by creating incentives, such as contribution points, for creating or updating educational materials to a community area that could then be used to “buy” special OpenMRS gear or participate in special events at the OpenMRS annual event, or other such reward.

Activities for this package include both educational and training materials, as well as sample tools for conducting the work:

• Activity 3.1 - Conduct a survey to discover interest in eLearning program, incentivization schemes for contributions, and what topics would be useful for self-learning.  
• Activity 3.2 - Curate and organize education materials that have already been created by various organizations and community members.
• Activity 3.3 - Work with the OpenMRS community to develop an educational program strategic plan for OpenMRS, including the program goals, a roadmap of identified eLearning components and courses, and an incentivization scheme for encouraging other contributors for the program.
• Activity 3.4 - Generalize and tailor an OpenMRS Implementation Toolkit for use by implementers in planning and conducting implementations.
• Activity 3.5 - Curriculum development of short courses for the initial prioritized roadmap topics and sessions.
• Activity 3.6 - Record and publish prioritized Implementer’s eLearning course and pilot for proof of concept.  The team will then conduct a qualitative survey for identified test users, conduct an analysis of the results, evaluate the appropriate ‘price point’ for educational offerings and document identified improvements for the next iteration of course update and development.

In addition, we propose to build a new area of our existing partnership program to include partnerships with service providers that would like to use these eLearning courses to support implementers/implementations within their service region.  This activity is

• Activity 3.7 - Conduct a survey of potential service providers to better understand the interest and need for a Training of Trainers package, and what the appropriate model may be for utilizing this material.  Based on these results, develop a Training of Trainers package for service providers to utilize in understanding how to use the educational materials. In addition, these service providers could use the eLearning course to conduct classroom trainings to multiple implementers or organizations in a region.

Lastly, based on our broader understanding of implementer and service providers needs for education, we propose to:

• Activity 3.8: Develop a scalable business model for the educational program within OpenMRS, to ensure long term growth to meet the ever evolving needs of the community and for sustainability of the program.  Disseminate Work Package 3 knowledge and model at Global Digital Health Forum or similar conference.

Expected Outcomes

Expected outcomes from this funding include:

• Deep understanding of the wide variety of OpenMRS implementations and the impact on the health programs they serve and identification of efforts needed by the community long-term to meet the needs of those implementations
• Identification of factors for and barriers to implementation success, challenges experienced during implementation and in supporting the use of the system, and user experiences and attitudes with the system
• Determination of usability issues that cause challenges for implementations, prioritized by implementers for addition to the product release roadmap
• Improved quality assurance process that results in increased trust by implementers and engagement by implementers in the release acceptance
• Published implementation support and eLearning education materials available to both implementers and service providers supporting implementations
• Identification of an appropriate business model to increase sustainability of training and implementations

This will strengthen the OpenMRS as a Global Good, specifically addressing key indicators in the global goods maturity model, including:

• Understanding for better support of Country Utilization,
• Identification and prioritization of activities to support Country Strategy,
• Increasing Implementer Community Engagement,
• Improving the Software Roadmap process,
• Increasing Software Maturity by improving Productization and Security,
• Improving User Documentation; and,
• Focusing on Funding and Revenue sustainability through business models

Note that all work products published from this project will be licensed as open source software or under the Creative Commons license, and will be openly and freely available for download.

Use of Digital Technologies

The OpenMRS platform is a generic platform for developing electronic medical record (EMR) system implementations. It is designed to collect and manage patient-centric longitudinal medical data. The platform consists of a database, an abstraction layer between code and the database (i.e., Hibernate, a tool to map between Java objects and a database), a Java-based service layer, and a web services (a bespoke REST interface and a standard FHIR interface). The data model is heavily influenced by the HL7 reference information model and uses a central concept dictionary to define the data it contains. As a result, the system is very flexible – not focused on a specific vertical use case – and can be adapted for any patient-centric health solution. The platform is also designed to be modular, making it extremely extensible by allowing customizations to be added or removed to meet local needs. Multiple APIs are available, supporting interoperability. Proven interoperability already exists between multiple systems, and, in fact, OpenMRS has been proven to support case based reporting using the OpenHIE architecture.

Workplan and Schedule

We anticipate a 12-month workplan.  Milestone deliverables are denoted by A,B,C, and D. and are aligned with the outputs of each activity listed in the Project Deliverables section below.  We’ve identified and included 3 communities that are prioritized for our team to collaborate/consult with and to keep informed of key findings: OpenMRS, Digital Atlas, and the Digital Square Community.

Full PDF of workplan available in attachments.

Project Deliverables

Work Package 1: Understanding the Implementation Ecosystem

Work Package 2:  Improving QA Processes for Implementer Acceptance

Workstream 3: Implementation Toolkit and OpenMRS eLearning Courses

Digital Health Atlas

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

2-sentence overview

In use at over 3,000 health facilities in 64 countries worldwide, OpenMRS is a high quality, open source, integrated electronic medical record (EMR) platform aimed at resource-constrained settings where structured patient record keeping systems can improve health outcomes.  This proposal will fund improvement to the support of OpenMRS implementations by increasing implementer engagement through improved implementer alignment, community QA processes, implementation toolkits and guidance documentation, elearning and educational materials, and partnerships.

Community Feedback

The OpenMRS Community has multiple pathways for engaging with the various cadres of community members.  OpenMRS communication and engagement pathways include the Strategy & Operations calls (formerly the Leadership Team), the Project Management calls (including the Scrum of Scrums), the Design calls and Development calls, and the OpenMRS Talk forum that includes channels for developers, implementers, service providers, and distributions.  In addition, OpenMRS has both a director of community and a technical project manager that will be engaged for designing strategies and incorporating identified scopes into the various product roadmaps. The consortium will need to utilize all of these pathways to successfully achieve each of the proposed activities.

For Workstream 1, the consortium will engage with the OpenMRS community and within the network of other common digital health communities and organizations (such as DHIS2, OpenHIE, etc) to identify OpenMRS implementers and end user stakeholders, and to conduct in-depth surveys.  The consortium will engage with these communities and organizations through community forums, such as OpenMRS Talk or DHIS2 mailing list, and the network of members whom UW and RI already have existing relationships with. The consortium will specifically engage with the OpenMRS leadership team and the development community to prioritize and incorporate the results from the surveys into the product vision and strategy, including the software development roadmap.

For Workstream 2, the consortium will engage with the eSaude distribution community to leverage the automated testing framework and automated tests previously developed.  In addition, we will engage with the OpenMRS implementer and development community to identify which tests should be prioritized for end to end testing in a structured manner, and to develop the testing/QA roadmap.  The consortium will also engage other global goods communities and organizations to better understand other QA processes that are being used and how they could be leveraged to improve the OpenMRS QA process.

For Workstream 3, the consortium will work broadly across the OpenMRS community to better understand the needs for elearning and educational materials.  To specifically focus on the implementer aspect of this program, the consortium will facilitate community education program calls with specific invites to identified implementers to join.  The team will also engage with the OpenMRS service providers through virtual calls, online forum discussions, and specific outreach communication channels such as the offline mailing lists, to incorporate their input into the ToT package.

Use Cases, User Stories

Workstream 1 User Stories

User Story 1.1a As an OpenMRS implementer, I would like to find other implementers with similar contexts so that I can share knowledge and lessons learned, find out how they solved similar issues, and to potentially collaborate on aligned interests and activities.

User Story 1.2a As an OpenMRS implementer, I would like to understand how OpenMRS is being used in other implementations to help me identify additional potential uses in my own implementations.

User Story 1.2b As an OpenMRS software developer, I would like to understand the overlap of aligned interests in how OpenMRS is being used in implementations so that I can better understand what to prioritize in development based on the demand, who to engage in user centered design of that feature, and who might help test and pilot a new feature.

User Story 1.3a As an OpenMRS implementer, I want the OpenMRS system to be very user-friendly, intuitive for users, and easy for users with low computer skills or low experience with the health system.

User Story 1.3b As an OpenMRS user, I want to have a voice in what things in the software interface make it hard or impossible for me to do my job efficiently and effectively. 

User Story 1.3c As an OpenMRS implementer, I want to improve the software interface to address user challenges that prevent or hinder the training, adoption, and support of OpenMRS so that my users want to use the system because it makes their work easier and provides them value in their decision making.

User Story 1.3d As an OpenMRS software developer, I want to understand what users need improved in the interface so that I know what work to prioritize as valuable and high impact for the implementations.

Workstream 2 User Stories

User Story 2.1a As an OpenMRS user, I want to be able to use the system without bugs so that I am not interrupted or having to find workarounds to do my work.

User Story 2.1b, 2.2b As an OpenMRS implementer, I want to know that the products I am installing are rigorously tested and bug-free so that I do not experience system issues during installation or implementation that can slow or delay my workplans and deliverables, and effect future funding.

User Story 2.1c, 2.2c As an OpenMRS software tester, I want to be able to systematically test the OpenMRS products, even if I’m new to OpenMRS.

User Story 2.1d As an stakeholder in the public health system, I want to feel confident that I can make critical and timely decisions based on the data within the systems that are implemented.

User Story 2.2a As an OpenMRS software developer, I want to be able to have my code quickly systematically tested once it is integrated into the development branch so that I know if there are issues I need to fix before I can consider that work completed.

User Story 2.3a As an OpenMRS implementer, I’d like to make sure that features or changes that I requested  work the way that I expected them and need them to before I install the product at the site.

Workstream 3 User Stories

User Story 3a As an OpenMRS implementer, I want to be able to learn how to conduct a successful and sustainable implementation in a structured, replicable way.

Conditions of Satisfaction

• Educational materials must be available in a variety of formats to suit the needs and situation of the participant.
• Educational materials must be available with a recommended structured path for self-learning
• Educational materials must be available and accessible freely outside of that recommended structured pathway for those participants who want only specific topics covered.

User Story 3b As an OpenMRS implementer, I want to leverage existing training and educational materials that others have made so I don’t have to reinvent the wheel all by myself when I’m conducting trainings.

User Story 3c As an OpenMRS implementer, I want to be able to share the training and educational materials that I have created so I can either improve those materials based on others feedback or so I can find opportunities to collaborate on improvements.

User Story 3d As an OpenMRS Service Provider, I want to have a standard set of structured training and educational materials that I can use to build my business around OpenMRS and teach a broad base of customers how to implement and support OpenMRS.

User story 3e As an OpenMRS community member, I want to ensure the near and long term viability of OpenMRS so that I can rely on the software and the community to be supported over the next decade.

Self-Assessment on the Global Goods Maturity Model

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

Tagging

• OpenMRS
• Electronic medical records system
• Opensource

Additional questions for global goods definition

Executive Summary

Healthsites is building a global commons of health facility data by making OpenStreetMap useful to the medical community and humanitarian sector. We are inviting organisations to share health facility data and collaborate to establish an accessible global baseline of health facility data in support of Sustainable Development Goal 3.8 Universal Health Coverage (UHC)

The primary stakeholders are national health agencies, donor governments, and citizens accessing health services. All have a significant interest in the quality of the data that drive health systems.

We are working to establish a social business model.

Consortium Team

Open Healthsites Consulting Ltd manages The Global Healthsites Mapping Project and specialises in developing open data solutions through Agile Digital production and human centered design.

Partner organisations (Notice B)

eHealth Africa

eHealth Africa is a non-governmental organization focused on improving health systems with core technical expertise driven by technology in Health Delivery Systems, Public Health Emergency Management Systems, Disease Surveillance Systems, Laboratory & Diagnostics systems, Nutrition & Food Security Systems and in sustaining program interventions.

CartONG

CartONG is a French NGO specialised in mapping and information management for humanitarians. It is supporting partners such as MSF, UNHCR, UNICEF, Terre des Hommes to improve the implementation, monitoring and evaluation of their projects with adapted tools. 

Kartoza

Kartoza provide bespoke services for the development of custom solutions based on Free and Open Source Software (FOSS) and include core contributors to projects such as GeoNode and QGIS, InaSAFE, Healthsites.io and more.

The Humanitarian Data Exchange - Dakar

The United Nations Office for the Coordination of Humanitarian Affairs (OCHA) operates a humanitarian data platform – the Humanitarian Data Exchange (HDX). The Data Lab provide data services such as data extraction, data cleaning, storage, analysis, trainings and visualization.

GEOMATICA

GEOMATICA is a Senegalese company specializes in applied geomatic solutions.

We are looking for collaborations with organisations who have experience working with health wallets / mobile payments and understand use cases that can drive access to health care.  

Project Description

Healthsites community is focused on three key things:

1. Enabling national health agencies and organisations to share and contribute data to OpenStreetMap
2. Enabling collaboration between national health agencies and volunteer communities
3. Connecting multiple data streams to build higher quality data

Healthsites.io is planning the following activities to complement those of Notice B:

Development of a Healthsites mobile application to enable users to update health facility data and explore if more money and better data could be made available to the healthcare system if patients were paid for their labor when generating data.

Integration with Whatsapp, SMS and voice-based surveys to address Lack of access to information as well provide normative ratings and compliance that both informs the public and health providers and serves to support and improve the quality of services provided at health facilities.

Internationalization and localization of the Healthsites Web application to offer content in languages and formats tailored to the audience.

Development of the Healthsites Location Validation Index (LVI). The LVI will enhance the reliability of health facility data by calculating a score that includes for manual data checks, user profile, data source and update frequency.

Enhancement of the Healthsites API so that other service providers can leverage the technology.

Support data creation and sharing in-country by supporting OpenStreetMap communities in skilling up and training local champions of open health data, in particular to develop locally, with national actors, the use cases presented below. 

Tagging

C Client applications
D Client communication system
F Community-based information system
G Data interchange interoperability and accessibility
I Emergency response system
K Facility management information system
L Geographic information system (GIS)
S Learning and training system
T Logistics management information system (LMIS)
Y Telemedicine