Digital Imaging and Communications in Medicine (DICOM) is an application layer network protocol for the transmission of medical images, waveform and accompanying information. DICOM was originally developed by the National Electrical Manufacturers Association (NEMA) and the American College of Radiology for computerized axial tomography (CAT) and magnetic resonance imaging (MRI) scan images. It is now controlled by the DICOM Standards Committee and supports a wide range of medical images across the fields of radiology, cardiology, pathology and dentistry. DICOM uses TCP/IP as the lower-layer transport protocol.
With the introduction of computed tomography (CT) followed by other digital diagnostic imaging modalities in the 1970's, and the increasing use of computers in clinical applications, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) recognized the emerging need for a standard method for transferring images and associated information between devices manufactured by various vendors. These devices produce a variety of digital image formats. 
The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee in 1983 to develop a standard to:
- Promote communication of digital image information, regardless of device manufacturer
- Facilitate the development and expansion of Picture Archiving and Communication Systems (PACS) that can also interface with other systems of hospital information
- Allow the creation of diagnostic information data bases that can be interrogated by a wide variety of devices distributed geographically.
This standard, designated DICOM, embodies a number of major enhancements to previous versions of the ACR-NEMA Standard:
a. It is applicable to a networked environment. The ACR-NEMA Standard was applicable in a point to point environment only; for operation in a networked environment a Network Interface Unit (NIU) was required. DICOM supports operation in a networked environment using the industry standard networking protocol TCP/IP.
b. It is applicable to an off-line media environment. The ACR-NEMA Standard did not specify a file format or choice of physical media or logical filesystem. DICOM supports operation in an off-line media environment using industry standard media such as CD-R and MOD and logical filesystems such as ISO 9660 and PC File System (FAT16).
c. It specifies how devices claiming conformance to the Standard react to commands and data being exchanged. The ACR-NEMA Standard was confined to the transfer of data, but DICOM specifies, through the concept of Service Classes, the semantics of commands and associated data.
d. It specifies levels of conformance. The ACR-NEMA Standard specified a minimum level of conformance. DICOM explicitly describes how an implementor must structure a Conformance Statement to select specific options.
e. It is structured as a multi part document. This facilitates evolution of the Standard in a rapidly evolving environment by simplifying the addition of new features. ISO directives which define how to structure multi part documents have been followed in the construction of the DICOM Standard.
f. It introduces explicit Information Objects not only for images and graphics but also for waveforms, reports, printing, etc.
g. It specifies an established technique for uniquely identifying any Information Object. This facilitates unambiguous definitions of relationships between Information Objects as they are acted upon across the network.
The DICOM standard is divided into related but independent parts:
The links below are to the 2011 version. Additions to the standard (Supplements and Change Proposals) since that publication are available through the DICOM Web site.
- PS 3.1: Introduction
- PS 3.2: Conformance
- PS 3.3: Information Object Definitions
- PS 3.4: Service Class Specifications
- PS 3.5: Data Structure and Encoding
- PS 3.6: Data Dictionary
- PS 3.7: Message Exchange
- PS 3.8: Network Communication Support for Message Exchange
- PS 3.9: Retired (formerly Point-to-Point Communication Support for Message Exchange)
- PS 3.10: Media Storage and File Format for Media Interchange
- PS 3.11: Media Storage Application Profiles
- PS 3.12: Media Formats and Physical Media
- PS 3.13: Retired (formerly Print Management Point-to-Point Communication Support)
- PS 3.14: Grayscale Standard Display Function
- PS 3.15: Security and System Management Profiles
- PS 3.16: Content Mapping Resource
- PS 3.17: Explanatory Information
- PS 3.18: Web Access to DICOM
- PS 3.19: Application Hosting
- PS 3.20: Transformation of DICOM to and from HL7 Standards
DICOM differs from some, but not all, data formats in that it groups information into data sets. That means that a file of a chest x-ray image, for example, actually contains the patient ID within the file, so that the image can never be separated from this information by mistake. This is similar to the way that image formats such as JPEG can also have embedded tags to identify and otherwise describe the image.
A DICOM data object consists of a number of attributes, including items such as name, ID, etc., and also one special attribute containing the image pixel data (i.e. logically, the main object has no "header" as such: merely a list of attributes, including the pixel data). A single DICOM object can have only one attribute containing pixel data. For many modalities, this corresponds to a single image. But note that the attribute may contain multiple "frames", allowing storage of cine loops or other multi-frame data. Another example is NM data, where an NM image, by definition, is a multi-dimensional multi-frame image. In these cases, three- or four-dimensional data can be encapsulated in a single DICOM object. Pixel data can be compressed using a variety of standards, including JPEG, JPEG Lossless, JPEG 2000, and [[Run-length encoding|Run-length encoding (RLE). LZW (zip) compression can be used for the whole data set (not just the pixel data), but this has rarely been implemented.
DICOM uses three different Data Element encoding schemes. With Explicit Value Representation (VR) Data Elements, for VRs that are not OB, OW, OF, SQ, UT, or UN, the format for each Data Element is: GROUP (2 bytes) ELEMENT (2 bytes) VR (2 bytes) LengthInByte (2 bytes) Data (variable length). For the other Explicit Data Elements or Implicit Data Elements, see section 7.1 of Part 5 of the DICOM Standard.
The same basic format is used for all applications, including network and file usage, but when written to a file, usually a true "header" (containing copies of a few key attributes and details of the application which wrote it) is added.
To promote identical grayscale image display on different monitors and consistent hard-copy images from various printers, the DICOM committee developed a lookup table to display digitally assigned pixel values. To use the DICOM grayscale standard display function (GSDF), images must be viewed (or printed) on devices that have this lookup curve or on devices that have been calibrated to the GSDF curve.6
Extracted from Chapter 6.2 of * PS 3.5: Data Structure and Encoding
|FL||Floating Point Single (4 bytes)|
|FD||Floating Point Double (8 bytes)|
|SQ||Sequence of Items|
In addition to a Value Representation, each attribute also has a Value Multiplicity to indicate the number of data elements contained in the attribute. For character string value representations, if more than one data element is being encoded, the successive data elements are separated by the backslash character "\".
DICOM consists of many different services, most of which involve transmission of data over a network, and the file format below is a later and relatively minor addition to the standard.
The DICOM Store service is used to send images or other persistent objects (structured reports, etc.) to a picture archiving and communication system (PACS) or workstation.
The DICOM storage commitment service is used to confirm that an image has been permanently stored by a device (either on redundant disks or on backup media, e.g. burnt to a CD). The Service Class User (SCU: similar to a client), a modality or workstation, etc., uses the confirmation from the Service Class Provider (SCP: similar to a server), an archive station for instance, to make sure that it is safe to delete the images locally.
This enables a workstation to find lists of images or other such objects and then retrieve them from a picture archiving and communication system.
This enables a piece of imaging equipment (a modality) to obtain details of patients and scheduled examinations electronically, avoiding the need to type such information multiple times (and the mistakes caused by retyping).
Modality performed procedure step
A complementary service to Modality Worklist, this enables the modality to send a report about a performed examination including data about the images acquired, beginning time, end time, and duration of a study, dose delivered, etc. It helps give the radiology department a more precise handle on resource (acquisition station) use. Also known as MPPS, this service allows a modality to better coordinate with image storage servers by giving the server a list of objects to send before or while actually sending such objects.
The DICOM Printing service is used to send images to a DICOM Printer, normally to print an "X-Ray" film. There is a standard calibration (defined in DICOM Part 14) to help ensure consistency between various display devices, including hard copy printout.
Off-line media (files)
The off-line media files correspond to Part 10 of the DICOM standard. It describes how to store medical imaging information on removable media. Except for the data set containing, for example, an image and demography, it's also mandatory to include the File Meta Information.
DICOM restricts the filenames on DICOM media to 8 characters (some systems wrongly use 8.3, but this does not conform to the standard). No information must be extracted from these names (PS3.10 Section 126.96.36.199). This is a common source of problems with media created by developers who did not read the specifications carefully. This is a historical requirement to maintain compatibility with older existing systems. It also mandates the presence of a media directory, the DICOMDIR file, A unique and mandatory DICOM File within a File-set which contains the Media Storage, which provides index and summary information for all the DICOM files on the media. The DICOMDIR information provides substantially greater information about each file than any filename could, so there is less need for meaningful file names.
DICOM files typically have a .dcm file extension if they are not part of a DICOM media (which requires them to be without extension).
The Uniform Type Identifier type for DICOM files is org.nema.dicom.
There is also an ongoing media exchange test and "connectathon" process for CD media and network operation that is organized by the IHE organization. MicroDicom is free Windows software for reading DICOM data.
DICOM services use a limited number of basic DICOM operations (officially called DIMSE operations), all of which are of course supported by DicomObjects.
These are "self-contained", and the objects passed therefore contain enough information for the operation to exist independently, without reference to other operations on the same or different associations (though of course they are commonly used as part of more complex operations!)
|C-STORE||AThe most basic DICOM operation, otherwise known as "DICOM Push" allows an SCU to send a Composite_Instance to an SCP. For instance, it is used to send images from a modality to PACS or create the delivery mechanism for C-MOVE|
|C-FIND||Initially used as part of the Query/Retrieve service, but subsequently re-used in the Modality_Worklist and General_Purpose_Worklist services, this is a very simple operaiton rather akin to a SQL query, whereby a dataset is passed from the SCU to the SCP containing 2 sorts of attributes. The SCP responds by sending a number of matching datasets, followed by a "complete" response to say that it has finished.|
|C-MOVE||This requests the C-MOVE SCP to act as a C-STORE SCU and to copy composite_instances to a requested AET which may or may not be the original C-MOVE SCU (99% of the time it is!). This operation has multiple problems. Despite all these problems, C-MOVE is the only retrieval protocol used by most PACS.|
|C-GET||C-GET is like C-MOVE, but instead of using a secondary Association, the requested Composite_Instances are sent over the original association. This avoids all the problems described above for C-MOVE. There are 2 downsides to C-GET.|
|C-ECHO||This is a basic "is everything working OK" test - sometimes refereed to as "DICOM Ping". It should not be confused with a basic TCP/IP ping however as it is a full-blown DICOM service, using full negotiation, and tests AE title, port numbers, and IP connectivity. Support for C-ECHO is mandatory for all Application_Entities which accept associations.This is the only way to verify that two AE titles are configured properly.|
Port numbers over IP
DICOM have reserved the following TCP and UDP port numbers by the Internet Assigned Numbers Authority (IANA):
- 104 well-known port for DICOM over Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). Since 104 is in the reserved subset, many operating systems require special privileges to use it.
- 2761 registered port for DICOM using Integrated Secure Communication Layer (ISCL) over TCP or UDP
- 2762 registered port for DICOM using Transport Layer Security (TLS) over TCP or UDP
- 11112 registered port for DICOM using standard, open communication over TCP or UDP
The standard recommends but does not require the use of these port numbers.
DICOM is a standard for handling, storing, printing, and transmitting information in medical imaging. The communication protocol is an application protocol that uses TCP/IP to communicate between systems. DICOM files can be exchanged between two entities that are capable of receiving image and patient data in DICOM format. The National Electrical Manufacturers Association (NEMA) holds the copyright to this standard. It was developed by the DICOM Standards Committee, whose members are also partly members of NEMA.
Health Level Seven (HL7), is a non-profit organization involved in the development of international healthcare informatics interoperability standards. "HL7" also refers to some of the specific standards created by the organization (e.g., HL7 v2.x, v3.0, HL7 RIM). The HL7 Strategic Initiatives document is a business plan for our products and services and was designed specifically to meet the business needs of our members and stakeholders. Derived from collaborative efforts with our members, government and non-government agencies and other standards development organizations, the Strategic Initiatives are five high-level organizational strategies that are supported by a detailed tactical plan with clearly defined objectives, milestones, and metrics for success.
Both of the standards are focused on the data exchange and the data compatibility. Among many standards for the syntax, HL7 and DICOM are most successful. However, everything could not be handled by HL7 solely. DICOM is good for radiology images, but, other clinical images are already handled by other ‘lighter’ data formats like JPEG, TIFF. So, it is not realistic to use only one standard for every area of clinical information.
Opening the HL7 and DICOM standards in order to foster the integrated use of persistent health information objects is proposed as a step towards the creation of the health information infrastructure.
- ↑ Whatis.com. "DICOM". http://whatis.techtarget.com/definition/DICOM-Digital-Imaging-and-Communications-in-Medicine
- ↑ DICOM, National Electrical Manufacturers Association (NEMA), Digital Imaging and Communications in Medicine (DICOM, 2008
- ↑ Digital Imaging and Communications in Medicine (DICOM) Part 1: Introduction and Overview | chapter=6.1 DIMSE Services | pages=11 | publisher=National Electrical Manufacturers Association | 2006. ftp://medical.nema.org/medical/dicom/2009/08_01pu.pdf }}
- ↑ http://medical.nema.org/Dicom/2011/11_14pu.pdf
- ↑ Shiroma, J. T. (2006). An introduction to DICOM. Veterinary Medicine, , 19-20. Retrieved from http://0-search.proquest.com.alpha2.latrobe.edu.au/docview/195482647?accountid=12001
- ↑ Medical Connections Ltd. Basic DICOM Commands. 2013. http://www.medicalconnections.co.uk/kb/Basic_DICOM_Operations#C-ECHO
- ↑ http://www.dicombuzz.blogspot.in/p/dicom.html. July 2013
- ↑ http://www.hl7.org/about/index.cfm. July 2013
- ↑ Kimura, M. Ohe, K. . Yoshihara, H. MERIT-9: A patient information exchange guideline using MML, HL7 and DICOM |volume=51 |issue=1 |pages=59–68 |journal=International Journal of Medical Informatics
- ↑ Access to persistent health information objects: Exchange of image and document data by the use of DICOM and HL7 standards |year=2005 |last1=König |first1=H. |journal=International Congress Series |volume=1281 |pages=932–7
- DICOM website
- DICOM glossary
- Image FAQ part 2 - Standard formats including DICOM.
- Image FAQ part 8 - Contains a long list DICOM software.
- of DICOM images (clinical images and technical testpatterns