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