DICOM Glossary of Terms
Describes the services that DICOM applications can render to each other; they encode SOPs supported on the communicating AEs.
Generally equivalent to a SOP class, the specification used to define the information to exchange in a message; does not represent a specific instance of the data object, but rather a class of similar data objects that have the same properties. Examples: MR image storage, CT image storage, MWL.
application entity (AE)
Uniquely identifies a DICOM device or program. Typically labeled with numbers and uppercase characters only.
An end point of a DICOM information exchange, including the DICOM network or media interface software; that is, the software that sends or receives DICOM information objects or messages. A single device may have multiple application entities.
application entity title (AET)
The externally known name of an application entity, used to identify a DICOM application to other DICOM applications on the network.
A network communication channel set up between application entities; the DICOM network data exchange between SCU and SCP peers. Each network transfer begins with an association establishment — a DICOM handshake.
DICOM association rules define the low-level protocols for DICOM network connectivity to ensure that two communicating DICOM applications (AEs) are compatible and transfer data in a well-defined format and order.
called AE title
This parameter identifies the application entity that shall contain the intended acceptor of the A-ASSOCIATE service. It is based on the destination DICOM application name. The called AE title may or may not be the same as the receiver address present in DICOM messages exchanged over the association. Note: It is the responsibility of the UL User that received the A-ASSOCIATE-RQ to verify whether the Called AE Title is its (or one of its) DICOM Application Name(s).
calling AE title
This parameter identifies the Application Entity (AE) that shall contain the requestor of the A-ASSOCIATE service. It is based on the Source DICOM Application Name. The relationship between DICOM Application Names and AE titles is specified in Annex C. The Calling AE title may or may not be the same as the Initiator Address present in DICOM Messages exchanged over the association. Note: It is the responsibility of the UL User that received the A-ASSOCIATE-RQ to verify whether the Calling AE Title is one of its known remote DICOM Application Names.
data dictionary element
A unit of information as defined by a single entry in the data dictionary. An encoded Information Object Definition (IOD) Attribute that is composed of, at a minimum, three fields: a Data Element Tag, a Value Length, and a Value Field. For some specific Transfer Syntaxes, a Data Element also contains a VR Field where the Value Representation of that Data Element is specified explicitly.
A device that communicates using the DICOM standard.
picture archiving and communication system (PACS)
A system that acquires, transmits, stores, retrieves, and displays digital images and related patient information from a variety of imaging sources and communicates the information over a network.
Set of DICOM network services used over an association, as negotiated between application entities; includes abstract syntaxes and transfer syntaxes.
Each network transfer begins with an association establishment (DICOM handshake), when the two connecting applications exchange information about each other. This information is called the presentation context; if the two applications can match their contexts, they can connect and start SCU-SCP processing.
radiology information system (RIS)
System used by radiology departments to store, manipulate, and distribute patient radiological data and imagery. The system generally comprises of patient tracking and scheduling, result reporting, and image tracking capabilities.
service class provider (SCP)
Role of an application entity that provides a DICOM network service; typically, a server that performs operations requested by another application entity (Service Class User). Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve SCP), Radiology Information System (modality worklist SCP).
service class user (SCU)
Role of an application entity that uses a DICOM network service; typically, a client. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image query/retrieve SCU).
service-object pair (SOP)
The pairing of compatible DICOM data and commands.
services and objects. IODs define DICOM data and DIMSE services define DICOM commands
service-object pair (SOP) class
The specification of the network or media transfer (service) of a particular type of data (object); the fundamental unit of DICOM interoperability specification. Examples: verification, CT image storage, print job.
service object pair (SOP) instance
An information object; a specific occurrence of information exchanged in a SOP Class. Example: a specific x-ray image.
transfer syntax (standard and private)
Encoding used for exchange of DICOM information objects and messages. Allows application entities to unambiguously negotiate the encoding techniques they are able to support (for example, data element structure, byte ordering, compression), thereby allowing these application entities to communicate.
See “ DICOM Transfer Syntax” for a table of standard values. Manufacturers may also define private transfer syntax values for use among their own devices.
unique identifier (UID)
A globally unique dotted decimal string of characters that identifies a wide variety of items. Identifies object instances.
DICOM networking uses UIDs to encode various transactions types. Examples: SOP class and transfer syntax values.
value multiplicity (VM)
Specifies the number of values that can be encoded in the value field of that data element.
value representation (VR)
Format type of an individual DICOM data element, such as text, an integer, a person’s name, or a code. DICOM information objects can be transmitted with either explicit identification of the type of each data element (Explicit VR), or without explicit identification (Implicit VR). With Implicit VR, the receiving application must use a DICOM data dictionary to look up the format of each data element.