Extractors not supporting our SOPClassUID

[Lars Kroll]

I am trying to set up OpenREM right now. In combination with Orthanc (and the “openrem_orthanc_config.lua”) I am receiving errors when trying to import dicom data:

W0522 16:13:02.410006 LuaContext.cpp:103] Lua says: Rejecting a DICOM instance: SOPClassUID: 1.2.840.10008.5.1.4.1.1.2; Modality: CT; Manufacturer: Philips; ManufacturerModelName: Brilliance 16; SoftwareVersions: 2.3.0; StationName: HOST-5382

I guess this means our CT-machine is not supported? Is there anything that can be done? Thank you in advance

[Ed McDonagh]

That error is being produced by Orthanc, and I don’t think it is to do with the lua script that we have provided. We also know that Philips Brilliance CT scanners are supported by OpenREM, normally using the ‘Dose Info' series where RDSRs are not available.

Has anything been processed successfully by Orthanc?

[Lars Kroll]

Strangely enough there are actually a very few CTs which were successfully processed. At least those are showing up with data in OpenREM. I figured those were just having a different SOPClassUID (was feeding it a lot of data with from random patients who were scanned with a different Philips Brilliance).

Maybe I am doing something wrong after all? I also tried to setup Conquest and the unstable OpenREM-receiver. Both acting kind of similar to Orthanc.

[Ed McDonagh]

Do you have the files locally so you can import them directly into OpenREM without going through Orthanc?

[Lars Kroll]

Thank you for taking time for responding to my problem

After your suggestion, I tried importing local files with the openrem_ctphilips.py filename.dcm command (found in the documentation). Unfortunately I do not get any feedback from the commandline (I am using windows server 2012). I did some digging in the code which led me from openrem_ctphilips.py (in Scripts) to ct_philips.py (in remapp\extractors) which turns out to be filtering the SOPClassUID in line 368:

if dataset.SOPClassUID != '1.2.840.10008.5.1.4.1.1.7' or dataset.Manufacturer != 'Philips' \
             or dataset.SeriesDescription != 'Dose Info':
    return u'{0} is not a Philips CT dose report image'.format(philips_file)

I am not sure why I am not getting this error message though. But assuming this message to be true, that would mean those images are not relevant to OpenREM (or atleast they are not containing any dose report information). Any ideas?

[Ed McDonagh]

Does your Philips CT scanner create Radiation Dose Structured Reports (RDSRs) @m2lars? If so, then the RDSR should be passed to the openrem_rdsr.py rdsrfile.dcm command.

If it doesn't, then OpenREM can instead extract the dose related data from the 'Dose Info' series image that is created. Pass that image to openrem_ctphilips.py doseinfoimage.dcm

Whilst Orthanc should process the SOP Class UID 1.2.840.10008.5.1.4.1.1.2 (CT image), we currently only use that when making use of the openrem_cttoshiba.pyscript, where the RDSR is generated from the image header data. Both the RDSR and the Dose Info image have different SOPs; the Dose Info image is of type 1.2.840.10008.5.1.4.1.1.7 which is Secondary Capture, hence the if statement.

Does that make sense?

I don't know why the error message wasn't printed to the command line. However, most of the logging is written to the logs which are configured in local_settings.py - you can see more details about this in the docs, including how to increase the verbosity by changing to DEBUG.

[Lars Kroll]

Alright, I think I have found the problem.

I was not aware that CTs have a lot of .dcm files which are put together in one directory for a patient. One or more of these files is getting processed by OpenREM (probably the 'Dose Info' series you were talking about).

Long story short: OpenREM did everything right and discarded every .dcm file that is not relevant and only uses the .dcm file with the actual useful content (that explains why ‘some CTs' were imported).

Thank you @Ed McDonagh for helping me and giving me the right pointers

[Ed McDonagh]

Excellent. Glad to have cleared that up! Marked as invalid as there is nothing to change in the codebase - very happy to have had the query and been able to answer it though