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.

Think about this: If you are a physician and a patient has an app on their smartphone, you must have an API published that the app can utilize to obtain data. EHR vendors are scrambling to ensure they can meet this requirement. There are a myriad of hurdles to overcome with these two being at the top of everyone’s list:

1. How will you ensure your system has the capacity to connect to hundreds of patient apps when your previous connectivity was limited to well-known and defined HL7 2.x connections?
2. How do you validate apps? Anytime a door to valuable information is opened, there will be those who seek to steal and profit from this information. This will be no different with healthcare API’s so defining the validation process of an app will be critical.

Healthcare API: FHIR

There is an emerging standard under the governance of HL7 called Fast Healthcare Interoperability Resource (FHIR), which is gaining significant momentum to become the de facto API for healthcare. It is likely the ONC did not declare FHIR as a requirement because the standard was in draft form at the time the rule was passed. While an EHR vendor can create their own custom API if they choose, it is highly likely that nearly all vendors will take advantage of the FHIR standard.

2016: Year of the Patient Consumer

The healthcare industry operates unlike most other industries in that its primary focus of revenue is not the consumer of services.  Patients consume the services, while health insurance companies pay the bulk of the revenue.  Hospitals make money via price negotiations with health insurance companies.  Patients are marketed to, but significantly less so than other industries.  However, I believe there are two critical trends in 2016 that will require hospitals and physicians to look at the patient as a consumer:

1. API — It is estimated that 646 million Internet of Things (IoT) devices will be used for healthcare by 2020. Connected healthcare devices can collect and analyze data, automate processes, and more. As IoT and mobile technology continue to explode in 2016, patients will finally be able to obtain their healthcare data using an app of their choosing.
2. Retail Care — The retail industry saw the healthcare industry from the consumer perspective and realized there was an opportunity, thus retail care was born. Retail care includes walk-in clinics that traditionally accept cash only and offer limited services. CVS Minute Clinic, The Little Clinic, and Walgreens Healthcare Clinic are some of the leaders in this space. There are more than 2,000 of these clinics in 41 states and they have covered 35 million patient visits. This trend of providing services that patients pay for at a much lower cost transforms patients into consumers.

Summary

This year, 2016, looks to be the year of the consumer: patients will research, select and pay for their healthcare – while receiving their personal health data on-demand – via an API. Patients will become empowered to choose where they consume their healthcare based upon convenience, price, and access to data. This consumer-focused trend will shift the traditionally slow moving large health systems to become more agile and focused on the patient as a customer and consumer of healthcare.