OpenMRS as an emergency EMR—How we used a global good to create an emergency EMR in a week

Abstract

Background

As the coronavirus pandemic progressed through the United States, Indianapolis Emergency Medical Services (IEMS) identified a gap between the health system capacity and the projected need to support an overwhelmed health care system. In addressing emergencies or special cases, each medical institution in a metropolitan area typically has a siloed process for capturing emergency patient records. These approaches vary in technical capabilities and may include use of an electronic medical record system (EMR) or a hybrid paper/EMR process. Given the projected volume of patients for the COVID-19 pandemic and the proposed multi-institutional team approach needed in case of significant provider illness, IEMS sought a simple, efficient, consolidated EMR solution to support planning for the potential capacity gap. IEMS approached Regenstrief Institute (RI), an established partner with experience in supporting OpenMRS, a global good EMR platform that had been deployed in multiple settings globally.

Objective

The purpose of this project was to determine if OpenMRS, a global good, could be used to quickly stand up a system that would meet the needs for health emergency data collection and reporting.

Design and implementation methods

The team used an “all hands on deck” approach, bringing together technical and subject matter experts, and a human-centered and iterative process to ensure the system met the key needs of IEMS. The OpenMRS Reference Application was adapted to the specific need and deployed as Docker containers to servers within the Indiana Health Information Exchange.

Project outcomes and lessons learned

In less than two weeks, the Regenstrief team was able to install, configure and set up a working version of OpenMRS to support the desired electronic record requirements for the IEMS disaster field clinics. Using a human-centered approach, the RI team developed, tested, and released a user-friendly, installation-ready solution complete with an end user manual and a base support plan. IEMS and RI are sharing this approach to demonstrate how a global good can quickly generate a solution for COVID-19 and other disaster responses.

Conclusions

Open source global goods can rapidly be adapted to meet local needs in an emergency. OpenMRS can be adapted to meet the needs of basic emergency medical services registration, triage, and basic data collection.

1. Background

As the coronavirus pandemic progressed through the United States in March of 2020, Indianapolis Emergency Medical Services (IEMS) realized that, according to nationally accepted statistical and disease transmission models [1], the city’s traditional healthcare systems could be overwhelmed in as little as two weeks. As with many sites across the country, the team was challenged to devise a support structure to mitigate potentially overwhelmed emergency medical services (EMS), emergency departments (EDs), and hospitals. To meet this infrastructure need, Indianapolis EMS (IEMS) proposed establishing urgent care disaster field clinics as alternate care sites to provide care to patients with low-acuity COVID-19 infections, COVID-19 exposure, or low-acuity non-COVID concerns. The field clinics were designed to be administered by the public health department in collaboration with IEMS and staffed by various healthcare groups throughout Indianapolis. This delivery framework included a patient-level record system that could be deployed within two weeks in case statewide-applied social distancing measures were ineffective in slowing the projected curve of COVID-19 cases. The clinics required a basic electronic medical record (EMR) system to register patients into their disaster field clinics, capture vitals, record encounters, and communicate data to the Indiana state health information exchange.

As in many disasters throughout the country, responders in Indianapolis have historically relied on a combination of paper records and conventional EMR owned and operated by distinct institutions during crisis situations. Given the volume of patients likely to present to healthcare systems during the COVID-19 pandemic and the possible requirement for multi-institutional teams that would be required in case of significant healthcare provider illness, IEMS perceived a critical need for a simple EMR that would fall under the purview of the state, communicate with statewide data to facilitate patient care, and be usable by multidisciplinary teams from multiple institutions. While hospital systems around the world with established commercial systems were adapting and expanding those systems [[2], [3], [4]], the IEMS team was starting from scratch. Because of an established, positive relationship, IEMS reached out to Regenstrief Institute (RI) for an EMR solution to fill the void highlighted by the COVID-19 health crisis in Indiana. The RI Center of Biomedical Informatics (CBMI) Global Health Informatics (GHI) program [5] has demonstrated success in the design and implementation of OpenMRS, one of the world’s leading open source EMRs used in international and disaster settings [6,7]. OpenMRS is a global good that has been widely adopted in resource-constrained environments [8,9]. The challenge was to determine if the RI team could meet IEMS’s EMR requirements in a matter of days.

1.1. A week from requirements to solution

IEMS required a solution that would enable a designated field disaster clinic to offset low acuity COVID and low acuity non-COVID cases from typical emergency room care. The thought was to unburden overwhelmed EDs, improve ED flow to reduce ambulance wall time, and provide medical care to patients with non-COVID related complaints without exposing them to COVID patients in the ED. The system was designed to support patients who likely would not require hospitalization or a high level of care. The desired base functionality included the ability to record:

