【e医疗原创】互操作平台、ESB和CDR，此平台与彼平台的辨析
想说点儿什么？欢迎点击文章下方“写评论”留下您的精彩观点。
——编者按——
提起西游记里的真假美猴王，大家并不陌生，孙悟空与六耳猕猴，一个真，一个假，难以分辨，但在终极大BOSS（如来佛祖）面前，六耳猕猴还是现了原形——也是神物，非美猴王而已。
关于医疗信息平台，行业目前盛行三类提法：互操作性平台、ESB、CDR。厂商各有侧重的宣传，使这三类平台出现了概念、提法方面的混淆。但是在终极大BOSS（临床用户）面前，精准、便捷、及时的那一个，才是BOSS最想要的那个平台——其他的，也是好平台，只是不能满足互操作性的平台，难以负“医疗信息平台”之名而已。
文
上海岱嘉医学信息系统有限公司
傅海
2015年11月，岱嘉医学联合e医疗微信平台进行了一次有关互操作性医疗信息平台知识的有奖竞答活动， 以促进大家参与对这些平台本质的理解和厘清。
我们选取了当前市场上被称作“平台”的三类最典型的医院信息化解决方案，分别是：（1）符合国际医疗信息互操作性的全院平台，即互操作性平台； （2）应用在医疗业务中的、常常被称作“集成平台”的企业服务总线，即ESB；（3）基于HIS系统数据库、电子病历数据库的临床文档中心，即非标准CDR。竞猜问题及参考答案见表1，参考答案中的“正确”或“错误”，是针对这三类系统本身的功能特性，在其达成整体性能的前提下能实现的效果。
表1 三种平台的功能辨析
*市场对三种平台的功能理解高度相似
图1：竞猜者对三种平台功能理解是高度相似的
我们把每题回答“是”（即认为某方案具备此功能）的人数绘成曲线图，于是看到了一个有趣的结果：虽然事实上，这三种“平台”在技术上存在着十分巨大的本质差异，但竞猜者对于三种“平台”的功能理解是高度相似的（见图1），大家认为这三种“平台”是差不多一样的。
这份数据留给我们的印象是：行业中对一些最基本概念的正确介绍和宣传是远远不够的，一些厂商的商业宣传也进一步造成了误导。
根据表1中我们对ESB功能勾选情况可以看出，ESB作为IT行业很成熟的一类系统集成产品，简化接口开发（问题1）、消息的发送和接收（问题7）属于其核心功能，但正确地勾选了这两项功能的竞猜者只占50%和28%。而ESB无法实现的很多功能，却有很多（远高于问题7或1）的竞猜者勾选了“是”（附图中的红色曲线）。这个现象和我们与医院内同行日常交流中所观察到的情况相吻合， 即，ESB这样一个企业服务总线，被夸大成医疗信息平台进行宣传，使很多同行信以为真；而对ESB本身功能的正确介绍却又很少。类似的现象对于非标准CDR也存在，读者可以对比参考答案与实际答案，这里不着更多笔墨。我们来对三种方案一些最主要的技术差别和实现效果进行分析和解释。
**谁的实时性最佳？
实时或及时地从系统中得到电子病历信息或管理统计数据，是许多医护人员和医院管理部门都希望实现的效果（问题5，问题11）。三种方案是否存在差异呢？
我们给出的参考答案是：互操作性平台正确，而ESB、非标准CDR错误。针对问题5，只有35%的竞猜者正确选择了互操作性平台，与错误地选择ESB （33%）和非标准CDR（39%）的比例差不多；针对问题11，仅有21%的竞猜者正确地勾选了互操作性平台，而有更多数量的竞猜者错误地勾选了ESB （27%）和非标准化CDR（27%）。
为什么只有互操作性平台是正确的呢？互操作性平台把数据共享的及时性作为核心目标之一，通过平台软件一系列的互操作功能，能把各个业务子系统产生的新的患者信息或文档数据，进行实时或及时的识别、转换、注册和存储。由于数据采集和平台包含的临床文档中心内容更新能够做到实时或及时，使得医护和管理人员随时随地通过自己的应用系统从互操作性平台得到所需数据成为可能。
相比之下，ESB尽管有很强的传输服务和中介功能，可以通过消息机制实现接入ESB的各个子系统之间的数据传输和联动，但本身不具备互操作性的数据采集功能，无法完成数据文档的及时采集和转换。当采用ESB 来进行系统集成和数据传输时，必须依靠其他软件（例如ETL）来完成数据采集、转换和存储，这在实际操作中当数据抽取频率较高时，系统就会死机，所以很难做到数据采集的及时。
非标准CDR通常是依托一个已有的主要业务系统（HIS或电子病历）的数据库，或者单独建立一个中间库，可以通俗理解为一个数据大池子。子系统的数据，不论数据结构，直接倒在池子里，之后再依赖ETL工具对大池子中的数据进行处理，形成CDR，然后才能实现BI数据挖掘、展示、和其他应用。因此，与采用ESB做“平台”一样，采用非标准CDR的通常做法，是在系统不忙时（如夜间）进行数据处理，以减少对子系统和中心库造成的压力。这么做的代价是数据无法实现实时、及时、按需地抓取利用。
***谁更能精确管理患者临床文档？
问题6涉及到“同一患者临床文档的精确关联”，我们提供的参考答案是：互操作性平台正确，而ESB、非标准CDR错误。仅有31%的竞猜者正确勾选了互操作性平台，分别有31%、34%的竞猜者选择了ESB和非标准CDR。
患者主索引（EMPI）的建立是所有以患者为中心的临床文档关联的基础。按照IHE框架下PIX（患者索引建立）和PDQ（患者参考信息检索）规范建立的患者主索引，是目前确保主索引数据准确性最全面的方案。按照PIX/PDQ规范，EMPI的建立要运用一套复杂的逻辑算法，综合多种就诊索引号（身份证号、医保号等）以及多种参考身份信息（姓名、性别、地址、电话号码等）进行身份匹配。PIX/PDQ规范在制定时充分考虑了各个国家地区、社会文化、医疗体系、应用场景下各种患者身份信息可能存在的形态，因此遵从PIX/PDQ开发的互操作性平台的EMPI模块和匹配算法，为各种业务场景下都能建立高度准确的患者主索引提供了保证。
如果要实现临床数据的关联，非标准CDR也必须建立EMPI。但通常的做法是在各个子系统的患者索引之间搭建映射表。在复杂多变的业务场景中，映射表方式会产生大量匹配失败和匹配错误。当然，非标准CDR也可以采用综合的身份参考信息、复杂的匹配算法，采用这些方法能够显著提高主索引的准确性，但是遵循经过广泛论证、实践检验后形成的行业成熟标准肯定是最直接、最可靠的方法。
ESB是解决系统间消息传递的工具，但其本身并不包括EMPI服务，由ESB来实现患者主索引和文档关联无从谈起。
****谁能进行消息管理？
互操作性的定义“在需要的时间、把需要的信息、推送到需要的人，并有意义的使用”，在问题7关注的“及时推送各类消息（如危急值）给使用者” 功能中，得到了充分体现。哪类解决方案能够做到呢？我们提供的参考答案是：互操作性平台、ESB可以实现，而非标准CDR不能。仅有26%的竞猜者正确勾选了互操作性平台，29%正确勾选了ESB，而78%正确地否定了非标准CDR。
互操作性平台包含了ESB作为自身的消息引擎，实现接入子系统之间、子系统与平台之间的数据交互。危急值数据，在生产子系统中产生，按照预定规则判断，达到阈值后系统自动触发消息，依据ESB中预先设定的路由规则、权限传递到指定子系统，推送给指定使用者角色，以弹窗、短信等形式实现提醒功能。
非标准CDR，在没有ESB功能的情况下，要实现危急值等消息的推送，只有通过子系统之间的两两接口触发器进行，而现实中，这种做法在多个分布系统间协同很多流程的消息传递时是有较大局限性的，这也是ESB产生的原因。
*****谁面向的用户更广？
医护人员从自己使用的诊疗、查房、护理等系统中，都能获得所需要的电子病历信息（问题2），我们认为互操作性平台可以实现，而ESB、非标准CDR不能。65%的竞猜者勾选了互操作性平台，另有44%的竞猜者分别勾选了ESB和非标准CDR。
我们的参考答案之所以认定ESB、非标准CDR为错误选项，并非因为它们一定不能把患者的检查、检验等电子病历信息分享到临床电子病历系统、查房系统或护理系统，而是因为现实中这样做的结果往往是数据不能及时展现、系统稳定性差，使得实用意义大打折扣，或者用户因使用感受差而放弃使用。而互操作性平台因能做到及时、完整、准确地产生符合CDA结构的临床文档，形成标准化的CDR，其他系统就可以及时准确地通过得到所需要的信息，并且系统的性能和稳定性是有保障的。从这个意义讲，问题2的正确选项是互操作性平台。
以上来源：e医疗2015年12月刊
12月阅读
您可点击订阅号下方菜单栏阅读“推荐”、“特别报道”中的往期精彩内容。
重要行业资讯
刊首语
点击查看“‘分级诊疗背景下的远程影像”专题精彩内容：
【e医疗原创】相距3500公里：一个完整的远程生态链是如何运行的？
【e医疗原创】邵逸夫医院：多层次灵活的影像帮扶可作为分级诊疗的探路者
【e医疗原创】百年老店说：当用户开始寻求整体服务而非单一产品时
推荐关注
e医疗2015年12月刊
“e医疗”原创文章，转载请注明来源。
▶e医疗
医疗卫生信息化资讯平台
微博 | @ e医疗
微信 | e-healthcare
杂志 | e医疗