The Problem
Technologists are having trouble storing images from a medical imaging modality to PACS.
In this scenario, technologists are complaining that they can no longer send images from an MR modality to the Picture Archiving and Communication System. The technologists confirmed that they can view the images on the workstation attached to the MRI. This verifies that images were indeed collected on the local computer from the MRI modality. Ruling out any issues within the MRI gantry + MRI workstation combination. The images from this workstation, however, cannot be sent to PACS. Earlier today, it was sending. But not anymore. It is your responsibility as the PACS administrator to fix it. We’re here you guide you through the process. We will work our way through the troubleshooting steps in this section.
Here is a step by step guide on how to resolve DICOM store errors from modality to PACS.
Before we Begin
The method
Start with the most simple possible cause of error, then work your way gradually to more complex possibilities. The root cause could be a variety of things. A power outage or other malfunction with the modality itself could occasionally be the cause of the issue. In other instances, the PACS server or network connection may be the issue. This guide may not catch every possibility but hopefully you can use the incremental methodology described below, to continue troubleshooting your problem. This methodology can be loosely applied to any troubleshooting method between DICOM application entities.
Gather your contacts
You don’t have to troubleshoot alone. It would be helpful to have resources on standby. Either in person, on the phone, or on a webex. The field engineer or your facility’s biomedical engineer to help with the modality. A network administrator to help with possible connectivity or switch related issues. The PACS vendor’s support representative to help with the PACS software. Lastly, a senior resource on your team if one is available. Remember. You are trying to resolve this issue so a patient can get the care they need. In this scenario, you want these images transferred to PACS so a Radiologist may view them. For urgent cases, you can find a workaround to first get the images into a Backup PACS before troubleshooting. Gauge the situation and keep an open line of communication with the technologists. The desired outcome is to reduce the amount of time it takes to fix this problem. So use all the resources at your disposal and do not be afraid to ask for help. Speaking of saving time..
Important note to save time
Sometimes you don’t have to go through this whole serial step by step process. Sometimes the reason for failure may pop up as an error message on either the modality or the PACS. If you can’t find the reason in the UI you may be able to dig into the logs of both sender and receiver. For more advanced professionals, this is the preferred method. Instead of ruling out each of the possibilities one by one. For the newbs, let’s dive right in.
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.
Conclusion
That is all for now folks. Hopefully, we’ve helped you resolve the issue. There could be many more possibilities but we’ll dig into those another time. Remember, start with the basic stuff then gradually work your way through the more complex scenarios. And don’t be afraid to ask for help. Reach out if you find topics like this helpful so we may focus our efforts on creating more modules just like this one. Also stay tuned as we convert this article into a video on our Youtube Playlist below.
Have an interesting troubleshooting experience to share? Let us know in the Youtube comments. Don’t forget to Like and subscribe to our channel.
Check out our Study Guide and Practice Exam if you’re looking to become a PACS Administrator, looking to obtain CIIP certification or just looking to earn some CEs while improving your medical imaging knowledge.
Earn 3.5 CAT A CEs
Approved by the ASRT
PACS Boot Camp is for anyone who wants to learn more about configuring and managing a PACS. As always, feel free to contact us with any questions. We’re here to help!