Assign tag from file path?

[Mike Lunney]

Hi all,

I apologize in advance for my technical ignorance; I don't have much experience with javascript or xml, so I'm hoping that my problem may be a simple solution for someone more knowledgeable. 

In a nutshell, I'm trying to use CTP to fully anonymize a locally stored DICOM dataset that does not have consistent, reliable identifiers anywhere in the metadata. I would like to associate images with the name of the directory in which the files reside, which is also the subject's ID number. Beginning the anonymization pipeline with the ArchiveImportService and assigning the fsName to a DICOM tag seems promising, though I'm not sure how I should enter this field.

The treeRoot is /Users/Mike/Desktop/SampleImages. Directory structure within that is /SampleImages/1001/*.dcm, /SampleImages/1002/*.dcm, etc. I would like to take the study number (1001, 1002) and assign it to fsNameTag. 

Is this possible? I'm certainly open to other methods of solving my problem if there's a better way to go about it.

Thanks for any assistance you can provide!

Mike

[John Perry]

It sounds like you have images stored in a directory tree, organized into directories whose names are study numbers.

 

Is your objective to copy the images to a new storage tree organized in the same way, anonymizing them in the process, while preserving the original images? If so, presumably you would define a pipeline like this:

 

ArchiveImportService

DicomAnonymizer

DirectoryStorageService

 

To replicate the directory names, you need the directory name to be stored in each DICOM image so the DirectoryStorageService can access it in its structure attribute.

 

You said that the names of the directories are the study numbers, which are also the subjects’ ID numbers, but you also said that the identifiers are not consistent in the images.

 

Just to make sure I understand the situation clearly, are the ID numbers stored in the DICOM images, presumably in the PatientID element (0010,0020), or is there no element that is reliable for this information?

 

If the PatientID elements contain the study numbers, then you can just include (0010,0020) in the DirectoryStorageService’s structure attribute. If you can’t depend on that, then we have to figure out how to get the directory name into some DICOM element.

 

The ArchiveImportService provides a way to store a static text string in an element, but doesn’t currently provide a way to store the directory name. It wouldn’t be hard to add the feature, but first I want to make sure I understand the problem.

 

JP

--
You received this message because you are subscribed to the Google Groups "RSNA's CTP/MIRC User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Lunney]

Hi John,

Thanks a lot for your quick reply and willingness to help. See below for answers to your specific questions.

To elaborate, the name of the parent directory of each subject is the only reliable identifier of the images. I know this is complex, but ideally, I want this workflow to go something like this. Definitely willing to make compromises or consider other solutions if it's not feasible.

• import all images in /SampleImages/1001/ and any subfolders (some subjects have, some don't), labelling some tag "1001"
• reference lookup table for subject 1001 and gather additional data points (secondary ID, deidentified site identifier, other data)
• replace certain existing tags with data from lookup table and remove all others potentially containing PHI
• relabel both folder and filenames of deidentified images from secondary ID

On Wednesday, May 27, 2015 at 2:47:05 PM UTC-4, John Perry wrote:

It sounds like you have images stored in a directory tree, organized into directories whose names are study numbers. Exactly.

 

Is your objective to copy the images to a new storage tree organized in the same way, anonymizing them in the process, while preserving the original images? If so, presumably you would define a pipeline like this: Indeed I would prefer the organization to remain the same, with one case/subject per directory. No need to preserve originals (once I have the process finalized anyways), as the working files are duplicates from a master backup. If it is easier to replace/rewrite originals, that's fine with me.

 

ArchiveImportService  This is what I was thinking, except I also had

    LookupTableChecker       processor here, as there are other associated data elements I would like written into the metadata.

DicomAnonymizer

DirectoryStorageService

 

To replicate the directory names, you need the directory name to be stored in each DICOM image so the DirectoryStorageService can access it in its structure attribute. Ideally, I want directory and file names to be changed as well (presumably from other data elements in the lookup table). I'll take what I can get if this is too complicated though.

 

You said that the names of the directories are the study numbers, which are also the subjects’ ID numbers, but you also said that the identifiers are not consistent in the images.

 

Just to make sure I understand the situation clearly, are the ID numbers stored in the DICOM images, presumably in the PatientID element (0010,0020), or is there no element that is reliable for this information? No element in DICOM tags reliable for identification. Some cases have info in 0010,0020; some do not.

[John Perry]

One more question:

 

Suppose you have two images in these locations:

 

/SampleImages/1001/image1.dcm

/SampleImages/1001/subdirectoryname/image2.dcm

 

What directory name is to be used for image2.dcm? 1001 or subdirectoryname?

 

JP

--

[Mike Lunney]

Always the first folder; 1001 in this case.

[John Perry]

It turns out that there is a problem in using the ArchiveImportService or the DirectoryImportService for this project.

 

It’s possible, but it butcher the code quite a bit.

 

Is this a one-time problem, or do you need something that will be part of an on-going service?

 

If the former, I can just write you a small program to preprocess the files and put in the directory names; then you can use the standard ArchiveImportService to import them.

 

If the latter, I’ll see just how much damage the modifications to the ArchiveImportService will require.

 

JP

 

 

 

From: Mike Lunney

Sent: Wednesday, May 27, 2015 8:24 PM

To: rsnas-ctpmir...@googlegroups.com

Subject: Re: CTP-MIRC Group Assign tag from file path?

 

Always the first folder; 1001 in this case.

[Mike Lunney]

Good morning, John.

The image collection for this project is complete, so we're not trying to set up an ongoing process here. I was planning on doing the project in stages though, but it would all follow the same workflow as described above.

I can't tell you how much I appreciate your help with this. 

Mike

[Smith, Kirk]

It might be nice to have that as a general option as well. What I have often encountered are sites that have their data stored in this manner and the Patient ID has been emptied or some common text written to it. The only way to associate the DICOM objects with a particular subject is by way of the directory names under which the files are stored.

 

Thanks,

Kirk

 

 

Kirk E. Smith

Mallinckrodt Institute of Radiology

 

 

 

From: rsnas-ctpmir...@googlegroups.com [mailto:rsnas-ctpmir...@googlegroups.com] On Behalf Of Mike Lunney
Sent: Thursday, May 28, 2015 8:36 AM
To: rsnas-ctpmir...@googlegroups.com
Subject: Re: CTP-MIRC Group Assign tag from file path?

 

Good morning, John.

--

You received this message because you are subscribed to the Google Groups "RSNA's CTP/MIRC User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

---

The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Andriy Fedorov]

This feature was also mentioned as a must by someone I know that needed to run deidentification for a pharma use case.

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[John Perry]

Mike:

 

I put a new version of DicomEditor on the RSNA site at:

 

    http://mirc.rsna.org/DicomEditor-installer.jar

 

This version has a function that can set the PatientID element to the directory name. The Help tab documents how it works, especially how it chooses the directory name to use.

 

I recommend making a copy of your data collection and trying the program on the copy. The function overwrites the files.

 

You could also use the program to anonymize the files. It uses the CTP DicomAnonymizer, so it has all the functions (except the @call function).

 

If you want to use the program for anonymization, you must first put the directory names in the PatientID elements. You must also provide a file called lookup-table.properties if you need the @lookup function. You can use the Anonymizer tab in the program to edit the anonymizer script, but you’ll have to use some other editor (like the one in CTP) to create the lookup table.

 

Let’s see if the PatientID function works for you; then I’ll see about putting the function into CTP.

 

JP

 

From: Mike Lunney

Sent: Thursday, May 28, 2015 8:36 AM

To: rsnas-ctpmir...@googlegroups.com

Subject: Re: CTP-MIRC Group Assign tag from file path?

[Pattanasak Mongkolwat]

Hi John,

The URL for DicomEditor is not a valid URL for me. It is missing a "download" directory in the path. http://mirc.rsna.org/download/DicomEditor-installer.jar. 

Thanks,

Pat

[Mike Lunney]

For some reason that happened to me too, Pat. Go to http://mirc.rsna.org/, select "download software" from the left column, then select DicomEditor from the list.

[am0...@gmail.com]

Hi all,

I'm wondering if there is a way to incorporate this solution into the CTP application so that it can be used in conjunction with other tools like the pixel anonymizer? Specifically, I'm interested in replicating the source directory in the de-identified directory such that each image from the de-identified directory (i.e. anonymized DICOM attributes and anonymized burned-in pixels) can be compared to the original image. Is this possible?

Thank you so much.

Andrew

[John Perry]

Andrew:

 

CTP does not preserve the original directory structure of files it imports.

 

The DicomEditor program can preserve directory structures, but it only modifies non-pixel elements.

 

The only tool that preserves directory structures while de-identifying both the pixel and non-pixel elements is the DicomAnonymizerTool (http://mirc.rsna.org/download/DicomAnonymizerTool-installer.jar).

 

The DicomAnonymizerTool is a command-line utility that includes the CTP DicomAnonymizer and DicomPixelAnonymizer code. It is described in this article: http://mircwiki.rsna.org/index.php?title=The_DicomAnonymizerTool.

 

JP

--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rsnas-ctpmirc-user-group/b2714048-d73b-443e-9634-a08a6430f0a0n%40googlegroups.com.