The UID modification of the logic analysis of Dicom:dcm4chee flower

background:
Recently, due to the needs of the project, I began to frequently contact the Java-based DICOM standard implementation library, which is dcm4che. Unlike the dcmtk and fo-dicom used in the past, the dcm4che toolkit is part of the entire dcm4che project and is only used by dcm4chee as a toolkit for parsing the DICOM format, while dcm4chee is a web application hosted in JBoss AS. So it adds a lot of business layer logic inside. I encountered several problems this time in practical applications, and recorded them for later careful study and analysis.

Processing logic for duplicate data:
When I used dcmtk or fo-dicom to develop PACS related functional modules, I often used direct coverage to process the uploaded image data. At first I thought that this was also done in dcm4chee. When I checked the server log today, I discovered that dcm4chee does not duplicate the duplicate data, but directly ignores the newly uploaded data.
Here is a DICOM: dcm4chee + oviyam2.1 installed under Ubuntu14 environment as an example for testing. I use the Ubuntu virtual machine to run locally. The deployment address is: 192.168.148.149, port 8088. A set of data has been uploaded before, as shown:


Re-use the dcmsnd.bat tool to upload it locally again and check the server log output.


It can be clearly seen from the log that for the existing data, it will be ignored when uploading again. The specific implementation logic is in the org.dcm4chex.archive.dcm.storescp package of dcm4jboss-sar.

UID modification logic:
Since duplicate data cannot be uploaded, what if I need to upload two sets of data? Such scenarios exist in reality, such as the example in the A Practical Introduction and Survival Guide.
The word "Intance" is often mentioned in object-oriented applications. It is usually considered to be a specific object of a certain class, which is a snapshot of all the data of a specific object at a certain moment (Originally: Where you ever played with object-oriented applications) or not, you should be familiar with the notion of "instance". In brief, an instance is a snapshot of an object in time with all its current data values.). So modifying the object data always generates another instance. In head-side X-rays, raw data is often edited, such as sketching relevant ROI regions, compressing images, uploading to PACS backups, diagnostic reports, and so on. At this time, there are many different instances (multiple instances) corresponding to the same set of original data.

The above examples are uploaded to the dcm4chee server and cannot be stored smoothly. So how to solve this problem? We have already explained a lot about DICOM before, but the method is actually very simple. In the DICOM standard, UID (Unique Identifiers) is just like human DNA, as the unique identification of the data, so you want to store the same data (the data here usually refers to the patient information, examination information, and sequence contained in the DICOM file The information and the actual image are the same, except that the UID is different.) You can modify the UID to achieve it.
In order to verify our idea, directly use the Sante DICOM Editor tool to modify the SeriesInstanceUID of the entire sequence data of the test data zstest1, from 1.3.6.1.4.1.30071.6.979046.4296168899037731.2 to 1.3.6.1.4.1.30071.6.979046.4296168899037731.2.2.

[Note]: At this time, in order to quickly modify the method of storing the same data, each SOPInstanceUID under the Series is not modified, only the SeriesInstanceUID is modified one level.
Upload test again using dcmsnd.bat, but it failed again, as shown:

The prompt found that the verification logic behind dcm4chee was strange enough, and it was suggested that the data already existed. According to the above-mentioned four-level UID structure (for example), after modifying the SeriesInstanceUID, it should be possible to store it even without modifying the subordinate SOPInstanceUID. This is equivalent to re-opening a sequence, except that the same image is stored.


Since laziness can only be modified by modifying the SeriesInstanceUID, you have to modify the SOPInstanceUID of each file, but if you manually modify this step, the workload is huge, usually a sequence of as few as hundreds or as many as thousands of pictures. Therefore, I use dcm4che to write a program that automatically changes the three levels of StudyInstanceUID, SeriesInstanceUID, and SOPInstanceUID. The modification idea is to add a suffix to the original UID, and the suffix format is "yyyyMMdd.HHmmss" timestamp. Modify the code of StudyInstanceUID as follows:

The specific complete code blog post will give a download link at the end.

postscript:
Through this debugging, I found that the internal logic of dcm4chee is more complicated. Although I have a good understanding of the DICOM standard and I am familiar with related open source toolkits, I still encountered many problems in the actual use process. Here is a simple record of the above two "pits", and I will analyze the underlying source code implementation of dcm4chee in detail later to find out the truth behind the strange logic. Stay tuned!

Code example:
GitHub: changeUIDbyYourselfUsingDcm4che
CSDN: changeUIDbyYourselfUsingDcm4che





[email protected]
Time: 2015-06-14

DICOM: UID modification of dcm4chee's bizarre logic analysis