【e医疗原创】朱杰：关于CDR，事情正在起变化

想说点儿什么？欢迎点击文章下方“写评论”留下您的精彩观点。

e医疗专栏作家：朱杰

北京嘉和美康信息技术有限公司市场总监

　　关于CDR这件事情，自诞生之初就有一些争论：到底是“临床数据中心”（Clinical Data Repository) 还是“临床文档库”（Clinical Document Repository)。 2010年之前，当电子病历系统还没有占据医院信息系统半壁河山的时候， 似乎由各大PACS提出的以CDA标准为基础的“临床文档库”更是一个让人放心的技术方案。

　　其实，在2010年之后我们发现各大PACS公司确实没有虚晃一枪，而是货真价实地开始在市场上推广自己的“临床文档库”产品，明眼人一看就知道其实是大家都是充分利用了各自在DICOM文件存储、注册、归档、解析、调用、展示方面的底层技术，将其扩展到CDA文件应用，而推出的临床文件管理产品。

　　无奈计划往往赶不上变化，当这类产品真正上市的时间已经是2013年以后，这时候整个市场已经对电子病历结构化数据处理和应用提出了更高的要求，来自不同业务系统的数据必须以某种规范的形式进入一个独立的数据库随时等候不同维度的查询调阅，远不是文档存储、调用、浏览那么简单。于是，CDR逐渐回归到了“临床数据中心”的定位。 偶尔有人再提以临床文档为基础的数据存储系统也是谨慎地定位为“归档”系统，而非“数据应用”系统。

　　为此，笔者还一度很坦然地四处宣讲CDR的四大分离特色： “业务应用系统与数据应用系统分离、数据采集界面与数据展示界面分离、过程数据与结果数据分离、数据存储与数据注册分离。”认为这样，终于可以清晰地定义一个教科书式的“临床数据中心”系统，不再与前端业务系统有纠缠不清的关系。

　　然而好景不长，从2013年开始关于“CDR只包含‘结果数据’”这个命题也出现了争论。用句网络用语：对于CDR处理过程性实时数据，最初我是拒绝的。想想看，一个非实时的CDR系统有着严谨稳定的数据结构，基于公开的数据标准，远离业务系统的纷纷扰扰专心接收和转换解析临床数据，将自己的主要计算能力贡献给数据分析和数据展现，这是多么让人神清气爽的产品格局。

　　直到经历了几个电子病历资深用户的现场，发现一个隔岸观火的“非实时CDR”系统确实不能够满足机构对临床数据中心的期望。

　　首先，越来越多的专业系统需要实时临床数据的支持。最典型的就是“智能感染控制”这样的后台质控系统，系统本身不产生数据但是凭借优秀的专业知识库可以从各个业务系统中抓数据来给出人工干预提示，检验报告里面的检验值、药房系统里面的用药信息、HIS系统里面的床位占用时间、病历系统里面的诊断和手术代码，都需要对在院患者以住院次为轴线实时抓取。如果医院没有一个“实时CDR”，那么智能感控就会把HIS或者电子病历系统作为主要数据来源甚至是“数据二传手”，搞的两大业务系统不堪其扰。

　　其次，从医院角度来说，原先分布在医生工作站、检验医技系统、手术麻醉系统等等各个前端系统的临床知识库，需要有一个集中部署和管理的地方，否则医务处每次加载一个诊断--检查规则，或者用药——诊断规则，都要一连串的业务系统调整前端代码，这实在不是个好办法。

　　总而言之， 医疗机构在信息系统实现全流程覆盖之后，发现日益强大的规则库“无处安放”。这时候一个“非实时CDR”就犹如鸡肋了。 那么如何从“非实时CDR”进化成为“实时CDR”呢？CDR再次发挥其有容乃大的特长，将原先若即若离的集成平台（准确的说是企业集成总线ESB）拉入怀抱。

　　获得过程性临床数据（例如：检验报告数值的变化、尚未执行医嘱的下达、在院患者的诊断变化和转科情况）最可靠的途径就是ESB集成消息的持久化数据库。将ESB纳入CDR范围之后，集成消息的持久化数据成为CDR中新的数据成员，临床规则的引发和干预消息的发出正是借助这个新成员才能实现并融入前端业务系统。

　　当然，在2015年的今天我们还只能说“实时CDR”恐怕是个不可逾越的选择，具体的实践和现场验证还需要假以时日。

　　现在能说的只是：事情正在起变化。

以上内容来源：e医疗2015年6月刊

“e医疗”原创文章，转载请注明来源。

---

▶e医疗

医疗卫生信息化资讯平台
微博 | @ e医疗
微信 | e-healthcare
杂志 | e医疗