Get ready for a revolution in radiological communications was the message of a panel of presenters on “Web Technologies: The New Healthcare IT Standard,” on May 15 at the 2014 meeting of the Society of Imaging Informatics in Medicine in Long Beach, Calif. The revolt will be accomplished with technologies, architectures and concepts from web computing, and it is already under way.
“Today, when we talk about the Internet and the web, there are a number of technologies that we are familiar with and use on a daily basis,” consultant and SIIM board member Don Dennison said during introductory remarks. Web technologies are good at defining data, communications and presentation and there is temendous innovation in web communications, but much of it has not been incorporated in the systems used in radiology on a daily basis—HL-7 messages and DICOM associations, objects and communications. “That is about to change,” he said.
Take, for instance, application provider interfaces (APIs), essentially an interface in a piece of software that allows it to communicate, connect and exchange data, commands and messages with another piece of software. “A lot of times, you don’t actually use the application itself, so it’s usually computer to computer,” he said.
Add to that representational state transfer, better known as REST, another common web concept that has not yet made its way into healthcare. “It is not a technology particularly, but more of design pattern, an architectural style—basically a very simple model where things are defined as resources.” If you use Facebook, Twitter, Google and many other popular Internet sites, you likely are using a REST-based API.
“These sites make their API documentation public, thereby exposing capabilities in such a way that anyone could write a piece of software that utilizes those application platforms without having to actually launch their user interfaces,” Dennison noted. “This explains why you can add things to Facebook without actually using their user interface (using instead, for instance, Hootsuite).
A fundamental concept within REST is resources, so within an API that is REST-based, there is an explicit act of defining what are those resources, he explained. He provided the following, simple example: The URL server.com/patients would give an immediate sense of what would be found: a list of all patients. If another resource is added, such as an MRN number, the assumption would be that information on a specific patient would be found. Add yet a third resource, the word studies, and one would expect to find a list of that patient’s studies.
“For the lay person, it is very easy to understand REST, which is why the development community loved it,” Dennison said. “It is essentially very easy for them in plain language to publish these APIs as contracts and allow people to do all kinds of innovative things, and they just provide capabilities or data access behind those APIs.”
More web concepts
When web resources are paired with web commands (QIDO, WADO, STOW), it is possible to list, create, replace, and delete reports, for instance. “With a combination of these basic verbs and resources, you can pretty much do anything in an API,” Dennison said.
The ability to simplify communications with DICOMweb and its HL-7 counterpart FHIR, for Fast Healthcare Interoperability Resoruces, could have profound implications for development time. “The new standards provide the ability to get patient-level information—study, series, object—in terms of hierarchical and metadata information,” Dennison said. “Without having to push HL-7 everywhere and without having to go and parse a bunch of DICOM headers, we can just ask basic URLs and get stuff back.”
Integrating the Healthcare Enterprise has begun to develop integration profiles and actors that lay on top of the new standards, including IHE Management of Radiology