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

来源：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实现的技术问题。这都是有待大家去认识和交流的方面。

【责任编辑：谭啸】