北京清华长庚医院临床数据归档设计与实践

张 灿 刘海一 汤云杰 唐 尧 沈玲菲 桑振华

北京清华长庚医院（以下简称“我院”）开业初期就开始使用电子病历总览系统，由于覆盖的业务分支有限，运营几年后已不能满足日益精进的业务需求。因此，2018年我院提出重新规划建设新的临床数据共享平台。

我院为新临床数据共享平台设定了4个目标：一是为临床提供一套统一的查阅病历的数据平台[1]；二是以“患者为中心”来组织构建临床数据结构[2]；三是希望这个数据平台可以成为未来临床数据长期留存的场所，减小业务系统的数据负荷过重的问题；四是通过统一口径管理进出平台的数据，使实际操作更便捷，管理上更有效。明确了目标之后，又将思考如何将全院数据更高效、更安全、更完整地组织在一起，建设一套临床数据仓库（clinical data repository，CDR）体系。

临床数据仓库体系包括数据归档、权限管理和数据展示3个部分。其中数据归档是整个CDR体系的核心，对数据的实时性、内容完整性、准确性都提出了要求[3]。数据归档包括数据采集、加工、收集、归档处理（图1）。

图1 数据归档流程架构

1 系统规划与设计

1.1 数据归档功能设计

基于临床业务系统产生的数据进行有目的的采集、加工、集成、归档，形成临床数据仓库。随着临床业务系统不断产生新的数据，通过增量数据同步，将新产生的临床数据源源不断地抽取到临床数据仓库中，确保临床数据仓库与业务系统数据库准实时同步。

基于以患者为中心的共享平台目标，为了将整个医疗体系的临床数据集成共享，我院为每位患者在平台中建立患者主索引（enterprise master patient index，EMPI）[4]，在患者全球唯一标识符（globally unique identifier，GUID）与医疗机构内患者唯一标识之间生成患者交叉索引（patient identifier cross-referencing，PIX）。体系内各医疗机构有新患者建档时，通过PIX检索该患者是否已经在共享平台建档并生成GUID，如果没有，则生成患者的GUID；如果已经生成，则增加一个GUID与该医疗机构患者唯一标识的PIX。

基于CDR长期存储有效的目标设计了临床数据索引，即每个临床数据主记录及实际存储位置进行唯一编码注册，建设成为数据记录与存储地址一对多的关系。临床归档仓库是按照患者、就诊记录、业务记录的层级关系存储，是面向临床文档数据及文件数据的集合。CDR存储构成见图2。

1.2 数据结构设计

基于为临床提供一套统一的查阅病历平台的目标，需要统一数据接口。数据归档结构设计考虑以下几方面：数据归档业务系统有哪些；临床数据的数据结构是怎样的；增量归档的参考依据是什么。解决完以上问题后，通过各个业务系统的特点，将相关结构以及相似设计进行整合，作为CDR数据存储标准。

业务系统归档范围主要包括患者基本信息（包括过敏史）、就诊信息、电子病历、检查、检验、微生物、病理、护理、手术、输血。随着业务平稳运行，还将增加其他业务分支的归档作业。

面向文档存储的MongoDB数据库的CDR数据存储结构体系，大体分为就诊记录和业务记录两类。就诊记录作为访问业务记录的主索引，它将就诊下的所有临床数据主索引进行映射。业务记录是以临床数据主索引为标记的临床数据集，记录患者就诊过程中临床数据的主信息，可将关联的一对多数据结构记录在下一级节点中。

增量数据范围的确定一般是以业务具有审核标志的时间节点作为认定归档的时间点，比如报告提交时间，医嘱审核时间等。因此，数据结构设计时会将参考时间节点放置在业务记录的节点中。

图2 临床数据仓库存储构成

图3 CDR业务归档模型流程

1.3 数据归档流程设计

基于归档功能设计、归档结构设计，将归档流程建模为一类通用模型（图3）。归档形式上又分为按常规归档、按日期归档、按患者归档3种形式。常规归档用于定期归档任务处理，目前我院为10分钟归档一次所有业务；按日期归档多用于系统初期归档任务；按患者归档一般为处理异常数据时的再归档作业。

为了在归档中不占用过多的系统资源，我院设计了归档运行时序图。通过系统压力测试，模拟各个业务未来5年后的数据规模，记录归档时长，以确定归档定时执行时间及顺序。CDR归档运行时序图见图4。随着业务需求变化，今后可以将时序图进行调整，灵活调度归档业务数据和时间。与此同时，在发生系统故障时，分布式归档对于异常处理也是很有帮助的。

2 系统实践

2.1 CDR归档实践

在CDR归档实践中遇到的一些问题，已通过调整设计或者实施流程得到了解决。

案例1：患者在院区内有多个病历号，病历号合并后，只有一个病历号为有效。在临床数据展示时会将当前无效的病历号显示，造成误解。解决方案是通过在患者交叉索引表中新增字段，区分临床患者标识符和有效患者标识符，实现展示的患者病历号永远为有效的。

案例2：部分业务在实际操作中不会产生就诊记录，这些数据将无法归档。解决方案是在归档过程中不依赖于就诊记录，将归档存储在患者通用记录，保证数据完整、结构统一。

图4 CDR归档运行时序

案例3：过敏记录归档是以就诊为单位归的，但是临床归档数据展示时发现提取数据不方便、效率低。解决方案是将过敏史等不依赖于就诊的记录的临床数据归档为患者通用记录。

案例4：归档一次性运行的业务分支太多或者归档的时间长度选择不恰当，导致占用内存过大，产生系统崩溃的现象。解决方案是将归档时长最长切分，目前我院设定为一天，常规归档时长设定为10分钟；各个业务系统均独立归档，互不干扰，通过运行时序图的形式控制归档流程，可灵活应对突发情况。

案例5：常规归档无监听导致系统归档异常几天后才发现。解决方案是将归档时间进行监听，一旦监听到异常，短信通知系统管理员及时处理。

2.2 CDR归档结果

临床数据阅览是通过各个业务系统场景中调用统一接口实现的。首先根据患者就诊信息选择借阅病历，再经过申请借阅、审核权限、记录借阅日志后方可进入到CDR浏览器中浏览。

3 小结

目前我院已完成主要业务系统的归档作业及临床数据浏览器的应用。下一步将讨论的课题有电子签名归档、病历下载及转移的应用。特别声明，我院的医学影像存储、病理切片等大量影像图片仍存放在独立的服务器中，平台阅览时是通过第三方软件调取出来的，如PACS。本次规划中没有将其纳入归档范围内。