A Mature API for an Electronic Health Record: the OpenMRS Process

Posted on August 14, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

By some measures, OpenMRS may be the most successful of the open source EHRs, widely deployed around the world. It also has a long experience with its API, which has been developed and refined over the last several years. I talked to OpenMRS developer Wyclif Luyima recently and looked at OpenMRS’s REST API documentation to see what the API offers.

One example (which I have taken from the documentation) is that one concept defines an object in the system, blood type. Four answer concepts define the value that you can assign this object: A, B, AB, and O. Note that the example in the documentation doesn’t include RhD status (normally designated with + and – signs).

This tiny detail shows how complicated it can be to define adequate values for health conditions. Whole ontologies such as SNOMED and LOINC have been developed to meet these needs. Transgender patients, a growing population, make coding even more complicated.

OpenMRS offers some advanced features, such as the ability to add patients to “cohorts.” This is helpful in tracking epidemics or identifying patients who may be candidates for a research study.

The RESTful API is not the only way to interact with OpenMRS. The API is built on top of the underlying Java API, which developers also use. The Java API (and in the future, the RESTful API as well) lets you can define a “program” for a patient, assign “workflows” to a program, and define “states” through which a workflow passes.

One area I’d like OpenMRS to explore is support for checking that a patient is handled correctly as she moves through a workflow. For instance, certain things have to be done in a hospital before a patient is discharged: a medication list has to be drawn up, a discharge summary needs to be written, a doctor has to do a final visit to make sure the patient is stable, etc. An EHR should help institutions enforce these rules–it should refuse to let a workflow move to the “discharged” state without a discharge summary in place.

Currently, it’s up to the programmer to code such requirements outside of the EHR. This harks back to a long-standing discussion in the computer field about what restrictions a database should enforce and what should be one at the programmatic level. Databases offer “triggers” to take some checks and error reporting (among other things) off the programmer’s hands.

As a global open source community, the OpenMRS project has hundreds of worldwide contributors and API users. Its documentation is supplemented by OpenMRS Talk, an online forum for project planning and support. The modular architecture allows new features to be plugged in, like FireFox plugins or Chrome extensions.

Third-party mobile apps have begun to appear, with the OpenMRS community actively developing Android and iOS apps. An exemplary open source project is mUzima, which uses the API to enter and read data from OpenMRS. Beyond mobile, the API is heavily used in some parts of the world to enter data. OpenMRS, therefore, appears to be a mature API with proven value.