Dicom Cleaner

[Desiderato Chouinard]

Inoticed that the local dicom database files stick around even when you delete all the patients, and will continue growing in size as more patients are added and removed. I would like to clean up these files to prevent any issues if a computer has to process many patients.

Also, it points to the sql data file in the folder. If i just assigned that to a new path with the same data file name, would it create a new file with the given name or would i have to initialize the database somehow?

Flagging images with potentially having burned in PHI is based on a well establishedrule-based approach. We know a concrete list of header fields and known locationswith PHI associated with fields in the header, and we can check these fields in anyfiles and then perform cleaning if there is a match. This approach is based on theMIRCTP functions to filter DICOMand then Anonymize.The DicomPixelAnonymizer.scriptis a rule based list of known machine and modality types, and specific locationsin the pixels where annotations are commonly found. TheBurnedInPixels.scriptis a set of filters that, given that an image passes through them, it continues processing.If it fails, then we flag it. If we look at the script above, we see the following:

We have a set of pixel functions that mirror the functionality of MIRCTP,and we take a similar approach of deriving the rules for this process from adeid recipe. Our implementeation of a DicomCleaner generally works as follows:

By default, we use a list of rules provided by CTP and other users in dicom.deid, and these are based on finding known locations based on dicom header values.With and without the ctp prefix to determine the coordinate convention used, there are two operations we can apply to coordinates:

By default, deid will start with a mask of all 1s, indicating that we keep all coordinates. We thenapply the list of rules provided by CTP and others in dicom.deidto add regions with 0s, indicating regions to be cleaned. For example, here is a rule to scrub a box of pixelsbased on finding a particular set of metadata:

In the above, we first tell deid to blank the entire mask (setting values of 0). Wethen ask to look for the dicom header SequenceOfUltrasoundRegions(it must be present), and given this condition, we look for coordinatesfrom that field, and set then to a value of 1 (keep) in our mask.These actions is added to the provided deid.dicom.ultrasound recipe, a subset shownbelow:

After detection, the flags that were triggered are saved with the client, untilyou override with another file. You can now run clean, and save theimages to a format that you like. Remember that even with flags, if there are no coordinatesassociated with the flag, no changes are done to the image.

In a recent pull request we encounteredan issue where a user had decompressed the data without changing the dicom.PixelInterpretation,which is a header that tells pydicom how to read the data. The suggested approachwhen you do dicom.decompress() is to set dicom.PhotometricInterpretation = 'RGB'after doing so:

I'm setting up conquest as a QA image server (replacing KPACS plus manual archiving). I have created a lua makefilename file so images that are sent directly from modalities can be placed into a logical human-friendly files structure for ease of subsequent analysis using a variety if tools. The makefilename script uses modalities, station names and serial numbers to work out which bit of kit/site etc each image comes from.

A good proportion of our QA images however are copied onto the server from USB or CD/DVD. I'd like to be able to 'dump' these into a folder, then run a script to import them to conquest, with the objects being moved to the locations determined by the same makefilname.lua script.

set ImportExportDragAndDrop = 1

and create a directory named "incoming" in the conquest data directory.

If you drop images in that folder the dicom images are automatically imported into conquest.

There is a right and wrong way to ensure this type of equipment is clean, especially after the pandemic. Regulations are tight, and to make your investment last, you should know the best ways to disinfect x-rays.

Daily cleaning of x-ray equipment helps to prevent exposure to blood, bodily fluids, and other materials that spread disease. Everything you do should be to protect against cross-contamination first, and then to ensure the longevity of the equipment second.

Gloves must stay on during all radiological procedures, including sterilizing and cleaning tasks. Additionally, between cleaning different systems, it also wouldn't hurt to change gloves to avoid cross-contamination of equipment.

Although some products are highly efficient cleaners, they have a dire effect on protective equipment coating. Avoid all direct sprays, brushes, water, or any immersion that may penetrate electronic objects. Also, do not use any of the following agents:

The outer layers of protective garments can be porous and regularly come into contact with objects, surfaces, and patients that may contain pathogens. If your x-ray aprons and protective clothing get dirty, they need to be cleaned as soon as possible. However, using the wrong agent or solvent can permanently damage things.

Deep cleaning and the disinfection of radiation protection garments can be done by professional x-ray garment cleaning companies like Radiological Care Services (RCS). A documented and regularly scheduled deep cleaning helps to mitigate the risk of pathogens.

Only one tool was able to de-identify all required elements with the default setting. Not all of the toolkits provide a customizable de-identification profile. Six tools allowed changes by selecting the provided profiles, giving input through a graphical user interface (GUI) or configuration text file, or providing the appropriate command-line arguments. Using adjusted settings, four of those six toolkits were able to perform full de-identification.

Only five tools could properly de-identify the defined DICOM elements, and in four cases, only after careful customization. Therefore, free DICOM toolkits should be used with extreme care to prevent the risk of disclosing PHI, especially when using the default configuration. In case optimal security is required, one of the five toolkits is proposed.

The Digital Imaging and Communication in Medicine (DICOM) standard [1] has been commonly used for storing, viewing, and transmitting information in medical imaging [2]. Because of its structure and open character it can be easily adapted and upgraded to accommodate changes in medical imaging technology [3]. DICOM was developed to ease the exchange of data between different manufacturers, but it also enables data sharing between institutions or enterprises for clinical research or clinical practice.

A DICOM file not only contains a viewable image that holds all of the pixel values but it also contains a header with a large variety of data elements. Each data element is represented by a unique tag with specific values and data types. The tag of an element is written with two hexadecimal numbers indicating its group and element number. These meta-data elements include identifiable information about the patient, the study, and the institution. Sharing such sensitive data demands proper protection to ensure data safety and maintain patient privacy.

Various applications, libraries, and frameworks have been developed for handling, viewing, transmitting, and processing DICOM data. These toolkits offer many features useful for clinical practice or clinical research purposes such as DICOM data validation, image viewing and analysis, PACS server, and converting and modifying, including de-identifying, DICOM data. Similar work examining seven free DICOM software toolkits and their ability to de-identify 38 tags that contain patient or study information using their default and modified configurations has been previously presented [7, 8].

Two scenarios were defined to perform the de-identification. First, the default setting of the tools were used, meaning that the installed tools were used to perform the process as is, without any customization. Then, customized settings were defined to obtain the best possible configuration to perform the de-identification process. For each test, the unchanged elements were observed to determine whether any of the potential identifying information was retained. The test was performed using a dummy DICOM image (Fig. 1).

All selected tools are easy to install by following a step-by-step installation wizard. Additionally, some require other supporting applications, frameworks, or runtime environments to be pre-installed, depending on what type of programming language in which they were developed. Toolkits developed using Java will need a Java Runtime to be pre-installed. A NET framework is needed for applications that are developed using C#. Some toolkits require other, more specific, applications to be pre-installed to support the complete process of reading or processing the DICOM files. For example, Tudordicom and CTP also require additional Java ImageIO Tools [27] to be present on the system to be able to read and process the compressed DICOM files. The GDCM installation under Microsoft Windows requires a Win32 OpenSSL [28] to be pre-installed, while YAKAMI needs DirectX to be present. All required pre-installations are available freely from the web from their respective manufacturers.

Using both default and customized configurations, two scenarios were performed to determine to what extent the profiles could provide a secure de-identification by observing the remaining original values of the defined 50 elements. These elements were selected based on their likelihood of being the cause of a data breach when exposed to a third party, either by the element itself or combination with other elements.

Success rate of the toolkit to de-identify fifty DICOM header elements using the advanced settings. The numbers presented in the bars are the maximum success rate obtained after customization of the de-identification settings

3a8082e126