U.S. healthcare patients just dodged a bullet. In late May, misconceptions about APIs nearly led to the Joint Health IT Committee shooting down our best chance of universal electronic health records becoming a reality. The vote was 13-10; a close call — far too close.
The positive sign in that equation is that a majority of the task force members agreed that there were no “show-stopping” barriers that would prevent the deployment of APIs within the timelines that ONC has set for 2015 Meaningful Use Criteria.
However, let’s examine the reasons behind the naysayers.
The issue that almost blocked the API Task Force’s recommendation? API security.
Let’s get into the nuts and bolts of this argument. For those unacquainted with APIs, the security concept around APIs is pretty simple: At the most basic level, an API is a contract. Along with other attributes, this “contract” outlines the specific ways an API can be accessed and clearly defines the set of security credentials required for access.
This contract-driven interaction model makes it possible for organizations that provide APIs to add policies and security controls at every point of interaction. This means the owner of the API can fully regulate access to it, including the specific actions authorized users can take, and even when they can do it.
Rather than presenting a new security risk, APIs provide a secure and well-documented way for organizations to share access to data and services with third parties, while also maintaining strict security controls at every level. In fact, when compared to other ways of sharing data — such as via web site, file transfer, email or even printing press — a well-implemented API offers a far stronger set of configurable and granular security controls.
This is the crux of the issue. Despite the ubiquity of APIs today, there are still fundamental misconceptions about how they work, especially when it comes to security. For healthcare, in particular, there are two common objections, both of which lack substance: A) that APIs provide too much access, while at the same time B) failing to provide enough.
Despite the ubiquity of APIs today, there are still fundamental misconceptions about how they work.
Ask any developer and they’ll tell you both are fundamentally misguided and, importantly, fail to account for the reality of how health information is exchanged today.
Many of today’s healthcare institutions interact with their consumers and partners through portals — a system where data is served up via web pages located inside a password-protected section of the site. As is generally the case with website access and portals, once a bad actor is inside the firewall, it’s a free-for-all. Any data that is viewable can also be scrapped. What’s worse — following this approach, there is no mechanism by which a site admin can determine who is viewing what data and for what reason. Concepts like rate limiting are virtually non-existent in such a scenario.
By contrast, with managed APIs, every individual and app with access to the API must first register for a security key, then present that key with every data request sent via the API. Keys can only be distributed by the authorized API owners, and every action performed on the API is monitored and recorded. Any attempted deviations from the rules outlined in the API contract are flagged.
As to the claim that APIs do not provide enough granularity for securely transferring data, the fear is the APIs will not be able to discern between an ER doctor requiring diagnostic data about a patient from a bot trying to access patient data for fraudulent means. Once again, unfounded.
This is probably one of the most complex problems to solve in healthcare, and APIs do it quite well.
API advocates across the country have a responsibility to consumers to educate and evolve the conversation about APIs.
When it comes to traditional data exchange mechanisms, healthcare doesn’t have to resort to technical mediocrity by creating one-offs, point to point solutions to sharing data. With many web portals, so-called “malicious access morphing” is as difficult to detect as screen-scraping. Again, there is little visibility into what happens once a firewall is breached. APIs leverage mature protocols (SSL, OAuth, TLS) that provide a level of granularity that makes it easy to prevent morphing in nearly every instance — and to expose it quickly and clearly if it should. And again, because APIs are well-defined contracts, it is easy to maintain tight controls around access to begin with.
In the end, it’s clear there are challenges that all healthcare API programs must grapple with before launch — chief among them is education. Acknowledging the fact that the majority of the task force were favorable toward the API, let’s get the rest of the industry on the same sheet of music through education, open dialog and proven proofs of concepts.
If you ask me, API advocates across the country have a responsibility to consumers to educate and evolve the conversation about APIs, and especially API security. It’s time we put these uninformed biases to rest. A healthier world depends on it.