最新消息:欢迎您,亲爱的读者!您可以通过QQ号或新浪、腾信微博账号直接在评论处登录,发表评论并选择转发到微博、QQ空间。

薛万国:数据集成与CDR的构建方法选择

管理视野 HIT金子 7608浏览 评论

来源:HIT专家网          记者:朱小兵

【编者按】3月11日上午,由北京卫生信息技术协会(英文简称:PHITA)在京举办的“稻香湖春季论坛”聚焦当下医疗信息化建设实操当中的热点议题——互操作性与信息平台。解放军总医院医学信息研究所高级工程师薛万国做了以《数据集成与CDR的构建方法选择》为主题的引导发言,其丝丝入扣的分析,专业深邃的洞察,深深吸引了全场注意力,成为本次论坛的最大亮点。HIT专家网在此将其演讲全文整理如下,以飨读者。

今天重点谈谈集成、CDR的技术性问题。我们讨论的集成,除了系统集成,还强调数据的集成、管理和应用。我想重点谈谈数据集成和CDR的构建方法选择。

两类集成需求

我们以医院为主来谈。医院的集成需求包括两类:一是流程集成,二是数据集成。

1、流程集成与数据集成的目标不同

流程集成的目标,是能够实现业务的协同,两个异构系统之间能够实现网络化的业务协同和流程优化。这种集成对实时性要求很高,一个业务申请发出,后面的流程马上就能看到。另外,它涉及过程化数据非常多,比如申请状态、收费等。

数据集成的目标,则是希望把所有医疗数据都能集中、统一地管理。集中管理的好处是,用起来方便,但是它对实时性的要求可以不那么高。只要管理起来能用就行,比如在浏览病历、展现的时候可以调用到即可。

2、流程集成与数据集成的技术不同

这两类需求,实现的技术也不同。

流程集成,通常用集成平台,当然也可以是点对点集成。虽然对集成平台的概念,大家说法不一样。比如业界讨论究竟应该是基于ESB还是HIE,我觉得不用特别强调集成平台是基于 ESB的。为什么?因为集成平台本来就是实现异构系统之间的桥梁,实际上ESB概念本身也不是很清晰的。可以分为广义和狭义理解,广义来说,ESB就是实现异构系统之间的消息分发、交换、转换。这样讲,以前的EAI也是做这件事。这时候,强调ESB就没有意义,都是基于消息的。如果从狭义上讲,ESB是和SOA结合的,是面向服务的,只要业务服务模块往上一插,就可以接收请求和提供服务。如果是这样,HL7 是消息,就不是标准化的服务了。难道说,基于HL7消息的平台,就不符合ESB平台了?因此,不用强调是不是ESB。只要是集成平台就好了。在流程集成上,我相信集成平台产品已经能做得很好。流程集成,只要能够实现实时的交换,消息是实时、多点的转发。

数据集成,采用的技术不一样。其技术实现一定是有中心的,比如注册服务,它不是网状交换的。同时,可以不是消息的,实时性可以不要求那么高。也可以采用比较笨的方法,比如ETL,虽然实时性不够好。有些数据实时是第二位的,首先要能集成到一起。

3、集成平台和CDR是两方面集成功能

集成平台和CDR,可以认为是两件事或两个部件。集成平台解决的是流程集成的问题,解决的是桥梁、数据运输问题;数据集成,解决的是仓库管理问题。比如,心电图报告,链接发过来,可以看数据,但是数据没有拿过来,也就是没有仓库管理。数据集成,解决的是数据仓储问题,就是要用数据仓库管起来。

所以,集成平台、CDR是两部分的功能。有的集成产品既有桥梁的能力,又有管理的能力。很多集成平台,只有桥梁,没有管理。总之,数据集成和流程集成这两类需求,对应的是集成平台和CDR这两方面的功能。

两种CDR构建方式

所以CDR的功能就是数据集成。这样挑明了之后,再来看CDR的构建需求就会简明很多。

