互操作性,来者何人? 推荐

      无论是用户还是厂商,行业对互操作性的重视是机会也是挑战。如果现有的“互联互通标准化成熟度测评”改为面向厂商产品的公开测试,则会像试水大陆市场多年的IHE-C Connectathon 测试一样成为厂商之间交流、比拼、磨合的一个竞技场,对行业更有促进意义。

      在最新的CHIMA《中国医院信息化状况调查报告》中,我们终于在一个方面与美国同行取得了一致:阻碍医院信息化建设的因素排名。双方排名惊人相似——第一缺乏资金,第二缺乏人才,第三厂商能力有限。

  细心的读者会发现我们排名第五项的因素是“缺乏医疗信息化标准”,而美国HIMSS报告排名第四项的因素是“缺乏有互操作性的系统”。文字上的细微差异,表明了两方工程人员思维上的差异:美国考虑的是如何描述问题本身,中国则直接给出了解决问题的手段,并指出手段的稀缺。

  严格来说,“ 标准” 和“ 互操作性” 还是有差别的。维基百科上专门在“Interoperability”词条下用一个章节解释了二者的不同。简言之,互操作性本身是产品(或系统)的一个特性,如同可操作性、易用性、稳定性、强壮性一样,是可以检测的;而“标准”是实现和检测“互操作性”的一个手段。

  美国医院信息化起步早十几年,大一统的HIS不成气候,我们每天面对的问题在美国更严重:医疗机构使用的系统越多,业务关联程度越紧密,最终对系统之间数据集成的要求就越高,因此对不同系统产品之间的互操作性呼声日益提升。HIMSS今年开展了新的认证项目ConCert,就是基于IHE标准分别对电子病历系统(EMR)、集成平台系统(HIE)和健康信息服务系统(HISP)做互操作性认证。

  可能会有人问:“集成平台”不就是解决集成问题的吗,为什么还要做互操作性测试?如果各应用系统都通过了互操作性测试,达到一定程度的“即插即用”,还要集成平台做什么?

  其实,任何一个信息系统只要存在对外数据接口,就有互操作性的优劣之分,基于“标准”的接口当然是具备优秀的互操作性。因为互操作性标准不但定义了数据集成的“语法”,而且定义了“语义”,理想条件下可以直接通过配置工具实现数据集成(医疗信息化领域中,DICOM是最早实现这一理想的互操作性标准)。当年没有行业标准的时候,各系统接口互相对不上,集成平台的“界面引擎功能”就唱了主角,在各系统之间充当协议转换的“翻译官”。现在各业务系统都具备标准化的接口(良好的互操作性),就需要集成平台本身也具备标准化接口(通过互操作性测试)才能快速实现集成。此时集成平台的总线服务、术语服务、消息路由等功能才能发挥出来,当年唱主角的“界面引擎功能”退居二线了。所以,在互操作性得到重视的时代,集成平台的价值和能力才能得到充分体现,那些拿着“界面引擎工具”诈称集成平台的厂商原形毕露。

  这样来看,互操作性仅是用来解决数据集成问题的,且这把尺子是用来考核产品考核厂商的,优良的互操作性并不直接为终端用户提供任何功能上的优势。

  十年前行业专家开会讨论“如何建立医疗信息化标准”的时候,李包罗老师就提出一个问题:“医院信息化标准解决的是厂商产品的问题,是不是应该由厂商来主导制定啊?为什么是一群医院的用户代表在开会呢?”问得大家一时语塞。

  十年后的今天,在这个问题上“眉毛胡子一把抓”的事儿还有。有些医院参加过“医院信息互联互通标准化成熟度评测”后有点窘迫:该测试一方面要求集成结果,一方面考察集成手段,这对于使用用户来说是不是过于苛求了?

  如果现有的“互联互通标准化成熟度测评”改为面向厂商产品的公开测试,则会像试水大陆市场多年的IHE-C Connectathon 测试一样成为厂商之间交流、比拼、磨合的一个竞技场,对行业更有促进意义。

 

  无论是用户还是厂商,行业对互操作性的重视是机会也是挑战,借刘禹锡的一句诗共勉:千淘万漉虽辛苦,吹尽狂沙始到金。

(文章来源:e医疗2015年10月刊)

最后修改于 星期二, 24 11月 2015 15:53