In part 1 of this 2-part series, we looked at the Digital Imaging and Communications in Medicine (DICOM) data hierarchy, culminating in the information object definition, or IOD. DICOM communication deals with this top data level. Part 1 also mentioned the DICOM message service elements (DIMSE), commands that tell DICOM what action to take with the data. Finally, part 1 discussed unique identifiers, or UIDs. These are formatted names given to portions of DICOM like the service object pair (SOP). SOPs combine the service class (or DIMSE) with an IOD, such as “store this MR image.”
Part 2 covers the association process that takes place between two application entities (AEs) to facilitate communication. It also takes a look at the DICOM conformance statement used by device manufacturers to indicate which part of the DICOM standard specific devices address.
AEs, DICOM’s term for devices on the network, establish a network communication connection using an association process. During this process, they essentially agree on the details of how to talk with each other, using several virtual handshakes in the process.
Let’s use a CT/archive SOP as an example, where the CT scanner is attempting to transfer images to the archive. First, the CT scanner AE asks the archive AE if it speaks DICOM. The archive replies that it does. The CT scanner then asks if the archive is a service class provider (SCP) for CT image storage, and the archive confirms that it is. The scanner might reply that it has 80 uncompressed images that it wants to store, but that it can send the files in a compressed format if the archive prefers. The scanner will also state the compression methods it can use. The archive replies that it can accept uncompressed images. The scanner then says, “OK, here they come,” and starts to send the images for storage. Together, the CT scanner and the archive keep track of which images have been sent and log the files as they transfer, neatly closing the association at the end.
Two important aspects defined during the association process are the abstract syntax and the transfer syntax. The abstract syntax identifies all the SOPs that it can handle, such as MR image storage. It also defines what functionality needs to be provided. The SOPs are clearly defined in the DICOM standard and will use UIDs as names. The association process will involve sending the SOP UIDs back and forth to each of the communicating systems for verification.
The transfer syntax also uses UIDs, and states the format of the transaction. It describes how the transferred information is encoded. There are many different methods of compression, depending on whether you’re sending compressed lossless or lossy data, for example. The transfer syntax defines the compression formats the transaction is using.
Of course, the actual communication is in DICOM-ese, in a so-called “primitive” DICOM language. In reality, the association process is much longer and more detailed. But the idea is that the AEs use the association process to agree on everything and establish a common understanding. If they don’t, the agreement can fail anywhere along the way: an AE can reject the association and abort, and nothing further will happen.
OEMs are required by the DICOM standard to supply a conformance statement that indicates how they use the standard. The statement is a structured document that is outlined in the standard’s section PS3.2 on conformance. It’s a pretty strict requirement, but the section includes templates for OEMs to follow. Overall, the DICOM template provides for a selection of services, each with a variety of options. Typically, DICOM implementations will only include those that are required by the OEM’s device—a subset of the available functions and options.
For AE communication especially, it’s vital that the OEM provide a complete and detailed list of the DICOM capabilities it addresses. The purpose of the conformance statement is to supply that list. The ultimate goal is to be able to determine whether two AEs can communicate in DICOM. Keep in mind that while comparing conformance statements does not guarantee compatibility, doing so will alert you if compatibility is impossible. For example, if each system identifies itself as a service class provider—meaning that neither one is a service class user—then communication will be impossible.
DICOM conformance statements include four main sections: the problem statement, application entity specifications, communication profiles, and specializations. The initial problem statement identifies the application domain of the equipment, such as transferring scans from a CT machine to storage. Essentially, the problem statement defines how the equipment interacts with the real world.
The equipment being described in the conformance statement may contain more than one AE. Each of the AEs is given a name and defined in the application entity specifications section. This section typically constitutes the majority of the conformance statement. Each AE’s list of DICOM services is defined, including whether it is an SCU or an SCP (a user or a provider). Its communication rules are also explained, showing how it will react during an association process—by either initiating or accepting connections, for example. In addition, how each AE encodes data will also be defined in this section.
The communication profiles section includes all the particulars for which communication protocols are used. This includes the physical layer, as in what kinds of media are supported (such as twisted pair). The data link layer specifies how the AE accesses the media (for example, via Ethernet). Obviously, if I only support FDDI over fiber and you only support Ethernet over twisted pair, we will not be able to communicate.
Finally, the equipment’s optional specialties are listed in the specializations section. An AE might add certain exclusive attributes to an image that other systems can ignore and still be able to communicate with those systems. However, if the AE is defining new attributes or ones not readily recognized by DICOM, it must clearly state those attributes to give other AEs a chance to adjust and be able to read them. Private attributes are generally discouraged to eliminate surprise instances of noninteroperability.
Examining two systems’ conformance statements can give you some idea as to their interconnectivity and interoperability. By checking the basics and confirming that both use compatible protocols and DICOM processes, you can increase—but not ensure—the likelihood of communication. Testing the connection at all necessary levels is the only real way to ensure communication.
You now know more about DICOM (hopefully, a lot more!) than the average person on the street. But understanding how data sets are built and how services and the association process take place is only the beginning. There are 18 active parts to the DICOM standard. All are available for free and in multiple formats at dicom.nema.org. If you’d like to learn more, I recommended reading not only the DICOM standard itself—the ultimate source—but also a book by Oleg Pianykh called DICOM: A Practical Introduction and Survival Guide. Happy DICOMing!
Jeff Kabachinski is the director of technical development for Aramark Healthcare Technologies in Charlotte, NC. For more information, contact chief editor Jenny Lower at [email protected].