healthcare API, REST

#DICOMweb cheatsheet 

We just wrapped up a very successful, inspiring and fantastic #DICOMweb conference and hands-on workshop. One of the things I put together (with the help of a few others) is a cheatsheet to provide a quick reference help to the medical imaging RESTful objects that #DICOMweb provides. The link to access this cheatsheet can be found here:

http://dicomweb.org/DICOMweb-Cheatsheet.pdf

If you have any feedback on how this one-pager can be improved, please let me know. Happy RESTing!

dicom, healthcare API, interoperability

DICOMweb QIDO-RS vs FHIR ImagingStudy

Over the last year or two, there has been fantastic synergy between the DICOM and HL7 working groups, to harmonize the RESTful services being developed out of both standards organizations. DICOM has the DICOMweb services (of WADO-RS, QIDO-RS, and STOW-RS), and HL7 has FHIR. They both have representations of the diagnostic imaging study. They have been harmonized – but remain un-unified and distinct. To some, this may seem like a peculiar concept – why not just have one standard that works for everybody? Why not develop one interface, one method, one response, one object type?

To me, this approach of objects in both standards – is logical and perfectly justifiable. My personal, perhaps biased take comes down to one main thing – target audience. Following are the two extremes.
For the Electronic Medical Record (EMR) system, their bread and butter interoperability method is HL7. They are interested in “events”, and “observations” – i.e., patient is admitted, or patient had a diagnostic test. They know about available lab work, and happily render that information (procedure + value + unit + abnormal flag). They know about and happily render reports (straight text). They know orders. But what they don’t do, is imaging. Peering into DICOM is an entirely different beast compared to other clinical data object types. Knowing how to hang images within a study is a science (and art) all its own. EMRs want to know what studies are available, and then they can have a dedicated buddy (an image display application, such as an enterprise viewer or PACS) to render for them. EMRs may want to show thumbnails, but that’s likely about as deep as they want to go. FHIR ImagingStudy is for them – they get a high level overview in a standard they know, and let someone else dig deeper if necessary.

For the PACS Radiology system, their bread and butter interoperability method is DICOM. They work at the instance level, and build up from there. They break apart and digest DICOM headers, and render complicated multi-frame instances with thousands of parts, without even breaking a sweat. They may have knowledge about orders, but that information is tertiary and linked, at best. They have massive repositories filled with DICOM, the standard that has worked for decades. Knowing the basic metadata about the instances is simply not enough for all of the use cases – depending on the modality, the specialty, the vendor, the task – the full header information and the complete instances are needed. DICOMweb is for them – querying headers of choice via QIDO-RS and retrieving via WADO-RS – they get in-depth detail in a standard they already speak. Modalities, who typically only deal with classic DICOM, can even leverage DICOMweb with the benefit of a helping go-between service that can map their classic queries onto DICOMweb ones (i.e., via a proxy).

So those are the black and white cases. There’s a vast middle-ground, where either standard (or both) is entirely appropriate. It depends a lot on their “imaging use maturity”; software that already has an established imaging connection might choose to stick to DICOM and augment themselves with DICOMweb services. Software that is ready to be image-enabled (nurse call, patient portals, rounds) might choose FHIR. To a large extent, this is an undecided, under-discussion, case-by-case type of thing.

It is important to keep in mind – both QIDO-RS and FHIR’s ImagingStudy resource both point to WADO-RS (DICOMweb’s retrieval service) to retrieve the images or a specific rendering of them. So, for the “provider”, they will either need to implement the necessary DICOMweb services anyway, or have a buddy that already has this available to talk to. It is also important that, since both standards are built on top of technologies such as JSON and XML, can gracefully be augmented with additional data outside the standards (just add new tags; existing systems will gracefully ignore them).

Whether it is top-to-bottom or bottom-to-top, there’s value having both available for the necessary constituents. Making a PACS or VNA implement the breadth and depth of FHIR is quite heavy-handed and provides little benefit in the near future; for example, the FHIR Patient sub-resource requires information that is not available in DICOM headers and so makes it more complicated to obtain. If the information is truly needed, systems can ask the appropriate source of truth for this. Similarly, finding EMR systems that speak DICOM has historically been quite challenging and other solutions to this problem (i.e., having a image viewing application buddy) have already taken hold.

It is hard for me to say what the future will hold – I’d check out Don Dennison’s article, entitled PACS 2018: An Autopsy, as a start. If one will eventually “win”, it surely won’t happen anytime soon. What I can say, though – the very fact that we can have these conversations – it truly is an exciting time for the integrator, and a transformative one for healthcare.

healthcare API, REST

I need a REST interface

I was thinking the other day – after going through the mail and other daily meanderings, how awesome it would be if I were to have a REST interface. It would work like this: if I became a resource (for example, http://rest.me/integratorbrad), then I could receive all sorts of communications in a fashion that would be extremely streamlined. If someone wanted to send a bill to me, just POST it to http://rest.me/integratorbrad/bills/cable. If someone wanted to check the status of my calendar, simply query http://rest.me/integratorbrad/calendar/20140118 for my busy/free times. Of course, it would be secured with OAuth tokens, so I can grant elevated rights where necessary (I wouldn’t want a buddy posting cable bills to me, or telemarketers scheduling annoying calls into my calendar).

This got me thinking, though, on another problem I think about – healthcare and patient empowerment. There is a lot of talk about the pros and the cons of patient data sharing, but I think, in general, it is a good thing. Personally, I am a strong advocate of the Quantified Self movement, and subscribe to self-measuring whenever I can, and fill up spreadsheets, and graph, and nerd out. I understand the limits and challenges, though (i.e., if I were able to notice I am low on iron, I know enough to talk it over with my healthcare provider, before self-medicating and ODing on iron supplements). But, as I collect this information on myself, it empowers me as I move through the healthcare system; it guarantees that each provider is as knowledgable as the last. I am in control of my health, as best as I possibly can.

However, it would be a humongous job for every health care provider and those associated to healthcare to provide me the information they collect on me. Getting paper copies without some sort of incredible OCR system means a lot of unnecessary work. I can’t imagine having a username and password in every hospital for me to access this information. I don’t think OpenID is a decent enough solution (the permanency of accounts concerns me), and OAuth won’t really be viable either (in a distributed repository sense – who would hold all of my tokens?). I think something like Google Health was a good start, but I think, thinking bigger, a solution is possible.

So – back to my opening question – what if I had a RESTful endpoint? Everyone could post relevant healthcare content to me. POSTing to http://rest.me/integratorbrad/healthcare/labs would be an excellent way to deliver content to me personally. How I manage this mailbox of stuff, is really up to whatever application provider I use. If I wanted to parse the raw data and make all kinds of cool graphs (Brad’s Totally Awesome Hematocrit Counts), so be it. And if I wanted to, in turn, share this lab report with another healthcare provider, I could simply share the REST link for a GET, as long as we have an OAuth handshake in advance. I would be my own advocate in the healthcare system. There are tons of uses for this – POSTing prescriptions, medication information sheets, dietary guidelines, scheduling follow-up tests – an integrated system instead of a disparate one.

This wouldn’t be without problems, of course. Handling spam would be paramount, lest I have a lot of garbage to manage. Managing access would have to be incredibly streamlined (maybe this could work in conjunction with the Big Blue Button initiative). Educating the masses to such a system may very well be the biggest challenge. But, there are so many interesting uses of this data – population health, widespread research – that, with the proper controls in place, could change the way we look at health from a national perspective. With great knowledge, comes great responsibility, for sure.

This is a pipe dream, for sure. Especially for a statistic junkie like me. But boy, it sure would be powerful.

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 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.

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.

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.