DICOM

Digital Imaging and Communications in Medicine (DICOM) is a standard for handling, storing, printing, and transmitting information in medical imaging. It includes a file format definition and a network communications protocol. 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.[1] It was developed by the DICOM Standards Committee, whose members[2] are also partly members of NEMA.[3]

DICOM enables the integration of medical imaging devices – like scanners, servers, workstations, printers, network hardware, and picture archiving and communication systems (PACS) – from multiple manufacturers. The different devices come with DICOM Conformance Statements which clearly state which DICOM classes they support. DICOM has been widely adopted by hospitals and is making inroads in smaller applications like dentists' and doctors' offices.

DICOM is known as NEMA standard PS3, and as ISO standard 12052:2006 "Health informatics -- Digital imaging and communication in medicine (DICOM) including workflow and data management".

Applications

DICOM is used worldwide to store, exchange, and transmit medical images. DICOM has been central to the development of modern radiological imaging: DICOM incorporates standards for imaging modalities such as radiography, ultrasonography, computed tomography (CT), magnetic resonance imaging (MRI), and radiation therapy. DICOM includes protocols for image exchange (e.g., via portable media such as DVDs), image compression, 3-D visualization, image presentation, and results reporting.[4]

Parts of the standard

The DICOM standard is divided into related but independent parts. The links below are to the chunked HTML representation of the current version; as the standard is updated the content at these links remains valid. Alternative formats as well as the DocBook source of the standard text, and additions to the standard (Supplements and Change Proposals), are available through the DICOM Web site and are also indexed on the DICOM status page.

History

Front page of ACR/NEMA 300, version 1.0, which was released in 1985

DICOM is the a standard developed by American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA).

In the beginning of the 1980s, it was very difficult for anyone other than manufacturers of computed tomography or magnetic resonance imaging devices to decode the images that the machines generated. Radiologists and medical physicists wanted to use the images for dose-planning for radiation therapy. ACR and NEMA joined forces and formed a standard committee in 1983. Their first standard, ACR/NEMA 300, was released in 1985. Very soon after its release, it became clear that improvements were needed. The text was vague and had internal contradictions.

In 1988 the second version was released. This version gained more acceptance among vendors. The image transmission was specified as over a dedicated 2 pair cable (EIA-485). The first demonstration of ACR/NEMA V2.0 interconnectivity technology was held at Georgetown University, May 21–23, 1990. Six companies participated in this event, DeJarnette Research Systems, General Electric Medical Systems, Merge Technologies, Siemens Medical Systems, Vortech (acquired by Kodak that same year) and 3M. Commercial equipment supporting ACR/NEMA 2.0 was presented at the annual meeting of the Radiological Society of North America (RSNA) in 1990 by these same vendors. Many soon realized that the second version also needed improvement. Several extensions to ACR/NEMA 2.0 were created, like Papyrus (developed by the University Hospital of Geneva, Switzerland) and SPI (Standard Product Interconnect), driven by Siemens Medical Systems and Philips Medical Systems.

The first large-scale deployment of ACR/NEMA technology was made in 1992 by the US Army and Air Force, as part of the MDIS (Medical Diagnostic Imaging Support) program based at f Ft. Detrick, Maryland. Loral Aerospace and Siemens Medical Systems led a consortium of companies in deploying the first US military PACS (Picture Archiving and Communications System) at all major Army and Air Force medical treatment facilities and teleradiology nodes at a large number of US military clinics. DeJarnette Research Systems and Merge Technologies provided the modality gateway interfaces from third party imaging modalities to the Siemens SPI network. The Veterans Administration and the Navy also purchased systems off this contract.

In 1993 the third version of the standard was released. Its name was then changed to "DICOM". New service classes were defined, network support added and the Conformance Statement was introduced. Officially, the latest version of the standard is still 3.0. It has been constantly updated and extended since 1993, but most changes are forward and backward compatible, except in rare cases where the original specification was not interoperable or conflicted with another standard. The standard should be referenced without specification of the date of release of a particular edition, except when specific conformance requirements are invoked that depend on a particular change (e.g., to reference a retired feature).

While the DICOM standard has achieved a near universal level of acceptance amongst medical imaging equipment vendors and healthcare IT organizations, the standard has its limitations. DICOM is a standard directed at addressing technical interoperability issues in medical imaging. It is not a framework or architecture for achieving a useful clinical workflow. The Integrating the Healthcare Enterprise (IHE) initiative layered on top of DICOM (and HL-7) defines profiles to select features from these standards to implement transactions for specific medical imaging interoperability use cases.

Though always Internet compatible and based on transport over TCP, over time there has been an increasing need to support port 80 http transport to make use easier within the web browser. Most recently, a family of DICOM RESTful web services have been defined to allow mobile device friendly access to DICOM objects and services, which include WADO-RS, STOW-RS and QIDO-RS, which together constitute the DICOMweb initiative,

Derivations

There are some derivations from the DICOM standard into other application areas. These include:

Data format

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, being 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. However, 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, Lossless JPEG, JPEG 2000, and 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.

Image display

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),[7] images must be viewed (or printed) on devices that have this lookup curve or on devices that have been calibrated to the GSDF curve.[8]

Value representations

See Table 6.2-1 of PS 3.5.

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 "\".

Services

DICOM consists of services, most of which involve transmission of data over a network. The file format for offline media is a later addition to the standard.

Store

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.

Storage Commitment

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.

Query/Retrieve

This enables a workstation to find lists of images or other such objects and then retrieve them from a picture archiving and communication system.

Modality Worklist

