Extractors not supporting our SOPClassUID
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
Comments (7)
-
-
reporter 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.
-
Do you have the files locally so you can import them directly into OpenREM without going through Orthanc?
-
reporter 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?
-
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 theopenrem_cttoshiba.py
script, 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 type1.2.840.10008.5.1.4.1.1.7
which is Secondary Capture, hence theif
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 toDEBUG
. -
reporter 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
-
- changed status to invalid
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
- Log in to comment
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?