I’m developing a software package for DICOM retrieval for research purposes. The package connects to a QR node, sends C-FIND requests for studies of enrolled patients, then enables the user to send C-MOVE requests for this to be moved to the local machine (where the package can appropriately deidentify them). All-in-all not too complex.
I’m having issues getting the C-FIND portion functioning properly on a Philips Vue installation. The connection is functional, and the QR node responds successfully to C-FIND requests (supplementing the response with the appropriate patient details, study date, and accession number, so I know it is finding relevant studies…), but for some reason the study UID is asbent.
I’ve been using study-level queries and injecting a blank study UID tag into the request to try and prompt the node to return this information (not that I’ve needed to do that on any of the other systems I’ve used) but I’m still not having much luck.
Does anyone know of any specific quirks of Vue that might be causing this issue?
Not an expert in any sense and may be way off the mark, but do either of the following apply:
Case-sensitive DICOM TAG - our new PACS returns ‘0020, 000d’ instead ‘0020,000D’ for STUDY_INSTANCE_UID.
Improperly configured STUDY_INSTANCE_UID in your C_FIND - I found the parameter had to be empty (“”) rather than the “*” set for the other tags when doing a study level search. [Sounds like you’ve already discounted this though.]
To help with debugging have you tried Sante DICOM Editor? It will show you the network log so you can see exactly how the query is formed. I’m sure other tools will do the same.
What DICOM library are you using for query-retrieve? Can you turn up the debug level?
If you are not getting enough useful error output from your DICOM implementation, you could try using the findscu and movescu from the open source dcmtk package. These have --verbose (-v) and --debug (-d) modes that you can switch on to help you try to work out where things are going wrong.
Personally, I’m not sure 0020,000d and 0020,000D should be treated any differently as both D and d represent the number 13 in hexadecimal (base 16) so should be treated identically. You can also probably get away with 20,0d for the same, all that matters is the underlying number that is referred to.
By any chance does your system architecture comprise a live as well as a backup PACS failover environment where your Dicom requests are made to a virtual IP (vIP) and not directly to the active server?
May be a long shot but I have seen this cause similar q/r failures in the past.
The tags seem to be set without issue, I’ve examined the outgoing C-FIND request and it all looks in order.
Indeed, this was my first thought as to the issue when it cropped up, but specifically setting the sUID within the request hasn’t sorted it…
@mark.thurston I’m using Fellow Oak DICOM; I’m running things as verbose as possible, but part of the issue is the C-FIND request is successful! It just doesn’t return a study UID for the studies I’m actually interested in…
Bizarrely it does seem to return study UIDs in some cases when performing C-FIND using a wildcard operator…
There’s a plethora of options for transfer syntax etc within the admin tool but nothing that seems specifically relevant (I’m told).
@doug The PACS manager I’ve been working with doesn’t think this is the case, but the exact configuration has been made a bit opaque by Phillips apparently.
Following another round of testing today it looks like it’s going to take a meeting with Phillips to try and get sorted unfortunately. Fingers crossed we should actually be able to work out what the issue is.
Are you C-FINDing the patient at the QueryRetrieveLevel=PATIENT then re-querying at QueryRetrieveLevel=STUDY once you have the PatientID? Or have you a list of PatientID values pre-populated?
Presumably all your AET/AECs are all correct?
I think I would try the C-FIND request using a different library, either dcmtk or pynetdicom, turning up the debug as much as possible and keeping the query as simple as possible, working up to more complicated until you have exactly what you need. If this isn’t possible despite trying multiple known working examples for other PACS, I would try to look through the Philips PACS configuration options in person with one of your PACS team to see if there is a configuration option that you can try (you might also need to reload the configuration).
If you can get the C-FIND request to work successfully with findscu, you are more likely to suspect a problem with the Fellow Oak DICOM calls (e.g. incorrect function parameter or other configuration option).
Hi Matt, if when you meet with Philips you discover you are pointing to a virtual PACS IP then let me know and I’ll dig out the configuration change we made resolve similar behaviour.