北京清華長庚醫院臨床數據歸檔設計與實踐

張 燦 劉海一 湯云杰 唐 堯 沈玲菲 桑振華

北京清華長庚醫院（以下簡稱“我院”）開業初期就開始使用電子病歷總覽系統，由于覆蓋的業務分支有限，運營幾年后已不能滿足日益精進的業務需求。因此，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。本次規劃中沒有將其納入歸檔范圍內。