实际上,医院对CDR有许多需求。第一,要有长期性。比如电子病历,需要历次就诊信息都要管起来。第二,要有很强的包容性,各种内容,格式都能管理。要求这个“仓库”什么都能放,要求非常不简单。而且,随着技术的发展,医疗数据的内容还在拓展。另外,在支持电子病历的时候,要求CDR尽可能过程化、实时化。当然,还有其他要求,比如提供服务如浏览服务、安全防护等。

具体实现CDR的时候,实际上可以有两种方法:

第一种,内建型CDR。即系统内置了CDR,CDR只是一个大概念,具体采用什么技术、模型,不用管它,只要达到上述效果即可。内置型CDR的好处是,系统设计一体化,比如医生工作站,考虑了数据管理,数据会沉淀下去、组织好,使用医生站的时候,都能利用这个数据服务。亲和性好,数据想怎么用就怎么用,因为都是事先想好的。但是它的问题是,对医生工作站的设计要求非常高,功能要求非常高,不仅是流程怎么实现,还有数据的管理,数据的长期性。最大的问题是,要考虑遗留系统如何处理,因为过去的系统往往没有考虑这些问题。过去的HIS有医嘱、医生站,但是没有电子病历系统,一是没解决病历书写问题,二是内容也没集中。所以,这时候内建系统就不行了,需要引入所谓的电子病历系统。这就给了专业电子病历系统公司很大的空间。这件事做了之后,和原有系统做对接,但是比较麻烦,存在两张皮的问题。

第二种,独立型CDR。即CDR不是内置的,和医院信息系统不是一体化设计,而是独立设计。这种设计的优点是独立性,功能可以独立设计,可以实现各种功能,包括对外的共享;缺点是和内建型相反,它不是一体化设计的。其好处是可以采用全景式浏览或360度,做个链接就行。其弊端是,当需要抽取一些细节信息的时候,处理起来比较麻烦。如果原有系统不具有 CDR的功能,不能实现数据的集中共享,而医院又不可能抛弃原来的系统,只能采取独立的CDR设计,去解决电子病历的实现问题。

到底是内建还是独立型CDR,这是医院要根据实际情况去考虑的。现实情况往往是过去的系统解决不好,所以独立型CDR就有了很好的机会。

CDR的两类数据模型

CDR有一个技术实现的问题,到底采用什么技术。这就首先必须研究CDR到底采取什么数据模型,中间这个D是数据(Data)还是文档(Document)?这就意味着数据模型不一样。包括它的概念模型、逻辑模型、物理模型,这都会影响到具体的使用。

1、面向文档的数据模型利弊

我们可以把电子病历看成是一组文档。这个概念模型,就是以文档为核心的一组模型。逻辑模型可能就是XML或面向对象的数据库。这时候用的时候就是使用文档方式,多数情况下符合我们对电子病历阅读的习惯,因为我们看的是一个报告。但是,当它要抽取数据的时候,比如医院做了很多BI,那么文档其实不适合直接做BI的,因为它不适合抽取数据。

2、面向事务的数据模型利弊

另外一种模型不是文档,而是数据。比如业务数据,医嘱、化验结果,逻辑模型采用关系模型去描述。这种模型的好处是,加工、统计、分析起来相对容易,但是在管理上要比文档要复杂。文档的最大好处是可以打包,甭管什么类型。这样保证数据多样性、兼容性比较比较好,但是关系模型最大的缺陷是,它是严格结构化的,一改软件都要改,但是它的优点是自由度很高,多元化的应用需求容易得到满足。

3、混合数据模型

这样导致我们要做判断:如何兼顾?既要管理方便,又想要好用。

还有一个办法:采取混合模型。比如,把数据保留两份,既有文档,做长期归档保存。比如,电子签名,在文档里是方便,而数据库不大方便处理。还有一个例子,体温单适合文档管理吗?体温单是一个一个数字输入累计的,最后是出院时候形成体温单结果,过程是一个一个动态数据不断累积的。如何在CDR中实现体温单呢?要么是动态输入数据,要么每天更新一个文档,这就是涉及到CDR实现的技术问题。这都是有待大家去认识和交流的方面。

【责任编辑:谭啸】

 

您必须 登录 才能发表评论!