If you’ve ever booked a trip online using a site such as Kayak or Expedia, you’ve seen something of the future of healthcare computing. Further, had you been able to look under the proverbial hood for a glance at how those sites use XML messaging to do what they do—access data from multiple airlines and hotel companies, then deliver it all to you in one easy interface—you would have seen the type of programming that healthcare providers’ IT teams must begin to adopt.

Those who fail to do so will risk being left out of a “web-services revolution” that will soon reshape healthcare computing at its very heart.  

That was the crux of an April 21 SIIM webinar presented by radiologist Marc Kohli, MD, director of clinical informatics, department of radiology, UCSF Medical Center. The talk was timed to prime the audience for participation in the 2016 SIIM Hackathon, which will be part of the organization’s annual meeting in Portland, Ore., the last week of June.

Like the webinar, the hackathon will be open not only to informaticists and software developers but also to non-technical healthcare professionals wishing to share their ideas on solving problems in healthcare.

Kohli began by reviewing the concept of application programming interfaces (APIs) and explaining why the concept continues to matter. Noting that an API is simply a mechanism by which two different applications or pieces of software communicate, he stressed that a web service—any software component that makes itself available over the Internet using standardized extensible markup language (XML) messaging—is simply a specific type of API that runs over Hypertext Transfer Protocol (HTTP), the language of the Internet.

What the travel websites are doing with web services “is in sharp contrast to where we are in healthcare,” Kohli said, “where we typically have all these different silos” in which data, including imaging, is out of reach to many who might draw from it to improve care quality.

“These new technologies for the web,” he said, “are going to help revolutionize healthcare.”

RESTful framework on FHIR

With that as overview and backdrop, Kohli drilled down into how-to’s that are applicable primarily to those who write code, or want to. However, he also laid out several principles accessible to a broader healthcare IT-savvy audience.

One of the latter topics revolved around the web-services framework called REST, for Representational State Transfer. REST “turns out to be a lot more simple than the other frameworks,” he said, adding that almost all of the APIs relevant to the use of web services in healthcare are both REST-friendly—or RESTful—and readily available over the Internet.

“One of the important concepts of REST is that each object has a unique ID,” he said. “If I’m using the Flickr API to access some of the photos in my Flickr stream, each one of those photos is going to have its own unique ID that can be used to get access to that same object every single time. That’s one of the ground rules of REST.”

Many RESTful web services allow the linking together of different objects, although some key ones don’t—yet.

“I would say that this is something that isn’t quite there with FHIR (Fast Healthcare Interoperability Resources, pronounced fire) and it isn’t really there with the DICOM web services,” Kohli said. “Their implementations are close to REST but not completely RESTful. But, if you were designing a fully RESTful API, you can imagine that, if you have a link to a unique customer, and if there was another resource type called ‘Orders,’ I could essentially send a request that would send me all of the orders for [that customer] just by adding the resource type on the end of that specific customer’s URL.”

Reviewing FHIR in greater detail, Kohli pointed out that it’s generally seen as the next generation of HL7, the standard for the exchange of electronic health data.

“One of the things that has been a big problem with HL7 in the past is that there was really no way to ask your EMR for a specific set of information—you basically had to be there to listen for an order or be there to listen for a report. If you weren’t there to listen for that event, you never really got that information,” Kohli said. “One of the really cool things about FHIR is that it’s going to give us the ability to ask a FHIR-enabled RIS or a FHIR-enabled EMR to give us a specific set of information about a patient.”

The RadLex road to data flexibility 

Turning to radiology-specific uses of web services, Kohli discussed an API unique to RSNA’s RadLex playbook developed at the last SIIM hackathon. The playbook supplies a standard system for naming radiology procedures based on terminology in RadLex, RSNA’s radiology language. The API, in turn, can allow users to quickly get playbook terms straight from the playbook’s webpage.

“You could imagine that someone could look through existing diagnostic report FHIR objects and create a small piece of software that would look up the RadLex playbook ID or playbook code that matched that particular diagnostic report,” Kohli said before explaining that a developer could use this to update a diagnostic report object and then send it back into the FHIR server to be improved.

“That’s one of the ways this data is going to become, I think, less static and more flexible over time,” he said.

“I’m really excited about this, because not only was this a fun thing that they did [at the last hackathon], but they actually took that fun thing and published it so that it is available throughout the scientific community,” he said, adding that the upcoming hackathon will further help “expand people’s understanding of these new tools.”

Wrapping up his session, Kohli reiterated his belief that web services “are going to be critical to the future of healthcare. REST is simple and powerful and pretty easy to get into from a web-services standpoint. And this is really part of the core mission of SIIM—to foster innovation and to support a vibrant developer community, both with our vendors and with other innovators who are part of our society.”

What does this geek speak mean to me?    

During the Q&A period, an attendee asked Kohli what are the practical implications of the “API/web-services revolution” to the clinical workflow or business process of, for example, a busy, multidisciplinary practice.

“That’s a million dollar question right now,” Kohli responded. “Much as it would be very difficult for us to have predicted the value of Google or Facebook, and how they would change the interactions that we have, I think we are still just at the very beginning of the API revolution in healthcare.”

He urged attendees to take steps to avoid getting caught off-guard.

“The one thing you want to make sure of is, when you are thinking about purchasing new systems, you don’t want to be left out of this revolution. Here at the University of California, we just went through a big RFP, and we specified that we were not going to buy anything that didn’t have these web services either baked into the product or coming out soon as part of a roadmap.”

“If you are not a developer,” he said, “the take-home message here is that you are going to be crippled in the future if you don’t have your silos FHIR-enabled and DICOM-web enabled.”

To learn more about the 2016 SIIM Hackathon, which will feature a participant challenge involving enterprise image capture and viewing, click here.