I'm a Senior Network Engineer for a major US hospital. I really appreciate this video however is there anything that can provide deeper technical information on how this whole system works? I would like to understand the entire data flow from start to finish. For example, what TCP/UDP ports need to be open between source/dest for this communication to successfully transfer? We currently have an intermittent issue where some studies transfer without issue and other times where is just gets hung up. We see a DICOM packet with a "provider abort" message in the packet capture however this really only tells me that the Xfer failed, not WHY it failed. I would also like to better understand how DICOM handles congestion issues? Please let me know if and/or how I can go about getting a much deeper understanding of how these flows are supposed to function? Thanks again!
For DICOM connectivity, it will be TCP IP only. The DICOM port is set by the application. 104 is commonly used but this varies depending on the application or the preference of the app administrator. In our experience, when study transfers fail intermittently with a generic error such as yours it is difficult to tell whether this is network or application related. For this reason the best approach is to host a working session between the app vendor, the pacs admin and your networking team to replicate the issue while capturing a Wireshark or network trace. As a senior network engineer you may have gone this route already and perhaps ruled out any network specific connectivity issue. Therefore this emphasizes the need to put pressure on the app vendor to investigate further on the error. Perhaps turning on verbose logging, attempting to replicate in a test environment can reproduce the same error. Certain DICOM images can be more troublesome than others. For ex Mammography studies can take significantly longer to transfer due to file size. Some images being 4Gigs can timeout causing the entire study to hang. This timeout is set on the application and would need further investigation on the app vendor side. Another reason it could hang is bc of DICOM metadata that does not conform to the standard or has special characters that are not allowed or accepted by the receiving system. This just a few examples of several app related reasons for failure that we cannot cover in conversation. That is why we stress a coordinated effort with heavy escalation on the app vendor side. Not sure if this helps but good luck on your efforts.
Thanks this was very helpful. I am new in supporting PACS in our environment very easy to follow.
So glad we could help! Keep it up!
As a new PACS admin, all of your videos are super helpful!
Thank you very much for your feedback!
I agree with Victor Maldonado - these videos are really helpful and thanks
Really appreciate the feedback 🤝
thank you very helpful
Of course. Thank you for your feedback!
I'm a Senior Network Engineer for a major US hospital. I really appreciate this video however is there anything that can provide deeper technical information on how this whole system works? I would like to understand the entire data flow from start to finish. For example, what TCP/UDP ports need to be open between source/dest for this communication to successfully transfer? We currently have an intermittent issue where some studies transfer without issue and other times where is just gets hung up. We see a DICOM packet with a "provider abort" message in the packet capture however this really only tells me that the Xfer failed, not WHY it failed. I would also like to better understand how DICOM handles congestion issues? Please let me know if and/or how I can go about getting a much deeper understanding of how these flows are supposed to function? Thanks again!
For DICOM connectivity, it will be TCP IP only. The DICOM port is set by the application. 104 is commonly used but this varies depending on the application or the preference of the app administrator.
In our experience, when study transfers fail intermittently with a generic error such as yours it is difficult to tell whether this is network or application related. For this reason the best approach is to host a working session between the app vendor, the pacs admin and your networking team to replicate the issue while capturing a Wireshark or network trace. As a senior network engineer you may have gone this route already and perhaps ruled out any network specific connectivity issue.
Therefore this emphasizes the need to put pressure on the app vendor to investigate further on the error. Perhaps turning on verbose logging, attempting to replicate in a test environment can reproduce the same error. Certain DICOM images can be more troublesome than others. For ex Mammography studies can take significantly longer to transfer due to file size. Some images being 4Gigs can timeout causing the entire study to hang. This timeout is set on the application and would need further investigation on the app vendor side. Another reason it could hang is bc of DICOM metadata that does not conform to the standard or has special characters that are not allowed or accepted by the receiving system. This just a few examples of several app related reasons for failure that we cannot cover in conversation. That is why we stress a coordinated effort with heavy escalation on the app vendor side.
Not sure if this helps but good luck on your efforts.
10 possibilities for PACS fail transfer