DICOM3.0标准中文版开源书籍

DICOM-Chinese,The Chinese version of DICOM 3.0 Standard.

以开源书籍的方式翻译DICOM协议，自发翻译DICOM官方标准，以DICOM协议为切入点，通过阅读、研究、直至翻译，更加全面掌握标准，尤其加深对医疗行业的了解。

随着国内新医改的逐步深入，各行各业的创业者开始涉足医疗行业，无论出于颠覆旧有体制和现行标准，还是出于对DICOM标准了解不足的角度，未来新的医疗大环境下必然需要标准的更新，或新的标准。称之为DICOMX.X也好，称之为XXX也罢。充分研读现有标准，实时关注当下新需求，为改善或制定适应未来医疗环境的新标做准备……

约定：

翻译工作非一人之劳，也定非一人之功。因此需要团队各成员之间协同配合。现约定如下：



1. 各Part的目录参照DICOM3.0标准官方网站，保留英文标题，方便后续检索以及查阅；


2. 各Part的前几部分，诸如Notice and Disclaimer、Foreword、Definitions不进行中文翻译，待后续标准整体翻译工作收尾时，再共同努力给出上述各公共部分的中文翻译；


3. 各Part的Symbols and Abbreviations会有诸多的重合，因此前期刚启动翻译时刻，必然会存在着诸多概念翻译不同的冲突，该冲突平日里可通过QQ群、邮件等方式沟通讨论解决、或者到每个月底统一整合时再修改；


4. 各Part的每一级（例如第二级、第三级、第四级）的内容长度不同，因此翻译工作不做强制要求。只要求每次提交完整一段即可，例如下图红色矩形框都算一段，每次至少提交一个完整段落即可。

……

备注：

博文专栏中介绍过DICOM标准中文版书籍的协作模式DICOM：开源书籍之『DICOM标准中文版』启动计划，之所以选择看云平台目的是希望更多的、各行各业的人员加入，例如英语专业、非医疗从业者都十分欢迎，对翻译中的语法、语言表述，甚至专业知识点进行评判修改。

对于日常工作很少使用版本管理工具的人员来说，看云的操作既简捷明了，又能很好的实现多人协作的目的。当然，如果您是一名IT从业者，已熟练使用SVN和GIT各种版本工具的人员，可以通过Github直接发起Pull requests请求，待审核通过后合并到master主线中。





了解开源书籍项目细节，请浏览ZSSURE的CSDN Blog

欢迎有兴趣者加入，联系：zssure@163.com

开源书籍：DICOM3.0标准中文版

题记：


博客早已不是时下最流行的传播媒介，或许在技术圈子还仅存一线生机。之所以选择技术博客，初衷是为了记录自己工作中的点滴，因为随着岁月流逝，记忆力已大不如从前；其次是为了交流和分享，结交同行和同好，相互探讨从而共同进步；最后是希望能够集合大众所长，做一些更远大、更有意义的事情。

零零散散，原创博文也已写了上百篇，有“DICOM医学图像处理”专栏、有“踩坑填坑”、有“日积月累”，还有近期的“那时今日”系列。之所以分类如此复杂，主要是希望保证原创博文的质量，通过近一年与博友的交流，发现在这及其细分的领域需求很大，而资料甚少，尤其是中文资料。

这样就萌发了之前的想法——以开源书籍的方式翻译DICOM协议。自发翻译DICOM官方标准，以DICOM协议为切入点，通过阅读、研究、直至翻译，更加全面掌握标准，尤其加深对医疗行业的了解。

随着国内新医改的逐步深入，各行各业的创业者开始涉足医疗行业，无论出于颠覆旧有体制和现行标准，还是出于对DICOM标准了解不足的角度，未来新的医疗大环境下必然需要标准的更新，或新的标准。称之为DICOMX.X也好，称之为XXX也罢。充分研读现有标准，实时关注当下新需求，为改善或制定适应未来医疗环境的新标做准备……

Read More

做一个平庸程序员，are you scared?

背景:

