developers, healthcare API

Driving Developer Adoption

As baby boomers age and the world becomes more technologically advanced, it will become ever more critical that the healthcare industry entices more developers into its ranks. I admit, making apps for healthcare isn’t nearly as sexy or killer as, say, a flatulence sound app, but one must wonder – what is behind the mass of developers developing for other verticals besides healthcare? There are a few key things that will help bring about critical mass healthcare must adopt.

1. Standardized APIs

I talked in a previous post about how, in healthcare, that there are so many vendors in the same environment. Different products in different hospitals accomplish similar functions using completely proprietary methods. The healthcare standards, prior to 2013, were not API-driven – meaning, they were on their own “non-industry-standard” protocols (I say this meaning not HTTP traffic) using “non-standard” formats (HL7 pipes and hats, DICOM binary, rather than XML and JSON). In 2013, we have started to see a movement solidify towards the API, with FHIR and DICOMweb. By using standard methods, developers will only have to learn the methods once, and can apply their queries and updates universally*.
(* it would be a dream if this were true, but individual products will come up with proprietary extensions – which is OK, so long as they are intuitive and documented)

2. Intuitive design and easy to use documentation

APIs these days have a certain look and feel, such that developers need only to have a basic understanding of the offering and a starting point, and without documentation, be able to feel out how it works with ease. For example, if I want to query pictures on Facebook, there should be an API call with the path /pictures. If I want to query the timeline, it should be /timeline. APIs should be rewarding, and there should be a quick turnaround. John Musser, a brilliant thought leader in this arena, referenced in a presentation an interesting acronym – “TTFHW”, or, “Time to First Hello World”. Minimizing this value is important.

Intuitive design aside, the API should have easy to navigate documentation. I often equate this to a quote from Homer Simpson, acting as town crier, in which he has two questions regarding the whereabouts of a historical artifact. “I’ve got two questions. One: Where’s the fife? Two: Give me the fife.”. When doing integrations, these are the very same questions I ask. Documentation should be concise. The most fantastic documentation includes interaction, where I can try out calls on the web site.

I have seen some fantastic documentation in the REST arena – both in actual implementations (such as Twilio, Facebook and Twitter APIs) and with documentation “platforms” (such as, and Swagger). By making it easy to discover and use these APIs, we enable developers to connect together applications and data without hardly any effort – allowing them to spend their effort on creativity and innovation.

This sort of documentation is harder to find in healthcare. FHIR has done a noble effort in documenting their API designs. IHE has just revised their web format, which looks great. And, I’ve been working on my own DICOMweb representation.

3. Ready to use implementation

There are some API providers that have taken their offering even further – by offering native libraries that make integrations easy. They do this by creating, in many different languages (such as Java, .Net, PHP, etc), libraries that do these calls. This is also an effective way to provide access to legacy APIs that are SOAP enabled. A great example of a library-enabled API is Twilio – you can drop one of their libraries into your code, connect your tokens, and immediately start sending out text messages using their API and example. It is extremely powerful. If you have an inspired community, you’ll even find that they will even create and share their own libraries – Oauth is an example of this. So, by providing libraries, the TTFHW is reduced further.

In some ways, the legacy healthcare platform has already done this. For example, check out Mirth for HL7. Unfortunately, these packages are too generic to function like what we would expect of the modern API (it is akin to the operating system level, as opposed to the application level). As healthcare becomes enabled by the API, it will evolve.

Parting thoughts

Healthcare is building the APIs. We need the developers to come to them. Driving developer adoption – harnessing their tinkering, their innovation, their transformative power – will advance healthcare. Better care at lower costs is what we need now and into the future.


What Drives Me

I spent the last couple of days at the I Love APIs 2013 conference. There were fantastic presentations, great and insightful conversations, and hacker-esque food (although no fried chicken and waffles). Listening to and being among those that are as passionate about APIs as me, is very inspirational – and it gave me pause to consider what drives me to do what I love to do.

My passion really compromises of two halves. First of all, after spending a decade cutting my teeth on healthcare information technology has really changed and shaped my perspective. Knowing the state of healthcare – how it is now, and where is it going – is really quite fascinating. For a vertical that truly means the difference between life or death, it boggles my mind that it has been so far behind other industries. It reminds me of a Jerry Seinfeld parable, where he talks about science and seedless watermelons. We have so many different areas that need attention – AIDS, cancer, heart disease, and we have scientists using their time developing a better seedless watermelon. It is staggering. Technologically speaking, while I imagine that there is a time and place for flatulence sound applications, there shouldn’t be much more paramount than healthcare. Health will eventually fail for us all. Healthcare needs the attention, the brunt and the force, of the developer. And the best way to mobilize this force, is with the API.

The API (application programming interface), my other passion, changes and transforms everything it touches. In the last few years, APIs have become more and more intertwined in our daily lives – it has become ubiquitous, and don’t even know it is happening. APIs provide the gateway to information. It is amazing, for me, to watch the bits align, like stars, as information is unlocked to create knowledge. It truly is a beautiful thing. 

These two circles, healthcare IT and the API, where they intersect, is incredibly exciting. I think that we are on the cusp for things that have never been seen before. 

Bonus: If I were to equate my love with the API with another brief TV vignette, it would be an episode of episode of Futurama in which space pilots Fry and Leela attempt a rescue of their colleague Bender by disguising themselves as robots, only to be faced with robot guards meant to prevent humans from entering. To safeguard this, they had a skill testing question. “Which would you rather have – a) a puppy, b) a flower from your sweetie, or c) a large, properly formatted data file?”. Indeed, a large, properly formatted data file is something magical.

healthcare API

The Healthcare API: A Brief History

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.