The Googlification of Radiology

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.

While a REST API could return anything (a video, a DICOM file, a Word document), usually when a query seeking structured information is made, it is delivered in a format called Extensible Markup Language (XML) or JavaScript Object Notation (JSON), which are web-renderable, easily parsed and commonly used in a lot of open web API found on the internet. “These things have a lot of very good attributes, which is why they are extremely popular in Web development,” Dennison said. “All of these things are going to be included in the standards that healthcare now has for both imaging and clinical data.”

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 Reporting Templates, Mobile Access to Health Documents, Mobile Access to Health Documents for Imaging, Unified Procedure Step.

“Long story short, a lot of the things that we have done, like DICOM Modality Worklist and other DICOM and HL-7 protocols, are being redone using the same web patterns that Facebook, Google and everybody else is using,” Dennison reported. “We now have the capability to intersect different types of web innovation.”

Developers now have the ability to compose applications that sit on top of systems that hold composite structured clinical data and binary imaging data—including EMRs, HIEs, PHRs, RIS, PACS and VNAs—either as part of those systems or as a middleware in between. “We now have the capability to compose applications and access clinical data over plain HTTPS, secure, encrypted HTTPS, without having to have a land connection or VPN,” he said.

Such APIs could reach beyond hospital walls to collect data from wearable sensors, mobile devices, patient-managed health records and health information databases that use the same data protocols and formats, pull it all together and present it in one view. Dennison pointed to Google maps, a compilation of geographic information systems, satellite imagery, directories for restaurants, traffic data and weather data. “We are on the verge of some very large innovation,” he concluded.

New web tools

Brad Genereaux. co-chair of DICOM Working Group 27, the group responsible for web technologies, shared some details on the new tools referred to as DICOMweb. To introduce the topic, he referred to Facebook as the world’s largest PACS archive, with 250 billion photos stored and 1.15 billion users.

While the Internet infrastructure required to run Facebook is massive, its hierarchy is simple to understand, enabling its users to retrieve, upload and query for images, precisely what is necessary to facilitate a medical imaging archive. Flashing an inscrutable page of DICOM code he said: “I look at DICOM, and it burns.”

“In today’s world, the world of yesteryear, we take all of these images, and we pile them into big silos, so information is locked away that really only specialist applications can get access to,” Genereaux said. “The question now becomes how do we react with our images in the same scale, the same functionality as Facebook? This is where DICOMweb comes in.”

DICOMweb plugs into the existing DICOM infrastructure, enabling web developers using web commands to query and build a list of studies using QIDO-RS, download (or retrieve) an image using WADO-RS and upload (or store) an image back to the infrastructure using STOW-RS.¹ Other services are coming soon, Generaux said.

When a clinician using a REST API goes into an archive to query (for studies, series, instances), a URL would be produced and the information would be provided inside the URL. Metadata also can be retrieved using XML and JSON.

“It shields what I call ‘necessary’ complication,” Generaux said. “Everything that is complicated—like querying for information, using C-FINDS, getting JPEGs out, authenticating, auditing—DICOMweb shields from our developers. They are necessary, critical, to the way DICOM works today, but for the hackers, the developers who are not familiar with the DICOM world, they can just jump right in and start to interact and build out fantastic applications.”

DICOMweb acts as a bridge between the DICOM and web worlds. “With DICOMweb and the use of a proxy, we are able to plug in DICOMweb directly so that the modality can still make its regular DICOM calls, and that can be proxied (by DICOMweb) into Internet archive storage,” Genereaux explained. “For our developers, they can interact in a natural way with the medical imaging world. We are able to take the image metadata now— who, what, when, where, why, how—and start to interact with that on a much easier scale.”

At the moment, DICOMweb does have its limitations: It doesn’t tell you how to render the images appropriately for the task, so DICOM knowledge is necessary for functions like window/level and markup. (You can grab images and do workflow exclusively with DICOMweb.) There are no DICOMweb modalities, but Genereaux expects that to change over time.

Also, the infrastructure is assumed, but the work involved is not trivial, he added: “It sits on the web, so all of the infrastructure that you need for that to happen—server, web servers, authentication, authorization—are still required, but they are not available out of the box for DICOMweb.”

In summary, Genereaux said the goal is to bring the 5-5-5 rule to medical imaging: five seconds to find documentation (DICOMweb.org), five minutes to building your first hello-world application (grab an image and put in on the screen) and five hours for a working prototype integration.

“This is the goal of any successful API, and this is what we are trying to achieve with DICOMweb: easy and simple tools to drive explosive innovation,” he said. “I really think we are on the cusp of a medical imaging revolution.”

Editor’s Note: For a description of FHIR, the HL-7 equivalent of DICOMweb, look for the 2015 February/March issue of Radiology Business Journal.

Reference

1. DICOMweb™. www.dicomweb.org. Accessed November 8, 2014.