C-FIND Study query: weird behavior of date range

[t.c....@gmail.com]

hi,

Today I noticed weird behavior with our AGFA PACS. When performing a study-level query from openrem, for a specific date for modality CT, 60 studies were returned. When performing the same query from the commandline with findscu (dcmtk) the same number of studies was returned. When using a date range spanning one day, I got 66 studies! The additional 6 studies were valid studies with correct studydate and modality and should have been shown in the first query in my opinion. Am I mistaken somehow? Or is it a bug?

findscu -v -S -aet AET1 -aec AET2 -k QueryRetrieveLevel="STUDY" -k StudyDate=20170324 -k ModalitiesInStudy=CT hostname 104
>>> 60 responses

findscu -v -S -aet AET1 -aec AET2 -k QueryRetrieveLevel="STUDY" -k StudyDate=”20170324-20170324” -k ModalitiesInStudy=CT hostname 104
>>> 66 responses

regards, Tim

[Ed McDonagh]

Hi Tim

That is weird! I haven't come across this myself, but then I haven't looked for it.

I'd be interested in whether anyone knows about what the correct behaviour is?

Tim, what happens when you set to and from dates using OpenREM? Is it 66 studies?

If so, one thing we could do to get a consistent approach would be to always use a date range? Currently if to and from dates are identical, a single date is used. In all other circumstances a range is used.

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+unsubscribe@googlegroups.com.
To post to this group, send an email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/openrem.
For more options, visit https://groups.google.com/d/optout.

[Ed McDonagh]

Oops, I wrote half that email, then checked the current behaviour of the date range, then wrote the last post of the email without reading it through.

Knowing the single date behaviour, I expect OpenREM to return the 60 responses.

[Tim de Wit]

Only 60 responses indeed... (using qrscu.py at the command line)

--- Sent from my iPhone

[Tim de Wit]

I've looked into it in more detail and made the following observations (numbers slightly changed since initial post; probably mutations in PACS):

Query1: findscu -v -S -aet AET1 -aec AET2 -k QueryRetrieveLevel="STUDY" -k StudyDate=20170324 -k ModalitiesInStudy=CT hostname 104

>>> 59 responses

Query2: findscu -v -S -aet AET1 -aec AET2 -k QueryRetrieveLevel="STUDY" -k StudyDate="20170324-20170324" -k ModalitiesInStudy=CT hostname 104

>>> 64 responses

Query3: findscu -v -S -aet AET1 -aec AET2 -k QueryRetrieveLevel="STUDY" -k StudyDate=20170324 -k ModalitiesInStudy=CT -k Modality hostname 104

>>> 117 responses

After analysis:

* Query1 and Query2 only have 6 studies in common! All studies unique to either Qeury1 or Query2 seem to be valid studies containing modality CT.

* Unique entries of Query1 and Query2 combined produces the same result as Query3

* Query3 with StudyDate range also yields 117 responses

So Query3 seems to give the most complete answer, even though "Modality" is not a valid query parameter at Study level!

Exact PACS version to which this seems to apply: AGFA IMPAX 6.6

regards, Tim

[Ed McDonagh]

It seems to me that this cannot be the correct behaviour!

Does IMPAX return anything in the invalid modality field in its response?

How many responses do you get if you query with modality, but use a date range?

What happens if you use a different extra return field, valid or invalid at study level?

Very strange!

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

[Tim de Wit]

Does IMPAX return anything in the invalid modality field in its response?

It returns CT mostly and in some cases also CTPT or CTNM. The StudiesInModality parameter returns an empty result in this case (without Modality parameter it's something like "CT\SR\PR\KO\CC" as you would expect)

 

How many responses do you get if you query with modality, but use a date range?

Same number, namely 117.

 

What happens if you use a different extra return field, valid or invalid at study level?

Using SeriesDescription instead of Modality gives me either Query1 or Query2 depending on date parameter.

[Tim de Wit]

The issue was analyzed by AGFA and apparently there's an internal restriction on the number of series being returned (max 2000). Above query is on study-level, but due to the "ModalitiesInStudy" parameter it needs to query all corresponding series for their modality. Between different queries (range vs single date) the date-order of the series is different, so a different set of studies can be returned after truncation, e.g.:   

The date range query for instance returns:   

series 2, accessionnr B   
series 1, accessionnr A   
series 3, accessionnr B   

The single date query returns:   
series 2, accessionnr B   
series 3, accessionnr B   
series 1, accessionnr A   

Suppose the series-limit is 2, in the first query 2 studies are returned (A and B); in the second query only one is returned (B). A "solution" seems to be to increase the limit, with the risk of decreasing pacs performance.

[Ed McDonagh]

Hi Tim. I'm trying to get my head around this, and I'm struggling!

Have I got this right?

• Issue 1: using date range vs single date produces the same results but in a different order. And if there is a truncation going on, you will therefore get different responses.

• Issue 2: If the query uses study level 'ModalitiesInStudy', AGFA PACS doesn't have this in the database, and therefore queries each study to see which series modalities they have to build the response. Presumably they will restrict the queryset for date first, then we have a queryset of every single exam of any modality in that data range; AGFA then queries each of those studies for modality at series level. Which is why they can get to a limit of 2000 series whilst only finding 60 studies that contained CT.
  

Blimey.

Can you query using Modality? So drop ModalitiesInStudy and use -k Modality=CT

I am thinking about how we can sort this out for OpenREM. One option would be to have a configuration option on our side to disable use of ModalitiesInStudy. We'd then get all the study level responses, and go off and populate the Series level responses ourselves. It would undoubtedly be slower, but at least we'd never hit the 2000 limit because we'd be doing the series query one study at a time and we should always get all the studies we are after.

Or if bizarrely the Modality query works (which is illegal), then we could have that as an option so that OpenREM can be configured to use that instead.

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+unsubscribe@googlegroups.com.

[Tim de Wit]

Seems plausible..

I've performed some more tests with query 3 and unfortunately it doesn't consistently return the most complete response.

Alternative solution I can think of:

- use datetime instead of date if supported by pacs (or possible at all; haven't looked at it yet), and divide the day in intervals to reduce the number of responses

Otherwise your suggestion might help indeed (would mean a larger burden on the pacs though).

[Tim de Wit]

The series-limit was increased to 10.000 and now the problem is gone... Perhaps it would be nice to add the possibility to the admin back-end to perform and compare (#responses) query1 and query2 to validate the pacs interface?