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