DICOM
Digital Imaging and Communications in Medicine (DICOM; German Digital Imaging and Communications in Medicine ) is an open standard for storing and exchanging information in medical image data management. This information may be for example, digital images, additional information such as segmentation, surface definitions or image registrations. DICOM standardized both the format to store the data, and the communication protocol to the exchange.
Almost all manufacturers of imaging or image processing systems in medicine such as Digital X-ray, magnetic resonance imaging, computed tomography or sonography implement the DICOM standard in their products. This enabling interoperability between systems from different manufacturers in the clinical environment.
DICOM is also the basis for the digital image archiving in practices and hospitals ( Picture Archiving and Communication System, PACS ).
- 2.1 The most important services
- 7.1 history
- 7.2 structure
- 7.3 standardization process
Data format
Next data field contains DICOM (eg, information about images, reports, patients, studies, series ), the syntax and semantics of commands and messages. Furthermore, the standard establishes requirements for the description of DICOM -compliant devices and software, since for each DICOM - compatible device with a precise description of system capability must be available and published (DICOM Conformance Statement ).
A DICOM data set is a container that can contain, in addition to one or more object definitions and related information like patient name, date, device parameters or doctor 's name. The object definitions can be image data, geometric or mathematical information and treatment-related information, such as in the so-called DICOM RT objects that themselves contain only treatment data and only reference image data sets.
DICOM stores or transmits images lossless or lossy, similar to the TIFF format and the JPEG standard. It can be summed image series. The various compression methods are specified in their own transfer syntaxes.
The DICOM standard also makes it possible to define your own, so-called private objects, modules, or attributes. However, this proprietary information is no longer compatible with implementations of other manufacturers in the normal case.
The picture on the right is based on a DICOM file. To view it was converted into a standard graphics format.
Real World Information Model
DICOM summarizes data in a so-called Real World Information Model, which is divided into the stages of patient, study, series and instance. Each instance of a DICOM object therefore considers that all information in order to assign them to ( a particular stay in the hospital or a single study ) and patients of a particular series ( such as image series), study.
The uniqueness of the information is converted using unique identifiers (Unique Identifier).
Information Object Definition
All objects in DICOM are defined via a so-called Information Object Definition. It consists of several modules, which in turn contain sequences of individual attributes and attributes.
It is this distinction between objects normalized ( normalized ) and composite (composite). Normalized objects are consistent with real-world objects, while composite objects contain attributes which, although quite consistent with the real world object in conjunction, but are not directly attributable to them.
The composite objects usually common to all the following modules: SOP Common, Patient, Study, Series and equipment. Other modules vary according to modality of the object. About this, even header information modules referred to any object can be clearly assigned to a particular task.
Module definition
Module definitions are grouped DICOM attributes in logical units. For example, the patient module contains all the information the patient in question, such as name, ID, gender or age. Modules may be reused in different composite objects. In every definition of a composite object is also defined if a particular module is mandatory and must be present (M - Mandatory ) whether the presence is subject 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.
Attribute Definition
An attribute is defined for a fixed eight-digit hexadecimal number, called a Data day. The first four digits define the membership of the attribute to a particular group ( such as File Meta Information ), the other four define the element. For better readability, a DICOM Data day usually in the form ( aaaa, bbbb ) represented by a comma in the middle. Patient 's Name - - Thus the tag 0x00100010 corresponds to the decimal value 1048592 and is represented by ( 0010,0010 ).
DICOM standard attributes always have an even number of groups, where the groups are 0000, 0002, 0004 and 0006 reserved for DIMSE commands and DICOM File Sets. Odd group numbers are reserved for private data elements which may be awarded by each 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 allowed character set, or explicitly illegal characters.
Furthermore, the definition of the Value Multiplicity (VM ), ie the multiplicity of an attribute necessary. As an example, the specification of an angle within a Double String multiplicity 1 A coordinate, also of type DS, has multiplicity 3, in order to specify the position in all spatial directions.
The fourth necessary feature is the type of the element. There are the distinctions between type 1 - mandatory and content must be present - Type 2 - mandatory, but can be empty - and type 3 - not absolutely necessary. Furthermore, the types may be subject to conditions by the addition of the letter C ( "1C ", " 2C" ). It follows then that, for example, an element of type 1 actually just have to be necessarily present when defined in the accompanying description condition is to be satisfied.
While the Value Representation and Value Multiplicity remain constant, the type may change, depending on which module is used the attribute. Conditions for the types 1C and 2C may also change accordingly and thus are in the respective module definition in the description of the attribute listed individually.
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 corresponding type definitions can be found in the DICOM standard in Chapter 3. Value Representation and Value Multiplicity for all attributes are defined in Chapter 6. The definitions of the Value Representation values are "Data Structures and Encoding " section in Chapter 5.
Class of Service
The service classes defined in DICOM Standard denote different services. If these are applied to an object, they form a service group. There are the following services:
- 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, italicized classes of service are of minor importance or of equipment manufacturers not yet widely supported ).
The most important services
Benefits of DICOM for user
DICOM is to ensure interoperability between different medical applications ( "application entity" ).
With DICOM as an open standard devices communicate primarily of medical imaging regardless of system platform or the manufacturer used. A user thus has the freedom to use the device with which he can solve his tasks best.
DICOM can also support workflows in hospitals. Has proven to be here for many years, the " Worklist " implementation in radiology, as well as in laboratories. This allows a film- free working and long-term archiving in digital systems.
Conformance Statements
In conformance statements describe the manufacturer of systems that DICOM functions support their products. A Conformance Statement is a mandatory requirement for the claim that a device or system is "DICOM -compliant ". However, this does not automatically mean that the interoperability of the device is guaranteed. This can normally make only by comparing several conformance statements, or by additional documents, such as so-called IHE Integration Statements.
DICOM also dictate how Conformance Statements are to submit to what structure they must have and what information must be included. A user with DICOM knowledge can analyze (or to be procured equipment), the Conformance Statements of its devices and make predictions about the possible data communications. The statements may also relate to only part of implementations.
Unique Identifiers (UIDs )
DICOM identifies each information object by unique identifiers (UIDs ). UIDs are globally unique according to ISO standard 9834-3. This is achieved by each implementer must apply for a "UID root ", a root entry on which he bases his identifications. This image data is uniquely identifiable, even image series and entire studies ( Studies) get UIDs. The DICOM own objects such as data object descriptions and transfer syntaxes with which data objects are transferred or exchanged, also have their own UID. The format of the UID is defined by ISO 8824, DICOM - specific information, refer to Chapter 5, Section 9 of the documentation.
DICOM File Sets
DICOM does not define independent " files ". The exchanged data can be saved as a file, but only as part of a DICOM File Sets. This DICOM File Sets can exist on removable media, standardization of DICOM file systems on hard drives or network shares do not exist - yet has come to be among the manufacturers to be able to deal with individual files from DICOM File Sets; these are referred to as " DICOM files " in the jargon.
In a DICOM File Set the lowest common denominator for the file system is selected. CDs should strictly comply with the ISO9660 standard: The file name should consist of max. eight characters ( uppercase letters, digits ) are and will ever wear no file extension. In addition, must be in the lowest directory level ( " Filesystem root " ) a file named DICOMDIR are, in turn, contains well-defined information about the content and path of the files on the disk.
In dealing with DICOM File Set members as independent data objects but also extensions have been established, for example. Ima. Img and. Dcm. These allow simple programs to assign the file from the file extension. However, this is not a part of the DICOM standard definition.
Standard
History
With the development of digital imaging systems at the beginning of the 1970s, all driven by the development of the computer tomograph by Godfrey Hounsfield, the need arose image data between systems to exchange different manufacturers. Then, founded in 1982, the American College of Radiology (ACR ) represents the interests of users and the National Electrical Manufacturers Association ( NEMA) as a professional association of North American manufacturers 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 and a second with the version 3.0 from 1993 the name was changed from " ACR - NEMA " in DICOM. Since then appear at regular intervals, new revisions of the standard, but is used here not the term "3.0", but it refers to the year of publication of the respective version. Currently, the Standard 2011 is available.
Structure
The DICOM standard, ( see Related links ) is provided in the current version with the NEMA, consists of several parts (as of August 2011):
- Part 1: Introduction and Overview ( Introduction and Overview )
- Part 2: Conformance ( Compliance )
- Part 3: Information Object Definitions (Information Object Definitions )
- Part 4: Service Class Specifications ( Class of Service Specifications )
- Part 5: Data Structures and Encoding ( data structures and coding)
- Part 6: Data Dictionary ( data dictionary )
- Part 7: Message Exchange ( message exchange )
- 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 the 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 Interchange)
- 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 ( resource allocation for content )
- Part 17: Explanatory information ( explanatory information )
- Part 18: Web Access to DICOM Persistent Objects ( WADO ) ( web access to DICOM Persistent Objects ( WADO ) )
- Part 19: Application Hosting (application hosting )
- Part 20: Transformation of DICOM to and from HL7 standards (Transformation of DICOM to and from HL7 standards)
The 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.
Remediation process
The DICOM standard is still being continuously expanded by several research groups to address the continuing development of medical, hardware and software technology. Currently, there are 26 working groups (as of June 2008), extend the DICOM to different subregions ( eg, biosignals (ECG), nuclear medicine, data compression, data security, 3D, surgery, ...). Working Group members are employees of medical device manufacturers, hospitals, universities and other research institutions. As an example, the current developments of the working groups base standard and Radiotherapy deal with the introduction of a new definition of workflows within the various domains of a hospital and the consequent need for the introduction of new DICOM objects.
Further developments are added by so-called supplements to the standard. These are initially written by one or more working groups, and then submitted to the Working Group Base standard for viewing. Appears the expansion makes sense to supplement a number is assigned. Once the groups have finalized their accessories, be submitted to a vote this the voting members of NEMA (DICOM Voting Members ). After a positive vote receives the information within the additive validity and is incorporated into the next version of the DICOM standard.
Changes to the standard or errors in the documents may be obtained at the different working groups can be filed by an amendment request and also by the working group base standard submitted by voting members.
From the DICOM standard remote elements ( retired ) should not be considered for re-implementations. Generally, however, only items will be removed for reasons of backward compatibility, which is in conflict with other concepts of the standards or never or have rarely been implemented.
DICONDE
DICONDE (Digital Imaging and Communications for Non -Destructive Evaluation) is an extension of DICOM for non-destructive material testing. The patient data to be replaced by component data. DICONDE is being developed by ASTM International.