Save to truncating Structured Reports

Hi

I am using conquest primarily for dose audit collection. I have added the SOP for XRayRadiationDoseSRStorage and with no import arguments the structured reports are saved to the default location and I can extract all the dosimetry data using a python routine.

However, my preferred approach (aligned with what I have done for 'reading/ocr' the CT protocol images) is to 'save to' as an import argument, before running the analysis on the saved copy which subsequently deletes the image. The conquest version of the image is destroyed at the end of the import argument. Thus no patient data is stored on the server for more than a few minutes.

The problem is that the copy of the Dose SR that is made when using 'save to' only has the standard header data, none of the structured report section. The version that is saved to the default location is the whole thing.

Is this a feature or a bug? Can I change the behaviour?

Thanks in advance for you help!

Kind regards

Ed

Update: I thought I could get around the issue by simply passing the path of the SR in the default storage folder, but this doesn't work because the image isn't written there until after the 'system' command returns.

Therefore I really need to get 'save to' working in order to progress without resorting to scripts that monitor contents of folders...

Magic - thanks Gerald. I think that install is on 1.4.16beta. And my searching fu obviously isn't up to scratch!

I left the server running on Wednesday and was off yesterday, so this morning I have checked, and unfortunately I am still getting the same result with the new version. Just to confirm, the version I am now running is DGATE (1.4.16, build Wed Dec 14 18:05:11 2011, bits 32) as reported with a '-v' on startup.

I guess you are going to need an example in order to trouble shoot further? If so, I'll try and de-identify an example and pass it through the server.

Having a quick look at the 'before' and 'after' files when using 'save to' in 1.4.16h, it seems that the sequences are simply not being copied as was the case before 1.4.16a:

Before:

(0008,1110) SQ (Sequence with undefined length)                   # u/l,1 Referenced Study Sequence  (fffe,e000) na (Item with undefined length)    (0008,1150) UI [1.2.840.10008.3.1.2.3.1]                      # 24,1 Referenced SOP Class UID    (0008,1155) UI [1.3.51.0.1.1.192.168.90.77.100000476671.476706]         # 46,1 Referenced SOP Instance UID  (fffe,e00d)(fffe,e0dd)

After:

(0008,1110) SQ (Sequence with defined length)                     # 0,1 Referenced Study Sequence

Any clues as to where to go next?

Thanks Marcel

I think I started with a download of the complete package from http://ingenium.home.xs4all.nl/dicom.html as I was updating a beta version - has that been updated to 'h' or am I going mad!

Anyway, I have now updated using the zip file, and recompiled and indeed the sequences are now being saved.

BUT!

For some reason the sequence section is now a mixture of implicit and explicit VR when the original was explicit VR. Which (probably among other things) is making some DICOM tools refuse to read the file eg with the OFFIS dcmdump I get this error:

Quote

DcmElement: ScheduledProcedureStepDescription(0040,0007) larger (675660) that remaining bytes in file

This seems to be a bug in the new code - is this something you have seen before?

Thanks again.

Ed

P.S. I must say hello when you are next here at The Marsden for the course in March...

Thanks Marcel - it seems that they aren't in the dictionary.

They all seem to be in the 0040,xxxx range and describe dosimetric information about the scan. I shall endeavour to add them all in and see if it starts working.

Kind regards

Ed

Initial experiments suggest that we now have a working solution!

In case it saves anyone else updating the dgate.dic file for the same purpose, I have tried to attach my edited version here (see below). I won't vouch for it being completely without mistakes or in any way complete - I have simply added all the missing non-private elements from a small sample of Siemens DICOM Dose SR files, taking the VR, VM, Keyword and Name from PS 3.6-2011. I have assumed that VERS is always 3, but I don't know whether this is referring to version 3 of the DICOM/NEMA standard, or something else.

I hope it saves someone some time, or that Marcel might add it into the next release, along side adding the XRayRadiationDoseSRStorage 1.2.840.10008.5.1.4.1.1.88.67 sop to the dgatesop.lst file?

Kind regards,

Ed

Amendment: I couldn't attach a .dic or a .txt. When I tried to attach the file zipped, I get 'Could not upload attachment to ./files/289_eb75a22083b79a760cc5220898a723c3.' Are we allowed to attach files?

Quote from marcelvanherk

Have you trued lua to do the data processing?

Hi Marcel

No, I haven't. The python is working really well for me, and I haven't come across lua before so I don't have a huge incentive to try and reimplement what I have done using lua.

If I wanted to do something new, where should I go to help me dive in to lua?

Ed