Enabling Better Interoperability for HealthCare: Lessons in Developing a Standards Based Application Programing Interface for Electronic Medical Record Systems

From Clinfowiki
Jump to: navigation, search

Review: Enabling Better Interoperability for HealthCare: Lessons in Developing a Standards Based Application Programing Interface for Electronic Medical Record Systems[1]

Abstract

The authors developed an Application Programming Interface (API) to generalize interaction with OpenMRS using FHIR and "prevent ... developers from having to learn or work with a domain specific OpenMRS API". The work is intended to provide a model for retiring legacy/domain-specific APIs in favor of generalized, domain-independent APIs for EMRs implementing FHIR.

Objectives

The authors introduce FHIR in the context of the history and limitations of the HL7 v2 and v3 standards, and present it as a viable alternative that can address the problems that the earlier HL7 standards are known for. They offer it as a remedy for healthcare data fragmentation. Specifically, they note that the native API of OpenMRS, an EHR "system that is widely used across resource poor settings", has a number of limitations built-in because of its design. In particular, the API is domain specific, so developers have to learn the domain to use the API; on the other hand, the API is extensible, so some "domain objects can be generic". The authors describe how FHIR can be applied as an API whereas standards such as Clinical Document Architecture (CDA) are tied to documents. FHIR can support documents but also "other resource exchange frameworks including messaging, searches and operations." Additionally, there is work being done on a "CDA on FHIR initiative" which will allow FHIR to represent CDA objects. Though discussing the benefits of FHIR the authors note that OpenMRS is not readily capable of integrating with FHIR resources; they therefore set out to develop an API that can be used to extend OpenMRS to provide interoperability and to work toward specifying a new native FHIR API for OpenMRS.

Materials and Methods

This section first discusses the background of OpenMRS, FHIR, and the current status of OpenMRS interoperability. The authors note that OpenMRS was not architected with interoperability specifically in mind, so the "ad hoc efforts that were less synchronized with long term architectural goals" resulted in a fragmented set of available add-ons for OpenMRS, many of which duplicated each other's effort.

FHIR Development Efforts

The development goal was to build software to "enable the management of OpenMRS data as FHIR resources." The software is meant to be domain independent. The authors worked to identify existing FHIR libraries that could be used in their project so that they could focus on developing the integration between OpenMRS and FHIR instead of developing an implementation of FHIR first. They selected the HAPI-FHIR library on the basis of its active development community which they judged to be most likely to be able to sustain development and support of the library in the longer term.

Architecting the FHIR Module

The authors wrote their FHIR module as an independent API and did not use the existing web services layer of OpenMRS. They discuss the technical details of the API in some depth, including the development of their own web services layer.

Results

The authors were successful in developing their API. It provides access to "FHIR Patient, Person, Location, Observation, Encounter and Allergy Intolerance resources" from OpenMRS in XML and JSON formats. They have published their software with an open-source license in the repository of extensions to OpenMRS.

SMART on FHIR for OpenMRS

The team also demonstrated the interoperability of their API by integrating an OpenMRS instance with an instance of the SMART Pediatric Growth Chart application. A graphical representation of the integration workflow is presented in the article.

Discussion

The authors recommend that their approach be adopted by the OpenMRS project, as their success "highlighted the value of moving towards a domain independent and standards based API that supports interoperability", whereas the existing OpenMRS API is constrained in these areas. They recognize, though, that integrating the API is technically challenging, so they propose a development roadmap that is meant to allow for a rolling, phased integration.

Conclusion

The authors are realistic in noting that in order for their API and the dataflow model it represents to be adopted, FHIR itself has to be adopted more broadly in the health information technology (HIT) market, that the OpenMRS community has to embrace it, and that FHIR has to move beyond its current status as a draft standard; they note that this combination of factors could take many years to coalesce. They optimistically state, though, that even if FHIR never takes off, their work can still be of value in that it represents an advance in the understanding of development of standards-compliant and domain-nonspecific APIs for open source healthcare projects, even if another standard is ultimately adopted.

Comment

The article demonstrates an interesting point that allows the reader to know that HIT is approaching the integration and interoperability of the EHR system through many programs and softwares. The FHIR is one step further in the advancement of the adoption and implementation.

References

  1. Kasthurirathne, S., Mamlin, B., Kumara, H., Grieve, G., & Biondich, P. (2015). Enabling Better Interoperability for HealthCare: Lessons in Developing a Standards Based Application Programing Interface for Electronic Medical Record Systems. J Med Syst Journal of Medical Systems, 39(182). http://dx.doi.org/10.1007/s10916-015-0356-6