A few words about the DICOM services

Even an introductory document could not be told complete without a brief description of the basic DICOM services.

Data transfer between DICOM devices

As it has been already mentioned one of the main purposes of the DICOM standard is to provide a well defined file format and a communication protocol. This file format and communication protocol is understood by DICOM devices as it is described in their DICOM conformance statement. Since the standard allows a number of different possibilities to describe data, the first step of any DICOM communication is an exchange of meta data about the format both of the connecting devices can understand.
Another important aspect of the DICOM communication between devices is the way they identify each other. There are three data that identify a DICOM device: the IP address, the port and the so called Application Entity Title, usually abbreviated as AE Title. When one tries to connect two DICOM devices the first task is to learn the three characterizing data for both of the devices in question. Say, device A has to know the data identifying, say, device B, and vice versa. The user interface through which one can enter the “partner device’s” data may be different and password protected device by device. This is why the representative of the devices to be connected have to be present or at least available.

Forwarding Data

If two DICOM devices are connected and recognize each other then in theory both can forward data to the other device. However, usually one of them plays the role of a storage and the other one is the source. However, the DICOM standard does not enforce this differentiation. Usually, when connecting one device, say A, to another one, say B, one has to tell that from the point of view of device A what is the role of device B. There are two possibilities: device A is either a storage user (device B can receive data from device A) or a storage provider (device B can send data to device A). One can look at everything from the point of view of device B. In that case the roles turn around. The following possibilities are valid:
- Device A registers device B as a Storage Provider and device B registers device A as a storage user or vice versa.
- Both device A and device B register he other one as storage user and storage provider.
It is meaningless to say the both A and B are storage users but neither of the are storage providers. Also, it is meaningless if both devices are storage provider and none are storage users.

DICOM Query and Retrieve

Following he logic of he previous paragraph one can talk about devices being query users and query providers. The user is allowed to send standard queries to the query provider and the provider will answer with a list of study identifiers. If there are studies conformant to the query in the queried device then the querying party may request the transfer of the studies in question.

The DICOM Modality Worklist

We have not yet mentioned the concept of the “DICOM Order”. Such an order usually contain patient data, a modality type and a request for certain examination procedure. Following the logic of the paragraphs above, one may say that a device is a DICOM MW (Modality Worklist) Provider. Then if another DICOM device is a DICOM MW user then this latter device may query the first one and the result is a list of requests to perform certain examinations on certain patients.
The orders may come originally from Hospital Information Systems or may be created manually on DICOM devices. Another standard the so called HL7 standard describes the communication protocols and data formats governing the communication between DICOM devices and non DICOM devices like hospital information systems. There is no room here to detail the HL7 standard.

---