Why fail silently?

[a.h...@epcc.ed.ac.uk]

Hi,

I'm evaluating CTP for our DICOM anonymization needs and I was surprised to see that it failed silently in several cases:

1) When I entered the name of the pixel anonymizer script wrongly.  It simply created the file for me and populated it with "true."  Thus it appeared that everything was working fine but no pixels were masked out.

2) It failed to process my images due to an unsupported transferSyntaxUID. Again it just failed silently and let the image though untouched. I found the problem when I switched on debug logging for that class.

Can you explain the reason for this fail silently design approach? It could well be that in larger scale production systems there is a sound reason for it that I'm failing to appreciate just now. 

Thanks,

Ally Hume

EPCC, University of Edinburgh

[John Perry]

Ally:

 

1. You are correct. There was a bug in the DicomPixelAnonymizer that caused it not to be able to load the script file when the file identified in the configuration doesn't exist. It was supposed to do what the DicomAnonymizer does: copy the example file (CTP/examples/example-dicom-pixel-anonymizer.script) into the specified file. We never saw the bug because most people use the standard script file and the Configuration Editor in the Launcher program specifies it by default (and spells it correctly).

 

I have fixed the bug so it copies the example file correctly, but I haven't released it because I want to solve the second problem first.

 

By the way, it is rare that anyone needs to use a modified pixel anonymizer script. It is only required if you have a modality that doesn't appear in the standard script. When that happens, people usually send me their script modifications so I can include them in the release.

 

2. I need to do some testing to understand the second problem better. My first thought was that maybe the DICOM library has an old dictionary, so I built a new library with the latest dictionary, current as of this morning. I doubt that that will fix the problem, though. Are you certain that it is a TransferSyntaxUID problem and not a SOPClassUID problem? Is there any way you can directly send me (john...@dls.net) the file that didn't work? If you can't do that, please trap the error in the log and send me the CTP/logs/ctp.log file.

 

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 post to this group, send email to rsnas-ctpmir...@googlegroups.com.
Visit this group at https://groups.google.com/group/rsnas-ctpmirc-user-group.
For more options, visit https://groups.google.com/d/optout.

[a.h...@epcc.ed.ac.uk]

Hi John,

Thanks for the answer re 1.  I was just playing with it myself to see what it could do. I hadn't realised that the example script will just work in most cases and that most people use that rather than write their own.  That's cool.  I has assumed the scripts may need to be written per hospital but having looked at the script I guess it is mostly a matter of manufacturer and hence a standard script that collects this knowledge is possible.  That's great!  Kind of solves a problem that I thought would take a lot of time and effort.

Does the same concept apply for the tag de-identificaton - is there a default script that just works for most cases?

Re 2: The error I got was: 

10:03:23 DEBUG [DICOMPixelAnonymizer] Unsupported TransferSyntaxUID: 1.2.840.10008.1.2.4.70)




Which comes from the following code in DICOMPixelAnonymizer.java:

logger.debug("Unsupported TransferSyntaxUID: "+transferSyntaxUID+")");

return AnonymizerStatus.SKIP(inFile, "Unsupported TransferSyntaxUID: "+transferSyntaxUID+")");





This is the image is not in the correct transfer format it is just skipped.  I now think I understand that I need to put processes in the pipeline before this one that uncompress the data and if I do that then this error should go away.  I was just playing at building up a basic pipeline to see how CTP worked and had not realised I needed the uncompress stage.

Thanks for responding.

Ally

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

[John Perry]

Ally:

 

The DicomAnonymizer modifies non-pixel elements.

 

When you add a DicomAnonymizer stage into as pipeline, the configuration editor initially specifies a file in the CTP/scripts folder (scripts/DicomAnonymizer.script). You can change that if you want. I strongly recommend keeping all your scripts in the scripts directory, but if you want different scripts for different purposes, just give them different names. Remember that if you have multiple stages using the same script file, any changes you make to the script for one stage will be seen by all the stages that use that script.

 

When the DicomAnonymizer is instantiated during CTP startup, it looks to see if the specified script exists. If it doesn't exist, it copies an example file from the CTP/examples directory and gives it the specified name. Because CTP is used for both clinical trials and radiological teaching files, and because those two applications have very different anonymization requirements, the DicomAnonymizer copies either the example-ctp-dicom-anonymizer.script or the example-tfs-dicom-anonymizer.script, depending on whether the configuration includes the MIRC teaching file plugin.

 

The TFS version of the DicomAnonymizer script is an implementation of the DICOM PS 3.15 Appendix E Basic Application Confidentiality Profile (113100). It is very aggressive. It is useful for teaching files where attribute confidentiality is critical.

 

The CTP version of the DicomAnonymizer script is the script defined by the U.S. National Cancer Institute for its clinical trials. It includes the following profiles from DICOM PS 3.15 Appendix E:

 

113100 Basic Application Confidentiality Profile

113105 Clean Descriptors Option

113107 Retain Longitudinal Temporal Information – Modified Dates Option

113108 Retain Patient Characteristics Option

113109 Retain Device Identity Option

 

It is the responsibility of the CTP site administrator to examine the script to confirm that it is meeting the requirements of the trial before beginning production.

 

Your analysis to the DicomPixelAnonymizer transfer syntax problem is correct. The DicomPixelAnonymizer can only process uncompressed images or images with the JPEG Baseline transfer syntax. It skips images that it cannot handle. You can put a DicomDecompressor stage before the DicomPixelAnonymizer to guarantee that the images can be handled by the DicomPixelAnonymizer. You can put a DicomTranscoder stage after the DicomPixelAnonymizer stage if you want to recompress to Lossless JPEG to save space.

 

Note: since the DicomPixelAnonymizer matches signatures based on the contents of the non-pixel elements and the DicomAnonymizer modifies non-pixel elements, it is best to put the DicomPixelAnonymizer ahead of the DicomAnonymizer in the pipeline to ensure that elements required for signature matching haven't been anonymized away.

 

One more thing: If you have a pipeline that is intended only to handle images of a certain type, you can put a DicomFilter stage in the pipeline after the import service to quarantine images that don't meet the requirements of the pipeline.

 

JP

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