• ●Patient demographics
• ●Vital signs including temperature, respiratory rate, blood pressure, oxygen saturation, heart rate, height, and weight
• ●Visit details for a suspected COVID-19 case, including the capacity to simply capture patient symptom and disposition data
• ●Visit details for patients unlikely to have COVID-19

The OpenMRS Reference Application (demo.openmrs.org) innately supports the ability to manage user accounts, register patients, record vitals, record allergies, and handle basic clinical encounters. Although not critical, IEMS also desired the ability to send patient registration data to the Indiana Health Information Exchange (IHIE). IHIE collects information from a large percentage of Indiana’s care facilities. Sharing the patient registration with IHIE would allow IHIE to link a patient to existing records from other health systems and allow disaster clinic staff to access pertinent medical history, including COVID-19 test results. The modular architecture of OpenMRS allowed this functionality to be quickly included in the solution.

Within days of the initial discussion reviewing IEMS requirements and existing OpenMRS functionality, the RI team created a working demonstration to show how the tool could support the required functionality. An existing form from another OpenMRS-based project at RI called the Academic Model Providing Access to Healthcare [10] was used as a template for the disaster clinic prototype. In the seven days between the initial discussions on the concepts and the demonstration, the RI team worked with IEMS on a business process that entailed patient registration, vitals and COVID-19 and non-COVID 19 visits, and the base data collection requirements for that process (Fig. 1 ). In addition, the team worked on terminology, application installation, form design, and configuring a workable prototype.

Fig. 1.

IEMS disaster field clinic process overview.

In the week that the RI team had to configure and demonstrate the system, Indiana and Indianapolis residents were observing Governor Holcomb’s Stay-At-Home order and the COVID-19 predictive models were regularly refined. The resulting reprieve in the burden to the healthcare system provided the RI team with additional time to fine-tune the production system. The team addressed minor feedback on the COVID-19 form and the interface, modified packaging to allow easy installation of production and test systems, and further developed and tested the data exchange with IHIE A module was created to trigger on patient registration and send HL7 messages to the HIE in its preferred format (HL7 v2 A04 events) with demographics and an OpenMRS-generated unique patient identifier, allowing clinicians to use that identifier to access the patient’s statewide chart within the HIE. The solution is being shared in hope that the creativity used to quickly build this solution can serve as a foundation for international communities engaging in field work, responding to the ongoing COVID-19 pandemic, and responding to other disasters.

2. Design and implementation methods

2.1. Technology

To meet the short timeline and create a reproducible configuration of OpenMRS that would meet IEMS requirements, the Regenstrief team leveraged OpenMRS’ pre-packaged Reference Application 2.9.0 docker image as the base application [11]. OpenMRS is a freely available, open source medical record system platform released under Mozilla Public License 2.0 with a Healthcare Disclaimer. Readers are encouraged to visit the OpenMRS Wiki (wiki.openmrs.org) for an overview of the system. The first step was to understand the requirements and develop a paper data capture form. Next, the team developed a COVID-19 data dictionary that included the necessary IEMS questions and concepts required to support the implementation. These concepts were matched with the Columbia International eHealth Laboratory (CIEL) dictionary codes, used by most OpenMRS implementations [12]. CIEL had recently been updated to include COVID-19 concepts. Following code matching, the data dictionary was formatted for the OpenMRS Initializer Module designed by Mekom Solutions (mekomsolutions.com) and used by many OpenMRS implementations [13]. The Initializer Module allows metadata (concepts, locations, encounter types, etc.) in CSV or XML form to be automatically imported into the system. The initializer module served as the primary terminology management tool for ensuring consistent concept metadata across the development, testing, and production instances of OpenMRS. The team also needed to create a data entry form that would support the data capture for a COVID-19 visit. An HTML form was created to mirror the IEMS COVID-19 paper form. This form was incorporated into the data collection interface of OpenMRS to be used by clinicians and staff in the field. These steps provided an initial configuration of the OpenMRS system that could be reproducibly created.

While the system met most of the requirements of IEMS, there were some minor defects in the user interface and the application was not designed to work well on mobile devices. OpenMRS has a community development model that enables world-wide contributions. Fortunately, during the same week under the direction of a Ugandan release manager, the OpenMRS Community released a new version of the OpenMRS Reference Application (version 2.10) that addressed these deficiencies and Regenstrief was able to easily switch to the updated OpenMRS version.

