醫保數據中臺建設的實踐與思考

黃 越 彭思翔 羅 源 倪劍文 朱曉娟 施鑫杰 梅 好 王雅迪

（1騰訊云計算（北京）有限責任公司 北京 100193；2騰訊科技（深圳）有限公司 深圳 518057）

1 背景

隨著醫保覆蓋率的不斷提升、醫保制度的不斷完善，我國對醫保精細化管理的要求愈發強烈。信息化作為實現醫保精細化管理的重要手段，已成為我國醫保體系建設的必然趨勢，而數據中臺作為國家醫保信息化系統中的重要組成部分，也成為實現醫保精細化管理的有效途徑。

從2000年-2009年建立的社保管理信息系統核心平臺一版、二版、三版，到2018年國家醫保局成立后開始進行的全國統一醫療保障信息平臺建設，醫保信息化建設已經積累了20多年的寶貴經驗。在這20多年中，醫保信息化得到了很大的發展。在業務層面，醫保信息化從主要面向經辦發展到兼顧經辦、監管、公共服務和決策；在架構層面，醫保信息化從最初的C/S架構發展到當前基于政務云和專有云的HSAF架構。此外，伴隨著大量醫保數據的積累，醫保信息化系統也從面向事務發展到面向“事務+大數據分析”。當前的醫保信息平臺頂層設計在核心業務區中明確規劃了大數據區，并在該區域內通過數據中臺來支撐大數據的存儲、加工和應用。

在目前的醫保信息平臺建設中，我國是以“中臺+子系統”的方式進行的。其中，中臺部分包含了業務中臺和數據中臺，業務中臺是基于國家醫保局下發的程序代碼進行部署，數據中臺則基于我國發布的《醫療保障信息平臺數據中臺建設及應用指南》（以下簡稱《指南》），需要各地對建設的內容和需求進行消化吸收后再具體建設實施；子系統部分共包含14個子系統，遵循強約束、基礎約束和弱約束的原則在下發的代碼版本上進行建設。

2 數據中臺建設的具體架構

數據中臺建設需要對《指南》進行深入解讀，結合醫保信息平臺建設場景需求，對應具體的內容，進而加以建設實施。結合數據中臺建設和大數據應用的經驗，通過對《指南》中的6大模塊、16大功能需求進行詳細分析，可梳理出數據中臺所對應的建設內容。

2.1 大數據計算引擎

此部分內容主要對應建設當前主流的、經過實踐的大數據存儲和計算引擎，包括Hadoop和Spark等離線計算引擎，以及Spark Streaming和Flink等實時和流式計算引擎，以滿足大吞吐量的計算場景和高實時性的計算場景。

2.2 數據集成

此部分內容需要包含數據采集和數據集成兩個模塊。其中，數據采集指通過離線同步、實時同步、文件傳輸等方式，將新平臺生產的業務數據、地方歷史業務數據、平行委辦局共享數據等來自各個數據源的數據傳輸到數據中臺；數據集成則負責將這些縱向（不同時間維度）和橫向（不同空間維度）的數據納入同一個框架下進行統一使用。

2.3 數據倉庫

該部分內容由大數據倉庫和數據資產管理共同組成。其中，大數據倉庫按照《指南》的建議分為緩沖層、操作數據層、通用數據模型層、數據應用層，并承擔相應的功能；數據資產管理是大數據倉庫的頂層管理系統，負責根據當前大數據倉庫的存儲內容，實時對其庫表、主題、血緣（指表與表之間的生成關系）、權限等進行梳理，并提供相應的管理和展示界面，方便各醫保局的大數據倉庫管理人員對當前的數據資產進行把控。

2.4 數據治理

數據治理是當前醫保數據中臺建設中的核心部分，包含數據標準(模型)管理模塊、數據質控管理模塊及數據轉換模塊。其中，數據標準(模型)管理模塊管理和融合不同來源、不同版本的數據元數據、數據值域等，以保證數據中臺最后提供的數據在符合國家標準要求的統一框架下運轉；數據質控管理模塊優先承載國家下發的各個版本的質控要求，并在此基礎上擴展地方業務需要的其他質控標準；數據轉換模塊是數據中臺工作流的核心模塊，提供從數據源到數據倉各層的可視化工作流配置，并將數據標準和數據質控融合其中，帶動數據中臺的整體運轉。

2.5 數據服務

