Dicom modification - removing sequences?

[John Roberts]

Hello,

I'd like to remove the sequence (0040,0275) from my DICOM.  According to dicomLookup it's an optional sequence that can be deleted.

However, I don't seem to be able to make the remove work from Lua, even if I set the Force flag to true.

I don't think I've tried deleting a sequence type of DICOM tag before.  Is that possible in Orthanc?  Or will I need to implement a recursive delete and delete the series from the inside out?

Thanks,
John.

[John Roberts]

As a followup, I've tried both Replace and Remove options to both anonymize and modify calls.  At no time is the sequence removed.

I turned on verbose logging, but saw no indication of an error.

I'm sure I've seen other sequences successfully deleted before.

This sequence appears to store duplicate copies of DICOM tags stored elsewhere in the DICOM header.  Some of those original tags cannot be removed by definition (Class 1 type tags).  However, their copy within the sequence should be removable, if my understanding is correct.

Is there some underlying logic in the anonymization process that forces Orthanc to protect these "required" fields even though they are copies and do already exist at the top level of the DICOM tags?

Thanks,
John.

[Alain Mazy]

Hi John,

I do confirm that sequences can be removed.  

However, it is not currently possible to remove a tag within a sequence.  Is it what you're trying to perform ?

--

Alain Mazy / CTO 
a...@osimis.io / +32 494 31 67 27

	OSIMIS S.A.  Rue bois Saint-Jean 15/1BE-4102 Seraing  www.osimis.io

[John Roberts]

Hi Alain,

I'm attempting to remove the entire sequence.  I'm hoping to avoid having to address the contents of the sequence individually.

Putting the DICOM tag into the Remove part of the Lua call to the anonymizer (or the modify) appears to have no effect.  The sequence is never removed.

Additionally, attempting to use the Replace field of a Lua call to modify the header similarly does not work.

I just can't seem to delete the field no matter what I try.

My suspicion is that Orthanc may have a list of fields it will NOT delete because they violate the DICOM standard.  In this case, it is not the sequence that is the problem, but what the manufacturer has placed inside the sequence.  The sequence contains copies of DICOM fields which on their own should not be deleted, but because they are copies within this sequence should be legal to delete. 

However, I think that maybe Orthanc refuses the deletion regardless of where it finds the problem tags?  That is, Orthanc makes no distinction where required DICOM tags occur and therefore insists they must always be preserved, over-riding my Remove request?

I've tried the Force=true option, which the Orthanc documention indicates should allow the modification of required DICOM tags, but this also has no effect.

This has proven to be a very difficult sequence to get rid of!

John.

[John Roberts]

     Now that I've had a chance to switch to the most recent Docker baseline Orthanc (Api 1.0, Version: mainline), I am still UNABLE to remove this sequence from my DICOM.

Placing '0040-0275' in the remove list is apparently ignored by the call to anonymize without any errors or warnings generated.

Likewise, adding '0040-0275' to the replace list with an empty Lua table as a value is similarly ignored by anonymize.

[John Roberts]

Progress.

I decided to attempt a call to anonymize on one instance without any replace/remove/keep modifications.  The standard anonymize erases this problematic 0040-0275 sequence that I am unable to delete otherwise.

That got me to thinking that I had a clash between my Remove and Keep parameters that I give to anonymize.  My Keep does include the AccessionNumber, which happens to be one of the fields copied inside this problematic 0040-0275 sequence that I would like to remove.

I suspect that my Keep request is over-ruling the Remove request.

Is there an order of precedence imposed with the Keep/Replace/Remove parameters?  Would it matter what order I give them to the json body fed to the anonymize POST?

It seems that the Keep requests are indifferent to where the requested Keep occurs - whether at the top level or within sequences.  I only care about AccessionNumber as it occurs at the top level outside of any sequence.

[John Roberts]

For the time being, I have separated my single Remove/Replace/Keep anonymize call into two separate modify and anonymize calls.  This has the effect of doubling the time required to anonymize/modify, but seems to be the only way I can remove the problem sequence.

[Sébastien Jodogne]

Hello,

In order for us to be able to help you on this problem with deleting the 0040-0275 sequence, please send us a sample problematic DICOM file, together with the exact REST API call you use.

Regards,

Sébastien-

[John Roberts]

Hi Sebastien,

Unfortunately, I can't send one of the problematic files and would need to create one for you artificially.  The problematic sequence contains patient information that I am attempting to scrub from the file.  For the time being, my two step process (designating remove and keep operations to separate API calls) is working.

If I have some time, I'll try to create an artificial example of what I'm talking about.

My guess is that Orthanc sweeps through all the DICOM tags, comparing them against the keep/remove/replace list and flags their status accordingly prior to performing the anonymization step.  The order in which keep/remove/replace is evaluated is important if, for example, a sequence marked for deletion (remove) is then found to contain a tag marked to keep. 

An example of what the sequence 0040-0275 might contain can be found here and is listed below:

(0040,0275) Request Attributes Sequence	3	Sequence
(0040,1001) Requested Procedure ID	1C	Short String
(0008,0050) Accession Number	3	Short String
(0008,0051) Issuer of Accession Number Sequence	3	Sequence
(0020,000D) Study Instance UID	3	Unique Identifier
(0008,1110) Referenced Study Sequence	3	Sequence
(0032,1060) Requested Procedure Description	3	Long String
(0032,1064) Requested Procedure Code Sequence	3	Sequence
(0040,1002) Reason for the Requested Procedure	3	Long String
(0040,100A) Reason for Requested Procedure Code Sequence	3	Sequence
(0040,0009) Scheduled Procedure Step ID	1C	Short String
(0040,0007) Scheduled Procedure Step Description	3	Long String
(0040,0008) Scheduled Protocol Code Sequence	3	Sequence

Note that some of the contents may be copies of tags that often occur outside the sequence (ex. AccessionNumber, StudyID, StudyInstanceUID, etc.).

In my case, I want to get rid of the entire sequence regardless of its contents.  However, because I'm also wanting to Keep some things elsewhere like AccessionNumber, I believe I'm running into a conflict between my Remove and my Keep requests when executed in a single Anonymize.  I think Orthanc is opting to honor the Keep over the Remove.  So, it keeps the sequence because it contains a copy of AccessionNumber that I indicated I wanted to keep.

You might argue that there is a distinction between AccessionNumber as it appears in the top level of the DICOM tags and when it appears here in 0040-0275 as a copy.  But, I suspect Orthanc does not make that distinction - it does not recognize whether it occurs in a sequence or not and labels the whole sequence to be kept in order to preserve the requested Keep.

When I have a chance, I'll try to make a fake DICOM for you to test.

Thanks for the help,
John.

[Sébastien Jodogne]

Dear John,

I have still not managed to reproduce your issue.

We really need an artificial example to further work on this issue... please let us know as soon as you have one.

Regards,

Sébastien-