Electronic Health Reporter

Guest post by Jason W. Buckner, senior vice president, informatics, The Health Collaborative.

Last year, 2015, was a year of buildup, anticipation, and finally some bold moves to propel healthcare technologies forward, specifically regarding interoperability of data. The Office of the National Coordination, under the auspices of the department of Health and Human Services, released the long-awaited and much-debated meaningful use Stage 3 requirements in October. All the players in the health tech space were awaiting the final verdict on how Application Programming Interface (API) technology was placed into the regulations, and the wait was worth it, regardless of which side of the fence you were on. Before we get into the predictions, though, a little background knowledge about these technologies, and their benefits, will be helpful.

API Overview

An API is a programmatic method that allows for the exchange of data with an application. Modern APIs are typically web-based and usually take advantage of XML or JSON formats. If you are reading this article, you almost inevitably have used apps that exchange data using an API. For example, an application for your smartphone that collects data from your Facebook account will use an API to obtain this data. Weather apps on phones also utilize an API to collect data.

HL7 Overview

Next let’s take a look at the history of interoperability of healthcare data. HL7 2.x is a long standing method to exchange healthcare data in a transactional model. The system is based on TCP/IP principles and typically operates with Lower Layer Protocol (LLP) which allows for rapid communication of small delimited messages. The standard defines both the communications protocol and the message content format. No doubt about it, HL7 2.x is incredibly effective for transactional processing of data, but it has been limited in two key areas:

1. A pioneering developer of a successful HL7 interface engine once said: “Once you have developed one HL7 interface … you have developed one HL7 interface.” The standard exists, but there is nowhere near enough conformity to allow this to be plug-and-play. For example, a patient’s ethnicity is supposed to be in a specific location and there is a defined industry standard list of values (code set) to represent ethnicity. In reality, the ethnicity field is not always populated and if it is, it rarely follows the defined code set.
2. HL7 is an unsolicited push method, which means when a connection is made, messages simply flow from one system to another. If you are attempting to build a collection of cumulative data over time, this is a mostly sufficient method, but what you cannot do is ask a question and receive a response. Although some query/response methods have existed for years, their adoption has been very sparse in the industry.

2016: Year of the Healthcare API

If you are a physician with an electronic health record (EHR) system and you accept Medicare patients, you likely have gone through the process of becoming meaningful use (MU) certified, which means you have purchased an EHR software solution certified by the ONC. This EHR must follow guidelines of technical features, and physicians must ensure they utilize those features in some manner. In October 2015, the ONC released MU Stage 3 criteria (optional requirement in 2017, mandatory in 2018) which includes this game changer: A patient has a right to their electronic health information via an API.

Continue Reading