Cooking Up An Open Source EMR For Developing Countries: OpenMRS – A Recipe For Successful Collaboration

Burke W. Mamlin, M.D. †‡, Paul G. Biondich, M.D., M.S. †‡, Ben A. Wolfe†, Hamish Fraser, M.B. Ch.B., M.Sc. §, Darius Jazayeri§, Christian Allen§, Justin Miranda§, William M. Tierney, M.D. †‡

†Regenstrief Institute, Inc., ‡Indiana University School of Medicine, §

ABSTRACT believe the overwhelming need for basic clinical data Millions of people continue to die each year from management (often to provide data to funding HIV/AIDS. The majority of infected persons (>95%) agencies) along with the need for rapid response in live in the developing world. A worthy response to the face of limited technical resources led to many this pandemic will require coordinated, scalable, and disparate, "stovepipe" efforts which often stored non- flexible information systems. We describe the coded values and rarely scaled well. OpenMRS system, an open source, collaborative To combat these challenges, OpenMRS aims to effort that can serve as a foundation for EMR provide the foundation and "building blocks" from development in developing countries. We report our which fledgling implementations can begin progress to date, lessons learned, and future constructing health information systems to meet directions. specific needs. Admittedly, as a fledgling effort, INTRODUCTION we’re just another stovepipe; but we hope that by Our world continues to be ravaged by a pandemic of using freely available tools, employing modular epic proportions. Over 40 million people are infected design techniques, and sharing our work, we can seed with or dying from HIV. The vast majority of these something bigger. We’re excited about our progress people (up to 95%) are in developing countries. In to date and the hunger for collaboration that we have 2005, over 3 million people died from AIDS. The found among other upstart initiatives in the field. brutality of this pandemic demands rapid and There are many components which compose a basic coordinated efforts toward prevention and treatment. OpenMRS implementation. In 2004, we (BWM & PGB) began as consultants, THE COLLABORATION asked to scale up an MS Access®-based system in OpenMRS is more than just software or a data model. western . Our response was to design and One of the more powerful and exciting aspects of develop the AMPATH Medical Record System OpenMRS is the collaboration we’ve enjoyed, (AMRS).1 initially with PIH and, more recently, with teams like One year later, we began a collaborative effort KwaZulu-Natal in South . These relationships between teams at Regenstrief Institute in Indianapolis have been nurtured, in part, through support from the and Partners In Health (PIH) in Boston. Regenstrief WHO, the Rockefeller Foundation, and the was developing the AMRS for an HIV/AIDS project President’s Emergency Plan for AIDS Relief in western Kenya and PIH was supporting existing (PEPFAR). projects in Peru and initially focused on TB but We worked collectively to construct a core expanding into HIV/AIDS.2 We quickly learned that application programming interface (API) around the our approaches and data models shared more data model and build up a framework for a web- similarities than differences and embarked on a based application running above the API. We collaborative effort to build a foundation which could leveraged weekly conferences calls, mailing lists, a be shared by both efforts and, hopefully, fuel a larger wiki site, a code versioning system, and project collaboration throughout developing countries. We tracking software to manage the collaboration. We coined the name OpenMRS for our collaborative have also tried to keep the core group of developers project. relatively small, especially at the early stages of OPENMRS collaboration. OpenMRS (openmrs.org) represents our earnest DATA MODEL attempt to create the foundation for collaborative We designed an enterprise-quality data repository EMR development within developing countries. modeled upon the lessons learned in the 30-year When we began our work on this project in early history of the Regenstrief Medical Record system. 2004, we evaluated other work in this arena. We The data model is patient-centric and conforms fairly

AMIA 2006 Symposium Proceedings Page - 529

