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

ironstone

前段时间区域医疗火了一阵，各大平台厂商也是四处出击。但反过来最现实的问题是医院内部的数据交换都还没有实现呢？现在的问题就是那么如果在大型的三级医院内部要进行数据交换现实中可用的那些平台有哪些？性能表现又如何呢？不知道大家有没有看到过什么测试报告、新闻或者使用经验啊？

tyq

平台像插座,应用软件像家电,如果光有个插座,有何用处?
插座公司想做标准,可是家电公司不买帐,凭什么要按插座的标准而不按家电的标准?呵呵,日本的家电到中国,中国就做插座,要不日本就改家电,要不走中间路线,做一个变压器.客大欺店,店大欺客.

wholx

看集成平台的表现是否应该要从业务的需求角度出发制定评价的标准，比如思考业务流程的集成需求和业务流程标准化的需求，这些业务需求对集成平台的要求是什么？

lifegame

赞同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、虽然这方面经验不多，但不太赞成或不太理解这个观点。信息系统的一步步发展的确要有一个规划，以充分考虑到资金状况、用户接受的过程等。但是在一个好的架构下面，应该没有任何一个部件是必须先上的，如果是这样的话，用分布式领域的术语就是单点故障，这对于要求高可用性的医疗系统，是不可理喻的。

wholx

Paullee的第一个问题我想稍微转换一下问。从医院的投资回报比的角度来看，那些使用了几十家软件厂商的不同模块产品的大医院是否应该投资于集成平台从而满足业务需求？从厂商看潜在市场的角度，有什么样特点的医院是真正潜在的集成平台的购买者，有多少医院属于这一范畴？

看了一下上述的讨论，我不知道大家谈到集成平台是不是都在指SOA或者EAI。与应用集成稍有区别的数据集成的技术是不是也在讨论范围之内？

lifegame

看来正如某位先人所说，提问题的学问真的要比回答问题的学问大得多啊。。

其实对于这个问题，我也很想知道答案。。或者这块市场确实还在逐步培养之中？

不过这个行业里面捆绑销售已经成为一种惯用的策略，一些厂商也在买PACS或者HIS的同时，附带一个集成平台（或者小一点，叫集成引擎）的做法，也是有的。多年前，在慢慢培养PACS市场的时候，不也是这样吗。

关于数据集成和应用集成，个人的感觉，从业务上来讲，两者的确有点差别，通常会被划分成集成的不同层面或者不同阶段，以便逐步实施，分开收钱。但从技术上来讲，两者本质是一样的：应用集成无非也是在不同系统之间交换数据，只不过这些数据带上了更多的业务语义，从而对流程的管控产生更加显著的影响而已。虽然业务流程整体的复杂性跟局部的数据流转或者文件共享不可同日而语，但作为一个集成中间件，如果真的能称得上是“平台”级的产品的话，个人感觉应该能同时支持数据集成和应用集成，否则还是不要叫做集成平台，叫做集成引擎就行了。