DICOM medical image processing: Setup of aetitle in C-FIND and C-MOVE requests

Background:

Recently I went to the hospital to deploy the equipment and debug the PACS system, and encountered a strange problem.The basic scenario is: The internal network conditions of the hospital are complex. You must access the PACS server in the top-floor data center when you have installed the graphic clients in the clinics on multiple floors. At first, the firewall was shut down for debugging, And the ping between the graphic end and the PACS server on each floor was allowed, and the port was opened smoothly. However, during the deployment and debugging process, we found that "some floors can normally perform worklist queries and query/retrieve queries, while some floors can only perform worklist queries normally, query/retrieve: no image data is obtained locally after query. "After trying the next day, the system found that" The lookup end that originally conducted worklist and query/retrieve queries normally can only perform worklist queries normally, after query/retrieve query, there is no image data locally. However, if the query/retrieve query fails, the image can be downloaded miraculously ".

On-site troubleshooting:

The figure end and the PACS server have checked the connectivity between the network and the port by Using Ping and talnet commands respectively. Therefore, the network hardware environment can be ruled out. Most of the problems are the DICOM server and graph configuration. The worst is the internal system bug (the most undesirable is the system bug, ^_^ ). First, copy the log files on the PACS server and the normal graph reader, and compare and analyze the abnormal graph log files, as shown in:

Is a normal view of the image, you can see that there is a log record to save the image at the view end; while in the middle is an abnormal view of the log record at the image end, the comparison shows that the PACS server responds to the C-move request message of the graph end, that is, the C-move response, successfully arrives at the graph end, and the information stored on the image end does not appear. It is found that the C-move response information can be returned smoothly, but the image cannot be saved. Therefore, it may be because the hospital network environment restricts the transmission of image data, because the amount of video data transmitted is large, but after communicating with the network management, it is found that there is no traffic limit on the network. Therefore, the first troubleshooting attempt fails.

Since there are no restrictions on the network environment, what is the problem? In order to have a more comprehensive understanding of the problem, we decided to make statistics on the current situation of the hospital on the graphic end, hoping to find clues, So we began to troubleshoot the problem on a floor-by-floor basis. First, check the bottom floor. At this time, make sure that no one on the other floors uses the view end. After troubleshooting one by one, you can only query worklist on the graph end. query/retrieve queries still fail. If the record fails, you can view the IP address and aetitle on the graph end, it took a whole day to measure the graph connection status of multiple floors. After sorting, we found that the aetitle on the graph end of most query/retrieve query failures had a large overlap. Therefore, we can conclude that the query/retrieve query failure was mostly caused by the repetition of aetitle.

Solution:

We randomly selected two image viewing terminals with duplicate aetitle. By modifying the aetitle of the PACS server and image viewing server, we found that the problem was solved miraculously. Therefore, by observing the DICOM node database file on the PACS server, the aetitle has been modified to see the graphic end, which successfully solved the deployment.

Problem simulation:

Although the wonderful problem introduced in the background is solved on the site, the problem is not further explored. For example, since aetitle already exists, why can all view-side worklist queries be successful, but query/retrieve queries will fail? Since the query/retrieve query fails, why does the C-move response information of the PACS server appear in the log file on the Image view end? In order to conduct a comprehensive analysis of the problem and find the root cause of the problem. After returning, I decided to restore the "on-site scenario" and hoped to find the root cause of the problem by analyzing the local source code.

Use VMware to restore the site

To simulate multiple view ends and PACS servers in the same brain at the same time, we need to use the vmwarevm tool (recently popular docker seems to be able to complete similar functions, however, because the related projects are developed based on Windows, it is estimated that it is still difficult to use docker for simulation. If a great God has done similar simulation, please kindly advise ^_^ ).

1. Local simulation structure of Vmware

As shown in, two virtual machines are built using vmware workstation to simulate the visualization of duplicate aetitle on site. The pacs server of pacsserver simulation hospital is installed locally. Shows the basic simulation process,

1) using the GuestOS-1 Virtual Machine to upload a set of data to the Hostos, because the local Hostos after installing pacsserver does not store the relevant data, so the need to use GuestOS-1 upload to write a piece of data to the pacsserver database;

