Digital Imaging and Communications in Medicine

Digital Imaging and Communications in Medicine ( DICOM ; German digital imaging and communication in medicine ) is an open standard for storing and exchanging information in medical image data management. This information can be, for example, digital images, additional information such as segmentations , surface definitions or image registrations . DICOM standardizes both the format for storing data and the communication protocol for exchanging them.

Almost all manufacturers of imaging or image processing systems in medicine such as B. Digital X-ray , magnetic resonance tomography , computed tomography or sonography implement the DICOM standard in their products. This enables interoperability between systems from different manufacturers in the clinical environment .

DICOM is also the basis for digital image archiving in practices and hospitals ( Picture Archiving and Communication System , PACS).

Data format

DCM sample image (see text)

In addition to data fields (e.g. information about images, findings , patients, studies, series), DICOM also contains the syntax and semantics of commands and messages. Furthermore, the standard defines regulations for the description of DICOM-compatible devices and software, since an exact description of the system capability must be available and published for every DICOM-compatible device (DICOM Conformance Statement).

A DICOM data record serves as a container which, in addition to one or more object definitions, can also contain meta information such as patient name, admission date, device parameters or doctor name. The object definitions can be image data, geometric or mathematical information and also treatment-specific information, such as in the so-called DICOM RT objects, which themselves only contain treatment data and only reference image data sets.

DICOM stores or transmits images lossless or lossy, based on the TIFF format and the JPEG standard. It can summarize series of images. The various compression methods are defined in their own transfer syntax.

The DICOM standard also allows you to define your own, so-called private objects, modules or attributes. However, this proprietary information is normally no longer compatible with implementations from other manufacturers.

The image on the right is based on a DICOM file. It has been converted to a standard graphic format for display.

Real World Information Model

Real World Information Model

DICOM interprets data in a so-called Real World Information Model , which is divided into the levels of patient, study, series and instance . Each instance of a DICOM object thus holds all information in order to be able to assign it to a certain series (for example image series), study (a certain stay in the clinic or an individual examination) and patients.

The uniqueness of the information is based on unique identifiers (Unique Identifier ) implemented.

Information Object Definition

Example of the IOP of an image

All objects in DICOM are specified using a so-called information object definition . This consists of several modules, which in turn contain individual attributes or sequences of attributes.

It is made between normalized (normalized) and composite (composite) distinguish objects. Normalized objects correspond to objects in the real world, while composite objects contain attributes that are indeed related to the object in the real world, but cannot be directly assigned to them.

The composite objects usually have all of the following modules in common: SOP Common, Patient, Study, Series and Equipment. Other modules vary depending on the modality of the property. This module , also known as header information, allows any object to be clearly assigned to a specific process.

Module definition

Module definitions group DICOM attributes in logical units. For example, the patient module contains all information relating to the patient, such as name, ID, gender or age. Modules can be reused in various composite objects. In every definition of a composite object it is also defined whether a certain module is absolutely necessary and must be available ( M - Mandatory), whether its existence is linked to certain conditions ( C - Conditional) or whether it is at the discretion of the user ( U - User Option).

Module definitions can be found in the DICOM standard in Chapter 3.

Attributes definition

DICOM data element

An attribute is defined using a fixed eight-digit hexadecimal number , a so-called data tag . The first four digits define the affiliation of the attribute to a certain group (such as File Meta Information ), the other four define the element. For better readability, a DICOM data tag is usually shown in the form (aaaa, bbbb) with a comma in the middle. Thus the tag 0x00100010 - patient's name - corresponds to the decimal value 1048592 and is represented as (0010,0010).

DICOM standard attributes always have an even group number, with groups 0000, 0002, 0004 and 0006 being reserved for DIMSE commands and DICOM file sets . Uneven group numbers are reserved for private data elements that can be assigned by any implementer.

Another characteristic of an attribute is its value representation (VR), for example DS (Decimal String), IS (Integer String) or ST (Short Text). This includes the maximum possible length of a field and the permitted character set or explicitly prohibited characters.

Furthermore, the definition of Value Multiplicity (VM), i.e. H. the multiplicity of an attribute is necessary. As an example, the specification of an angle within a decimal string has the multiplicity 1. A coordinate , also of type DS, has the multiplicity 3 in order to be able to specify the position in all spatial directions.

