Studies failed to import

[Alan Chamberlain]

Hi All

We have a production system running in a docker container. Dose reports are pushed to it automatically by the Fluoro machine. For the last year it has run without problems but from middle May studies have not been importing even though the Fluoroscopy machine shows them as exported successfully.

If I go to "Config, Display names and modality, Failed Imports" I see there are 1151 failed imports under Fluoro. I don't know why these studies don't have an entry in the unique_equipment_name table. I'm not aware of anything that has changed.

If anyone has any idea where I need to start looking, or possible reasons why the imports are failing I'd appreciate it. Is it possible to import the studies again? They are unfortunately not kept on the Fluoro machine.

Regards

Alan

[Ed McDonagh]

Hi Alan

Are they set to delete on your instance? And are they saved to PACS?

Are there other modalities saving to your OpenREM - are they working ok?

First thing we need to do I think is work out what is going wrong on import. 

Are there messages on the tasks log in the web interface?

Do you have any RDSR from QA that we can investigate? 

Kind regards

Ed

--
You received this message because you are subscribed to the Google Groups "OpenREM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrem+u...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openrem/85e39b0a-d8ff-4e3e-8b8d-15d2a021ab23n%40googlegroups.com.

[Alan Chamberlain]

Hi Ed

Thanks for your response. I looked at the logs, but could not see anything useful except that nginx was recording a failed import.

The failed studies were still in the /import directory (bless you) of the Orthanc container. I copied them out using:

'''docker cp openrem-orthanc-1:import/. .'''

and imported them directly into my test system using rsdr.py. They all imported 100% correctly.

Is there anyway I can run the Orthanc lua script manually on the failed imports with debugging enabled to test. I am not excluding any systems or anything in the Orthanc configuration.

I see there are a whole of failed tasks with the most recent being 13 May when then system stopped recording dose (attached). I will terminate all these.

Regards

Alan

[Ed McDonagh]

So do you think that the queue was stuck, so nothing new would be processed?

The easiest way might be to just send them again via DICOM Alan - otherwise I'll need to think hard about docker commands!

If you have the DCMTK tools on your computer that you have copied the files to, then you can do something along the lines of 

storescp openremserver 104 *.dcm

Would that work?

Kind regards

Ed

To view this discussion, visit https://groups.google.com/d/msgid/openrem/aeb61ac9-64d1-4048-a4e6-b32dbfbdfa85n%40googlegroups.com.

[Ed McDonagh]

Apologies by the way for the delay - Google Groups decided that your message was spam, and didn't tell me about it for a while!

[Alan Chamberlain]

Hi Ed

It was indeed a task that was stuck. It looks like there was a power outage during the import of a report and this clogged the queue. I'll see if I can try your suggestion above.

Regards

Alan

[Alan Chamberlain]

Thanks Ed

I don't know why Google is putting it in spam, I'm posting from the browser. In addition to the study blocking the queue there were a lot of other failed imports.  I eventually did the following:

Copied the dicom files that failed import out of the Orthanc container by

> mkdir failedstudies

> cd failedstudies

> docker cp openrem-orthanc-1:/imports/. .

Copied the dicom files into the openrem container by:
> docker cp . openrem:/failedimports/

Opened a shell in the openrem container
> docker exec -it openrem /bin/bash

Executed this script

from openrem.remapp.extractors.rdsr import rdsr
from pathlib import Path

directory = "/failedimports/"
files = Path(directory).glob("*.dcm")
for file in files:
    rdsr(file)
    print(file)

The files all imported correctly so the problem is not from the OpenREM side but rather Orthanc/Nginx. I will try and trouble shoot further.

Regards

Alan

On Saturday, 12 July 2025 at 14:10:40 UTC+2 Ed McDonagh wrote: