DICOM

Some of my research to have a better understanding of DICOM

DICOM is made of two main components:
1) DICOM file format
2) DICOM network protocol

These two components work together in todays healthcare imaging as a standard way.
DICOM file format:
In all of the imaging sections related to healthcare DICOM file format is being used.
All the medical images are saved in this format, medical equipment creates DICOM files, doctors use DICOM
viewers, applications for diagnose fractures have input of DICOM file format.
But what makes it specific for healthcare? This format contains more than just image. In overall it has patient’s
data (ID, Name, Sex, Age and etc.), image and also some other important data like what equipment and which
settings are used to acquisition image.

DICOM Network Protocol:

All the imaging applications are connected to the hospital network use the DICOM protocol to exchange
information, mainly for DICOM images but also patient and procedure information.
The DICOM network protocol is used to search for imaging studies in archive and retrieve image studies to the
workstation in order to display it. There are also more advanced network commands that are used to schedule
Procedure, report status, share workload between doctors and imaging devices.
The main 5 benefits of DICOM standard are:
• DICOM supports all 65,536 shades of gray (full gray scale spectrum) so excellent image quality .
• A universally adopted medical standard. All imaging devices and PACs use DICOM.
• Full support for numerous image acquisition parameters and different data types. It includes patient and device
information not just only image data.
• Complete encoding of medical data. DICOM devices use more than 2000 attributes to convey precise medical
data.
• Predictable process in the working with DICOM interfaces through any device. (As soon as you see the image you
can discover that it is the CT or Ultrasound)

IOD (Information Object Definition):

There are many IOD’s for every modality such as patient’s IOD (DOB, weight, age, sex etc.), CR image IOD, CT image
IOD, NM image IOD, Contrast IOD, Display shutter IOD, Device IOD and…
DICOM Glossary of Terms
abstract syntax
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.
association
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.
modality
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.
presentation context
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.
Installation manual for CS-7 (Sys051)
Dear Mr. Assaie

The installation of Konica Minolta application (CS-7) is now

available in persian for educational purposes.

According to your request the CS-7 installation file is attached

to this E-mail (CS-7V 1.40R00_sys
51_win10_installation_manual_persian-
pairing_attachments_process_excluded.pdf).

Best regards,
Ali Nikoomanzar.