一个平庸程序员的自白。近期看到的少有的好文，细细品味，感触良多，思来想去不知如何与作者交流。无论从工作经验，还是从境界，都与原作与译作有一段差距。但很多人都会有相似的经历，说出自己的故事，彼此交流或许是最好的途径。

题记:


编程在外人看来绝对属于脑力劳动，至少从大学教育来看软件工程、计算机专业都是需要很强的理科功底的。然而看看帝都上地、中关村深夜的壮观景象，你又会觉得编程是体力活，要不怎么会被戏称为“码农”呢（当然我觉得“农”这个字用的有点歧视，诸如农民工，农民，他们都是靠自己双手和劳动生活的、最淳朴的人，比所谓的商人高尚n个数量级。怎奈现实“拜金主义”大肆其道，崇尚金钱至上，我等又能奈何呢）。即使程序员自己，想必都时常迷茫犹豫。下面从一个程序员的角度，谈谈自己的感受，欢迎拍砖！

Read More

再次剖析fo-dicom中DicomService的自定义事件绑定

题记：


趁着《从0到1》大火的热潮，近期重新翻阅了一遍《从一到无穷大》（这样是不是感觉整个非负数轴就圆满了^_^）。虽然作为科普类书籍，但是里面的内容还是比较深奥，幸亏有作者精准的翻译，一番细细品味后犹如醍醐灌顶，心中透亮。

一直幻想有外星人、宇宙外生物的存在，从《源代码》描述的“平行世界”，到《星际穿越》的“超维空间”，再到时下泛滥的穿越剧，却总未解开心中那团疑惑。或许只有时间的流逝才能给我解答，只怕光阴荏苒，时不我待。遂突发奇想，想模仿大雄坐时空隧道去看看“那年今日”的我。于是从书柜里翻出了上学时的硬盘，找到了那年今天的学习笔记，有种莫名的激动，闭上双眼努力回想‘那时那景’——这程序好难调啊，还有好多书没看，还有好多事要做——
原来我一直如此单调的生活，汗！

背景：


通过寥寥几笔，只可简单回想“那时那景”，但却清晰记得也遇到了奇葩问题，如同今天的‘坑’一样:


在之前的专栏中曾简单介绍过fo-dicom实现各种DIMSE-C服务，简便快捷，诸如fo-dicom网络传输之C-FIND and C-MOVE。今天在结合WCF使用fo-dicom时遇到了一个问题，“多个序列的文件被写入到了同一个文件中，最后生成了一个多大几个G的大文件”。


起初以为是对WCF中实例模式和对象生命周期，即PerCall、PerSession、Singleton，掌握不清，使得将多次客户端调用共用了同一个存储地址。遂阅读了诸多关于这方面的资料，以及C#中的闭包、变量作用域和变量生命周期相关的资料（详情可参见博文最后参考文献章节【1】【2】）。

最后在单步调试时发现，原来是fo-dicom开源库搞的鬼。基于WCF的C-MOVE服务无法实现同时下载多套数据的根源在于fo-dicom中的DicomService服务的绑定采用的是类的绑定，因此其对于CStoreRequest的事件只能绑定到类一级中。而我们此刻实际的需求是“要根据不同的dicom文件存储到不同的位置，且该位置信息通过dicom文件内部自有信息无法构造”。之前错误的将文件存储信息通过“闭包”【3】的形式传递进了DicomService类绑定函数中，此刻绑定到类的DicomService服务与闭包封送的绑定到对象的存储路径之间出现了矛盾，这也就是最终导致多个dcm序列存储到同一个大文件中的问题。

Read More

Add UserIdentity Sub-Item to A-ASSOCIATE-RQ PDU for fo-dicom(mDCM)

背景:


5月份的前半段好懒惰，手里积攒了好多篇文章，也有之前答应过博友要写的，迟迟未动笔。究其根源，有些许懒惰，但更多的是迷惑和一知半解，虽想写但却不知如何入手，零星的感悟要积累成文还是需要时间去沉淀的，以期尽量做到每篇博文有理有据。