2) use the GuestOS-1 to query the uploaded data, test the environment pacsserver is running normally. Tests show that the pacsserver in Hostos runs normally.

Then the use of GuestOS-1 and GuestOS-2 to restore the hospital site,

3) GuestOS-1 to the server to initiate the worklist query service;

4) The GuestOS-1 can see that the patient information in pacsserver is obtained smoothly on the graph end;

5) GuestOS-2 to the server to initiate the worklist query service;

6) The GuestOS-2 can see that the patient information in pacsserver is obtained smoothly on the graph end;

7) The GuestOS-1 looks at the graph end to initiate the query/retrieve request to the server;

(8) The GuestOS-1 can smoothly obtain c-move response and image information;

9) The GuestOS-2 View to the server to initiate query/retrieve requests;

10) The GuestOS-2 can see that the image side successfully obtained C-move response, but not the image information;

At this point, the site was successfully restored and the local debugging was prepared.

2. Network Connection (LAN) between vmwarevm guestos and Hostos)

To achieve the simulation in the above structure diagram, you need to establish a connection between the guestos Virtual Machine and the Hostos. There are three network connections for vmwarevm: Bridge Mode, host-only mode, and Nat mode. Blog (http://www.cnblogs.com/xiaochaohuashengmi/archive/2011/03/15/1985084.html) and blog (http://zhaisx.iteye.com/blog/458671) have a brief introduction to the three modes, You can carefully read, here I choose the host-only mode, hostos host's VMware network adapter vmnet1 IP address is 192.168.24.1, The GuestOS-1 IP address is 192.168.24.100, The GuestOS-2 IP address is 192.168.24.200.

DICOM network source code analysis (based on mdcm)

The dicomviewer here shows that the image end and the pacsserver server use the mdcm open source library written in C. To solve the above problems, we will analyze the DICOM network related classes in the mdcm open source library and have a macro understanding of the implementation process of DICOM network services in mdcm, we hope to quickly find the root cause of the problem.

Download the mdcm source code from GitHub and use vs to open it (for example ). Find the DICOM network service folder network in mdcm. You can see that mdcm divides the implementation class of DICOM network service into two parts by client and server.

The inheritance relationships between classes in are as follows,

The implementation of the pacsserver server is used to analyze the related classes of mdcm. The analysis of the client branch is not described here. The client process is simpler than that of the server, it is mainly a process of active connection and passively receiving responses from the server, and there are few corresponding processing functions. If you are interested, you can browse the mdcm source code by yourself.

Dcmnetworkbase	Is the base class used by mdcm to implement DICOM network services. The base class network services are provided in the class, 1) Various response functions that can be reloaded, such as onreceiveechorequest/onreceiveechoresponse and onreceivecmoverequest/onreceivecmoveresponse. As a base class, each response function does not actually implement corresponding operations, but simply sends a termination response, that is, calls the sendabort function. 2) functions that send various requests and responses, such as sendechorequest/sendechoresponse, sendcmoverequest/sendcmoveresponse, cannot be overloaded. According to the requirements of DICOM network service protocol, this type of function encapsulates the corresponding sending operations and can be freely used after being derived. 3) Private, defining key process functions, suchProcess, processnetpdu, processpdatatf, processdimse. These four functions indicate the flow of information flows in the DICOM service. You cannot modify the process, but you can add your own operations to the process by reloading the corresponding request and response functions. 4) private functions that define the underlying network operation process, suchConnect. You can add your own operations to the connection process by reloading the oninitializenetwork function.
Cstoreservice	Cstoreservice is the class used by the server to respond to the C-STORE request, that is, the C-STORE-SCP class, derived from the dcmnetworkbase class, and the base class about the C-STORE request and C-ECHO request is customized. The following overload functions are implemented: 1) onreceiveassociaterequest 2) on‑ecstorerequest: The on‑ecstore delegate is called in the function. You can bind your own function to customize cstore requests. For example, writing data to a database. 3) onreceiveechorequest 4) onreceivedimsebegin 5) onreceivedimseprogress The last two functions can add their own operations before the dcmnetworkbase class processes DIMSE messages. The two functions call the oncstorerequestbegin and oncstorerequestprogress delegates. For example, you can write related logs.
Cechoservice	This class is a connection test class, which is relatively simple. The onreceiveassociationrequest and onreceiveechorequest functions are overloaded.
Dcmserver <t> Where T: dcmserivebase	This class is a generic class used by the pacsserver server. This class contains the service class members derived from dcmservicebase, and then implements the pacsserver server through the basic connection process. Functions related to the process include, 1) Common, accessible startup, shutdown, port, and other related operation functions, such as addport, start, stop, etc. 2) Private, unchangeable core process control functions,Serverproc. This function uses the select mode to receive responses from the client, and then calls the service class derived from dcmservicebae for the obtained client socket object to implement the pacsserver function. The specific functionality provided by pacsserver is t: dcmservicebase class.

