When It Is Not a Good Time for APIs: Voices Against Mandatory APIs in Healthcare

Electronic health records management policies in the United States are keen to set up APIs as a mandatory industry standard for interoperability. But several leadership voices say it is too early for APIs to take a central role.

Healthcare is an inherently complex data management field. Personal healthcare records - often starting from written notes in a doctor’s office or on an ambulance form — need to be passed to diagnostic testing, back to primary care physicians, to insurance agencies, to specialists, then to allied healthcare. These records are then integrated with data from medical and fitness devices, used in hospital discharge, used to fill prescriptions, sent back to a primary care physician, and possibly on to allied healthcare services.

With health and medical records becoming digitized alongside the proliferation of healthcare medical devices and personal fitness tracking equipment, the creation of health records data is exploding. In this new data driven healthcare context, healthcare policy decision-makers are looking to the potential of APIs to facilitate transferability of data and to ease complexity burden.

Healthcare Interoperability Standards

But after several waves of reform in electronic healthcare records management across the United States, some leaders — including those in the API space — are cautioning for a more tempered road ahead. The idea is to allow the healthcare industry to catch up and create an application ecosystem that can make use of shared patient health data before APIs become an industry standard in how that data is moved around.

Health records interoperability has made major strides in the United States and around the world in the past ten to twenty years. The introduction of HL7 — an international health records interoperability standard — paved the way towards standard schemas so that data regarding diagnostics, lab tests, prescriptions, and hospital discharge summaries could more easily flow between electronic health record (EHR) systems. More recently HL7 has been at the base of the Fast Healthcare Interoperability Resources (FHIR), which include support for a RESTful architecture and encourage the use of JSON and other web standards.


Alongside HL7 and FIHR, the US Center for Medicare and Medicaid Services (CMS) introduced the Meaningful Use policy. In Stage One of Meaingful Use, hospitals and healthcare providers needed to conform to 20 EHR standards (made up of 15 mandatory electronic health reporting standards and five that could be chosen from another list of 10 possible requirements). Now the Meaningful Use policy is in Stage Two and uses an incentive program to encourage healthcare providers (healthcare professionals and hospitals) to adopt FIHR and HL7 standards and meet goals around enabling patients to download data, digitize physician lab requests, provide electronic care summaries, protect health information digitally, secure electronic messaging systems, and maintain a digital register of immunizations, amongst other goals.

Already, an encouraging Platform-based ecosystem is emerging with players like Epic, athenaHealth, Redox and HumanAPI using APIs to move data between various service components and enabling patients to access healthcare records or Feed in their own data sources, from things like fitness devices.

Introducing Meaningful Use Stage Three

Now, the CMS is introducing Stage Three Meaningful Use policies. The new policy seeks to replace incentives for uptake of interoperability standards with penalties for non-compliance. Stage 3 Meaningful Use also requires healthcare providers and professionals to open up APIs as a way to facilitate the movement of patient data.

But several of the leaders in health records management are now voicing their objections, saying it is too early for APIs to play such a central role in electronic healthcare records management.

Three Voices Against Regulatory APIs

John Halamka, CIO for Beth Israel Deaconess Medical Center, writes in his blog GeekDoctor:

It requires patient accessible Application Programming Interfaces (APIs) without specifying any standards. It requires sending discharge e-prescriptions although pharmacies cannot widely support the cancel transaction that is essential to discharge medication management workflow.   It requires public health transactions but CMS has no authority to require public health authorities to standardize the way they receive data.

Halamka points out there is no way for a physician (in a standard twelve-minute consultation) to enter all the data required by Meaningful Use, diagnose a patient, check for any contraindications in planned treatment for allergies or existing medical conditions, make eye contact and establish rapport and ensure high quality healthcare.

He believes there is already strong support amongst the health IT industry for uptake of APIs, but that this should find its own way rather than be regulated so early in the market life:

Creating regulation before there is any industry experience as to what works makes little sense.   Government can help with issues such as data governance principles, rationalizing privacy policy,  and coordinating federal agencies but should not specify workflow or business process.

In an interview with Leonard Kish in The HealthCare Blog, Ed Park, COO of athenaHealth, believes APIs are an important part of the solution for interoperability of healthcare, comparing the potential to how ATMs can be utilized by anyone with any account card and will be able to access financial data and allow withdraws even from other banks. But he cautions against regulating APIs too strictly this early in the industry lifecycle:

…If you look at the history of Silicon Valley over the last ten years, at the Netflix API, the Google API, the Amazon API, the Apple API are unrecognizable from where they started.  And those API’s were not legislated, they were in fact built to appeal to a mass market of developers.

So whoever actually built the best API ended up attracting most developers and ended up building more value onto their platform. Insofar as their business depended on the success of their platform, they ended up spending a lot of time trying to evolve their API in a market-oriented fashion to ensure that developers would keep developing on them.

I think that is, in fact, what is happening in healthcare today. So the legislation and the standards were a good first cut at poking a hole in the dyke, but in order for the waters to rush through from my own personal perspective is that we’re going to have to encourage market forces to take their course in building truly usable API’s that allow for truly plug-and-play interoperability.

Those two pillars are the way that I see interoperability moving forward.

Building on this idea of encouraging the health industry to start evolving APIs, Halamka maps a more streamlined way forward in his blog.

He suggests a “laser-like focus on interoperability” with three clear goals:

  • To be able to use FIHR standards to search a provider directory and send a direct message to that provider
  • To use a FIHR API (with OAuth) to perform a query that checks for a particular relationship locator service and to return a response from the current Meaningful Use Common Data Set
  • For patients to be able to download their data sets using an app (which in turn would be accessing the information from a healthcare provider via API).

Halamka argues that providing data to a healthcare patient should be at the center of these interoperability goals. He believes that healthcare providers and health IT developers should be encouraged to develop such APIs through merit-based incentives rather than through current plans in Stage Three Meaningful Use of penalty-based policy directives.

Andrei Pop, Founder and CEO of Human API — who has previously talked about how the time is right for businesses and developers to create more health applications — also thinks that any move to regulating APIs is too premature. He told ProgrammableWeb:

I think John is spot on with many of his insights. I'd like to underline his point about providing data to the patient as a key to interoperability. Allowing patients to control the flow of their health data gives them the market power to dictate the applications and infrastructure being built on top of the data.

I'm more bullish than John about what already exists here today -- I've talked to countless developers building the next generation of health experiences who simply need a secure, cost-effective way to obtain the data. I think the APIs and standards emerging bottom-up in the industry today, will fuel this.

A Chance To Comment

For API providers, developers and IT departments in healthcare agencies and startups looking to enter the healthcare space, there is still time to comment on the proposed Meaningful Use Stage Three requirements. The Center for Medicare and Medicaid Services is inviting feedback on the new regulations by 15 December.

Meaningful use comments so fare

Already 338 comments have been received, with all three of the most recent arguing against implementation.

Be sure to read the next Healthcare article: MuleSoft Launches API Templates to Speed Up Innovation in Healthcare