15 Nov DICOM – the Teleradiology ‘Un’-standard

What is DICOM?

DICOM (Digital Imaging and Communications in Medicine) is a standard for storing and transmitting medical images between medical computer, software, and imaging systems. It is a standard protocol that was developed by the National Electrical Manufacturers Association (NEMA) and has been revised several times.  The current standard is DICOM 3.1. The basic understanding of how DICOM Images are stored and managed by systems can be thought of in two components: 1) there is an image or group of images that are tied to a particular imaging study which are stored in a JPEG standard format (either with or without compression); and 2) there is a group of text fields known as DICOM headers which store identifying information about the image, patient, and study.

DICOM Transmission

When transmitted, DICOM devices communicate via a specialized DICOM communication protocol over standard TCP/IP using a sequence of handshaking mechanisms such that a so-called DICOM association can be established between two devices, and then the DICOM data is transmitted over the open association. Sounds simple, right? Well, as most of us in the medical imaging industry know, the word “standard” here is not to be understood literally, unfortunately. While the representative companies in NEMA who are responsible for the DICOM specification are medical imaging equipment vendors, for the most part, it seems that even the standard they agreed to is not adhered to completely. For example, some vendors choose to use non-standard “proprietary” fields to store vendor specific data. Others choose to compress images in slightly different ways, taking advantage of flexibility within the JPEG standards.  While still others choose to store color formats in different methods.

When DICOM was young, these unique interpretations of the standard were not problematic as most medical imaging shops were isolated. Within a hospital, for example, the main goal was to get the CT, the MRI, and a few CR devices to communicate with the PACS.  In many of those situations, the facility might be a single-vendor shop which made this exercise even less challenging.  However, as the medical imaging industry has evolved over the years in much the same way as the rest of the world has, individual islands of technology have grown and connected to each other across vast networks.  Today, many hospitals are interconnected within large hospital networks which may or may not be homogeneous in the technology purchasing decisions.  Furthermore, teleradiology service providers now are not tied to the hospital systems; many of these groups themselves may cover large numbers of hospitals, in the hundreds, or even thousands in some cases, and thus, the radiology company must deploy medical imaging technology that can communicate with a wide array of diverse medical imaging systems.

The Un-Standard

You may be asking yourself here, “well, isn’t that an easy task given the DICOM standard?” The answer is, of course, that it would be if the DICOM standard were really a standard.  Of course, the original intent was to make these large, heterogeneous medical imaging communications networks possible, but the reality, even today at version 3.1 of the DICOM standard, is that it is just not that simple.

So, the question for companies that are trying to integrate diverse medical imaging equipment onto a single platform is how to deal with different vendors’ flavors of DICOM. For example, at ONRAD, we pull in medical images from over 200 facilities, which equates to over 1000 modalities and/or other PACS systems. The general rule seems to be better than the 80/20 rule.  Approximately 90% of all the equipment that we see out in the medical imaging world seems to communicate with our systems with no issue.  However, we spend 90% of our integration time on that remaining 10%, and not finding a way to integrate to a facility is not an option for us.

ONRAD’s Teleradiology Technology

ONRAD uses a GE Centricity PACS-IW PACS system to visualize our customer’s images for our radiologists. We have found that there are other PACS systems and several modalities that will create DICOM in flavors that the GE Centricity PACS-IW system does not deal with well. Our solution has always been to create a buffer layer. We use DICOM routers from DICOM Systems to help transform and manipulate DICOM feeds that have “quirks”.  We can run these transformations on the fly, or set permanent rules if we know, for example, that a CT from some facility with a specific IP address always sends studies with a strange compression or vendor-specific DICOM field. By sending all our customer’s images through these DICOM routers as a buffer before they reach our PACS, we have a great deal of flexibility in how we diagnose and correct DICOM incompatibilities. While this is not the only solution to such a problem, this certainly is a good solution. It is unlikely that DICOM will become a perfect standard, and thus, there will always be the need for integration tools like the ones that we use at ONRAD.

As always, I am curious to hear about what else is being done out there?

-Jesse Salen, CTO