DICOM consists of the following parts:
PS 3.1: Introduction and Overview (this document)
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
PS 3.10: Media Storage and File Format for Data Interchange
PS 3.11: Media Storage Application Profiles
PS 3.12: Media Formats and Physical Media for Data Interchange
PS 3.13: Retired
PS 3.14 Grayscale Standard Display Function
PS 3.15: Security Profiles
PS 3.16: Content Mapping Resource
PS 3.17: Explanatory Information
PS 3.18: Web Access to DICOM Persistent Objects (WADO)
PS 3.19: Application Hosting
PS 3.20: Transformation of DICOM to and from HL7 Standards
These parts of the Standard are related but independent documents. A brief description of each Part is provided in this section.
PS 3.2 of the DICOM Standard defines principles that implementations claiming conformance to the Standard shall follow:
— Conformance requirements. PS 3.2 specifies the general requirements which must be met by any implementation claiming conformance. It references the conformance sections of other parts of the Standard.
— Conformance Statement. PS 3.2 defines the structure of a Conformance Statement. It specifies the information which must be present in a Conformance Statement. It references the Conformance Statement sections of other parts of the Standard.
PS 3.2 does not specify a testing/validation procedure to assess an implementation's conformance to the Standard.
Figures 6.2-1 and 6.2-2 depict the construction process for a Conformance Statement for both network communication and media exchange. A Conformance Statement consists of the following parts:
— Set of Information Objects which is recognized by this implementation
— Set of Service Classes which this implementation supports
Set of communications protocols or physical media which this implementation supports
Set of security measures which this implementation supports.
Figure 6.2-1CONSTRUCTION PROCESS FOR A NETWORK CONFORMANCE CLAIM
Figure 6.2-2CONSTRUCTION PROCESS FOR A MEDIA CONFORMANCE CLAIM
PS 3.3 of the DICOM Standard specifies a number of Information Object Classes which provide an abstract definition of real-world entities applicable to communication of digital medical images and related information (e.g., waveforms, structured reports, radiation therapy dose, etc.). Each Information Object Class definition consists of a description of its purpose and the Attributes which define it. An Information Object Class does not include the values for the Attributes which comprise its definition.
Two types of Information Object Classes are defined: normalized and composite.
Normalized Information Object Classes include only those Attributes inherent in the real-world entity represented. For example the study Information Object Class, which is defined as normalized, contains study date and study time Attributes because they are inherent in an actual study. Patient name, however, is not an Attribute of the study Information Object Class because it is inherent in the patient on which the study was performed and not the study itself.
Composite Information Object Classes may additionally include Attributes which are related to but not inherent in the real-world entity. For example, the Computed Tomography Image Information Object Class, which is defined as composite, contains both Attributes which are inherent in the image (e.g. image date) and Attributes which are related to but not inherent in the image (e.g. patient name). Composite Information Object Classes provide a structured framework for expressing the communication requirements of images where image data and related data needs to be closely associated.
To simplify the Information Object Class definitions, the Attributes of each Information Object Class are partitioned with similar Attributes being grouped together. These groupings of Attributes are specified as independent modules and may be reused by other Composite Information Object Classes.
PS 3.3 deines a model of the Real World along with the corresponding Information Model that is reflected in the Information Object Definitions. Future editions of this Standard may extend this set of Information Objects to support new functionality.
To represent an occurrence of a real-world entity, an Information Object Instance is created, which includes values for the Attributes of the Information Object Class. The Attribute values of this Information Object Instance may change over time to accurately reflect the changing state of the entity which it represents. This is accomplished by performing different basic operations upon the Information Object Instance to render a specific set of services defined as a Service Class. These Service Classes are defined in PS 3.4 of the Standard.
PS 3.4 of the DICOM Standard defines a number of Service Classes. A Service Class associates one or more Information Objects with one or more Commands to be performed upon these objects. Service Class Specifications state requirements for Command Elements and how resulting Commands are applied to Information Objects. Service Class Specifications state requirements for both providers and users of communications services.
PS 3.4 of the DICOM Standard defines the characteristics shared by all Service Classes, and how a Conformance Statement to an individual Service Class is structured. It contains a number of normative annexes which describe individual Service Classes in detail.
Examples of Service Classes include the following:
— Storage Service Class
— Query/Retrieve Service Class
— basic Worklist Management Service Class
— Print Management Service Class.
PS 3.4 defines the operations performed upon the Information Objects defined in PS 3.3. PS 3.7 defines the Commands and protocols for using the Commands to accomplish the operations and notifications described in PS 3.4.
PS 3.5 of the DICOM Standard specifies how DICOM applications construct and encode the Data Set information resulting from the use of the Information Objects and Services Classes defined in PS 3.3 and PS 3.4 of the DICOM Standard. The support of a number of standard image compression techniques (e.g., JPEG lossless and lossy) is specified.
PS 3.5 addresses the encoding rules necessary to construct a Data Stream to be conveyed in a Message as specified in PS 3.7 of the DICOM Standard. This Data Stream is produced from the collection of Data Elements making up the Data Set.
PS 3.5 also defines the semantics of a number of generic functions that are common to many Information Objects. PS 3.5 defines the encoding rules for international character sets used within DICOM.
PS 3.6 of the DICOM Standard is the centralized registry which defines the collection of all DICOM Data Elements available to represent information, along with elements utilized for interchangeable media encoding and a list of uniquely identified items that are assigned by DICOM.
For each element, PS 3.6 specifies:
— its unique tag, which consists of a group and element number
— its name
— its value representation (character string, integer, etc)
its value multiplicity (how many values per attribute)
whether it is retired
For each uniquely identified item, PS 3.6 specifies:
its unique value, which is numeric with multiple components separated by decimal points and limited to 64 characters
its type, either Information Object Class, definition of encoding for data transfer, or certain well known Information Object Instances
in which part of the DICOM Standard it is defined
PS 3.7 of the DICOM Standard specifies both the service and protocol used by an application in a medical imaging environment to exchange Messages over the communications support services defined in PS 3.8. A Message is composed of a Command Stream defined in PS 3.7 followed by an optional Data Stream as defined in PS 3.5.
PS 3.7 specifies:
— the operations and notifications (DIMSE Services) made available to Service Classes defined in PS 3.4,
— rules to establish and terminate associations provided by the communications support specified in PS 3.8, and the impact on outstanding transactions
— rules that govern the exchange of Command requests and responses
— encoding rules necessary to construct Command Streams and Messages.
PS 3.8 of the DICOM Standard specifies the communication services and the upper layer protocols necessary to support, in a networked environment, communication between DICOM applications as specified in PS 3.3, PS 3.4, PS 3.5, PS 3.6, and PS 3.7. These communication services and protocols ensure that communication between DICOM applications is performed in an efficient and coordinated manner across the network.
The communication services specified in PS 3.8 are a proper subset of the services offered by the OSI Presentation Service (ISO 8822) and of the OSI Association Control Service Element (ACSE) (ISO 8649). They are referred to as the Upper Layer Service, which allows peer applications to establish associations, transfer messages and terminate associations.
This definition of the Upper Layer Service specifies the use of the DICOM Upper Layer Protocol in conjunction with TCP/IP transport protocols.
The TCP/IP communication protocol specified by PS 3.8 is a general purpose communication protocol not specific to the DICOM Standard. Figure 5-1 shows this protocol stack.
PS 3.9 of the DICOM Standard previously specified the services and protocols used for point-to-point communications in a manner compatible with ACR-NEMA 2.0. It has been retired.
PS 3.10 of the DICOM Standard specifies a general model for the storage of medical imaging information on removable media (see Figure 6.10-1). The purpose of this Part is to provide a framework allowing the interchange of various types of medical images and related information on a broad range of physical storage media.
Note: See Figure 5-1 for understanding how the media interchange model compares to the network model.
PS 3.10 Specifies:
— a layered model for the storage of medical images and related information on storage media. This model introduces the concept of media storage application profiles, which specify application specific subsets of the DICOM Standard to which a media storage implementation may claim conformance. Such a conformance applies only to the writing, readin and updating of the content of storage media.
— a DICOM file format supporting the encapsulation of any Information Object;
— a secure DICOM file format supporting the encapsulation of a DICOM file format in a cryptographic envelope;
a DICOM file service providing independence from the underlying media format and physical media.
PS 3.10 defines various media storage concepts:
a) the method to identify a set of files on a single medium
the method for naming a DICOM file within a specific file system
Figure 6.10-1DICOM Media Communication Model
PS 3.11 of the DICOM Standard specifies application specific subsets of the DICOM Standard to which an implementation may claim conformance. These application specific subsets will be referred to as Application Profiles in this section. Such a conformance statement applies to the interoperable interchange of medical images and related information on storage media for specific clinical uses. It follows the framework, defined in PS 3.10, for the interchange of various types of information on storage media.
An Application Profile annex is organized into the following major parts:
a) The name of the Application Profile, or the list of Application Profiles grouped in a related class
A description of the clinical context of the Application Profile
The definition of the media storage Service Class with the device roles for the Application Profile and associated options
Informative section describing the operational requirements of the Application Profile
Specification of the Information Object Classes and associated Information Objects supported and the encoding to be used for the data transfer
f) The selection of media formats and physical media to be used
g) Other parameters which need to be specified to ensure interoperable media interchange
h) Security parameters which select the cryptographic techniques to be used with secure media storage Application Profiles
The structure of DICOM and the design of the Application Profile mechanism is such that extension to additional Information Object Classes and the new exchange media is straightforward.
Note: Figure 6.11-1 shows how individual aspects of an Application profile map to the various parts of the DICOM Standard.
Figure 6.11-1 Relationship Between and Application Profile and Parts of DICOM
This part of the DICOM Standard facilitates the interchange of information between applications in medical environments by specifying:
a) A structure for describing the relationship between the media storage model and a specific physical media and media format.
b) Specific physical media characteristics and associated media formats.
PS 3.13 previously specified the services and protocols used for point-to-point communication of print management services. It has been retired.
PS 3.14 specifies a standardized display function for consistent display of grayscale images. This function provides methods for calibrating a particular display system for the purpose of presenting images consistently on different display media (e.g. monitors and printers).
The chosen display function is based on human visual perception. Human eye contrast sensitivity is distinctly non-linear within the luminance range of display devices. This standard uses Barten’s model of the human visual system.
PS 3.15 of the DICOM Standard specifies security and system management profiles to which implementations may claim conformance. Security and system management profiles are defined by referencing externally developed standard protocols, such as DHCP, LDAP, TLS and ISCL. Security protocols may use security techniques like public keys and “smart cards”. Data encryption can use various standardized data encryption schemes.
This part does not address issues of security policies. The standard only provides mechanisms that can be used to implement security policies with regard to the interchange of DICOM objects. It is the local administrator’s responsibility to establish appropriate security policies.
PS 3.16 of the DICOM Standard specifies:
— templates for structuring documents as DICOM Information Objects
— sets of coded terms for use in Information Objects
— a lexicon of terms defined and maintained by DICOM
country specific translations of coded terms
PS 3.17 of the DICOM Standard specifies:
— informative and normative annexes containing explanatory information
PS 3.18 of the DICOM Standard specifies the means whereby a request for access to a DICOM persistent object can be expressed as an HTTP URL/URI request that includes a pointer to a specific DICOM persistent object in the form of its Instance UID.
The request also specifies the format of the result to be returned in response to the request.
(MIME) Content-type, e.g., application/dicom or image/jpeg for images, application/dicom or application/rtf or xml for reports
reports as HL7/CDA Level 1
The parameters of the query URL as defined within this standard are sufficient for the HTTP server to act as a DICOM SCU (Service Class User) to retrieve the requested object from an appropriate DICOM SCP (Service Class Provider) using baseline DICOM functionality as defined in PS 3.4 and PS 3.7.
PS3.19 of the DICOM Standard specifies an Application Programming Interface (API) to a DICOM-based medical computing system into which programs written to that standardized interface can ‘plug-in’ (see Figure 6.19-1). A Hosting System implementer only needs to create the standardized API once to support a wide variety of add-on Hosted Applications.
Figure 6.19-1. Interface between a Hosted Application and a Hosting System
In the traditional ‘plug-in’ model, the ‘plug-in’ is dedicated to a particular host system (e.g. a web browsing program), and might not run under other host systems (e.g. other web browsing programs). PS3.19 defines an API that may be implemented by any Hosting System. A ’plug-in’ Hosted Application written to the API would be able run in any environment provided by a Hosting System that implements that API (see Figure 6.19-2).
Figure 6.19-2. Illustration of platform independence via the Hosted Application architecture.
PS3.19 specifies both the interactions and the Application Programming Interfaces (API) between Hosting Systems and Hosted Applications. PS3.19 also defines the data models that are used by the API.
PS 3.20 of the DICOM Standard specifies:
— Transformations of DICOM data to and from HL7 standards
Hosted Application (Plug
Hosting System (e.g. Medical Workstation)