The fourth necessary property is the type of the element. There is a distinction between type 1 - absolutely necessary and content must be present -, type 2 - absolutely necessary, but can be empty - and type 3 - not absolutely necessary. Furthermore, the types can be linked to conditions by adding the letter C (“1C”, “2C”). It then follows that, for example, an element of type 1 actually only needs to be present if the condition defined in the associated description is actually met.

While the value representation and the value multiplicity remain constant, the type can change depending on the module in which the attribute is used. Conditions for types 1C and 2C can therefore change accordingly and are listed individually in the respective module definition in the description of the attribute.

Examples

(0010,0010) - Patient's Name, VR: PN, VM: 1, Type: 2

(0010,0020) - PatientID, VR: LO, VM: 1, Type: 2

(0010,0021) - IssuerOfPatientID, VR: LO, VM: 1, Type: 2

Attribute and associated type definitions can be found in the DICOM standard in Chapter 3. Value representation and value multiplicity are defined for all attributes in chapter 6. The definitions of the Value Representation values are given in Chapter 5 " Data Structures and Encoding".

Service classes

The service classes defined in the DICOM standard designate different services. When these are applied to an object, they form a service group. The following services are available:

Verify
Store
Query / Retrieve
Procedure Step (Notification)
Print management
Media storage management
Storage commitment
Worklist management
Presentation state storage
Structured reporting storage
Application event logging
Relevant patient information query
Instance Availability Notification
Media creation management
Hanging Protocols Storage
Hanging Protocols Query / Retrieve
Substance Administration Query

(Descriptions can be found in Part 4 of the standard, service classes in italics are of lesser importance or are not yet widely supported by device manufacturers).

The main services

Verify: Verify can be used to check whether an external network node supports DICOM with the configured parameters.
Storage: The storage service stores a large part of the persistent data objects.
Query / Retrieve: With Query and Retrieve a PACS or another DICOM device can be searched for objects (Query) and found objects can then be transferred to another device (Retrieve).
Procedure Step (also abbreviated MPPS for Modality performed procedure Step ): Using procedure steps, DICOM devices can notify others about the examination steps that have been carried out. Typically, these procedures are communicated to the device for processing in a worklist , which then executes, aborts or changes them. This information can be transmitted to the planning system via Performed Procedure Step Notification.
Storage commitment: Using Storage Commitment, the storing modality can query whether the data it has transmitted has been securely stored. Background: Every storage system has a cache that initially buffers incoming data in a volatile data memory. A situation is conceivable in which an image data set was initially completely transferred to the PACS and stored in the cache. However, if the PACS or the storage system crashes before the content has been written to the non-volatile data carriers (mostly hard disks), this data would be gone, although error-free transmission was reported back to the transmitting modality. Since the storage space on the modality is only sufficient for a few days, the images could consequently be deleted there even though they were never saved in the PACS. The Storage Commitment message is only triggered by the PACS when the data has not only been received in full, but has also been securely stored on non-volatile memories. In this way, data loss caused by the scenario described can be excluded.
Worklist Management (also called MWL for Modality Worklist or DICOM Modality Worklist ): With worklist management, a planning system (typically the RIS ) can transmit a list of the next examinations, together with the patient data, to a (mostly imaging) device. This eliminates the need to enter patient data and the requested examination on the examination device (e.g. CT, MR, ultrasound).
Presentation state storage: Presentation State Storage can be used to transmit information on how an image was or is to be displayed. Presentation states include e.g. B. Information about grayscale adjustment, annotations and markings, and zoomed-in details.
Structured reporting storage: With structured reports it is possible to transmit a medical finding in coded form.
Hanging Protocols Storage: With Hanging Protocols Storage, a consistent representation of the series of images and studies can be stored on different displays for different users.
Hanging Protocols Query / Retrieve: With Hanging Protocols Query / Retrieve, display settings can be searched for and transferred (compare Query / Retrieve service class).

Benefits of DICOM for users

DICOM is intended to ensure interoperability between different medical applications ("application entity") .

With DICOM as an open standard , devices primarily used in medical imaging communicate independently of the system platform used or the manufacturer. A user thus has the freedom to use the devices with which he can best solve his tasks.

DICOM can also support workflows in clinics. The "worklist" implementation in radiology as well as in the laboratory area has proven itself for many years. This enables film-free work and long-term archiving in digital systems.

Declarations of Conformity

