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