医疗信息论坛上的两则回复

平时在论坛上我都是潜水居多，突然心血来潮回复了两篇，姑且转载一下，至少在这里，永远不会沉底。

新手求助：如何才能快速学好dicom

对于初学者，先看DICOM第一章，了解DICOM的内容。其实在现实世界中，DICOM真正落地以后，主要就是以下几个方面的协议，因此，你首先要弄清楚这几个方面分别是在DICOM的哪些章节里面描述的。

- 文件格式
- 网络通信协议
- 图像显示方式

然后熟悉一下DICOM文件格式：在网上顺便找几个DICOM文件，用ultraedit等二进制编辑工具打开，同时打开DICOM标准的文档，对照着看。搞清楚一些常用的概念和技术，如隐式显式，大头小头，压缩不压缩，字符编码等。通过具体的实例对DICOM的数据结构建立感性认识的以后，可以看看第三章里面的对象模型，尤其是Patient/Study/Series/Instance之间的关系，是DICOM对象模型的核心。

DICOM文件格式，或者准确地说，DICOM信息对象的数据格式，是学习DICOM网络通信和图像显示的基础。有了这个基础，对于网络通信和图像显示的学习可以并行进行，如果你有一个团队，可以分别让不同的人去做。

关于网络通信协议：找一些可以进行DICOM通信的服务端和客户端程序，如果你们自己有PACS，就更好。然后，找一些比较方便易用的DICOM SDK，用你自己熟悉的编程语言，自己做一个简单的客户端和服务端程序，跟你们自己的PACS里面的服务端和客户端通信，从而获得一个直观的认识。必要的话，还可以用网络抓包工具，看看二进制层面的通信过程，当然也是对照着DICOM标准的文档，一起看。刚开始可以从比较简单的通信过程如echo,store开始，搞清楚一些常用的概念和技术，如SCU/SCP，抽象语法，传输语法，服务类等，有了这些基础，你就可以慢慢学习一些常用的但可能稍微复杂一些的通信过程，如查询检索，存储确认，worklist/mpps，WADO等。

关于图像显示方式，或者说把DICOM文件中的像素编码解码成GUI上的像素的过程：你首先要有一些数字图像的基础。拿最常见的灰度图象来说，你要知道像素深度，窗宽，窗位，LUT等概念，如果你们自己的PACS工作站支持直方图调节（好像Photoshop里也有）的话，对于这些概念可能会有一些更加直观的认识。网上也可以找到很多代码，能够把DICOM像素解码成8位的Bitmap，或者反之，你可以找来看看。不过这个只是个开始，后面还有很多医生常用的图像浏览和处理技术，比如测距，缩放，CT定位线，显示状态，关键对象，悬挂协议，GSDF和一致性显示等，就要你慢慢去摸索了。

[讨论]在医院级别使用的集成平台有哪些呢？表现如何？

赞同wholx的观点，我们的确应该从业务需求出发来考虑集成平台的问题。

首先看看医院的业务。

我想我们这些搞医疗IT的，如果平时工作中到医院去机会比较少，至少自己去看病的时候可以多留心一下。当然最好的情况是，怀揣一颗敏感的心，亲自到医院去体验一段时间。虽然没有这么好的机会，但至少我自己去医院看病的时候，所看到的情况是，楼道里，走廊上，到处都是拿着各种各样的单据穿梭着的病人，各种病原体也随着这些单据到处飘散。想想看，如果集成做得好，会不会出现这种状况？

好了，就算有一天，病人不再需要怀揣一大堆单据，但是他们还是得在各个科室各个楼层之间到处穿梭啊？包括很多行动不便的病人。对于这种状况，我们的确无能为力，这是那些建筑师应该考虑的问题。但集成至少是第一步，集成给病人带来的价值远不至减轻手上的那一点点负担而已，它带来的是更好的医疗服务：医生可以依据你详尽的病史，为你设计最适合你的体质的治疗方案，或者根据你家庭成员情况，为全家设计家庭保健计划；如果你在互信的医院做过检查，不就再需要接受更多的辐射或者献出不必要的鲜血；汇总的医疗记录还可以提供某些公共卫生状况的警示，在全院或者社区范围内定位流行病状况和趋势。。

