Get SR in QR if empty image level query returned
One PACS is returning an empty response at image level when interrogating SR series to see which type of SR they are.
Instead of dropping the SR from the response in this circumstance we would do better to get it and drop it in import if not appropriate.
Comments (28)
-
reporter -
I was thinking of an implementation like your last point: have a command-line flag to try and retrieve empty SR series, otherwise just use current behaviour.
For CT my intention is to run a query with the
--toshiba
flag first, and then run another with a--try_empty_SR
flag to obtain the SR data. -
reporter So if we use this flag as a second query, do we make it behave as though empty SRs are RDSRs and if we find one we drop all other responses, ie images.
Is that what you were proposing?
-
Hi Ed. Yes, that's more-or-less what I was thinking. I don't want any images returned when I make this sort of query, just SRs.
-
reporter Initial attempt to address ref
#732for @dplatten. No tests yet, just adjusting existing tests so they work with the new arguments.→ <<cset 34f95af1bebb>>
-
reporter Added test for a PACS that returns nothing for an image level query for an SR series - this time with Mammo, will repeat for CT. Refs
#732.→ <<cset 188fe8dcc656>>
-
reporter Added a couple of CT tests. Should be good for testing in the field now. Refs
#732.→ <<cset a808ef58edec>>
-
reporter @dplatten - do you have anything you can test this branch with?
-
As it's just qrscu.py that's changed I could test it on my live system to query PACS, or would that be a really bad idea?
-
reporter I think that would be fine. I think the worst that could happen is that the query returns not quite the right results.
I'm never quite sure whether just switching out the file will automatically make the commands available via the executable script. I think it will.
-
@edmcdonagh I'm very pleased to report that the qrscu.py retrieves SRs from the "empty" series perfectly. I'll report back here tomorrow once some "regular" queries have also been carried out. Thanks.
In setting up a new PowerShell script to run a -emptysr query in the early hours of every morning I noticed that there's an error in the https://docs.openrem.org/en/latest/netdicom-qr.html documentation. It currently includes the line:
The above PowerShell script could be run on a regular basis by adding a task to the Windows Task Scheduler that executes the powershell program with an argument of -file C:\\path\\to\\script.ps1.
However, the double backslashes are not required; it should read:
The above PowerShell script could be run on a regular basis by adding a task to the Windows Task Scheduler that executes the powershell program with an argument of -file C:\path\to\script.ps1.
-
reporter Do you have time to throw that into the other branch and issue and then it can go out with the docs update?
I haven't had a chance to digest Richards suggestion, so if you want to implement that too, be my guest!
We can then merge into the docs branch then merge that back into latest.
-
Yes, I'll sort out the update I've suggested and those of Richard.
-
reporter Hi @dplatten - assuming this has continued to work well for you, do you think we should add it to the advanced section of the web UI?
-
Hi @edmcdonagh - yes, it is working well. I think it should be added to the advanced section of the web UI.
-
reporter Added get_empty_sr to web interface. @dplatten - can you have a look? Refs
#732→ <<cset 1b648e40d494>>
-
@edmcdonagh - I'll take a look at it, but won't be able to test it until next week.
-
reporter I did it on the train this morning, but forgot to push it when I got in. Then when I turned on the laptop this afternoon, the screen is dead again. Aaarrrrgggghhhh!
-
Note: the link to "DICOM store and query retrieve documentation" under the docs menu on the queryremote page doesn't work.
-
@edmcdonagh the new Advanced option in the web interface to retrieve objects inside empty SR studies works perfectly - thanks.
-
reporter Any chance you might update the docs for it?
-
Ok - will do
-
Updated netdicom qr docs [skip ci]. References issue
#732→ <<cset ea1b649d4650>>
-
@edmcdonagh is my statement in the revised docs that, "All other image series are deleted" for the empty SR switch correct?
-
reporter How about this @dplatten? Refs
#732→ <<cset 6064beaa4a95>>
-
reporter -
reporter Adding ref
#732to changes→ <<cset aa585a96e317>>
-
reporter - changed status to resolved
Merged in issue732getemptySR (pull request #287)
Fixes
#732Approved-by: David Platten
→ <<cset 737ff3ecbc7f>>
- Log in to comment
@dplatten I'm trying to think through the logic of this one.
Simple case:
Not so simple case:
CT:
Also, if we know a particular PACS behaves properly in this respect (i.e. most of them), do we maintain the current behaviour (i.e. ignore empty SR series), and just have a flag for naughty PACS in the QR node configuration?