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 Apiary.io, 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.
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.