From the above table, we have a basic understanding of the process for implementing the DICOM network service in mdcm. The following describes the actual implementation code of the pacsserver and the specific flow of the DICOM network service flow, as shown in:
The flow from serverproc to process to processnextpdu to processpdatatf to processdimse is the control flow implemented by mdcm for DICOM network services. Serverproc, process, processnextpdu, processpdatatf, processdimseAll are private functions in various classes mentioned in the table. The implication is that we cannot change the overall processing process at will, but the corresponding processing functions of each processing part can be customized freely. Through the above analysis, we have a deep understanding of the specific implementation of mdcm, so the next step is to analyze the root cause of the problem. For the query/retrieve request, the C-MOVE request is sent, so from the flow we can locate inside the on‑ecmoverequest function in the pacsscpimpl class, insert breakpoint, single-step debugging. The specific process is: 1) Start the pacsserver to enter the debugging mode; 2) use the dicomviewer in the GuestOS-1 Virtual Machine to initiate the query/retrieve query; 3) pacsserver to enter the onw.ecmoverequest function; start the View Graph end of the GuestOS-2 to initiate the query/retrieve request according to the same process. By comparing the member variables and local variables at the two debugging times, it is found that because the aetitle in the GuestOS-1 and GuestOS-2 are the same, the pacsserver server searches for the database at the time of retrieval. The IP address of the client corresponding to the first aetitleThen exit, so for the same aetitle in the GuestOS-1 and GuestOS-2, always in the server database in the order of the front of the view side can successfully complete the query/retrieve query request. Verified by modifying the order of GuestOS-1 and GuestOS-2 in the pacsserver Server database. There is another question: why does the dicomviewer log file in the failed GuestOS-2 receive the C-MOVE response information? Once again, follow the preceding method to go to the single-step debugging mode. When the query/retrieve request initiated by the corresponding client is sent, the sendcmoveresponse function in the dcmnetworkbase base class is used for response sending, this function sends the C-MOVE response information is According to the client socket received by the pacsserver server listening socketTherefore The Client IP address is not obtained by querying the aetitle in the server database.. So far, I have a perfect answer to this wonderful question, and I will summarize it. Although the mdcm database sends messages by querying the database to obtain the destination IP address, some directly use the client socket to obtain the IP address, it is reasonable to say that if the IP address in the socket is used directly to send messages (such as sendcmoveresponse), The aetitle in the figure can be the same, but with the extension of the hospital information system, we recommend that you set different aetitles according to the dicom3.0 standard to identify the number of terminal devices in the network. If the number of visual terminals is not enough for the hospital deployed on the site (the original design was to add the "SCU _" prefix based on the last digit of the IP address to name the visual terminals, I did not expect that there are hundreds of graphic terminals on each floor of the hospital, so the aetitle naming method with only the last part of the IP address as the suffix is repeated.) I will not find any problems in the pacsserver server program. Note: 1) the "gcdrom not loaded" error occurs when the vmwarevm installs win7.

After searching some information on the network, start winpe, format and partition the hard disk of the virtual machine, and then use the Installation Tool in winpe to install the win7 operating system on the vmwarevirtual machine.

2) Follow-up blog Introduction

Introduction to the mpps service in DICOM

Application of C # asynchronous programming mode in Fo-DICOM

Test the three network connection modes of Vmware

[Email protected]

Time:

DICOM medical image processing: Setup of aetitle in C-FIND and C-MOVE requests