in the early 1980s, the use of medical digital image devices such as computed tomography (CT) and magnetic resonance imaging (MRI) increased dramatically. These new digital imaging modalities not only greatly enhanced the diagnostic capabilities of the medical profession but also necessitated the intercommunication of diverse imaging devices such as workstations, printers, and the image acquisition modalities themselves.
Interconnectivity between these devices was difficult because the vendors of medical imaging equipment at the time used proprietary communication methods. In other words, a CT from company X could not communicate with a workstation from company Y without developing expensive-customized software. This lack of a communication standard was a burden to the end user because purchasing one piece of equipment from a vendor essentially locked the user into the entire line of imaging products from that vendor.
Medical equipment users, represented by the American College of Radiology (ACR), and medical equipment vendors, represented by the National Electrical Manufacturers Association (NEMA), worked together to address this lack of interoperability. By 1993, the Digital Imaging and Communication in Medicine (DICOM) 3.0 standard was released, and since then many supplements have been released that address the new technological changes and needs. DICOM 3.0 is now ubiquitous, respected, and acknowledged as a truly international standard by the International Organization for Standardization (ISO). In fact, there are no real alternatives.1
The DICOM standard includes a communication protocol that allows devices manufactured by different vendors to communicate with each other, both by exchanging digital images so that they can be created, archived, viewed, or printed, and by exchanging other information such as patient demographics, exam scheduling, and exam reporting.2 DICOM-conformant machines from two vendors can seamlessly communicate with each other, thus granting the user the option of purchasing a CT from one vendor, an ultrasound machine from another vendor, and a picture archiving and communication system (PACS) server from a third.
Conformance to the DICOM standard is entirely voluntary, and there is no official governing body that has the authority to enforce conformance. In fact, there is also no certification or testing authority to verify claims of conformance with the DICOM standard.1 Rather, the DICOM standard is a cooperative standard. Connectivity works because vendors cooperate in testing via scheduled public demonstration, over the Internet, and during private test sessions.3
The DICOM Standards Committee is a standards organization administered by the NEMA Diagnostic Imaging and Therapy Systems Division. The organization is divided into a number of subgroups called working groups. These working groups have their own area of expertise such as MRI, CT, and dentistry. Currently, there are 26 different working groups. Working group—25 was recently formed to address needs specific to veterinary medicine. The primary objective of this working group is to define the necessary information fields used in veterinary medicine that will allow storage of information in DICOM files. These information fields include breed, species, positioning, body parts, and owner (called responsible party).
Currently, many veterinarians have limited understanding of DICOM. This is because most DICOM introductory material has been written either for the engineer and is highly technical or for the hospital administrator and is rather superficial.4 The goal of this article is to provide veterinarians with an easy-to-understand introduction to the DICOM standard.
Any veterinarian using digital imaging modalities such as ultrasound, digital radiography, MRI, or CT needs to understand DICOM. Most veterinarians are familiar with analog (film) images, and analog images can be viewed anywhere there is a light source. It is the transition from analog images to digital images and the need to communicate, display, and store these images that has made DICOM necessary. It is easy to bundle printed CT and ultrasound images with traditional radiographs into an envelope and store the folder on a shelf or mail it to a colleague. However, to store the images of differing modalities electronically in a system that enables easy retrieval, viewing, and transmission of images to a remote destination requires a much higher level of technical infrastructure.
A cursory understanding of how a DICOM communication works is necessary to understand vendor marketing materials and DICOM conformance statements. An imaging device is described with three elements of DICOM information. These three elements are as follows:
- •the DICOM service object(s) a particular device supports,
- •the role the imaging device plays in the DICOM communication, and
- •the service classes the device supports.
DICOM Service Objects
DICOM specifies the types of data that can be sent and the format of those data. In DICOM, the different types of imaging data such as computed radiography (CR), digital radiography, or ultrasound images are called DICOM objects. DICOM objects are also known as DICOM image object definitions.2 Common DICOM objects in veterinary medicine include CR images, CT, and secondary capture (SC) images, such as those produced by a radiograph scanner.
A DICOM communication is based on an interplay between the participants in the communication. These participants are called DICOM service class users (SCU) and DICOM service class providers (SCP), and each of these participants plays a specific role in a DICOM communication.
As an analogy, consider dialing to an internet service provider (ISP) for an internet access. The caller initiates the call from his computer, requesting the use of internet service from the ISP. The caller is the service user and the ISP is the service provider.2
As another example, a digital radiography unit sends an image to a PACS for archival. In this situation, the digital radiography machine is the SCU of the storage service provided by the SCP (PACS) device (Fig. 1).
It is important to understand that the role of user or provider can change and is based on the relationship for a specific transaction. For instance, when a viewing workstation queries the server for a list of studies, the workstation is the user—SCU and the server is the provider—SCP of that information. It should be noted that when transferring images, the images are sent from SCU to SCP. Therefore, if the workstation subsequently requests an image from the PACS server, the server will act as the service user—SCU and send the image to the workstation that is acting as the provider—SCP. This process is important to understand, as a firewall that sits between the PACS server and the workstation will have to allow connections to be initiated from one device to the another. For more details on firewalls, refer to the article in this supplement related to networking.5
DICOM Service Classes
DICOM specifies types of communications called DICOM service classes. Each service class performs a different function. Examples of DICOM service classes include store, print, and query/retrieve.
The concepts of DICOM services and objects are used within DICOM in terms of a service object pair (SOP). An SOP is a combination of a DICOM service (store images) and an object (e.g., an image). The SOP instance is a unique occurrence of a specific SOP class (Fig. 2).6
An SOP tells the user what service class the modality supports and what types of images (DICOM objects) it handles.2 For example, the CT storage SOP represents the store command as it is used to exchange a CT image object.
Study, Series, and Image
Each patient can have one or more studies, each of which may consist of one or more series of images. A series may be a single image, such as a thoracic radiograph, or several images, as in a set of CT slices. Because each image, series, and study is unique, each is assigned a unique identifying number (UID) to identify it unambiguously. In fact, no two images anywhere in the world should have the same number. Each study is identified by a Study Instance UID, each series by a Series Instance UID, and each image by an SOP Instance UID. Technically, a UID will appear as a long string of numbers such as 1.2.840.1008.5.1…1.4321. The first several sets of digits, or the root of the number, are assigned to an organization or a vendor and can be used to determine whose equipment generated the image.