DICOM standard and application-DICOM message exchange and network communication

As the DICOM Standard itself is named, the main problem to be solved by DICOM is network transmission, that is, in various network hardware and software environments, how can medical images be reliably and efficiently transmitted to the desired target computer. To this end, the DICOM standard adopts the policy of adding support for medical images on the basis of a mature and standardized network environment, rather than starting from the minimum layer, in this way, existing network hardware and software resources can be used directly to promote the development and application of DICOM standards.
Level 1 DICOM network
In the formulation of DICOM standard, the TCP/IP protocol widely used in practice and the OSI network protocol with great influence are used as the basis for DICOM network support. The preceding two Protocols define the message-based Information Exchange Protocol DIMSE (DICOM message service element) of DICOM ). To maintain compatibility with previous versions, point-to-point printing is still supported. The hierarchical model 1 of DICOM network is shown in.
In this model, the rounded corner frame is defined in the DICOM standard, and the dotted box represents a specific application, which is customized by the user as needed. The box section is defined in other standards, but the DICOM standard is only used directly.
The application interface (API) between the application and DICOM application entity is not described in DICOM standards, but is determined by implementation. Generally, this API provides connections to other applications, constructs and processes SOP instances, and transfers such functions to remote applications.
For the application layer, two groups of services are provided for the application entities: the contact Control Protocol (ACSE) and the DICOM message protocol (DIMSE), which must be effective for DICOM. ACSE is a standard OSI protocol. The DICOM service of DIMSE is a part of the service provided in the application entity.
Interfaces between ACSE and DIMSE applications are DICOM interfaces described in DICOM standards. This description describes each parameter required for each function of the ACSE and DIMSE requests and is part of the DICOM application context.
The combination of TCP/IP stack and OSI application service extensions is widely used to implement DICOM through the network. Since no high-level layer is defined for TCP/IP, the application, performance, and Session Layer functions required by DICOM are combined into one layer in DICOM standard, which is called DICOM high-level layer or DUl.
DUL uses the same DICOM interface for the TCP/IP protocol stack. At the lower layer, dul has interfaces with the TCP layer. DICOM connections between application entities are mapped to a TCP connection. The presentation address maps to a TCP port number, which is combined with the IP number or host name. The combination of this IP number and the TCP port is called a set address. This combination is unique in the network.
In DICOM 3.0, point-to-point environments are reserved for compatibility with previous versions.
Ii. Working Process
For a DICOM communication, the specific process is:
● Applications send DICOM functional service requirements through APIS
● The DICOM server constructs an application entity and places API parameters in the context of the application entity
● The application entity calls the corresponding DICOM upper-layer service function according to the context functional requirements.
● The DICOM upper layer service transmits the TCP packet consisting of relevant parameters to the TCP socket
● The TCP/IP service of the operating system transmits data to the target computer through the physical network
● After receiving the information, the target computer returns the response information
The above communication process is just a very schematic summary. Due to the complex situations that may occur in the network, the actual communication process and content are cumbersome and specific. For the simplest example, we introduced the transmission syntax in the previous lecture, which defines the encoding method of the transmitted content, the byte sending order, and the image encapsulation form. DICOM communication between two computers (hosts in the Network) requires negotiation on the transmission syntax, first, the communication requestor uses the default transmission syntax to display the list of transmission syntaxes that can be used by the other party, the other party selects the appropriate transmission syntax based on its hardware, operating system, and other software, and then answers the other party's questions. In this way, the transmission syntax used in subsequent communication is determined.
The negotiation of transmission syntax is only a small part of DICOM network communication. There are many other aspects that must be determined during the communication contact process. For details, refer to the standard.
Three Data Structures
Multiple Data structures are used at different network layers of DICOM. The following describes the two main data structures.
1. Message)
In DICOM network interfaces, information is communicated through DICOM messages. A message is composed of a command set and a qualified dataset. The command set is used to specify the operations and announcements to be completed on the dataset.
A command set consists of several command elements. The command element contains the encoding values in each independent field of the command set with the DIMSE Protocol specified semantics (see 9.2 and 10.2 ). Each command element is composed of an explicit tag, value length, and value range. We have already introduced the dataset in the second lecture. We will not repeat it here. The structure of DICOM messages is shown in figure 2.
2. Protocol Data Unit (PDU)
The Protocol Data Unit (PDUS) is an information format exchanged between peer entities. It is used to send DICOM messages to each other through the DIMSE protocol. A pdu consists of Protocol control information and user data. PDUS consists of mandatory fixed fields and optional value fields followed by them. The optional value field contains one or more entries or subentries. DICOM ul protocol consists of P-DATA-TF PDU, A-ASSO-CIATION-RQ PDU, A-RELEASE-RQ PDU, A-ABORT PDU and other seven protocol data units PDUS. Structure of the A-ASSOCIATION-RQ PDU is shown in figure 3
DIMSE contact agreement
Like other communication protocols, DICOM also uses peer-to-peer views to explain and describe the protocols. The so-called peer-to-peer view means that operations by both parties are performed at the same level. For example, when the operations at the data link layer are described, the data sent is considered to be transmitted to the data link layer of the other party, the response information of the other Party also comes from the data link layer, without considering the information exchange from the data link layer of the receiver.
The connection between two application entities for information exchange is called Association ). For a contact, many communication content is determined as context, and the content can change. This change actually reflects the information exchange. This context (called the application context) is defined in the DICOM standard. Both parties must coordinate the action according to the definition of this context.
An application context is identified by a UID and passed to the other party during the contact initialization. By comparing the UID of the application context, the other party can decide whether to process the request of this contact. It can establish or reject a contact.
An application context overwrites the global function of information exchange. By association, the type of information exchange that can occur is defined by the SOP class and the service class of these SOP classes. The type of SOP recommended by the initiator to be contacted, the role and Information Representation of SCU/SCP (service user/service provider) of each SOP class, depending on the capabilities of the other party, it can accept or reject each individual SOP class.
After this negotiation, both parties know the capabilities and restrictions of the other party. The actual information exchange can be performed according to the service class and SOP class roles (defined for these classes. When the contact is no longer needed, the contact is terminated.
During the initialization process of the connection, each SOP class negotiated must reach an agreement between the two processes, involving the transmission syntax used between the two processes. The initiator recommends that all the transmission syntaxes that can be processed by specific SOP classes, and the other party selects one of them. After negotiation, the performance context accepted by both parties in the SOP category is determined.
The context of a presentation layer is identified by the number ID agreed by both parties. There may be many contexts in the context of a contact. The context ID identifies the SOP class in which information is exchanged.
The above contact information is encapsulated in the PDU and transmitted to the other party through TCP/IP and physical layer.
Conclusion 5
The DICOM network function adopts a standard low-layer structure and has a good application foundation. Due to the development of hardware technology, it can directly benefit from the improvement of network performance. This enables devices that support DICOM functions to have a long survival period and is the basis for medical information network.