Missing studies from Philips Azurion/Allura - any clues?

18 views
Skip to first unread message

CS Tima

unread,
Nov 7, 2025, 11:33:45 AMNov 7
to OpenREM
Dear all,

we have an issue here:

From 10 studies from our cath lab, only one is displayed.
  • We have two identical Philips azurion machines that send SR dose reports to the PACS
  • openREM query for today finds 10 FL studies to import from the PACS that we downloaded
  • In the "previous queries" we find that 10 studies were successfully downloaded
  • When we check, only dose reports of 1 study are processed into the Flouroscopy tab
  • when carefully checking the query details, it shows that the successfully imported dose information is the only one that has a Task UUID and a status saying "Import finished successfully"
  • the other 9 studies have no Task UUID and no status. Interestingly, there is a structured dose report in every study.
Now comes the mysterious part:
One of the Philips Azurion was installed recently, replacing a Philips Allura system. With the Allura, we would at least have 2 studies imported successfully in openREM each day.

My assumption is that, somehow the dose reports from these systems all look too similar and openREM might take the first one and ignore the rest.

Where could I start searching, or what information may I provide to you?
It is a real pain and I have spent a lot of time looking for clues but nothing worked so far.

Kind regards,
Charles

Installation:
openrem 1.0.0b2 running in docker on ubuntu 


Ed McDonagh

unread,
Nov 7, 2025, 1:00:50 PMNov 7
to CS Tima, OpenREM
First thing to check is the Device Observer UID for the various Philips systems you have. When we got our second Azurion I didn't understand why the RDSRs were not appearing - it turns out that Philips standard practice is to set the Device Observer UID as the same UUID for all their systems! OpenREM on my systems is to use the Device Observer UID to set the display name, and therefore all the studies from the second system were appearing as the first system. 

If this is a situation you are in, Philips service engineers were able to reset the Device Observer UID based on the system serial number. 

None of this should stop them being imported though - they might just turn up in the wrong lab. 

I'm not sure what the logs are showing you. I wonder how difficult it would be to anonymise the logs to forward to me (not the group)?

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/00d2d961-f8f5-4862-a549-1c710607a453n%40googlegroups.com.

CS Tima

unread,
Nov 24, 2025, 2:24:08 AM (12 days ago) Nov 24
to OpenREM
Hi Ed,

thank you for your support.
Our investigation showed that a query correctly returns the number of studies for the given time frame. We verified this by switching on the orthanc web interface and disabling the delete commands in the lua file.
Unfortunately, during the MOVE , the PACS system does not return all the studies (previously found). A possible reason was found in our PACS Log: it detects some DICOM non-conformities and therefore does not send certain studies.
The PACS vendor (also Philips) is currently investigating this behaviour. Either there is a non-conformity in the studies coming from the modalities, or the conformance check of the PACS is returning false positives.

I will keep you posted. Currently I do not think that openREM is the cause of the issue.

Kind regards,
Charles

Reply all
Reply to author
Forward
0 new messages