DICOM medical image processing: Comprehensive Analysis of the Communication Service Module in dicom3.0

Background:

Recently, I have been debugging the worklist query between the PACS terminal and the RIS system. Therefore, I have read the network transmission section in dicom3.0, here I will summarize the work of this week, in order to deepen the understanding of the dicom3.0 standard, from the bottom layer a clearer understanding of worklist query, C-store, C-FIND and other services.

Key points: 1) Abbreviation

Many common terms are abbreviated in this section. Therefore, to better understand the meaning of the terms, the full names corresponding to the terms are given first. There are two reasons why Chinese characters are not used for translation, first, the English version is very simple and clear, and second, it is because the dicom3.0 standard does not have an official Chinese version, so I do not dare to perform translation.

Common abbreviations and their full names are as follows:

ACSE: Association Control Service Element

AE: Application entity

CMIS: Common Management Information Service

Cmise: Common Management Information Serivce Element

DICOM: Digital Imaging and communications in medicine

DIMSE: DICOM messsage Service Element

DIMSE-C: DICOM message service element-Composite

DIMSE-N: DICOM message service element-normalized

HL7: Health Level 7

OSI: Open Systems Interconnection

PDU: Protocol Data Unit

PDV: Protocol Data Value

Sop: service object pair

TCP/IP: Transmission Control Protocol/Internet Protocol

DUL: DICOM upper layers

2) DICOM network communication model

DICOM network services are end-to-end communication services built on the traditional OSI Layer-7 model, including servers and clients. Shows the basic communication service model:

Compared with the traditional OSI Layer-7 model, we can see that the DICOM network communication service described in dicom3.0 does not include a simple layer in the OSI Layer-7 model, instead, the layers from the transport layer/network layer are described and defined in detail. In the next section, I will detail the layers or modules of the DICOM network communication service based on the dicom3.0 standard.

3) Description of DICOM network communication in dicom3.0

The following figure shows the dicom3.0 standard. First, we have a general understanding of the dicom3.0 standard, as shown below:

The figure on the right shows that the DICOM communication model is built on the TCP/IP layer, and the bottom layer isDICOM upper layer protocol, This part is mainly responsible for connecting to TCP, above which is the dicom3.0 StandardDICOM Communication ModelThe DICOM Communication Model coversSession, presentation, and Application).Session Layer)It is mainly responsible for establishing communication methods for both parties and creating and canceling sessions. This part corresponds to Part 1 of the dicom3.0 standard, that isACSE (Association Control Service Element);Presentation layer (presentation)It can provide different clients with syntax conversion incodes for data and information, so that the system can interpret the data correctly. It also supports compression, decompression, encryption, and decryption. CorrespondinglyDIMSE ServiceThat is, part 1 of the dicom3.0 standard (C-store, C-find, C-Get, C-move, C-ECHO.

The left is in the rightDICOM upper layer serviceThe detailed structure of the above service also shows the corresponding parts of dicom3.0. A more comprehensive structure is provided below:

After a simple combination of the dicom3.0 standard, the name of the module corresponding to each layer in the DCMTK source code library is also given, the short name also shows how the entire DICOM network communication is completed. Several files related to DICOM Communication Service are as follows:DIMSE. H, Assoc. H, dul. h(Sequentially follow the OSI Layer-7 model from top to bottom .)DIMSE. hThe DIMSE layer information structure (suchT_dimse_message, t_dimse_c_echorq, t_dimse_c_echorspAnd functions of various services (suchDimse_echouser, dimse_sendechoresponse, dimse_storeuser, dimse_storeprovider).DIMSE. hAll service functions defined in the file have a network connection parameter.T_asc_association * assocSuch:

From the parameter type, you can guess that this type is defined inAssoc. hFile (for example ),Assoc. hNote that the file provides connection management for DICOM network applications (Association ManagementAll structures defined in the file are created to support connections (for exampleIndicates context, abstract semantics, transmission semantics, and maximum PDU length.And so on ). At the same time, the file also pointed out that the function is implemented using the DICOM upper layer service. WhileT_asc_associationStructure indicates an activity link.

Since the assoc. h header file indicates that this module is implemented on the basis of DICOM upper layer, you can guess that the source code implementation of various functions linked must be called.DUl. hFunction in the file.Asc_initializenetworkFor example, as shown in, the function is directly called internally.Dul_initializenetworkFunction, presumably, if we continue to follow the above analysis, we will certainly see the TCP layer function, that is, our commonly usedSocket socket function(If you like it, you can view it on your own.DUl. hSource code of the function, suchDul_initializenetworkFunctionInitializenetworktcpThe function directly uses common socket operation functions, suchSocket establish socket function,Setsockopt,Bind a socket functionAnd so on)

Now, by viewing the source code of the DCMTK open source library, we have a more intuitive understanding of the overall structure, so that we can have a better understanding of the dicom3.0 standard.

Actual engineering test:

After viewing the DCMTK source code design, in order to better understand the DICOM network communication process, taking the worklist query service between the common PACS and RIS system and the C-STORE image storage service of DICOM as an example, the real data packets of the server and client communication are captured and analyzed, in this way, we can better and more intuitively understand DICOM communication services.

1) test tool:

To simulate the DICOM communication model, we naturally need to construct the service and the client's two ends. The bin of the dcmtk open source Library provides us with a good tool. The tools used here are divided into two types:

Server	Client
Wlmscpfs.exe	Findscu.exe
Storescp.exe	Storescu.exe

In addition, to match the structure of the DICOM network service in dicom3.0 (for exampleDIMSE, PDUAnd commands (A-Association, C-FINDThen, the captured data packets are saved into a pcap file, and then the powerful statistical analysis function of Wireshark is used for intuitive comparison and analysis.

Local Loop packet capture tool	Rawcap.exe
Data Packet Analysis and viewing tools	Wireshark

2) Communication Process Analysis of the worklist query service

Step 1: Start the routing capture tool. rawcap.exe 5 dumpfile.pcap(you can use rawcap.exe -hto use rawcap.exe)

Step 2: Start the worklistserver program. wlmscpfs.exe-D 104-DFP wlistdb> worklist-server.txt(save the worker information to worklist-server.txt using shell's redirection)

Step 3, start workistquery client program, findscu.exe-D 127.0.0.1 104 testqry. WL-AEC offis> worklist-client.txt (testqry. WL file is the previous Blog Post published)

.

Note::Sometimes, if you use redirection to output debugging information to a text file, an interruption error occurs. Therefore, you can directly display the result in the console window and manually copy it to the corresponding file.. My operations on the local machine are shown in:

So far, the entire data capture and information record task has been completed, and the next step is our analysis phase.

FirstUse the text editor to open two debugging information text files. The local results are shown in:

The debugging information also provides the desired data, for exampleA-associate-AC, A-associate-RQ, DIMSE message. The yellow arrows in the edge attachment indicate the order of the layers of the data flow when the two ends (that is, two dicom AE) are actually communicating, which is similar to that in OSI. On the way, the red rectangular boxes indicate 1, 2, 3, and 4 as the DICOM protocol layer (AssociationFrom the data, we can see that the association layer has some underlying structures (suchPDU, PDV). The blue box indicates the DIMSE protocol layer, which mainly defines various DICOM services, suchC-store, C-FIND.

Then, we use Wireshark to open the dumpfile. pcap packet file.

With the filtering of protocols, we only observe the related data packets of DICOM protocol (if you are interested, you can analyze all the data packets throughout the process ). As shown in, you can clearly see the interaction process between the findscu client and the worklist server. Double-click the first interaction information, as shown in:

In this figure, we can clearly see the complete data packet in the association layer, as shown in the total red circle, 01 represents the ASSOCIATE-RQ PDU type, what follows is the fields specified in dicom3.0 Part 1 Table 9-11.

3) C-STORE service provider (SCP), user (SCU) Communication Process Analysis

The test process of this part is the same as that of worklist query in 2.

Step 1: Start the routing capture tool. rawcap.exe 5 dumpfile.pcap(you can use rawcap.exe -hto use rawcap.exe)

Step 2: Start the storescpserver program. storescp.exe-D 104-AET offis> storescp.txt(use shell's redirection to save the tracing information to storescp.txt)

Step 3: Start the storescurequest client program. storescu.exe-D 127.0.0.1 104-F test. DCM-AEC offis> storescu.txt (test. DCM is a standard DCM file)

.

The analysis process is also the same as that in 2). Here we will not elaborate on it. Only the result graph is provided.

[Note ]:

The above tool solves the problem that the previous blog failed to use fo-DICOM to send C-find to query worklist. The specific troubleshooting process is to first use the DCMTK open-source toolkit for simulation, then use the tool to capture the data packet analysis results, and then switch to the fo-DICOM environment when the determination is correct, the cause of the packet capture analysis error is the same. Then, debug the code to the createworklistquery function of C-find in the open-source fo-DICOM library. The cause of the problem is determined. For more information, see my GitHub: https://github.com/zssure-thu/fo-dicom. I have recorded the code for this modification in this branch for further confirmation.

The specific files in the blog post have been uploaded to csdn,Link: http://download.csdn.net/detail/zssureqh/7870789

[Email protected]

Time:

DICOM medical image processing: Comprehensive Analysis of the Communication Service Module in dicom3.0