How to fix Send to PACS errors

10 Troubleshooting Steps for DICOM Send Errors

1. The acquisition computer of the modality may need a reboot

Sometimes the DICOM services within the local workstation get hung up.?The services can be restarted in the windows task manager if you know what they are.?However, these permissions are usually locked and only managed by the modality vendor.?So instead, a simple reboot of the station should do the trick.?Power off, power on!?BUT!?Big but!?You must be sure the images are saved and will not be lost upon reboot.?If you don’t know this, call the biomedical engineer or the MRI vendor’s field service engineer.?If the reboot didn’t resolve the issue, proceed to the next step.

2. The modality is not connected to the network

Sometimes this is as simple as an unplugged network cable.?Be sure to check behind the acquisition computer.?Ensure the Ethernet cable is properly plugged in.?Then run a windows command prompt on the computer.?Perform a network ping of the PACS server by entering the word ping. Followed by the IP address. If the network ping fails then there may be a network issue.?Contact your network administrator for further troubleshooting.?If there is a valid network connection but sending fails, proceed to the next step.

3. The modality is not connected to the PACS server

In order for DICOM images to be stored from a modality to PACS, the modality must have DICOM connectivity to the PACS server. Not just a network connection.?But a DICOM association.?If not, image transmission will fail.?To test this connection, you can perform a DICOM C-ECHO.?This button is usually found in the configuration UI of the MR software. You can also initiate the C-ECHO from your PACS to the Modality instead. The C-ECHO confirms there is not only a valid network connection, but a valid DICOM connection.?The modality must know who the PACS is, and the PACS must know who the modality is.?They must have each other’s name and address.?Otherwise known as A.E. Title, I.P. address and Port.?If any of these three values have been recently changed, the DICOM C-ECHO will fail.?If there is a valid DICOM connection but you still cannot store to PACS, proceed to the next step.

4. The IP address on the modality was changed

This is pretty common where the computer components connected to the MR modality have been changed, swapped or upgraded.?If techs were experiencing problems with the software the vendor could have replaced the network interface card.?Or even the whole computer.?In some cases, resetting or upgrading the software could erase the current configuration.?What’s so important about the current configuration.?Well the MR’s AE Title, Port and IP address must remain constant for the PACS to accept images from it.?Any of these changes could have caused the MR to lose its static IP address. It could have defaulted to DHCP. If another IP address was assigned to the MR, it will not connect to the PACS.?But in this scenario, the techs said the system was working earlier today.?So perhaps this isn’t the issue.?Let’s move on.

5. The PACS server is down or not responding

If the PACS server is down or offline, images will not be able to be stored from any modality. In some cases, the DICOM server may be online but the storage servers could be experiencing issues – causing storage failures.?In other words, the part of the PACS responsible for receiving DICOM images can still actively receive images.?However, there may be internal storage issues within the PACS that causes the images to not be viewable in the PACS viewer – leading to complaints from the end users that no images were ever stored.?This would rule out the modality being the root of the problem.?You may test this theory from the modality. By sending the same images from the MR to an alternate DICOM destination.?Such as a VNA, 3D Post-Proccessing application or a Backup PACS.?If the images become available in the alternate system, then perhaps the problem is the PACS. Also test if other modalities can send to PACS. Pro tip. Check the error logs on your PACS to look for the exact reason why transfers failed.?If you can’t find anything wrong with the PACS then proceed to the next step.

6. The PACS network was temporarily down or experiencing packet loss

For images to be transmitted, the connection should not be interrupted. If the network was temporarily down during transfer.. or if there was packet loss, the images could have been corrupted. This doesn’t always happen but it is possible.?The corrupt images could have transferred over but become unviewable or unavailable in the PACS software.?If this is the case, delete the images in PACS.?Then resend from the modality.?BUT! Big But again!?Make sure the original copy is still available on the modality to resend BEFORE deleting any patient data. Also confirm with your site’s policy and procedures before any deletion. If the resend doesn’t work, try the next step.

7. The DICOM router is down or not functioning properly

Some organizations use a DICOM router in between the modality and PACS.?Routers can be used for several reasons. To modify DICOM tags on transfer.?To load balance.?To block certain image types.?To send certain images to different destinations based on the file type or metadata.?Be sure the DICOM router is online and make sure there were no recent changes to the rules.?Be sure additions of new rules do not affect previous rules.?Also be sure there’s no connection issue between the router and PACS.?Don’t use a DICOM router??Next.

8. Firewall Issues

Though not a common issue for internal networks, it’s possible the networking team could have made a change to the firewall settings.?Confirm with the appropriate team that there is no firewall blocking any of the ports.

9. The DICOM tags on the images are incorrect or incomplete

It is possible the metadata on the DICOM tags for this particular study could be invalid.?Perhaps there was a change to the original order on RIS which led to invalid data being written onto the DICOM tags.?You’d have to run the images through a DICOM validator to confirm.?Or perhaps find this from the error logs on the PACS.?Not the issue??Let’s try the next step.

10. The DICOM images are not supported

How could this be??All previous images were sent today.?Well, sometimes the setting to change the file type of the image could be a simple button press in the MR software UI.?For example, MR images are usually stored as something called an MR image storage SOP.?Most PACS can store and view these. But if this setting was accidentally changed to the?Enhanced?MR image storage SOP, then you’ve got yourself a problem.?Older PACS may not be able to store or view this class of images.?There were no changes to the SOP class??I guess we’re not done. Let’s look at a bonus step 11.

Bonus reason. There is already a study in there with the same SOP Instance UID

This is a bonus reason because most PACS are not configured this way. If there is already an image in the PACS with the same SOP Instance UID, sometimes the new image cannot be stored. This could happen if the images were sent to the PACS more than once with the same UID.?This really depends on your PACS settings.?Most PACS just accept the newer images and replace the older ones.?Some PACS ignore the duplicates but accept any new images that come in the second time.?Then some PACS are just plain stubborn.?They won’t accept any images at all even if new images are included in the set.?Some PACS may block duplicates on a study instance UID level instead of the SOP instance UID level.?In other words, it will block the whole study, and not just the duplicate images.?You don’t want this setting enabled on your PACS, that’s for sure.?You may want to instead allow your PACS to update the existing images if the same are sent in again. Confirm with your organizational policies before making this change.