The DICOM Modality Worklist service provides a list of imaging procedures that have been scheduled for performance by an image acquisition device (sometimes referred to as a modality system). The items in the worklist include relevant details about the subject of the procedure (patient ID, name, sex, and age), the type of procedure (equipment type, procedure description, procedure code) and the procedure order (referring physician, accession number, reason for exam). An image acquisition device, such as a CT scanner, queries a service provider, such as a RIS, to get this information which is then presented to the system operator and is used by the imaging device to populate details in the image metadata.

Prior to the use of the DICOM Modality Worklist service, the scanner operator was required to manually enter all the relevant details. Manual entry is slower and introduces the risk of misspelled patient names, and other data entry errors.

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.

Print

The DICOM Print 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 format for off-line media files is specified in Part 10 of the DICOM Standard. Such files are sometimes referred to as "Part 10 files".

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 6.2.3.2). 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, 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 MIME type for DICOM files is defined by RFC 3240 as application/dicom.

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.

Application areas

The core application of the DICOM standard is to capture, store and distribute medical images. The standard also provides services related to imaging such as managing imaging procedure worklists, printing images on film or digital media like DVDs, reporting procedure status like completion of an imaging acquisition, confirming successful archiving of images, encrypting datasets, removing patient identifying information from datasets, organizing layouts of images for review, saving image manipulations and annotations, calibrating image displays, encoding ECGs, encoding CAD results, encoding structured measurement data, and storing acquisition protocols.

Types of Equipment

The DICOM Information Object Definitions encode the data produced by a wide variety of imaging device types, including:

  • CT (Computed Tomography)
  • MRI (Magnetic Resonance Imaging)
  • Ultrasound
  • X-Ray
  • Fluoroscopy
  • Angiography
  • Mammography
  • Breast Tomosynthesis
  • PET (Positron Emission Tomography)
  • SPECT (Single Photon Emission Computed Tomography)
  • Endoscopy
  • Microscopy
  • Whole Slide Imaging
  • OCT (Optical Coherence Tomography)

DICOM is also implemented by devices associated with images or imaging workflow including:

  • PACS (Picture Archiving and Communication Systems)
  • Image Viewers and Display Stations
  • CAD (Computer Aided Detection/Diagnosis Systems)
  • 3D Visualization Systems
  • Clinical Analysis Applications
  • Image Printers
  • Film Scanners
  • Media Burners (that export DICOM files onto CDs, DVDs, etc)
  • Media Importers (that import DICOM files from CDs, DVDs, USBs, etc)
  • RIS (Radiology Information Systems)
  • VNA (Vendor Neutral Archives)
  • EMR (Electronic Medical Record Systems)
  • Radiology Reporting Systems

Fields of Medicine

Many fields of medicine have a dedicated Working Group within DICOM,[9] and DICOM is applicable to any field of medicine in which imaging is prevalent, including:

  • Radiology
  • Cardiology
  • Oncology
  • Radiotherapy
  • Neurology
  • Orthopedics
  • Obstetrics
  • Gynecology
  • Ophthalmology
  • Dentistry
  • Maxillofacial Surgery
  • Dermatology
  • Pathology
  • Clinical Trials
  • Veterinary Medicine

Port numbers over IP

DICOM have reserved the following TCP and UDP port numbers by the Internet Assigned Numbers Authority (IANA):

The standard recommends but does not require the use of these port numbers.

Disadvantages

According to a paper presented at an international symposium in 2008, the DICOM standard has problems related to data entry. "A major disadvantage of the DICOM Standard is the possibility for entering probably too many optional fields. This disadvantage is mostly showing in inconsistency of filling all the fields with the data. Some image objects are often incomplete because some fields are left blank and some are filled with incorrect data."[10]

See also

Software

Related standards and SDOs

References

  1. ↑ DICOM brochure, nema.org.
  2. ↑ MEMBERS of the DICOM STANDARDS COMMITTEE
  3. ↑ NEMA. "NEMA Members - NEMA". www.nema.org. Retrieved 2016-09-15.
  4. ↑ 62. Kahn CE Jr, Carrino JA, Flynn MJ, Peck DJ, Horii SC. DICOM and radiology: past, present, and future. Journal of the American College of Radiology 2007; 4:652-657. DOI 10.1016/j.jacr.2007.06.004
  5. ↑ http://www.astm.org: If a Picture Is Worth 1,000 Words, then Pervasive, Ubiquitous Imaging Is Priceless
  6. ↑ http://www.nema.org: Industrial Imaging and Communications Section
  7. ↑ http://medical.nema.org/Dicom/2011/11_14pu.pdf
  8. ↑ Shiroma, J. T. (2006). An introduction to DICOM. Veterinary Medicine, , 19-20. http://search.proquest.com/docview/195482647
  9. ↑ DICOM Strategy Document
  10. ↑ Mustra, Mario; Delac, Kresimir; Grgic, Mislav (September 2008). Overview of the DICOM Standard (PDF). ELMAR, 2008. 50th International Symposium. Zadar, Croatia. pp. 39–44. ISBN 978-1-4244-3364-3.
  11. ↑ Clunie, D.; Cordonnier, k. (February 2002). Digital Imaging and Communications in Medicine (DICOM) – Application/dicom MIME Sub-type Registration.. IETF. RFC 3240. https://tools.ietf.org/html/rfc3240. Retrieved 2014-03-02.
  12. ↑ IHE Profiles
  13. ↑ Flanders, A.E., Carrino, J.A., 2003. Understanding DICOM and IHE. Seminars in Roentgenology 38, 270–281.

External links

This article is issued from Wikipedia - version of the 10/1/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.