关于锐科PACS的傲娇DICOM Print协议

博客随笔 DICOMPrintScp1.2.840.113704.

最近遇到了一个傲娇的锐科PACS工作站

具体情况是这样的:

某个同鞋(同事)反馈对接某医院影像工作站的时候其中一台DICOM通信无法通过验证,然后可以确认的是网络 配置什么的都没有问题,但设备验证通信时确实提示错误的,服务端这边实际是可以收到通信请求的,也没有报其他任何错误,工作站提交打印弹出错误提示 如图所示![锐科PACS--56(02-1130)]

锐科PACS--56(02-1130)

作为一名没接触这方面多久的新人 一脸懵逼,问对方的工程师也是表示无能为力,也就是说只能靠自己 毕竟公司也确实没有这方面的大神,完全得靠自己摸索

一般情况!想要实现一个打印SCP服务器对接打印SCU客户端只要双方的SOP Class UID能够协商一致就可以完成打印通讯。

根据医院实际情况问题排查的到情况

  1. DICOM通讯可以产生正常响应,即通讯网络正常 但C-ECHO不通且无法打印
  2. 服务器没有报错,即代表SCU提交的SOP Class UID 服务端SCP处理都已经协商通过
  3. 医院对接过其他自助DICOM打印系统 ,C-ECHO测试验证无法通过 但是却可以正常打印

基于以上三个判断 可以确定问题是出在协商通信这块,最开始以为是某个协商协议被我忽略或者拒绝掉了,导致通讯失败。但由于对方工程师无法提供相应的具体错误日志,只能将通信时的协议一个一个的输出测试,最后发现即使全部都接受还是情况一样。反反复复的测试十来遍都不行

相关推荐
免责声明 本站部分内容来源于互联网公开资源分享学习交流,若其中有侵犯到了您的权益 还请邮件联系我方删除