Is anyone familiar with Insignia PACS configuration?
We have a site where we’re unable to retrieve images to the ultrasound system.
All DICOM communication otherwise works normally, we can query the patient information and see the image series on the PACS. But attempting to retrieve the images fails.
The fact that it fails instantly, rather than after a timeout period suggests the request is being denied or is failing due to a configuration problem on the PACS end.
I’ve been playing with Conquest DICOM Server to confirm that everything is working normally on the ultrasound and is does. I noticed we saw the same failure using Conquest if I havent added the ultrasound system’s AET, IP, etc. to the “Known DICOM Providors” section.
Is anyone is aware of an analogous configuration requirement on Insignia? We’re being told by local PACS team that there isn’t, but I’m not certain that’s accurate.
From the little I can get from your explanation, I would say that the PACS has not been configured to recognize and allow requests from the Ultrasound system.
Steps below
Check that the Ultrasound systems AE Title, IP address, and port are correctly entered into PACS, set for Query/Retrieve, this is also known as the “Known DICOM Providors” as you pointed out for Conquest
Perform an “C-ECHO” or ping from the Ultrasound system to PACS
Try Query/Retrieve again
Note: Make sure there are no firewalls or routing issues between systems, also it is best if they are on the same local network (mobile hotspot or mifi can be used) for initial test before changing to the desired network configurations
The problem we’re facing is that local PACS team are saying your point 1 doesn’t exist. We are assuming it does, but we’ve hit a brick wall.
I’m hoping someone out there might be able to describe where to find the the relevant menu in Insignia for registering the modality QR details. Some anonymised screen grabs might prove helpful if at all possible.
Points 2/3 - We get DICOM echo, we can send images to PACS, we can query patient ID or name and see how many images/series are avaiable to retrieve. But when we choose the series to retrieve, we just get a failure message.
We are due to go back to check the modality’s port number which may be incorrect, but when the port number is wrong on our workshop test setup it fails after the timeout period lapses(per expectation), not instantly as we are seeing on site. So there’s an outside chance it’s just the port number but I don’t believe this is the issue.
You need to check if the ultrasound has the ability to query , retrieve and store. U is for user part of the DICOM profile.
Do you have a DICOM conformance statement for the device to check if it has all the correct profiles. Have all these profile been added to the device and switched on?
Is PACS using a load balancer/f5/VIP or similar? That can cause issues. If so use the actual IP and AET of the PACS server to QR against and see how that works
Most of the PACS systems will allow anyone to Query studies however when it comes to Retrieve the client details (here is the Ultrasound) must be added to the PACS system so that it knows where to send studies, have you added the Ultrasound details (IP, AE, Port) to the PACS as a Dicom query node?
When you query, the user is the ultrasound machine, the provider is the PACS. If the user had the right details for the provider, and the provider doesn’t reject because it’s picky who it talks to, then you get a result - an answer to the query.
Retrieve is quite different, and it’s in two parts.
First part has the ultrasound send a C-MOVE request to the PACS. The important thing to know is that this request contains details of the study(/studies/series/image etc) you want to retrieve, and the AE Title of the device you want it to be sent to. This connection is then dropped.
The second part is the PACS creating a new C-STORE connection (where it is now the user) to your ultrasound system (now the provider). The only information it has to tell it where to send the images is the AET you told it in the C-MOVE request.
Therefore, for this to work, the PACS MUST have a configuration that lists the correct IP address and port number that matches the AET.
There is an alternative approach, more similar to almost every other network transaction, where the connection remains open and the images are sent back to the requesting device. This is called C-GET (instead of C-MOVE), but it’s seldom implemented.
If it’s the retrieval bit that’s failing, could be the listening port which is the issue.
When you set up a new modality in the insight IMS modalities table, the port you define after the IP address is the modality listening port, which is where images are sent in the retrieval part of QR. First confirm the listening port of the modality matches what you’ve set in the modalities table (often 104, but not always)
Second, if you have access to the pacs ds server used for q/r, use either telnet or powershell’s testnetconnection command to check the ds server can reach the modality on that port (if not, you have a firewall in the way, blocking retrieval).
And lastly, make sure in the modality setup page of the ims that the c-move options are ticked, then give inquire a restart in process monitor ds.
I didnt realise how active this forum is, thank you to everyone responding, it’s hugely appreciated.
It seems clear that there must be somewhere on the Insignia PACS to register the ultrasound as a DICOM Query node. But as a third-party we don’t have access to the PACS to see how this is configured. The PACS team at site don’t seem to believe this is something that exists.
I will have to make another attempt to explain it to them, probably try to get them to follow up with their PACS provider.
Thank you to everyone, all the information you have shared has been hugely informative.
You are a modality vendor who is trying to connect to the PACS?
Do you have single node for send and retrieve - there are a few vendors out there who have different details for these.
If the above is true - you are vendor with a single node - then its the service that needs turning on -
C-Find (SCU) is most likely on, and the C-Move(SCU) needs to be turned on as well.
You should also be able to see logs on your side to know at what point the connection is failing. The above is the basic that needs to be turned, on there a few more steps if the above failing.
From the many replies that you have received, there are lots of potential reasons why it may not be working. When I’ve had similar issues I’ve found that they can be more easily solved when you have all of the relevant experts around a virtual table at the same time. e.g. PACS Manager, PACS Vendor, modality vendor and Trust network engineer.
Everyone here has been great, I didn’t expect such a fantastic response.
I fully agree about getting all parties involved in the discussion together, but that’s always been the fun bit some sites are great for this, others can be very challenging.
some sites are great for this, others can be very challenging.