In declarations of conformity, the manufacturers of systems describe which DICOM functions their products support. A declaration of conformity is a mandatory requirement for the assertion that a device or system is "DICOM-capable". However, this does not automatically mean that the interoperability of a device is guaranteed. Normally, this can only be ensured by comparing several declarations of conformity or by means of additional documents, such as so-called IHE integration statements.

DICOM also prescribes how declarations of conformity are to be drawn up, what structure they must have and what information must be included. A user with DICOM knowledge can analyze the declarations of conformity of his devices (or the devices to be procured) and use them to make predictions about the possible data communication processes. The statements can only refer to partial implementations.

Unique Identifiers (UIDs)

DICOM identifies each information object using Unique Identifiers (UIDs). UIDs are unique worldwide according to ISO standard 9834-3. This is achieved in that every implementer has to apply for a "UID Root", a root entry on which he then builds his identifications. This means that image data can be clearly identified, and image series and entire studies are also given UIDs. DICOM's own objects such as data object descriptions and transfer syntax, with which data objects are transferred or exchanged, also have their own UID. The format of the UIDs is defined by ISO 8824, DICOM-specific information can be found in Chapter 5, Section 9 of the documentation.

DICOM file sets

DICOM does not define independent "files". The data to be exchanged can be saved as a file, but only as part of a DICOM file set. These DICOM file sets can exist on removable media, there is no standardization for DICOM file systems on hard disks or network shares - nevertheless it has become common practice among manufacturers to be able to handle individual files from DICOM file sets; these are then referred to in the jargon as "DICOM files".

In a DICOM file set, the lowest common denominator for the file system is chosen. CDs should strictly comply with the ISO 9660 standard: The file name should consist of max. eight characters (capital letters, digits) and have no file extension at all . In addition, a file named DICOMDIR must be located in the lowest directory level ("File System Root"), which in turn contains precisely defined information about the content and path of the files on the data carrier.

When dealing with DICOM file set members as independent data objects, file extensions have also become established, for example .ima, .img and .dcm. These enable simple programs to assign the file based on the file extension. However, this is not part of the DICOM standard definition.

default

history

In the course of the development of digital imaging systems at the beginning of the 1970s, especially driven by the development of the computer tomograph by Godfrey Hounsfield , the need arose to be able to exchange image data between systems from different manufacturers. In 1982 the American College of Radiology (ACR) to represent the interests of users and the National Electrical Manufacturers Association (NEMA) as the professional association of North American manufacturers founded a working group to define the exchange of digital image information.

In 1985 the first version of the ACR / NEMA standard was published, in 1988 a second and with version 3.0 from 1993 the name was changed from "ACR-NEMA" to DICOM. Since then, new revisions of the standard have appeared at regular intervals, but the term "3.0" is not used here, but rather the year of publication of the respective version. The 2019C standard is currently available.

structure

The DICOM standard, which is provided by NEMA (see web links) in the current version, consists of several parts (as of August 2011):

Part 1: Introduction and Overview (Introduction and Overview)

Part 2: Conformance (conformity)

Part 3: Information Object Definitions (information object definitions)

Part 4: Service Class Specifications (classes of service specifications)

Part 5: Data Structures and Encoding (data structures and coding)

Part 6: Data Dictionary (data dictionary)

Part 7: Message Exchange (messaging)

Part 8: Network Communication Support for Message Exchange (network communication support for data exchange )
Part 10: Media Storage and File Format for Media Interchange (storage on media and file format for media exchange)
Part 11: Media Storage Application Profiles (application profiles for storage on media)

Part 12: Media Formats and Physical Media for Media Interchange (media formats and physical media for media exchange)

Part 14: Grayscale Standard Display Function ( grayscale standard display function)

Part 15: Security and System Management Profiles (profiles for Security and System Management)

Part 16: Content Mapping Resource (auxiliary source for content mapping )

Part 17: Explanatory information (explanatory information)

Part 18: Web Access to DICOM Persistent Objects (WADO) (web access to persistent DICOM objects (WADO))

Part 19: Application Hosting (hosting of applications)

Part 20: Transformation of DICOM to and from HL7 standards (transformation of DICOM to and from HL7 standards)

Parts 9 (Point to Point Communication Support for Message Exchange) and 13 (Print Management Point-to-Point Communication Support) are no longer included in the standard.