數據服務主要依照《指南》，通過API接口、數據庫接口和數據文件接口，提供數據寫入和更新等數據類服務、數據查詢類服務、數據運算類服務。

2.6 數據應用

數據應用主要由應用支撐和應用集市構成。其中，應用支撐包含BI（智能報表分析工具）、可視化大屏、機器學習平臺等組件，在數據的基礎上進一步提供數據分析和深度加工的支持；應用集市負責托管、分類標記和組織各類醫保應用。

2.7 數據安全體系

數據安全體系包含角色權限配置管理、數據庫表權限審批管理、數據服務脫敏、數據查詢行級限制等功能，其從數據采集、數據存儲到數據服務和應用，貫穿于整個數據生命周期，因此并未在表格中直接體現（見表1）。

表1 數據中臺對應的建設內容

3 數據中臺建設的實踐與經驗

從明確具體的建設框架和功能模塊到實際完成建設還有很長一段路要走。在數據中臺建設的實際打磨中，一整套實施方法和路徑逐漸形成，為當前醫保數據中臺標準化的成型及下一步實踐提供了方向。

3.1 實施方法和路徑

實施方法和路徑是實施效果和質量的保證，尤其是對于醫保數據中臺這類功能多、對接方多、角色復雜的系統。根據數據中臺建設經驗，可總結出主要的實施步驟。

3.1.1 環境調研

部署環境是一切系統部署實施的基礎，當前數據中臺的主要建設目標是采集業務數據、完成省級數據上報和支持應用子系統建設，因此至少需要調研4個環境情況：一是數據中臺本身的部署環境。這部分主要包括數據中臺部署所需的硬件情況、網絡情況等，硬件和網絡配置會直接影響數據中臺大數據引擎的計算速度、存儲能力和服務調用效率。二是業務數據源環境。業務生產數據庫是數據中臺的主要數據來源，為了防止業務生產數據庫壓力過大，通常將與生產庫主備實時同步的生產備庫作為業務數據源。業務數據源環境要將數據庫的網絡環境、吞吐能力、是否支持實時同步機制（如：binlog獲取）等情況調研清楚，以明確制定數據采集策略，并提前申請測試庫進行測試。三是省級交換庫環境。數據上報是省級數據中臺建設的使命之一，一方面要確保省級交換庫的版本滿足國家要求，另一方面要確保省級交換庫與國家交換庫及數據中臺的網絡已打通，同時需要詳細了解交換庫的讀寫機制（如：XA機制）是否與數據中臺的大數據環境相匹配。四是應用數據庫環境。為了提升應用子系統對運算結果數據的統計和查詢速度，在省級平臺建設架構中，往往會在數據中臺和應用子系統之間設計大規模并行分析數據庫（MPP庫），因此，需要提前調研了解MPP庫所使用的產品特性，并提前申請測試庫進行測試。

3.1.2 數據歸集

數據歸集是數據中臺部署完成后的主要任務，主要包含數據模型收集、數據歸集兩部分。其中，數據模型收集包含了數據建表所需的元數據等信息，需要在數據實際歸集前進行創建。在實際工作中，會有大量的數據庫表歸集到數據中臺（目前數量級上千），在數據中臺會有4個大的數倉層，因此，在數據中臺中會涉及大量的數據模型創建工作。為減輕該部分工作所帶來的人力消耗，同時降低人工出錯率，數據模型創建主要采用批量收集建立的方式進行。數據歸集則可以大致劃分為歷史數據歸集和增量數據歸集，其中，歷史數據歸集采用一次性采集的方式進行，增量數據歸集則采用定時任務配置或實時任務配置的方式進行周期性采集。

3.1.3 數據治理

數據治理作為當前數據中臺建設的核心使命，主要包括6方面內容：一是數據質控鏈路規劃。其是指在數倉各層的工作流中規劃數據質控節點的位置。當前上報國家的庫表為數據中臺歸集庫表的一部分，因各地在數據應用中存在個性化差異，需要根據各地的建設需求，優先合理化規劃各條鏈路中的數據質控規則及質控方式。二是國家質控規則注入。其是指將國家最新版本的交換庫質控規則注入中臺質控規則庫，并通過版本管理的方式對國家交換庫質控規則的更新進行跟進。三是質控規則擴充，針對地方應用需求，對質控規則庫進行擴充及管理。四是質控規則啟用及質控報告，按質控鏈路規劃的質控方式啟用相應的質控規則集，并對質控報告結果進行跟進。五是質控結果反饋及治理，質控問題通常可以分為兩大類——業務生產數據問題和地方國家標準不一致問題。針對第一類問題，采用反饋至業務廠商并推動業務側改進的方式進行提升，而第二類問題通常是由于地方業務編碼顆粒度與國家下發標準不一致而引起的，因此可以通過數據轉換先行治理，并經由合理的方式向國家反饋。六是數據上報國家，將國家上報鏈路中治理后的數據上傳至省級交換庫，并持續跟蹤國家側對上傳數據的檢查反饋結果。