今天正好借着手头新任务的机会，介绍一下DICOM3.0标准中的又一新内容。继之前两篇博文基于JMeter+dcm4che2测试PACS服务器性能的解决方案(前/续篇)中提到的DICOM标准第15部分中的TransferCapability概念，本篇介绍标准第8部分附录D中A-ASSOCIATE-RQ中的UserInformation，以及其扩展UserIdentity（DICOM3.0标准第7部分附录D)

此外，在文章后半段，会通过对比dcm4che2与fo-dicom(mDCM）的实现，同时借助于RawCap+WireShark对实际数据包进行分析，给出扩展UserInformation的实现。

Read More

基于JMeter+dcm4che2测试PACS服务器性能的解决方案（续篇）

背景：


前一篇博文通过扩展JMeter的java请求，结合dcm4che2现有的工具包dcmsnd.bat实现了简单的测试DICOM服务器C-STORE SCP性能的尝试。由于借用了现有的dcmsnd.bat命令行工具，会有诸多的局限性，比如：

1）必须构造命令行中的参数，才能调用dcmsnd.bat，操作多此一举

2）无法准确跟踪一张图像上传完成后的准确时间

3）既然要模拟海量用户并发，需要准备对应的数量的文件，无法通过自动生成dcm的三级UID来自动生成海量测试文件。

Read More

基于JMeter+dcm4che2测试PACS服务器性能的解决方案（前篇）

背景：


目前对于传统WEB网站性能（压力/负载）的测试工具有很多，loadrunner、iperf、siege等，操作都比较简单，这里就不介绍了。然而对于医疗领域内的服务器，通常指的是DICOM服务器，提供满足DICOM3.0标准规定的各项DIMSE服务，诸如DIMSE-C(C-STORE、C-FIND、C-MOVE、C-ECHO)、DIMSE-N(N-CREATE、N-DELETE)等等。倘若使用传统的压力测试工具会有几大局限性：


  1. 常见压力测试工具，通过模拟上千万用户实施并发负载及实时性能监测的方式来实现对WEB服务端的压力测试，且模拟的并发请求多以HTTP或TCP为主。然而DICOM服务无法直接通过HTTP请求进行访问（WADO、WADO-RS服务除外）。

  2. 虽然部分压力测试工具（例如LoadRunner、JMeter等）可以发送TCP请求进行压力测试，但是DICOM服务在TCP基础上还需要继续多次“请求-响应”来完成，通过常见的手动填充TCP数据体的方式无法模拟真实的DICOM请求。

  3. 遵循DICOM协议的PACS影像服务器自身通常有一定的约束，例如模拟多用户同时上传同一组图像（即同时发送同一套数据）时服务端可能会直接忽略数据体来减少负载，即使我们成功模拟了请求，此时的检测的性能并不能代表影像服务器性能上限，测试结果不准确。


Read More

利用Hexo构建自己在GitHub上的主页

背景：


近期在跟圈内朋友谈一件事情：

搭建一个关于DICOM协议的中文社区，以开源书籍的模式，自发翻译DICOM官方最新标准。以DICOM协议为切入点，通过阅读、研究、到最后翻译，更加全面掌握标准，尤其是加深对医疗行业的了解。

随着国内新医改的逐步深入，各行各业的创业者开始涉足医疗行业，无论出于颠覆旧有体制和现行标准，还是出于对DICOM标准了解不足的角度，未来新的医疗大环境下必然需要标准的更新，或新的标准。称之为DICOMX.X也好，称之为XXX也罢。充分研读现有标准，实时关注当下新需求，为改善或制定适应未来医疗环境的新标做准备……

Read More

Hello World ZSSURE

背景：

最近项目中遇到的实际问题较多，且大多是较隐蔽的、不易被发现的错误。究其根源来看，还是对DICOM3.0协议中的细节掌握不够仔细，因而导致在实际编码过程中，常常想当然。前一篇中剖析了由于DicomClient中的AddRequest与Send函数调用逻辑错误导致的System.ObjectDisposedException异常，接下来要讲的是关于DICOM胶片打印的问题，由于在Association Negotiation中PresentationContext协商失误导致DICOM Print SCU在连接某些型号打印机时无法出片。

Read More