Study date minor issue for Varian Linacs on V3.0

[Carl Horsfield]

Hi there, 

We have been using OpenREM for a long time now in Hull but just came across a minor issue with our Truebeam and Halcyon V3.0 upgrade. It seems the convention in our clinic is that study collections are started from the CT scan and all subsequent CBCTs are grouped with this..

Prior to the upgrade, Study date seemed to get created from the actual scan date for on treatment CBCT scans. Post upgrade, the linacs are now taking the actual "Study" date from the CT scan. This now matches what is being used in Aria. The effect is that because we can only see study date, scans acquired on a given day look 2 weeks old (the planning scan date).

Is there a way to see Series creation date when exporting as csv. 

Kind regards, 

Carl

[Ed McDonagh]

That seems reasonable - is there any chance you could create a QA patient that demonstrates this do that I can test this please?

I remember when I added RT in the first place I had to change the concept of a study I think as in RT it is different to radiology!

Thanks,

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 on the web, visit https://groups.google.com/d/msgid/openrem/2ebe1727-c1ad-4523-95d6-ef5bc4c1e446n%40googlegroups.com.

[Carl Horsfield]

Hi Ed,

Thanks for your fast reply. I've created a test patient and attempted to capture the file, but they are sent, processed and imported before I can get them. any suggestions on how to get them? They are being sent via a dicom service direct from the linac into OpenREM.

Kind regards,

Carl

[Ed McDonagh]

Hi Carl

That depends on which version you are using and which DICOM Store SCP you are using?

It might be that you can simply change the OpenREM config to not delete objects: https://docs.openrem.org/en/0.10.0-docs/i_deletesettings.html

However, it might be that as soon as an object is imported, Orthanc deletes it anyway. If this is the case, you will need to edit the Orthanc Lua file temporarily and restart Orthanc before sending again - see this line near the end: https://bitbucket.org/openrem/openrem/src/develop/openrem/sample-config/openrem_orthanc_config_linux.lua#lines-288

Kind regards

Ed

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/c78a9d90-76ce-4924-9d79-47dfc562e39en%40googlegroups.com.

[Carl Horsfield]

Hi, 

Thanks for providing the clear instructions, they were easy to follow. In the end I commented out the deletion of the temporary file instead as the other end does not seem to get used in the same way here. I spent ages trying to get a test patient to go through, but in the end I've taken a clinical patient and anonymised them as these were populating fine. I don't know what I'm missing or at which end the problem is, but QA tests just didn't seem to make it through to the temp folder. Could be that it doesn't get exported from the linac. Are you ok for me to send this RDSR file via teams?

Kind regards,

Carl

[Ed McDonagh]

Hi Ben, Carl. Sorry for not working on this before now.

Everyone - RT and Diagnostic alike...

I've created Issue 1017 to manage the change, and I've added some thoughts about the consequences, particularly regarding the Study/Series/Content time value. I'd appreciate it if people could read that and comment, either on the BitBucket website or here in this thread.

Kind regards

Ed

On Fri, 5 Apr 2024 at 13:39, Ben Earner <ben.ear...@gmail.com> wrote:

More information...

Here is what a V3.0 RDSR contains:

and here is what I think is the relevant code in the development branch, which prioritises study date over series or content date (which I can imagine makes sense for diagnostic applications):

Ben

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/a06946f2-9331-4b27-ad31-e9002e3aa7aan%40googlegroups.com.