well to standard HL7 representations of observations, DECISION SUPPORT AND REPORTING encounters, etc. It incorporates room for The tragic scale of the HIV pandemic demands that internationalization and is tightly constrained to increasingly more care be delivered by providers with guard against invalid data. At the heart of the data less training – even, at times, by fellow patients.3 model is a concept dictionary with flexible semantic The ability to deliver quality guidance to providers relationships and significant context-dependent through decision support has never been more critical metadata that is used in various ways throughout the than in this setting. application. The OpenMRS data model has been We are building a full v2.5 Arden syntax rule builder described elsewhere and is available in more detail 1 and interpreter/compiler engine which will be applied online at openmrs.org. through the repository to drive not only alerts and API reminders, but also complex concept definitions and A tightly constrained and scalable relational data research tools. Our goal is for these rules to become model is inherently complex. OpenMRS hides much a fluid feature of the API – e.g., concepts such as of the complexity within an API, which greatly “PEAK FLOW” and “ASTHMATIC” are requested reduces the upfront barriers inherent in writing code through the same API call, yet “PEAK FLOW” to realize transactions within the database. returns a simple observation while “ASTHMATIC” Developers need not worry about all of the calculates a derived concept that represents an constraints and details required for manipulating the amalgam of existing diagnoses, peak flow data model, but rather can reference database query measurements, etc. functions such as: “getObservations(patient)”. The decision support logic will most often be called The OpenMRS API is built in Java with an eye on during report generation. OpenMRS provides service-oriented architecture. Its development has reporting features through patient-level abstracts and been aided by the use of the Eclipse (eclipse.org) IDE aggregate reports. We use the template engine of for Java, Subversion (subversion.tigris.org) for Velocity (jakarta.apache.org/velocity/) to provide version control, and (hibernate.org) as an template-based report definition. object/relational persistence layer between Java and OCC the data model. The OpenMRS Concept Co-op (OCC) is a WEB APPLICATION clearinghouse that manages links between all of the We created a web-based front end for access to and vocabularies of OpenMRS participants. The OCC management of the database. This includes a full serves as an important starting point for new projects, gamut of content and data management utilities looking to get a head start on vocabulary needed to build and maintain the repository – e.g., development, and will also serve as the platform for concept dictionary management, clinical data mapping concepts between systems and to management, user management, role/privilege standardized vocabularies such as LOINC, ICD-10, management, and form management. SNOMED, and CPT. The web application is written in Java, JSP, and The OpenMRS concept management interface will HTML, using the Spring Framework integrate calls to the OCC to aid content developers (springframework.org) for MVC design and in concept development. Local implementations will internationalization and DWR (getahead.ltd.uk/dwr) be able to publish any concepts they wish to the for AJAX-based bridging between client-side OCC, contributing their mappings to the co- JavaScript and server-based Java.* operative, benefiting from any mappings performed STANDARDS SUPPORT by others, and simplifying the process of sharing data OpenMRS uses HL7 as the primary mode of between implementations. transmitting data between external applications and DATA-DRIVEN FORMS the repository. This promotes re-usability and Of course, reports are only as good as the data from interoperability. The system also supports and stores which they are derived. Before we can take mappings between local concepts and existing advantage of OpenMRS’ reporting mechanism, we standards, such as LOINC, ICD-10, SNOMED, and must get data into the system. OpenMRS approaches CPT. data entry with the flexibility and scalability of data- driven forms. Forms are defined as a collection of data pointers – more specifically concepts and/or database attributes (e.g., patient demographics). This * Asynchronous JavaScript And XML (AJAX) is a web collection serves as a schema – in the case of our first development technique for creating interactive web applications. data entry module, an XML Schema – describing the See http://en.wikipedia.org/wiki/AJAX.

AMIA 2006 Symposium Proceedings Page - 530

data to be gathered for the form (the form’s discussed and shaped the data model and then “model”). How the form’s model is used to gather constructed an API that effectively wraps the data data is up to the data entry application. model within DAO and Services layers. The initial Data-driven forms provide the power to create and suite of application modules includes a registration design forms without programming. Our goal is to and data entry module (FormEntry) along with a HL7 take form design out of the programmers’ hands and interface from one team, an Arden Syntax module put it into the realm of content management, much as from another team and a reporting module and form-generation tools (like Ruby on Rails or Plone’s messaging/event module from yet another team. Archetypes) aid the developer in rapidly generating There has been little redundancy in efforts, which has forms. made collaboration easier thus far. Our first stab at data entry uses Microsoft® Office The collaboration has been greatly aided by regular 2003’s InfoPath® tool for form design and form communication, including weekly conference calls, a completion. We found the thicker client interface mailing list, a wiki, and a simple, yet elegant project afforded by InfoPath® to be a better experience that management system (edgewall.com/trac/). was not yet easily matched by browser-based While collaboration was easier at first, we’ve technologies such as AJAX. We were also attracted encountered some challenges while scaling up. by InfoPath’s ability to save form data as discrete Changes to the data model are more difficult to files – a feature we could use to for remote data implement once multiple implementations are in use. entry. In any case, not only InfoPath®, but also We’ve also found increasing energy is required to several other solutions are rapidly evolving toward a coordinate efforts and align design goals amongst richer client experience for web-based applications. multiple teams as the infrastructure’s scope grows. Our options for data entry tools will only increase There has also been a tension between bringing more over time. developers on board and getting overwhelmed by the OPEN SOURCE number of voices. OpenMRS comprises, almost entirely, open source Thus far, we have enjoyed the process of components and is itself available for public collaboration and OpenMRS has been much better consumption through open source licensing. We do served for it. Our efforts invested in collaboration not advocate open source as an alternative to have already begun paying dividends. commercial products; rather, we have chosen open 2. Scalability – the infrastructure must not only source technologies where they could meet our needs handle thousands of patients and hundreds of in order to reduce the barriers to adoption. Our goal thousands of observations, but also be scalable to is to allow projects to visit our website, download the tens of thousands of patients and millions of platform, and get started immediately at little to no observations up-front cost, helping to foster a collaborative The best test of scalability is proven usability in the development community. field. Admittedly, OpenMRS is young. Despite its PROGRESS REPORT youth, we have entered thousands of patient When we described our early work at AMIA 2005, encounters with a surprising lack of problems. We we laid down a series of nine design goals.1 Here, we owe this, in large part, to the fact that OpenMRS' data cover each of our goals and how we’ve done in model design was fashioned from proven, large-scale meeting them: the successes and the challenges systems. we’ve faced. Scaling up comes with its own challenges. Large 1. Collaboration – systems need to be developed scale systems require enterprise-quality design. For openly and built upon a common infrastructure, the example, as we adopted Hibernate as a persistence sharing of "best of breed" modules can best occur layer, we were initially performing our database within a shared platform transactions within the database layer. As we began We switched from Zope (a python-based portal that scaling up, this proved unsustainable and required a supported the original AMRS) to Java as our re-design to allow for transactions to occur at an development environment. We decided on Java, application level, above the service layer. primarily because the language works well in a 3. Flexibility – systems must support not only HIV- collaborative development environment by aiding centered care, but also general medical care, since good coding practices and normalizing coding styles, clinical care is not limited to HIV It also had some practical advantages (PIH’s To date, our content has focused only on HIV- and experience in Java, large existing base of potential TB-specific care. While our content (initial concepts, Java developers in the community). . The teams forms, and reports) are HIV- and TB-centered,

AMIA 2006 Symposium Proceedings Page - 531

there’s nothing about the code or infrastructure that for representation of data outside of the system and limits us to these domains. for of data. We have also targeted HL7 4. Rapid form design – data collection needs are a as a medium for transmission of data into and out of moving target; therefore, form design and the system. In fact, we’re working on a WHO and deployment must allow for continual change CDC-sponsored pilot to demonstrate the feasibility of In most of our sites, clinicians are completing paper using HL7 and vocabulary standards to transmit a forms which are collected and sent for data entry (or minimum dataset for HIV care between OpenMRS entered on site) before returning to the patient’s chart. and another independent system (Care-Ware). OpenMRS must keep up with changes to existing The primary challenge for using standards is the forms and allow for newly introduced forms. Also, simple faith that the additional energy expended in adding this information to the system must not delay supporting a standard returns values greater than the revisions to the paper forms. By using data-driven cost. In an environment where re-usability and forms within OpenMRS, changes to forms are made collaboration are the rungs to our ladder, we have no without programming, facilitating a rapid response. choice but to embrace standards whenever possible. One of the early challenges we faced with form 7. Support high-quality research – via non- design was simply the need to organize and ambiguous, coded data coordinate efforts so that all affected parties were Nearly all data collected by OpenMRS is coded. aware of changes. For example, simply adding While OpenMRS can accept non-coded observations version numbers to forms and creating an official (e.g., narrative reports), we have avoided these in the “Form Approval” committee has helped smooth the early phases of data collection, since our primary process. More challenges lie ahead. As multiple source of data is checkboxes on paper forms. implementations start using forms, there will likely Getting quality coded data into the system is highly be a desire to share forms between institutions. Since dependent on the quality of data collected in the field. the forms comprise implementation-specific One of our early challenges was trying to convert concepts, these components must be “translated” ambiguous questions on the existing paper forms into from one implementation to the next. Our hope is the non-ambiguous coded concepts. We used clinicians, OCC will facilitate the mappings needed for such a researchers, data managers, and informaticians to process. refine our paper encounter forms, focusing on 5. Clinically useful – feedback to providers and reducing ambiguity, increasing quality, maximizing caregivers is critical – if the system is not clinically the efficiency of data collection. Once the questions useful, it will not be used and answers on the paper encounter forms were Our first task after getting data into the system was disambiguated, created coded concepts for them was getting it back into the hands of those who generated relatively straightforward. the data – that is, the clinicians in the field. This OpenMRS helps content managers avoid ambiguous prioritization is driven by three beliefs: (1) clinical concepts by providing simple tools during concept summaries and decision support can improve patient development that search for similar concepts or look care (our primary aim), (2) all other parties – up definitions online. We expect the OCC to aid in including those looking for aggregate data – will best non-ambiguous concept development as well. To aid be served by reliable, coded data, and (3) maintaining in research, OpenMRS allows data managers to quality within the data relies, in large part, on getting define cohorts of patients and select observations of data back into the hands of those generating the data interest which can then be exported into a flat file for – i.e., errors in data entry are most likely to be analysis and reporting purposes. recognized by the providers caring for individual patients. 8. Web-based with support for intermittent connections – developing countries do not always The challenge will be keeping all parties happy. have reliable power or internet connections, but Clinicians must genuinely recognize the value of the when available, internet-based technologies offer data they’re producing and governmental and funding increased scalability agencies must be satisfied with their interval reports. While the OpenMRS database and surrounding API We believe our best chance of pleasing everyone is do not rely on a web-based front-end, the core through the collection of highly coded, quality data. application and all modules to date are managed 6. Use of standards – to maximize the flexibility and through a web-based interface. All content and extensibility of the system interaction is served through SSL connections for We have adopted several standards within the security. So, with reasonably fast internet OpenMRS system. We rely heavily on XML, XSLT connections, remote data entry can be performed