3.1.4 數據服務及應用

數據服務及應用作為當前數據中臺建設的另一核心使命，需要完成以下工作：一是數據庫表訪問權限。根據各個應用子系統建設廠商的使用需求，完成相應數據表權限的開放，并控制權限的讀寫設置，避免子系統間產生不必要的影響。二是應用子系統建設支撐。對各應用子系統廠商進行數據中臺的使用培訓，并及時解答廠商使用中的各種問題，以確保各應用子系統廠商可以正確地使用數據中臺，完成子系統的上線。三是數據資產管理發布。通過數據中臺中的“數據資產模塊”完成地方數據中臺數據資產的梳理，并對管理方進行培訓，以保證數據資產管理方可以通過數據資產模塊，快速、完整、動態地管理地方數據。

3.1.5 上線運維

完成以上任務后，即可進行數據中臺正式環境的整體上線運轉，但由于數據中臺功能多樣，大數據環境運維本身也較為復雜，為保障數據中臺的正常運轉，還需長期持續運維。

3.2 功能優化

醫保數據中臺涉及大量的庫表，需要對接多個系統，使用需求較為豐富，因此在實際落地實施的過程中，需針對各功能的使用做出相應的優化和改進。

3.2.1 自動批量建表

醫保場景下涉及數千個庫表模型的建設，若單純靠人工錄入或以寫腳本的方式建設，在消耗人力、拉長周期的同時，也容易出現人為錯誤。因此，可以通過自動批量導入建表的方式，快速、高質量地完成數據庫表模型的建立。

3.2.2 自動關聯大部分質控規則

目前，國家下發的交換庫質控規則已有數千條，如此大量的質控規則很難靠人力逐條錄入并維護。在分析國家質控規則庫后，可對規則進行詳細分類，并將其中絕大部分規則融入到建表環節一同關聯建立，從而減少質控規則錄入和管理的成本。

3.2.3 多樣化的質控方式

在實際建設過程中，各地不同應用及上傳國家的鏈路對質控的要求各有不同，因此，在數據中臺中，可以通過強質控（過濾臟數據）、弱質控（僅生成質控報告）和阻斷質控（阻斷臟數據鏈路）等方式對不同需求場景進行支持。

3.2.4 鏈路數據轉碼

地方編碼和國家編碼間的差異往往是大部分臟數據形成的原因，這其中既有業務因素，也有歷史因素。為同時保證上傳國家的數據質量（臟數據少）和數量（總體數據多），可以在鏈路中支持數據轉碼，把既往的“臟數據”轉化為國家要求的編碼數據。

3.2.5 常用功能算子化

一般的數據中臺僅支持數據同步、數據腳本等通用型算子，利用這些算子可以實現當前醫保數據中臺的需求，但這需要編寫大量腳本，工作量較大。為減少工作量，可將數據質控、數據轉碼等醫保場景下常用的操作進行算子化，方便可視化工作流的配置及后期的維護。

4 數據中臺建設的痛點及優化思路

目前，各地的醫保數據中臺建設已能夠基本滿足當前階段的使用需求，但在各地實際使用的過程中仍存在痛點，亟須優化。

4.1 數據治理體系

當前的醫保數據中臺已經在多個環節上引入國家下發和地方拓展的質控規則，并通過數據轉換、強弱質控等操作滿足了目前建設階段的基本需求。然而在各地的實際使用過程中，仍存在“零散化”的質控方式，無法完全滿足整體把控數據治理情況、各質控環節效果展現不夠清晰、部分環節仍存在缺失等問題。因此，作為數據中臺核心任務的數據治理需要向更體系化的方向進行優化。結合既往的經驗，數據治理體系應當至少實現數據標準、數據轉碼、數據對賬、數據質量、數據資產在業務上的聯動。

4.1.1 數據標準

