Absolutely! In fact, we prefer that you try Dicominator before buying it. We are all about solving problems, and we only want you to buy it if it helps solve some of your problems.

Dicominator is a software application that supports two primary workflows: 1. PACS analytics 2. Preparing your DICOM data for use in clinical trials. See below for more details.

• What is PACS analytics? Oftentimes, an MD will come to a PACS admin and ask that these 10,000 MRIs get sent to their S3 bucket de-identified and all slices with slice thickness greater than 5 mm filtered out. Dicominator can do this easily, but in addition, Dicominator can generate a report of all the files that make up the 10,000 MRIs (say 10,000,000 files) and easily show the accession number, the study instance uid, the SOP image uid, and the slice thickness (or whatever else you want to show) so that the MD can refine their request based on the data. Do they really want 4,000,000 of the 10,000,000 slices filtered out? Maybe, but maybe not, and having this detail empowers the PACS admins and the MDs to make better decisions. More broadly, Dicominator gives you a level of reporting capabilities that is hard for most PACS. Want to know the number of low dose lung CTs of 35 - 45 year old females in your PACS? No problem. Want to know the number of studies done by year for the last 10 years sub-totaled by modality? No problem.

• What is preparing your DICOM data for use in clinical trials? For research purposes, medical images need to be moved from PACS to any number of places for any number of reasons. An example is that studies/medical images need to be sent to a CRO where central reads are conducted. Getting a study ready to leave the hospital network is a critically important part of the process that is often not done well. There are three main steps to cleaning and prepping the data: #1 de-identification, #2 enrichment, and #3 normalization. De-identification has two parts: tag de-id and pixel de-id. Dicominator supports both. Enrichment means writing the patient's subject id to the appropriate group 12 tag (0012,0040), the site id to the appropriate group 12 tag (0012,0030), and the visit description to the appropriate group 12 tag (0012,0051). There are many variations to what is needed for enrichment, and the extensible customizability of Dicominator gives you powerful capabilities to support multiple different trial requirements simultaneously. Normalization means standardizing elements of the DICOM to comply with the trial's protocol. An example is transfer syntax. Dicominator has robust transcoding capabilities that can change each file's transfer syntax to whatever the trial's protocol requires. As Dicominator supports C-STORE, C-FIND, and C-MOVE, PACS admins can simply find the study they want to send and send it to Dicominator. After moving through Dicominator, Dicominator can automatically C-STORE the data directly to your image exchange platform (PowerShare, Ambra Health, etc), sending the data to where it needs to go. PACS admins can do all of the above with a single click!

Dicominator is a local application that typically sits inside your network within your firewall. It can also be used effectively in your cloud environment (AWS, Azure, GCS, etc). From a workflow standpoint, Dicominator usually sits between your PACS and your image exchange platform. As Dicominator supports writing data to AWS, Azure and GCS directly, you do not need an image exchange platform for some workflows.

At this time, Dicominator is a Windows application. It works with Windows 10/11 and Windows Server 2022.

Ultimately, it depends what you are looking to do, but for many uses of Dicominator, 16 GB RAM, a core i5 or i7 processor, and 250 GB of storage is plenty. If you are using Dicominator as an analytics layer for your PACS store, you will need more storage. We can help you spec out custom requirements depending on how big your PACS store is.

We prefer to jump on a web meeting and work with you directly. However, you can also send us your config file and describe the problem. We can tie your config file to our Dicominator, figure out what is going on, and update your config to solve the problem!

Yes! We built a simulation function directly into Dicominator. Drop a DICOM into a specified file path, and Dicominator will simulate exactly what your configuration would do. By simulate exactly, we mean it will show you the before and after tag values and the before and after pixel masking. How sweet is that!

Absolutely! Dicominator supports different trial level configurations simultaneously.

Yes! Dicominator has robust logging in the Activity section of the application. Pick a date range, the level of logging, and search for your study instance UID. Everything that happened to your file is captured in the logs.

Yes, 100%.

Dicominator supports the ability to add custom masks. For example, some hospitals put a cover sheet on all outside images that includes PHI like name, dob, MRN, gender, and phone. Typically, these cover sheets have a different modality than the study itself (i.e. OT vs MR), and rules can be configured into your Dicominator to apply custom masks to these images. Other examples include:

• Organizations scanning reports, dose reports, referral documents, and check-in documents. Typically, these are in the last series, and almost always their modality is different from the study’s modality (i.e. OT vs CT). We recommend putting in the following rule: if the images in the last series are a different modality than the other images in the study, remove these images from the study.

• Applying hospital specific dog tags to the lower right of all images done at a facility. We have seen this done by University of Wisconsin images. Not sure why they do this. Hopefully, they don’t do it any longer.

We know that hospitals and imaging centers do different things when they create medical studies. One of the techniques we use is to search and destroy all other tag values in the file before destroying the source tag value itself. For example, if a patient’s MRN is 7810537 in the 0010,0020 tag, before deleting 7810537, we search all other tags in the file, and if we find 7810537 anywhere, we delete it wherever it is. Once we have deleted 7810537 wherever else it exists, we delete 7810537 in the 0010,0020 tag.

• 0010,0010 - patient name

• 0010,1001 - other patient names

• 0010,1002 - other patient IDs sequence

• 0010,1000 - other patient IDs

• 0010,1060 - patient mother birth name

• 0010,0020 - patient id

• 0010,0030 - patient birth date

• 0010,0040 - patient gender

• 0008,0050 - accession number

• 0008,1030 - study description

• 0008,103E - series description

• 0008,0018 - SOP instance uid

• 0010,21B0 - additional patient history

• 0018,0015 - body part examined

• 0020,000D - study instance uid

• 0020,000E - series instance uid

• 0012,0040 - subject (for a clinical trial)

• 0012,0010 - sponsor (for a clinical trial)

• 0012,0030 - site id (for a clinical trial)

• 0012,0051 - visit description

• 0018,0050 - slice thickness

• 0018,0088 - spacing between slices

• 0020,0010 - study id

Yes! Our recommendation can be found here. This configuration uses the de-id profiles outlined in “Digital Imaging and Communications in Medicine (DICOM) Supplement 142: 10 Clinical Trial De-identification Profiles” (an excellent starting point) with a few adjustments. For example, we don't think it makes sense to remove series description (0008,103E) or study description (0008,1030).

Please also see our DICOM and HL7 Resources page for additional sources.

We use FO-DICOM. We think it is excellent, and we love that it is actively maintained.