AMIA 2006 Symposium Proceedings Page - 532

today over any distance. Support for remote data extended through active user forums and published entry with intermittent or absent internet connectivity books. is a work in progress. The FormEntry module lends PARTNERSHIPS CAN CHANGE LIVES itself to a disconnected environment, since InfoPath Indiana University and Regenstrief Institute have provides a mechanism for saving form data directly been immeasurably rewarded by the partnership with to a file, but there is still a need for keeping remote Moi University in Eldoret, Kenya and through patient lists synchronized with the central repository. working with our Kenyan colleagues. Mechanisms for doing this are in development. There's an immediate need for partners that have a 9. Low cost – if the system is to be widely available deeper level of informatics expertise. We need help and adaptable in developing countries, cost must not building and maintaining this infrastructure. We've prohibit adoption. Ideally, the nuts and bolts of the been asked to scale the early pieces of this project system should be downloadable for free. into Tanzania and , but, as you can imagine, OpenMRS comprises, almost entirely, open source once these sites get in the habit of collecting quality components and is itself available for public structured data, they're going to want to maximize consumption through open source licensing. their workflows by building and customizing Everything from the database to the web server we multiple applications that re-use the data to serve use can be downloaded off the internet and used for many different uses and constituencies. Our groups free. The only aspect of the current system that is not alone cannot scale this effort appropriately. In fact, open source and freely available is InfoPath®, which we believe that each country implementing was chosen for features not yet matched within the OpenMRS should have a companion informatics open source community. Since InfoPath® is a team in a developed country with significant component of Microsoft® Office, it does not pose a informatics/programming expertise to help dive into significant barrier to adoption. the bowels of the OpenMRS source to tailor the Although the system is freely available, the cost of system. We're not building a turnkey system by content management and expertise needed for design, because we don't consider it feasible in these adapting the system for various implementations is types of resource-poor environments. not trivial. While we do not believe that a turnkey FUTURE PLANS solution is viable, we hope that, as OpenMRS The OpenMRS system has been deployed into matures, the barriers to adoption will continue to Eldoret, Kenya and is planned for use in Tanzania decrease, and the costs to implementation will and Uganda. PIH is adapting OpenMRS to their decrease as well. needs to serve . A team in KwaZulu-Natal is LESSONS LEARNED working to implement OpenMRS within South NOTHING INFORMS DEVELOPMENT MORE Africa. THAN LIFE ITSELF Our work has just begun. In the initial implementation of the FormEntry module, we had patient searches restricted to either a ACKNOWLEDGEMENTS We are indebted to the World Health Organization and PEPFAR name lookup or exact identifier. Once we tried using for their generous support, and to Dr. Joseph Mamlin for his this algorithm with actual encounter forms, we leadership and sperm. This project was supported by a grant from discovered that ~25% of the patients could not be the Rockefeller Foundation and grant number 1-D43-TW01082 properly identified within the system using data from from the Fogarty International Center, National Institutes of the paper form. After adjusting the search algorithm, Health. we were quickly able to reduce the failure-to-find REFERENCES rate to near zero. In fact, we were pleased on the first 1. Mamlin BW, Biondich PG. AMPATH Medical day of training when data entry assistants could not Record System (AMRS): Collaborating Toward an only find the patients easily, but also were able to EMR for Developing Countries. AMIA Annual identify transcription errors in the patient identifier Symposium; 2005; 2005. based on search results within the new system. 2. Fraser H, Biondich P, Moodley D, Choi S, Mamlin B, Szolovits P. Implementing electronic medical USE LIBRARIES WITH A LARGE USERBASE record systems in developing countries. Informatics We have found powerful efficiencies through the in Primary Care. 2005;13:83-95. adoption of popular open source development tools 3. Wools-Kaloustian K. Community Care such as Subversion, Eclipse, Hibernate, Spring Coordinator Protocol. Unpublished work. Indiana Framework, and MySQL. With an adequately large University; 2006. user base, online support and documentation is

AMIA 2006 Symposium Proceedings Page - 533