數據標準作為數據治理的起點，除了目前已經涵蓋的元數據等數據模型信息外，還需包含各個庫表、字段、值域等相關聯的數據質控規則，即數據質控規則應當在數據模型建立之初就進入到整個體系內，而不是在后續工作流中進行補充，這樣一方面可以在整體標準層面維護和掌握所有的質控規則，保證各層數倉的一致性和透明度，另一方面還可以統一質控規則的分類、標簽等，便于對大量的質控規則進行統一管理和分析。

4.1.2 數據轉碼

數據轉碼是醫保數據中臺中最常見、數量最大的數據轉化操作之一。為避免不同鏈路手動轉碼出現的各類錯誤，需要增加統一的數據轉碼管理子模塊對數據轉碼進行管理。數據轉碼是建立在數據標準之上，對不同數據標準之間關聯性的進一步約束。通過該子模塊的增加，整個數據中臺中的數據將得到進一步規范。

4.1.3 數據對賬

醫保數據中臺涉及多層數倉，其間的工作流由各個不同廠商共同參與使用和修改。因此，各層數倉的表間出現各類不一致性的可能性較大，從而導致最后的出口數據受到此前鏈路上各節點數據的影響而出錯。為最大限度避免此問題，需要在數據治理體系中引入數據對賬環節。這里的對賬既包括數據層面的對賬，如數據量、去重后主鍵數量等，也包括業務層面的對賬，如參保人數、就診人數、基金支出等，以滿足實際工作中對數據準確性把控的復雜需求。

數據對賬中比較特殊的一類需求是業務源數據庫與數據中臺的數據對賬。由于該類對賬及后續數據問題的處理均涉及兩個獨立系統之間的聯動，因此，需要針對兩個系統的設計特性進行特殊的修正處理。醫保業務子系統的設計需求使得醫保業務庫可進行物理刪除或更新等操作，但是由于業務庫事務特性和大數據倉庫分析特性的區別，該類操作會引發兩側數據的不一致。因此，該類對賬問題的修正還需要通過引入實時同步等方式對業務庫物理操作進行捕獲并同步至數據中臺。

4.1.4 數據質量

數據質量指的是整體數據質量的把控，而不是某個節點的質控報告結果。整體質量把控是建立在數據標準和數據轉碼基礎之上，對整個數據中臺各個環節中數據對賬、數據轉碼、數據質控的綜合把控。醫保數據中臺中各層數倉之間有較為復雜的工作流關聯，若需要每日掌握各級工作流的工作狀態和生成結果，需要到各層的表中進行查看和統計。為把控整個中臺的數據質量，需要添加統一的工作流看板，自動統計各層的工作情況并進行展示，同時支持對工作節點進行下鉆以掌握具體的工作執行細節，從而使管理者能夠快速掌握并定位可能存在的問題。

4.1.5 數據資產

數據質量把控著工作流間數據庫表變化導致的數據質量變化，即工作流上的數據質量。除工作流上的數據質量，我們還需要把控從采集到存儲、應用、共享各類節點上的數據質量，這就需要一個完整的數據資產模塊來完成。當前的醫保數據中臺已支持數據資產管理模塊，但是數據資產管理模塊主要針對中臺內的數據資產進行梳理，未形成完整的體系。完整的數據資產應實現從數據收集到數據處理、應用、共享全生命周期的全面覆蓋，需要覆蓋數據資產采集（哪里來）、數據資源目錄（怎么看）、數據資產管理（怎么管）、數據共享使用（怎么用）和數據安全管理（怎么保證安全）。

4.2 大數據倉庫體系

當前的醫保數據中臺已經在分布式文件存儲系統上初步形成了分層的大數據倉庫，但是醫保大數據倉庫從設計、使用上暫時仍未完全發揮大數據引擎的能力，仍存在各項目數倉建設規范不同、數據操作在各層數倉之間劃分不清晰等問題，一方面使得大數據引擎的能力受限，另一方面也導致了資源利用不合理。一個完整的大數據倉庫體系一般包含大數據倉庫規范、數據指標、分析引擎等，結合既往經驗，建議從數據倉庫、數倉應用、新型聯機分析處理（OLAP）引擎引入方面進行優化。

4.2.1 數據倉庫優化

數據倉庫是一切計算和分析的基礎，但因其多分層的結構也使其使用和維護的難度加大，因此需要在開始便明確數據倉庫的建設規范，并通過權限管理、規范約束等保證后續使用符合此規范，從而避免數倉使用的混亂。依據《指南》的規定及以往的實踐經驗，數據倉庫優化可實行以下細化方案：（見圖1）。