To support the implementation, Regenstrief and IEMS reached out to IHIE to provide the infrastructure to run the application. Using their service provider, IHIE was rapidly able to provide two virtual machines (Four 2.3 GHz CPUs, 8 GB RAM, 60–100 GB disk) and arrange for VPN access for the Regenstrief development team within an isolated section of their production network.

2.2. Human-centered approaches and techniques

Although the solution was developed on a rapid timeline, the team used human-centered approaches to ensure that the system would meet the needs of the disaster clinic teams, applying an iterative agile approach focusing on the User Acceptance Testing (UAT) quadrant of Marick’s Agile Testing Matrix (Fig. 2 ) [14]. To accomplish this, the RI team met with the IEMS for a few minutes nearly every day to understand quickly evolving strategies and plans for care in central Indiana and to ensure that the system was evolving in a manner consistent with IEMS plans and the COVID-19 trajectory. RI also produced a paper data collection form in case of system non-functionality. The IEMS team completed usability testing to ensure that the form was readable, easy to complete, and captured the desired information. As the system was being developed, the RI team performed frequent, iterative demonstrations and IEMS conducted reviews of draft support documentation to ensure customer alignment with the system functionality.

Fig. 2.

Marick’s Agile Testing Matrix.

2.3. Validation and testing

Application testing, performed by the RI team, focused on system functionality, the ability to maintain system performance for the anticipated system load, and testing of a repeatable installation process supported by appropriate application configurations. The RI team also created a framework for IEMS to use to conduct user testing. The IEMS physicians and the IEMS technical lead executed test cases and anticipated workflow scenarios to ensure that the system adequately supported the clinical requirements and business process needs. After testing, IEMS proposed minor changes, such as adding support for imperial instead of metric measurements. None of the proposed changes were deemed requisite to utilization in the field. RI reviewed the proposed changes and determined which could be implemented quickly.

2.4. Support and training

The plans for training and support during live operations were minimal but human-centered as well. RI developed support documents to outline steps for using the system in the disaster clinics. This material included information for using the system to support the health workflow and information for managing functionality like account creation and password management. Because it was unclear what the support needs for the system might be, RI and IEMS created an approach that leveraged the existing IEMS help desk and technology team with further support from RI for technical issues that could arise during operation. The approach was intended for iteration once the RI and IEMS better understood the support needs that might arise during production system operation.

3. Project outcomes and lessons learned

3.1. Project outcomes

IEMS and RI were able to leverage OpenMRS, a global good EMR platform, from initial plan to a working prototype in a week and a had tested and approved a production-ready basic EMR (user accounts, registration, clinical dashboard, vitals collection, and basic encounter forms) for a disaster response within two weeks. This was possible through the combination of an “all hands on deck” approach with daily stand-ups, a combination of skill sets (BAs, developers, subject matter experts, project managers), and the work done by open source communities like OpenMRS and Docker. The basic functionality of an EMR, including registration, vitals, and simple data collection, was valuable for public health epidemiology. This particular use of a field disaster clinic aligned with the basic needs of a clinic workflow shared across many implementations.

At least 80 % of what we needed was already available in the OpenMRS Reference Application and this was further improved by the timely release of OpenMRS Reference Application 2.10. The up-to-date changes, including COVID-19 concepts, within the community’s CIEL dictionary provided most of the concepts we needed for COVID-19 encounter forms. All of this was made possible through the OpenMRS Infrastructure supported by Jetstream [15,16]. By adopting Mekom Solutions’ initializer module for OpenMRS, we were able to package metadata to configure the system in a way that not only allows the system to be set up quickly, but also easily adapted for future use cases. In the process of exporting the CIEL dictionary into a form used by the initializer module, we were able to find and resolve bugs that benefit others within the OpenMRS community.

Working closely with rapid iterations with providers who would use the system alongside subject matter experts and developers allowed us to identify and quickly address usability issues, getting to a workable solution more efficiently. The “all hands on deck” approach enabled by a pandemic response also allowed us to quickly bring additional members into our team and facilitated coordination with our partners.

The early adoption of a “deployment perspective” – i.e., choosing solutions that could be automated or semi-automated and were repeatable as part of a deployment pipeline rather than manual adaptations – not only led us to develop reusable artifacts, but also made our solution more robust. For example, we could use the same pipeline to deploy development, testing, and production environments.

Our initial experience and some performance testing of the system provided confidence that a Docker-based deployment of OpenMRS could meet production requirements. The use of Docker Compose with published images for MySQL, OpenMRS, and Nginx provides an application stack that can be rapidly and reliably deployed and adapted to needs.

3.2. Lessons learned

Applying EMR functionality to epidemic use. As seen with Ebola and now COVID-19, an EMR platform can be adapted to meet the needs of healthcare workers in a disaster.

