Last updated: 1/31/18
The recent announcement by AthenaHealth that their APIs had been called one billion times serves as both a milestone for the use of APIs in healthcare and a reminder that API quality is as important as quantity. After all, McDonalds may have served billions of hamburgers, but no one is going to confuse them with a hand-fashioned burger with homemade condiments and the freshest fixings at a fancy restaurant!
Health IT (HIT) has been both late and slow in making the transition to this key technology that powers much of the rest of the digital economy, so it’s great news that the adoption and use of APIs is now on the rise. But, as more of HIT moves to leveraging APIs, there are key aspects of API quality that must be considered. This is especially true when using APIs for EMR integration.
At Sansoro Health, we believe great APIs should be robust, reliable, secure, agile and economical. These qualities animate our philosophy and are embedded in our products. As demonstrated in other industries, high quality APIs are rapidly and widely adopted leading to a rapid rise in API quantity. More importantly, they enable a more efficient approach to innovation.
APIs are robust
Great APIs are robust. They provide the data and functionality that HIT developers and end-users actually need to build better products and services. They are broad-based rather than narrowly tailored and provide lots of functionality. They support real-time, bi-directional (read and write) data exchange between applications.
In the case of APIs for EMR integration, they should be EMR-agnostic, meaning they work the same way regardless of the EMR involved. In contrast, EMR-specific APIs, whether they are vendor supplied or one of the many flavors of FHIR being deployed by those vendors, lead to a tower of babel of incompatible APIs and are highly inefficient.
Robust APIs are also easy to deploy and maintain. Installation packages should be automated as much as possible and developers should avoid dependencies that slow or complicate deployment. Robust APIs should not depend on legacy technologies like HL7 protocols as this will “drag forward” all the limitations and problems of these technologies. After all, one key reason HIT is moving towards APIs is the need to move away from these limited, outdated approaches. To do otherwise, is simply putting “lipstick on a pig.”
APIs are reliable.
Reliability of APIs reflects both the developer’s knowledge and the care with which they develop. The hallmarks of reliable APIs are that they are stable and have solid error-handling. We think of stability and error handling as going hand-in-hand. Well-designed APIs are highly stable. They. Just. Work. But, nothing is perfect so, great APIs (and great developers!) focus on error-handling, too. They know detecting errors and providing that information to consuming applications applies a ‘belt and suspenders’ approach to reliability. They address the paradox of designing them well in the first place while acknowledging that failure will still occur and should be handled gracefully.
APIs are secure.
Security has never been more important in HIT and APIs address key security concerns. A combination of application keys and user credentials can be used for identity management and verification in real-time for every API call. APIs must be stateless which allows for designs that do not retain copies of the sensitive data (like personal health information) that flow through them thus, eliminating tempting targets for hackers. APIs can leverage end-to-end encryption and other features of secure web services to further safeguard data.
APIs are agile.
A great potential advantage of APIs is that they are far easier to modify and extend than traditional methods of HIT data exchange. Too much of traditional healthcare development is still mired in the “waterfall” approach to development, which has been largely abandoned by IT developers in other industries. But simply moving to APIs will not necessarily create agility.
For example, consensus standards like FHIR can take years to deploy new capabilities or revise existing ones. While the dream of a single standard is enticing, the reality is that reaching consensus is time consuming and results in all kinds of compromises. By its very nature, this approach will never be agile. Likewise, vendor-specific APIs, like the ones offered by EMR vendors, are entirely dependent on the priorities of the vendor. Those priorities may or may not align with a specific customer’s needs. They almost certainly and very intentionally won’t align with the needs of potential competitors.
In contrast, commercial APIs developed and delivered by third-party developers like Sansoro Health are highly agile. They are far more market-driven and respond rapidly to new or changing requirements. Agility is built-in from the ground up starting with the choice of development platform, supported by robust design and agile development processes and driven forward by constant feedback from customers. They succeed by meeting customer demands and beating their competitors.
APIs are economical.
The greatest API in the world won’t change healthcare if it is not also economically sound. This applies to both the development and use of APIs. The ready availability of proven API development tools combined with agile development processes sets the stage for efficient and economical development and maintenance of APIs. To a large degree, this can be engineered into the API generation process.
Equally, if not more important, is the licensing model of the company that supplies the APIs. When selecting APIs, seek out vendors that understand their business model must be flexible and able to align with their customer’s needs. In many cases, an “all you can eat” approach is best as it encourages rapid adoption and wide use of the APIs. In other cases, a “per call” model may make more sense. In still others, some combination of the two is best. Regardless of the model, the cost should be predictable and sustainable over time. The key point here is that licensing should be flexible and negotiated as a win-win between the supplier and the customer. Vendors that insist on one model, especially those that require excessive “per call” fees should be avoided. As the former National Coordinator for Health IT, Dr. Farzad Mostashari, recently tweeted, “Is charging $5 per API call *really* an open API?”
API quality matters.
It is clear that when it comes to APIs, quality is exceedingly important. Quantity reflects and should be a by-product of quality. Seek out APIs that are robust, reliable, secure, agile, and economical and they will be readily adopted and widely used. That’s what we produce every day at Sansoro!
John is the Chief Technology Officer for Sansoro Health with decades of experience launching and growing healthcare organizations, focusing on healthcare software development and clinical integration initiatives. His deep knowledge of electronic health record systems and interoperability challenges were the foundation for Sansoro’s Emissary technology. He previously served on the Advisory Group for the Office of the National Coordinator (ONC) Functional Interoperability & Health Information Exchange. You can follow him @Oroscojc or email John.Orosco@SansoroHealth.com
Dave Levin, MD is the Chief Medical Officer for Sansoro Health where he focuses on bringing true interoperability to healthcare. Dave is a nationally recognized speaker, author and the former CMIO for the Cleveland Clinic. He has served in a variety of leadership and advisory roles for Health IT companies, health systems and investors. You can follow him @DaveLevinMD or email Dave.Levin@SansoroHealth.com