The evolution of the healthcare API is a peculiar one. The healthcare API world was born in the 1990s, before many other API domains developed, and then followed quite a different evolutionary path than other verticals. Before the rise of the internet, other verticals developed closed software, adding any integration points that fit directly into their vision along the way. As the internet became common place, software became web-based and APIs took hold. It opened up new worlds. The trajectory and momentum started slowly, but with the advent of first SOAP, and then REST, and supporting technologies like OAuth, rose to a fevered pitch. APIs have taken off and transformed forever the ways we live and work. Mashing APIs into dashboards, portals, and ultimately, into apps, have become common place.
Healthcare is different. Before I explain why, there is something critical to understand about this vertical. I often equate it to this example: take any other vertical, like banking. When you look at the banking software stack in any company, it consists of single-sourced core software, and back office software (like HR, payroll, staff scheduling, e-mail, etc.). Restaurants – same thing – a core piece of software, and back-office. Airline industry – same thing. Healthcare, on the other hand, consists of many different functions – patient registration, laboratory systems, radiology scheduling systems, radiology imaging systems, modality software, operating room software, nurse call software, the list goes on and on and on – and these are all provided by individual best of breed vendors. And they all need to talk to each other – otherwise, dire consequences.
So, for this reason, healthcare realized early on that they had to build interoperability first. Vendors came together and agreed on standard ways to communicate between each other. Baked into its very DNA, healthcare standards have taken to heart the need to work in harmony. Two of the core healthcare standards – HL7 and DICOM – have focused on communication between systems – transferring data and triggering workflow between and amongst each provider of software. This level of cooperation is relatively rare. This divergence from the evolution of other APIs happened early on, and has become more pronounced in recent years.
While healthcare interoperability is clearly a strength, many people – physicians, nurses, patients, IT analysts, governments – all wondered – how is it that one can book a flight to anywhere in the world, share this information instantly to all their friends electronically, and explore the area they are traveling to by navigating virtual streets of continuous photos – and yet, schedule their CT examination on paper-based systems? The focus on interoperability as the common denominator has deprived the systems of what APIs make possible. Rapid growth by the armies of Red Bull guzzling developers have simply not been available. Forays into healthcare of those that built their business on the web API have failed in epic proportions. So – the question we needed to ask ourselves was, what can the healthcare industry learn? How can it benefit from these advancements? How can it transform itself like so many other industries have?
It is beginning to happen. We are seeing a renaissance in the healthcare API. Transformations are occurring – the advancements in API technology in other verticals is moving to this industry. It is happening fast, and it is happening furious. It is an exciting time to be a part of it.