Adapting vs. building from scratch. This project underscores the value of global goods available as open source and how these goods make it possible to reach a solution much quicker than starting from scratch.

Engaging SMEs. We benefited greatly from having the attention of subject matter experts in clinical informatics, OpenMRS content and architecture, and in emergency medicine. This approach facilitated rapid iteration to meet the needs of the team.

Rapid development cycle. The “all hands on deck” approach afforded by a pandemic response allowed us to perform development cycles more rapidly than usual and resulted in a better solution far more quickly than normal. It raises the question whether replicating aspects of this “all hands on deck” approach (focused team attention) could also be useful in non-emergency situations.

Prioritizing re-usability. Resisting the “just get it working” shortcuts and forcing ourselves to fit solutions within a deployment pipeline ended up saving us time and provided a more reliable solution that supported a reusable deployment strategy.

4. Discussion

This project demonstrated the power of public goods such as OpenMRS and Docker. The speed at which we were able to deploy a production ready system was largely due to the great work of these open source communities and the global goods that are designed to support base requirements. We’ve outlined the key steps involved in adapting OpenMRS to our specific need along with the requirements needed for each step in Table 1 .

Table 1.

Key steps and what is needed to adapt OpenMRS to specific needs.

Key Step	Requirements
Setting up OpenMRS	Prior experience deploying OpenMRS or assistance from a service organization experienced in deploying OpenMRS. Steps such as using a secure web proxy, limiting exposed ports, and enforcing strong passwords as important for security. Examples from efforts like ours and a strategy within the OpenMRS community toward standardizing a container-based deployment will make this easier in time.
System configuration	Prior experience deploying OpenMRS or assistance from a service organization experienced in deploying OpenMRS will help. Alternatively, OpenMRS documentation and help through community forums could be utilized.
Concept management	A terminologist or assistance from a service organization experienced in deploying OpenMRS. OpenMRS uses a central concept dictionary and the concepts (questions & answers) needed to support forms must be present. In our effort, we used the CIEL dictionary and a few custom concepts. Efforts in the OpenMRS community such as the Open Concept Lab will make this easier in time.
Form design	Adapting encounter forms or creating your own requires some basic HTML editing skills and working with the HTML Form Entry module. It helps to have a basic understanding of how data are modelled as observations within OpenMRS.
User acceptance testing	Business analyst(s) capable of demonstrating the system to users and communicating their feedback to a developer or to a service organization assisting with the deployment.
HIE integration	Java development skills and the ability to make a simple OpenMRS module. There are organizations and individuals within the worldwide OpenMRS community who could be hired if needed.

There are several limitations to the system. While clinical data are protected, this system is not a HIPAA-certified system, so its use outside of a disaster “break the glass” response is limited. While the OpenMRS Reference Application can gather basic information into a medical record, it does not have some basic functions of an EMR such as order entry or decision support.

The team has proven that it’s possible for a solution like this to fill a gap in disaster and other temporary clinics. With simple modifications to the solution, there is the potential for applicability to other cases requiring extension to the traditional health system and public health settings and in other disaster situations. Next steps include piloting the system, adapting & applying the solution to other use cases, investigating HIPAA certification or approaches for certifying support of global privacy and security needs, and further integration with the health exchange. Further exploration could be done to determine if a solution like this is applicable for long-term health facilities as well. The artifacts from the project are available as open source products [17] and a summary of the project was presented as a Lightning Talk for the OpenMRS Community [18].

Summary table

What was already known

• • •
    OpenMRS provides an open-source platform for building electronic medical record systems
  • •
    Emergency Medical Services responding to crisis situations, such as the COVID-19 pandemic, need access to electronic medical records to provide efficient and effective care

What this study has added:

• • •
    Open source global goods can rapidly be adapted to meet local needs in an emergency.
  • •
    OpenMRS can be adapted to meet the needs of basic emergency medical services registration, triage, and basic data collection.

Funding sources

Contributions for this emergency effort were provided in kind. This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors.

CRediT authorship contribution statement

Burke W. Mamlin: Conceptualization, Methodology, Software, Validation, Investigation, Resources, Writing - original draft, Writing - review & editing, Visualization, Supervision, Project administration. Jennifer E. Shivers: Conceptualization, Methodology, Software, Validation, Investigation, Resources, Writing - original draft, Writing - review & editing, Visualization, Supervision, Project administration. Nancy K. Glober: Conceptualization, Validation, Writing - review & editing. Jonathan J. Dick: Conceptualization, Methodology, Software, Validation, Investigation, Resources, Writing - original draft, Writing - review & editing, Visualization, Supervision, Project administration.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.