簡介一份面向醫(yī)療信息化從業(yè)者、健康管理專業(yè)學(xué)生及關(guān)注智慧醫(yī)療趨勢讀者的專題文檔系統(tǒng)梳理大數(shù)據(jù)在健康醫(yī)療中的落地場景與應(yīng)用方向。壓縮包中共有1個docx文檔大小約83KB篇幅精煉、主題集中。目前已有60人瀏覽/學(xué)習(xí)。文檔從智能健康監(jiān)測設(shè)備、醫(yī)療檢測共享屋、手機APP預(yù)約與無紙化病歷、智能家庭醫(yī)療終端等多個真實場景入手解釋了遠程會診、一鍵問診、健康顧問隨訪等服務(wù)形態(tài)并延伸到可穿戴設(shè)備輔助初步診斷、藥品配送與緊急救助聯(lián)動、從出生開始的全生命周期健康檔案管理以及對流行病監(jiān)測和精準醫(yī)療的支撐作用。閱讀后可以幫助讀者理解大數(shù)據(jù)如何改變傳統(tǒng)就醫(yī)流程、推動個性化醫(yī)療與主動健康管理也適合作為健康醫(yī)療大數(shù)據(jù)科普文章、課堂展示或項目報告的參考資料。1. 大數(shù)據(jù)時代的健康醫(yī)療從數(shù)據(jù)堆積到數(shù)據(jù)資產(chǎn)第一步該落在哪一家中等規(guī)模的醫(yī)院HIS、EMR、LIS、PACS 一年能產(chǎn)生上億條結(jié)構(gòu)化記錄影像數(shù)據(jù)更是以 TB 為單位往上漲。但真到了要做科研回顧、運營分析或者輔助決策的時候你會發(fā)現(xiàn)大部分數(shù)據(jù)躺在那里動不了字段對不上、標準不統(tǒng)一、歷史數(shù)據(jù)缺項、接口文檔早就過期?！按髷?shù)據(jù)時代的健康醫(yī)療”說了很多年真正的瓶頸不在于買多貴的集群而在于把分散的業(yè)務(wù)數(shù)據(jù)變成可計算、可復(fù)用、可信賴的數(shù)據(jù)資產(chǎn)這件事始終沒被認真做完。這篇文章想聊的就是這條落地路徑——數(shù)據(jù)從哪來、治理怎么做、平臺怎么搭、安全怎么兜底以及中間那些不親自踩一遍根本不會信的坑。適合正在做或打算做醫(yī)療數(shù)據(jù)項目的團隊參考。2. 健康醫(yī)療的數(shù)據(jù)治理與標準化三類來源、一套主數(shù)據(jù)、六步落地醫(yī)療大數(shù)據(jù)項目最容易犯的錯誤是“數(shù)據(jù)還沒治理就開始建平臺”。平臺建得再大進去的是臟數(shù)據(jù)出來的一定是臟報表。健康醫(yī)療數(shù)據(jù)的治理本質(zhì)上是在跟“多系統(tǒng)、多廠商、多標準”這件事較勁誰能把源頭理清楚誰的項目就成功了一半。2.1 三類數(shù)據(jù)來源決定了你治理工作的優(yōu)先級醫(yī)院的數(shù)據(jù)不是“一種數(shù)據(jù)”它至少來自三個完全不同的世界。第一類是業(yè)務(wù)系統(tǒng)數(shù)據(jù)HIS、EMR、LIS、RIS/PACS、手麻、重癥監(jiān)護這些是結(jié)構(gòu)化程度最高、也是日常分析最依賴的數(shù)據(jù)。但它們的問題是“各建各的”同一患者在掛號、住院、檢驗系統(tǒng)里可能是三個不同的 ID。第二類是物聯(lián)設(shè)備與實時數(shù)據(jù)床旁監(jiān)護儀、呼吸機、可穿戴手環(huán)這類數(shù)據(jù)頻率高、時序性強、噪聲大經(jīng)常斷點續(xù)傳存儲成本和治理成本都不低。第三類是外部交換數(shù)據(jù)區(qū)域衛(wèi)生信息平臺轉(zhuǎn)過來的隨訪記錄、醫(yī)保結(jié)算數(shù)據(jù)、居民健康檔案格式差異最大質(zhì)量也最不可控。我把這三類數(shù)據(jù)擺在面前時通常先按“業(yè)務(wù)價值高、治理成本低”的優(yōu)先級排序而不是一味去啃最難的硬骨頭。下面這張表是常見的判斷底子來源典型格式時效性優(yōu)先治理的問題業(yè)務(wù)系統(tǒng)HIS/EMR/LIS結(jié)構(gòu)化表、XML準實時/次日患者主索引、編碼字典統(tǒng)一物聯(lián)設(shè)備/可穿戴時序流、JSON秒級/分鐘級數(shù)據(jù)清洗、斷點補傳、單位歸一外部交換/平臺下發(fā)CSV、JSON、HL7消息定時批量字段映射、重復(fù)數(shù)據(jù)、歷史欠賬分清來源之后才會有治理的邊界意識哪些字段只能信源系統(tǒng)、哪些字段需要自己加工、哪些數(shù)據(jù)直接棄用。醫(yī)療數(shù)據(jù)治理的第一步不是寫清洗腳本而是先畫這張來源地圖。2.2 主數(shù)據(jù)與術(shù)語標準先統(tǒng)一患者、科室和字典醫(yī)療數(shù)據(jù)治理的“方言”問題非常典型。同一個患者門診系統(tǒng)里叫“張三”住院系統(tǒng)里叫“張三男”體檢系統(tǒng)里存的則是身份證號。如果不先把患者主索引MPI建起來后面所有跨系統(tǒng)的關(guān)聯(lián)分析都會翻車。我一般建議優(yōu)先做四套主數(shù)據(jù)患者、科室、員工、關(guān)鍵業(yè)務(wù)字典。其中患者主索引最復(fù)雜需要靠證件號、姓名、出生日期、手機號做相似度匹配而不是只靠單一字段。術(shù)語標準的優(yōu)先級要按分析場景來排。診斷編碼、手術(shù)編碼、檢驗項目編碼是開展 DRG 分析、疾病回溯、科研隊列的命根子藥品編碼不統(tǒng)一用藥分析和抗菌藥物管理根本做不了。常見做法是先定一套“目標編碼標準”然后把各系統(tǒng)舊編碼逐張映射過來映射關(guān)系單獨存成字典表絕對不要直接改源系統(tǒng)里的原始值。這一層的設(shè)計原則是“源系統(tǒng)不動、字典映射先行”保證將來源系統(tǒng)升級時你的治理成果不會一擊即碎。2.3 數(shù)據(jù)治理的六步落地流程與角色分工數(shù)據(jù)治理不是一套工具而是一條流程。我打磨過不少醫(yī)療項目后沉淀下來的落地流程是六步走盤點現(xiàn)狀、確定標準、清洗主數(shù)據(jù)、補全歷史欠賬、配置質(zhì)量規(guī)則、建立運營機制。六步的順序不能亂跳步通常會在后面加倍還回來。步驟具體工作關(guān)鍵產(chǎn)出通常責(zé)任方1 數(shù)據(jù)現(xiàn)狀盤點梳理系統(tǒng)清單、數(shù)據(jù)字典、接口文檔數(shù)據(jù)地圖與問題清單數(shù)據(jù)團隊 信息科2 標準確定確定診斷、手術(shù)、檢驗、藥品編碼體系編碼映射表病案室 數(shù)據(jù)團隊3 主數(shù)據(jù)清洗構(gòu)建患者主索引、科室與員工對照主數(shù)據(jù) MDM 庫數(shù)據(jù)團隊4 歷史欠賬補全核對歷史接口、補齊缺失字段、修復(fù)亂碼歷史基線數(shù)據(jù)集數(shù)據(jù)團隊 廠商5 質(zhì)量規(guī)則配置配置非空、唯一、值域、波動規(guī)則質(zhì)量規(guī)則腳本數(shù)據(jù)團隊6 運營機制建立明確數(shù)據(jù)責(zé)任人、維護節(jié)奏、變更通知治理運營手冊信息科牽頭最后一步最容易被人忽略。數(shù)據(jù)治理是一個持續(xù)運營的活不是項目驗收后就結(jié)束的事。很多醫(yī)院把治理外包做完上線時就發(fā)現(xiàn)新接入的系統(tǒng)又把字典打回原形。關(guān)于這一點合理的做法是成立一個虛擬數(shù)據(jù)治理小組哪怕每月只開一次會也要把“源頭變更、字典維護、問題數(shù)據(jù)閉環(huán)”這三件事常態(tài)化否則治理成果就是個一次性快消品。3. 健康醫(yī)療大數(shù)據(jù)平臺怎么搭從選型到分層再到調(diào)度數(shù)據(jù)治理理清了“數(shù)據(jù)長什么樣”接下來要解決“數(shù)據(jù)放哪里、怎么算”。健康醫(yī)療大數(shù)據(jù)平臺的搭建最重要的決定通常不是選哪個組件而是先想清楚“以離線為主還是實時為主”這個決定直接影響整個平臺的復(fù)雜度和運維成本。3.1 先做架構(gòu)選型離線為主還是流批一體我見過的醫(yī)療大數(shù)據(jù)項目絕大多數(shù)業(yè)務(wù)場景都是離線批處理科研隊列回顧、運營指標日報、DRG 分組分析、病種費用統(tǒng)計這些場景對實時性的要求是 T1 甚至 T7。真正需要實時的場景其實很收斂主要是危急值提醒、院感實時監(jiān)測、設(shè)備異常告警這幾類。因此架構(gòu)選型上我非常不建議一上來就鋪開完整的流批一體體系那會讓運維復(fù)雜度成倍上升而業(yè)務(wù)收益并不明顯。更穩(wěn)妥的做法是“離線數(shù)倉為主干、輕量實時鏈路做補充”。離線部分承擔(dān)所有歷史分析、報表和科研取數(shù)實時部分只處理少數(shù)幾類高價值事件用輕量消息隊列加流處理引擎把結(jié)果寫進獨立的實時服務(wù)表就停不要試圖讓實時和離線共用一套完整的數(shù)倉鏈路。等離線體系跑穩(wěn)了再根據(jù)真實業(yè)務(wù)需求決定是否擴大實時范圍。3.2 數(shù)倉分層與存儲選型ODS、DWD、DWS、ADS 怎么切健康醫(yī)療數(shù)據(jù)進入平臺后我習(xí)慣切成四層。貼源層ODS負責(zé)原樣接入源系統(tǒng)數(shù)據(jù)做最基本的壓縮和分區(qū)不做清洗明細層DWD按照業(yè)務(wù)過程重新組織完成編碼統(tǒng)一、臟數(shù)據(jù)過濾、維度退化匯總層DWS面向主題比如門診主題、住院主題、檢驗主題做輕度匯總應(yīng)用層ADS直接面向報表和接口按最終消費方定制。分層的價值在于每一層職責(zé)清楚出了問題能快速定位不會出現(xiàn)“一張表既當(dāng)貼源又當(dāng)應(yīng)用層”的亂局。存儲格式上我一般這樣取舍ODS 和 DWD 用列式存儲加壓縮因為后續(xù)查詢經(jīng)常只取部分列列式存儲能大幅減少 IOADS 層如果有高頻點查需求則根據(jù)查詢模式?jīng)Q定是否換成行存或引入 OLAP 引擎。分區(qū)策略要按時間切這是醫(yī)療數(shù)據(jù)的剛需因為所有統(tǒng)計都離不開時間維度。常見做法是按日期分區(qū)明細量大的表比如檢驗明細可以按“日期 機構(gòu)”雙分區(qū)避免單分區(qū)數(shù)據(jù)量過大。分區(qū)的另一個作用是方便數(shù)據(jù)回溯——某天跑錯了只需要重跑那一個分區(qū)不用全表覆蓋。3.3 建表與調(diào)度的最小可跑配置這里給一個 ODS 層建表的參考它是我在項目里反復(fù)使用的基礎(chǔ)模板。-- ODS層門診掛號記錄貼源表 CREATE TABLE IF NOT EXISTS ods_his_register ( register_id STRING COMMENT 掛號流水號, patient_id STRING COMMENT 院內(nèi)患者ID未治理, id_card_no STRING COMMENT 證件號-原始值, dept_code STRING COMMENT 科室編碼-原始值, doctor_code STRING COMMENT 醫(yī)生編碼-原始值, register_time TIMESTAMP COMMENT 掛號時間, register_type STRING COMMENT 掛號類型, source_system STRING COMMENT 來源系統(tǒng)標識, etl_time TIMESTAMP COMMENT ETL寫入時間 ) COMMENT ODS-門診掛號貼源表 PARTITIONED BY (dt STRING COMMENT 采集日期分區(qū)) STORED AS PARQUET TBLPROPERTIES (parquet.compressionsnappy);幾個參數(shù)說清楚。分區(qū)字段 dt 是必須的醫(yī)療數(shù)據(jù)每天增量接入有了分區(qū)才能做定點回溯和增量重跑源系統(tǒng)字段原樣保留不要在這里做編碼轉(zhuǎn)換這一步挪到 DWD 層去干存儲格式用 PARQUET 加 snappy 壓縮是離線分析場景里兼顧查詢性能和壓縮率的保守選擇。建表語句刻意把注釋寫全字段注釋不僅是給同事看的更是將來做數(shù)據(jù)字典時的原始素材。調(diào)度配置用下面的模板就能跑起來。我習(xí)慣把定時任務(wù)寫成可重入的腳本保證重復(fù)執(zhí)行不會產(chǎn)生重復(fù)數(shù)據(jù)。# 每日 02:30 拉取前一日門診掛號數(shù)據(jù) 30 2 * * * cd /data/etl spark-submit \ --class com.example.etl.HisIncrementalSync \ --master yarn \ --num-executors 8 \ --executor-memory 8g \ /data/etl/jobs/his_register_sync.jar \ --source his --table register --dt $(date -d yesterday %Y%m%d)調(diào)度時間這么定是有講究的。凌晨兩點半避開了大部分報表的早晨高峰也給夜間批處理留出了緩沖executor 并發(fā)不拉太高是因為直接連的是 HIS 生產(chǎn)庫拉太猛會把源庫壓垮這里 8 個 executor 是相對安全的起始值具體要看源庫負載再調(diào)。腳本最后傳入的 dt 參數(shù)由 date 命令動態(tài)計算這樣即使某天忘記跑了手動補跑時只需要重新執(zhí)行一次寫入的還是同一個業(yè)務(wù)日期分區(qū)不會產(chǎn)生雙份數(shù)據(jù)。這個“分區(qū)冪等”的設(shè)計是醫(yī)療數(shù)據(jù)平臺健壯性的基石。4. 安全合規(guī)與隱私保護醫(yī)療大數(shù)據(jù)項目繞不開的紅線健康醫(yī)療數(shù)據(jù)是個人敏感信息涉及隱私保護和數(shù)據(jù)安全這一點在項目一開始就要寫進架構(gòu)設(shè)計里而不是最后補。安全合規(guī)在醫(yī)療大數(shù)據(jù)項目里不是一個功能模塊而是一組必須貫穿采集、存儲、計算、共享全鏈路的設(shè)計約束。4.1 數(shù)據(jù)分級分類先給每個字段貼上標簽做醫(yī)療數(shù)據(jù)安全第一個動作永遠是分級分類。不把字段級別摸清楚后面談脫敏、談權(quán)限都是空談。我的做法是給每張表的每個字段打安全標簽分成三類直接標識、間接標識、敏感醫(yī)療屬性。直接標識包括姓名、證件號、手機號、家庭住址這類字段能直接鎖定到個人間接標識包括出生日期、民族、籍貫、職業(yè)單獨看沒什么組合起來就能“重識別”敏感醫(yī)療屬性包括主診斷、檢驗結(jié)果、手術(shù)記錄、用藥記錄是醫(yī)療數(shù)據(jù)里最需要保護的部分。脫敏策略要分場景。生產(chǎn)環(huán)境的醫(yī)生工作站查詢要能看到完整數(shù)據(jù)因為診療需要但開發(fā)測試環(huán)境、科研分析環(huán)境、數(shù)據(jù)展示大屏看到的必須是脫敏后的數(shù)據(jù)。下面是一張常見的脫敏策略參考字段類別典型字段開發(fā)測試庫處理生產(chǎn)查詢處理直接標識姓名、證件號、手機號靜態(tài)替換為假名動態(tài)打碼展示間接標識出生日期、民族、籍貫泛化到年份/大分類按角色授權(quán)可見敏感醫(yī)療屬性診斷、檢驗值、手術(shù)默認隱藏按項目審批僅限診療與授權(quán)場景自由文本主訴、病程記錄禁止整段導(dǎo)出關(guān)鍵詞抽取后可用脫敏分靜態(tài)和動態(tài)兩種。靜態(tài)脫敏是把數(shù)據(jù)從生產(chǎn)同步到開發(fā)測試環(huán)境時做一次性的替換替換算法要保證“假名一致”——同一個患者在整張表里始終叫同一個假名否則關(guān)聯(lián)分析就廢了。動態(tài)脫敏是查詢時實時處理適合生產(chǎn)環(huán)境里的大屏展示和運維人員排查問題。我的經(jīng)驗是靜態(tài)脫敏最容易踩坑的是假名不一致動態(tài)脫敏最容易踩坑的是性能損耗這兩種坑后面會細說。4.2 最小授權(quán)與操作審計權(quán)限給到做事的邊界醫(yī)療數(shù)據(jù)平臺最容易出現(xiàn)的越權(quán)場景是“統(tǒng)計分析崗位順手查了患者明細”。最小授權(quán)原則在醫(yī)療場景里要拆得很細醫(yī)生只能看本科室患者的全字段數(shù)據(jù)護士只能看護理相關(guān)字段病案室可以看全院病案首頁但需要脫敏科研人員只能在授權(quán)項目范圍內(nèi)取數(shù)統(tǒng)計分析崗位原則上只能訪問匯總層數(shù)據(jù)。權(quán)限不是按職位名稱給的而是按“做這件事必須要哪些字段”給的。一個比較好用的落地方式是按照“數(shù)據(jù)域 字段范圍 生命周期”三個維度授權(quán)比如某科研項目允許訪問 2020 至 2023 年、某科室、去標識后的檢驗數(shù)據(jù)項目到期權(quán)限自動回收。審計之所以重要是因為權(quán)限總有漏掉的地方。所有查詢、導(dǎo)出、API 調(diào)用都要留下審計日志記錄誰、什么時間、查了什么患者、導(dǎo)出了多少行數(shù)據(jù)。日志本身不能被業(yè)務(wù)人員修改而且要定期抽查。我見過不少項目審計日志開了但從來沒人看直到數(shù)據(jù)泄露事件發(fā)生才回頭翻日志那時候往往已經(jīng)晚了。審計的目的不是事后追責(zé)而是通過“有人會看”這件事讓所有使用數(shù)據(jù)的人保持克制。4.3 數(shù)據(jù)出域與匿名化能不出域就不出域醫(yī)療數(shù)據(jù)最敏感的動作是“出域”——離開醫(yī)院或機構(gòu)的網(wǎng)絡(luò)邊界。常見的科研協(xié)作場景里數(shù)據(jù)需求方常常希望拿到一份患者明細做分析。我的建議是能不出域就不出域。優(yōu)先考慮“數(shù)據(jù)不動模型動”的模式把分析代碼或模型送進數(shù)據(jù)域內(nèi)執(zhí)行只輸出統(tǒng)計結(jié)果如果確實需要數(shù)據(jù)出域必須經(jīng)過匿名化處理。匿名化不是簡單去掉姓名和身份證號而是要能讓一條數(shù)據(jù)無法再關(guān)聯(lián)回具體個人。直接標識要刪除間接標識要做泛化比如出生日期只保留年份、民族合并成大分類極小樣本量要抑制——如果一個病種在某地區(qū)只有個位數(shù)病例那不管怎么脫敏都不能放出去因為太容易定位。任何出域行為都要有患者知情同意的底子并且走完內(nèi)部倫理與合規(guī)評審流程。這個底線不能松數(shù)據(jù)哪怕再有用也不能用不合規(guī)的方式拿出去。5. 健康醫(yī)療大數(shù)據(jù)項目的四個常見坑與排查記錄這一章記錄的是我在多個醫(yī)療數(shù)據(jù)項目里真實踩過、或者親眼見過別人踩進去的坑。每一條都不是什么高深技術(shù)問題但都足以讓項目延期幾個月甚至作廢。值得花時間仔細看。5.1 源系統(tǒng)升級后字段悄悄變了ETL 卻報成功現(xiàn)象某天開始數(shù)倉里的檢驗結(jié)果字段大量為空但 ETL 任務(wù)日志全部顯示成功。排查很久才發(fā)現(xiàn)源系統(tǒng)的檢驗結(jié)果字段從數(shù)值型改成了字符串型且新增了單位后綴解析邏輯直接失效數(shù)據(jù)寫入時變成了空值。原因源系統(tǒng)廠商升級時改了字段定義但接口文檔沒有同步ETL 腳本里的映射關(guān)系是寫死的解析不到新格式就靜默跳過了。解決在采集鏈路里加一道硬校驗。每次增量同步開始時先拉取源系統(tǒng)表的元數(shù)據(jù)結(jié)構(gòu)與上次做對比只要有字段類型、長度、可空性變化立刻終止任務(wù)并告警而不是讓它帶著錯誤跑完。另外所有 ETL 同步任務(wù)要監(jiān)控“解析失敗行數(shù)”當(dāng)失敗比例超過閾值我一般設(shè) 0.1%時直接置為失敗。這條規(guī)則能擋掉大部分靜默問題。5.2 “住院人次”四個字三張報表三個數(shù)現(xiàn)象運營部門、財務(wù)部門、臨床科室各出一份月報三份報表里的“住院人次”互相都對不上甚至差出 10% 以上管理層開會時當(dāng)面質(zhì)問。原因三個部門對“住院人次”的定義不一樣。運營部按“入院登記數(shù)”算財務(wù)部按“醫(yī)保結(jié)算數(shù)”算臨床科室按“實際占用床日推算數(shù)”算。同一個指標分子分母的窗口期、統(tǒng)計口徑完全不同但報表都叫同一個名字。解決建立指標口徑字典把每個指標的定義、計算公式、數(shù)據(jù)來源表、統(tǒng)計窗口用文檔鎖死。所有報表必須從同一個匯總層取數(shù)不能在應(yīng)用層各自寫一套 SQL。這件事看起來是管理問題其實技術(shù)上有明確的解法把口徑的“計算邏輯”固化成平臺里的一個視圖或存儲過程所有報表都從這個視圖取數(shù)而不是各寫各的。誰的報表要改口徑必須走評審流程改的是公共邏輯而不是單個報表。5.3 事后才發(fā)現(xiàn)臟數(shù)據(jù)已經(jīng)把下游模型污染了現(xiàn)象一個科研成果回顧項目進行了兩個月突然發(fā)現(xiàn)納入分析的 5000 例患者里有 300 例的性別字段全是“未知”而這 300 例集中在某兩個月。因為這兩個月源系統(tǒng)換了新界面下拉框默認值沒有提交全部寫成了空。此時很多中間表已經(jīng)跑完了只能全部回刷。原因數(shù)據(jù)質(zhì)量校驗只在月底跑了一次人工抽查而且抽查的是抽樣數(shù)據(jù)沒覆蓋全部月份。臟數(shù)據(jù)在 ODS 層就已經(jīng)進去了后面治理和建模時沒人發(fā)現(xiàn)一路傳到了最終數(shù)據(jù)集。解決把數(shù)據(jù)質(zhì)量規(guī)則前置到采集和加工鏈路里規(guī)則不通過就阻斷下游。這個做法我先賣個關(guān)子在最后一章專門展開。這里只提前說結(jié)論質(zhì)量校驗不能是事后抽檢必須變成每天調(diào)度鏈路里的自動關(guān)卡寧可當(dāng)天數(shù)據(jù)晚出也不能讓錯誤數(shù)據(jù)往下流。5.4 平臺建好了臨床科室就是不進來現(xiàn)象大數(shù)據(jù)平臺上線半年數(shù)據(jù)中心在持續(xù)接入數(shù)據(jù)但臨床科室的使用率極低?？蒲腥藛T寧愿繼續(xù)用 Excel 從 HIT 系統(tǒng)里手工導(dǎo)數(shù)據(jù)也不愿意碰平臺。原因平臺建設(shè)是“以數(shù)據(jù)為中心”而不是“以用戶為中心”。數(shù)據(jù)團隊埋頭做完了所有分層建模卻沒有和臨床科研人員坐在一起搞清楚他們最常用的取數(shù)場景是什么。結(jié)果就是平臺上每一張表都得寫 SQL 才能取到而臨床醫(yī)生根本沒時間學(xué) SQL。解決每個醫(yī)療數(shù)據(jù)平臺都應(yīng)該配一個“通俗查詢層”常見問題用可視化的方式建成模板某種疾病的歷年發(fā)病人數(shù)變化、某科室的 30 天再入院率、某類手術(shù)的并發(fā)癥分布做成預(yù)設(shè)查詢臨床人員勾選條件就能出結(jié)果。技術(shù)上的要點是這些模板要建在 ADS 層之上底層再怎么重構(gòu)模板不動。平臺好不好用不看數(shù)據(jù)接了多少而是看業(yè)務(wù)人員能不能自己拿到答案。6. 用質(zhì)量規(guī)則前置給下游模型上一道保險最后一章我想把一個具體技巧講透把數(shù)據(jù)質(zhì)量校驗做成調(diào)度鏈路上的“關(guān)卡”用可量化的規(guī)則擋掉臟數(shù)據(jù)。這個方法在所有醫(yī)療大數(shù)據(jù)項目里都適用是我自己吃過虧之后才養(yǎng)成的習(xí)慣。質(zhì)量規(guī)則前置的核心思路是在 ODS 層加工完成之后、DWD 層開始之前插入一組質(zhì)量檢查任務(wù)檢查不通過則下游任務(wù)直接暫停。規(guī)則不需要多先覆蓋四類最關(guān)鍵的問題——唯一性、空值率、值域合法性和波動異常。下面這個 SQL 是校驗 ODS 層門診掛號表的模板-- 質(zhì)量校驗檢查指定業(yè)務(wù)分區(qū)的空值率和主鍵唯一性 SELECT count(*) AS total_cnt, sum(CASE WHEN patient_id IS NULL OR patient_id THEN 1 ELSE 0 END) AS null_patient_cnt, count(DISTINCT register_id) AS distinct_register_cnt FROM ods_his_register WHERE dt ${biz_date};這段 SQL 跑完后調(diào)度腳本里需要做判斷如果 total_cnt 為 0說明增量任務(wù)可能漏拉數(shù)據(jù)直接失敗如果 null_patient_cnt 除以 total_cnt 超過 0.1%說明源系統(tǒng)側(cè)出了問題阻斷下游如果 distinct_register_cnt 不等于 total_cnt說明存在重復(fù)主鍵同樣要阻斷。值域校驗則可以針對性別、婚姻狀況這類枚舉字段檢查是否出現(xiàn)了預(yù)期之外的值。波動校驗更進一層拿最近 7 天的日均數(shù)據(jù)量做比較如果某天數(shù)據(jù)量突然掉了一半大概率是源端同步出了問題而不是業(yè)務(wù)真的發(fā)生了波動。把這段 SQL 和判斷邏輯包一層殼就能嵌入到任何調(diào)度系統(tǒng)里。我習(xí)慣的做法是單獨建一個 quality_check 的腳本目錄每條規(guī)則對應(yīng)一個可配置的 SQL 文件和一個閾值配置項失敗時拋出帶錯誤碼的異常。這樣后續(xù)加規(guī)則不需要改調(diào)度主流程只要加一個 SQL 和閾值即可。這層“質(zhì)量護欄”帶來的直接收益是下游建模團隊不再需要每天質(zhì)疑數(shù)據(jù)對不對他們默認平臺給出的數(shù)據(jù)是可信的只有在極少情況下才會收到質(zhì)量告警。這個習(xí)慣源于一次深刻的教訓(xùn)。某次模擬項目 X 里我為了趕進度跳過了質(zhì)量前置結(jié)果一個字段映射錯誤在三天后才被發(fā)現(xiàn)導(dǎo)致所有下游模型全部重跑整個迭代晚了整整兩周。從那以后我給自己定了一條鐵律數(shù)據(jù)質(zhì)量規(guī)則不是“等有空再補”的優(yōu)化項而是和數(shù)據(jù)接入同步建設(shè)的必選項。規(guī)則當(dāng)天跑通、當(dāng)天生效沒有例外。健康醫(yī)療大數(shù)據(jù)這條路上真正的成本門檻不在集群和算力而在“讓數(shù)據(jù)可信”這件事上。質(zhì)量關(guān)卡前置看似只是一個小小的工程習(xí)慣但它是整個平臺能持續(xù)輸出價值的底線。希望幫到你。本文還有配套的精品資源點擊獲取