圖1 數據倉庫細化方案

其中，各層功能的約定包括以下幾個方面：一是緩沖層（STG層）。緩沖層存儲數據源采集到的原始數據，一方面可以作為后期數據溯源或問題數據恢復的最初源頭，也可以實現與數據源的數據對賬，保證采集到的數據與數據來源一致。二是操作數據層（ODS層）。操作數據層主要實現元數據統一，通過對不同來源數據進行結構轉化，保證來自不同數據源的同一業務數據的表結構一致，以實現數據結構的統一，這其中包括醫保新老系統的元數據統一、橫向委辦局的元數據統一等。三是明細數據層（DWD層）。明細數據層在操作數據層之后實現明細數據的進一步標準化，這其中包含了數據去重、內涵治理等，在此層后提供的數據均為標準化數據。四是匯總數據層（DWS層）。匯總數據層在明細數據層之后面向主題進行主題數倉建設，主題數倉建設一方面是為提升主題內的查詢效率，一方面也希望針對后續主題使用場景，對某些維度和事實進行預匯總，以便于后續使用。五是數據應用層（ADS層）。數據應用層在數倉的最后面向應用進行進一步的使用優化，目前在醫保數據中臺中主要有兩個使用場景，即面向報表應用、面向子系統應用。六是維度數據層（DIM層）。維度數據層貫穿后幾層的使用，主要提供一致的維度數據。維度數據主要由主數據等組成的高基數維度表和數據字典等組成的低基數維度表構成。七是臨時數據層（TMP層）。臨時數據層主要服務于查詢的中間結果或臨時結果，不做長期存儲。

各層間數據轉化約定主要包括以下幾個方面：一是STG到ODS層。由于ODS層主要實現元數據統一化，因此，在STG到ODS層的過程中，主要需要完成數據轉換，包括表結構、表名、字段類型、字段名的轉換等。二是ODS到DWD層。DWD層可實現數據的全標準化，因此，在ODS到DWD層的過程中涉及大量的數據質控和數據清洗工作。這里的數據質控包括國家下發規則的質控以及地方面向業務需求的拓展。質控的主要目的是通過質控規則發現數據問題，包含清洗前質控和清洗后質控，而清洗的主要目的是對發現的數據問題進行修正或提出修正建議。在這個過程中的數據清洗包括通過智能化手段進行數據貫標、數據值域的轉換，實現數據的去重、去除數據表間的不一致性、全局或準全局數據信息抽取和補全等。三是DWD到DWS層。該步驟中針對規劃的主題進行數據表合并、字段行轉列等工作，其實施方式需要兼顧業務需求及OLAP引擎特性進行具體設計。四是DWS到ADS層。該過程中主要面向具體的使用場景，進行進一步的數據轉換和聚合，以便于最后的使用，并提升場景中的查詢速率。

4.2.2 數倉應用優化

當前醫保數據中臺對應用的支撐方式主要是各個應用獨立從數據中臺中取數進行分析統計，存在統一指標重復計算多、各應用統計口徑不一致的情況。此外，數倉應用層的組織方式和表設計暫未針對大數據OLAP引擎進行優化，難以發揮引擎的最大優勢。為優化當前存在的問題，可對各個應用的統計需求重新進行主題化組織，面向主題和引擎特性進行表設計，統一進行指標輸出，這在優化問題的同時，也可以在一定程度上避免未來子系統擴展而導致計算需求快速擴張的問題（因為有些指標不再需要重新計算）。

4.2.3 新型聯機分析處理（OLAP）引擎引入

目前，大數據社區中不斷有新的高性能OLAP引擎推出（如Presto、ClickHouse等），可以將這些引擎引入醫保數據中臺，以進一步提升醫保數據中臺的OLAP性能。

5 總結與展望

醫保數據中臺是醫保進一步邁向大數據的標志。當前，各地醫保數據中臺的建設為未來醫保數據中臺的發展打下了堅實的基礎。雖然目前醫保數據中臺的建設離其他行業完整的數據中臺建設仍有一定的距離，但可以預見的是，隨著各地醫保數據中臺使用的深入和數據中臺使用需求的增多，醫保數據中臺將會逐漸在各地經驗的積累下從“指南”走向“標準”，不斷隨著醫保大數據的應用共同成長，最終實現醫保大數據應用的智能化，并不斷向著智慧化方向發展。