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

Review: ''Enabling Better Interoperability for HealthCare: Lessons in Developing a Standards Based Application Programing Interface for Electronic Medical Record Systems''<ref>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</ref>

==Abstract==
The authors developed an [https://en.wikipedia.org/wiki/Application_programming_interface 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 [http://jamesagnew.github.io/hapi-fhir/ 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_uses_for_public_health | 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==
<references/>

[[Category:Reviews]]
[[Category:EHR]]
[[Category:Interoperability]]
[[Category:HI5313-2015-FALL]]
[[Category:HIE]]
[[Category:Interface, Usability and Accessibility]]
[[Category:Meaningful Use]]