我们看看以上这些集成能够带来的好处，多半都是跟病人直接相关的，有哪条能让医院直接赚到钱啦？你病人拿着脏兮兮的单据来又怎么拉，我可以用手套接着；你病人多做一次检查又怎么啦，我还可以多赚钱。。但人这一辈子，谁能说他没有当上病人的那一天呢。。

前几天在公交车上看到政府鼓励社会力量投资办医院，我举双手赞成，的确应该杀杀这些公立医院的威风了，要不医疗改革措施再多，也是上有政策下有对策。

但是，作为普通老百姓，谁又敢用自己的健康做赌注去尝试那些私立医院呢，中国的骗子不要太多了。看来还是需要有很多配套的，切实可行的监管啊。。

不管怎么样，稍微有点良知的人，都渴望实现全民共有的，高质量的医疗服务，而这一切的基础，就是集成。

再看看医疗IT厂商的业务。

首先我们必须承认，商务上的技巧永远比技术上的技巧更容易让公司取得成功，尤其在一个不成熟的市场里面。很遗憾，我们（技术人员）还是把责任推给了一个几乎没有人能掌控的东西，比如不成熟的市场、不成熟的社会、不成熟的GOV等等等。。

但是，每个真正懂得信息系统的工程师，都会明白，世界上绝对没有一个all-in-one的系统，你想用一个开发部门级业务系统的方式去开发一个医院级业务系统，是绝对不可能的。这几年很多人，包括HIS业内人士，都在讨论HIS的概念和范畴，还有按照SOA的原则来重新组织各个部门业务系统，这里我就不多说了。我只是想提醒大家，一个定义良好的集成平台，不仅是医院信息科理清各个部门业务系统之间的关系，从而实现更好的业务流程的切入点，更是医疗IT厂商理清自己的产品和产品线规划，从而满足各种个性化的解决方案需求的切入点。

另外，tyq提到标准的问题。不管是院内的标准，还是行业的标准，我们都需要把握一点，我们必须学会驾驭标准，而不是被标准驾驭。尤其是对于集成平台厂商，不管在员工面前，还是在客户面前，过分地强调标准，都是愚蠢的。否则，你就只能跟这标准的屁股跑，而意识不到这些标准（尤其是行业标准）其实都是其他（制定这些标准）厂家已经炒过的冷饭。更加糟糕的是，这些行业标准大多都是业务相关的，而且业务本身也不断的发展和变化，大家还会不断地把这个冷饭炒下去，你就永远没有跟得上的那一天。当然，我们并不鼓励每个厂商都自己搞一个标准，而是鼓励这些厂商积极地参加到这些标准中来。先进的厂商可以根据自己对行业的理解，在标准中加入自己的东西，为别人设立一些门槛，也为了建立行业经验共享和发展的良性循环；后进的厂商可以通过这些标准尽快地理解这个行业的核心业务，因为如果换成软件工程的术语，这些标准给你提供的可是一套很好的领域模型啊。

企业信息化领域的EAI和SOA搞了很多年，也为我们积累了很多经验和教训，其中《SOA实践指南——分布式系统设计的艺术》一书让人受益匪浅。正是因为医院的业务需要坚固需要灵活，公司的产品需要模块化需要互操作，行业的标准需要改进需要优化，才使得集成和集成平台更加有价值。

而这一切最终还是为了老百姓(也就是我们自己）的健康——就算是因为我自己被洗脑了也罢，就让我们这些工程师保持一些纯洁的理想吧。

最后简单回答一下Paullee的问题：

1、你需要瓶颈吗？等到私立医院靠物美价廉的服务取得成功的时候吧。
2、业务上的不同可以从IHE TF ITI中带cross的IP（包括很多在讨论之中的IP）中看出来，技术上嘛，主要就是基于互联网这个平台的各种新东西了。
3、个人的理解不一定准确，总之看到国外不少原来做集成引擎起家的厂商，把他们的集成引擎/平台产品稍微延展一下，比如加上一个集中存储、一个病人ID管理、一个门户等，就变成一个简单的电子病历了。
4、这个不太清楚，请大家指教，总之作为电子病历，存储需求应该是：长期/可靠/海量。
5、虽然这方面经验不多，但不太赞成或不太理解这个观点。信息系统的一步步发展的确要有一个规划，以充分考虑到资金状况、用户接受的过程等。但是在一个好的架构下面，应该没有任何一个部件是必须先上的，如果是这样的话，用分布式领域的术语就是单点故障，这对于要求高可用性的医疗系统，是不可理喻的。