Standardization process

The DICOM standard is still being continuously expanded today by several working groups in order to meet the ongoing development of medical, hardware and software technology. There are currently 31 working groups (as of January 2018) that expand DICOM by various sub-areas (see below). Members of the working groups are employees from medical technology manufacturers, clinics, universities and other research institutions. As an example, the current developments of the Base Standard and Radiotherapy working groups deal with the introduction of a new definition of work processes within the various domains of a clinic and the necessary introduction of new DICOM objects.

Further developments are added to the standard through so-called supplements . These are first drawn up by one or more working groups and then submitted to the Base Standard working group for review. If the extension makes sense, the supplement is assigned a number. As soon as the working groups have finalized their amendments, they are submitted to the NEMA members ( DICOM Voting Members ) who are entitled to vote. After a positive vote, the information within the addition is valid and is incorporated into the subsequent version of the DICOM standard.

Changes to the standard or errors in the documents can be submitted to the various working groups by means of a change request and are also presented to the voting members by the Base Standard working group .

Elements removed from the DICOM standard (retired) should no longer be taken into account in new implementations. In general, however, for reasons of downward compatibility, only elements are removed that conflict with other concepts of the standard or that have never or only rarely been implemented.

The working groups are:

DICOM Standards Committee
WG-01: Cardiac and Vascular Information
WG-02: Projection Radiography and Angiography
WG-03: Nuclear Medicine
WG-04: Compression
WG-05: Exchange Media
WG-06: Base Standard
WG-07: Radiotherapy
WG-08: Structured Reporting
WG-09: Ophthalmology
WG-10: Strategic Advisory
WG-11: Display Function Standard
WG-12: Ultrasound
WG-13: Visible Light
WG-14: Security
WG-15: Digital Mammography and CAD
WG-16: Magnetic Resonance
WG-17: 3D
WG-18: Clinical Trials and Education
WG-19: Dermatologic Standards
WG-20: Integration of Imaging and Information Systems
WG-21: Computed Tomography
WG-22: Dentistry
WG-23: Application Hosting
WG-24: Surgery
WG-25: Veterinary Medicine
WG-26: Pathology
WG-27: Web Technology for DICOM
WG-28: Physics
WG-29: Education, Communication and Outreach
WG-30: Small Animal Imaging
WG-31: Conformance

DICONDE

DICONDE (Digital Imaging and Communications for Non-Destructive Evaluation) is an extension of DICOM for non-destructive material testing. The patient data is replaced by component data. DICONDE is developed by ASTM International .

Definitions of terms

IOD (Information Object Definition): Information objects represent objects from the (real) medical world (e.g. patient, study, series, image) and their relationships to one another.
SC (Service Class): Service classes describe actions that can be carried out with the information objects. Examples: Store, Print, Query, Retrieval, Modality Worklist, Storage Commitment, Modality Performed Procedure Step (MPPS). It is not necessary to support all service classes in order to be able to describe yourself as "DICOM compatible". Most applications and devices only support those service classes that are necessary for their intended use.
SOP Class (Service Object Pair Class): The combination of information object and the action to be carried out with it forms a service-object pair (e.g. “save MR image”, “print ultrasound image” etc.). SOPs form the basic functional units of DICOM.
Transfer syntax: The data can be exchanged in different data representations using transfer syntaxes. They describe how numbers and image data are represented and how image data may be compressed. DICOM also uses embedded formats such as JFIF for this purpose .
SCU (Service Class User): A service class user is a device or an application that uses a service.
SCP (Service Class Provider): A service class provider is a device or an application that offers a service.
DICOM Storage Service Class: Service class, which includes the sending, receiving and saving of medical images. See also PACS (Picture Archiving and Communication System) .
DICOM Print Management Service Class: Service class, which includes printing medical images.
DICOM Worklist Management Service Class: Service class, which deals with the transfer of patient data from the input station to the respective modality (e.g. ultrasound device , CT ).
DICOM Verification Service Class: Service class, which deals with the verification of the network connection between two DICOM systems. This process is often referred to as an echo .
AE Title (Application Entity Title): "Name" of a DICOM node.

Web links

Commons : Digital Imaging and Communications in Medicine - collection of images, videos and audio files

Individual evidence

[1] varian.com

[2] thcare.de

[3] reepatentsonline.com

[4] visus.com DICOM Conformance Statement