硬核:用區塊鏈技術改進國家級傳染病監測預警網絡

2020年春節，新型冠狀肺炎牽動著大家的心。作為一名互聯人，我們能在這場戰役中做些什麼？這篇文章，作者從專業的角度，告訴我們，很多事情我們都可以做。

關鍵字：區塊鏈 傳染病監測預警 傳染病直報

相關名詞：國家傳染病自動預警信息系統，傳染病報告信息管理系統，醫院信息管理系統（HIS），國家傳染病網絡直報系統（NNDRS），公共衛生數據交換平臺，公共衛生管理信息系統，ICD-10診斷編碼，人口健康信息平臺，傳染性非典型肺炎（SARS），電子健康檔案（EHR），電子病歷（EMR），國家疾病預防控制中心（CDC）

2020年註定是一個不平凡的年份，筆者懷揣這複雜的心情，在決定寫下本文的時候，最新的國家統計的新型冠狀病毒感染肺炎疫情數據是：

截止2020年1月29日19 : 26時，中國（含港澳臺）確診6081例，死亡132例，治癒116例；已經感染了除西藏自治區外的全國大部分省份——疫情的擴散速度，直追當年的SARS。

要知道：SARS可是17年前啊，無論國內醫療基礎建設，衛生條件，還是配套防疫管理軟體都已經突飛猛進，傳染病自動化預警和防疫也已達到國際先進水平，我怎麼都不敢相信在2020年開春之際，疫情爆發的如此迅猛，如此的措手不及。

懷著對於國內傳染病防疫系統的好奇，筆者查閱了大量疾病監測網文獻，試圖去找到沒有成功預防和及時控制疫情的原因。

因為筆者不是醫護人員，所以本文不講如何防治冠狀病毒；不是政府工作人員，不是微博大V，所以不談論事件的功過是非；筆者只是一名IT技術工作者，我試圖通過技術性和系統性視角去審視和分析當前國內傳染病自動化上報和預警系統的現狀，希望採用新技術，新架構提高傳染病監測預警的透明性和時效性。

更重要的是：筆者是國家公民，有權利和義務貢獻自己的力量參與到國家和社會治理中去。文中涉及專業系統部分如有偏差請讀者及時指正，謝謝！

一、現狀分析

目前國家傳染病上報和監測預警現狀：

我國於 2008 年 4 月在全國 31 個省(直轄市、自治區)就運行了國家傳染病自動預警系統，建立了自動預警與響應機制；已實現39種傳染病的監測數據自動分析、時空聚集性實時識別、預警信號發送和響應結果實時追蹤等功能，目前處於世界先進地位。

同時我國在除國家傳染病自動預警系統外，還相繼建設了國家傳染病報告信息管理系統以及其核心子系統國家傳染病網絡直報系統（NNDRS），實現了基於醫療衛生機構的法定傳染病病例的實時、在線、直接報告；同時為了提高監測數據的完整性和準確性，實現電子健康檔案（EHR）、電子病歷（EMR）等數據的標準化統一採集，也相繼試點和運行了四級人口健康信息平臺和其數據交換平臺（區、市、省、國家）；為了降低診療醫生填寫傳染病報告卡的難度，又打通了醫院HIS系統和直報系統，通過診療病歷自動彈出或人工打開填報頁，半自動提交傳染病報告卡。

具體系統架構大致如下：

由於全國各省建設情況不完全相同，我以下圖作為參照，重點介紹目前國家傳染病報告上報的具體過程：

目前我國傳染病報告上報和預警結構

在一些建設較好的省份可以支持半自動和手工兩種傳染病報告上傳方式，診治醫生可通過醫院HIS系統在填寫電子病歷的時候自動彈出傳染病報告上報，上報後的傳染病報告卡通過四級公共衛生數據交換平臺，對數據格式和完整性補充後（電子健康卡和電子病歷）最終採集到國家傳染病網絡直報系統（NNDRS）中，而國家傳染病自動預警系統通過這些傳染病報告卡，採用固定閥值法和時間模型法（移動百分位數法、累積和控制圖法、聚集性疫情法）以日為單位計算和監測分析39種傳染病疫情情況並向基層醫院和CDC預警。

上報具體業務流程大致如下：

再來看看傳染病報告卡上報的審批過程，傳染病由臨床醫生發現後半自動或人工填寫傳染病報告卡，然後提交院內審核，院內防保科醫生審核後，提交給區縣和市級疾控中心分別審核和補充，最後通過省級和國家級衛生數據交換平臺送往國家傳染病網絡直報系統中。

基於電子病歷直推的傳染病疫情報告流程

註：圖來自孔園園，高桂玲，張清慧，郭曉芹 基於醫院電子病歷直推的傳染病疫情報告與管理信息系統的實踐 2019

無論是系統結構，還是傳染病報告卡的審核提交流程都是層層逐級上傳推進，並實現分級管理。

而上傳的傳染病報告卡結構大致如下：

某基層醫院HIS系統中的傳染病報告卡

二、為什麼這次沒有預警

其實我國的傳染病監測體系已經從舊有的人工上報方式發展到IT化和信息化的上報方式，基本實現全國範圍內39種傳染病數據的匯聚和監測，相比2003年SARS那會兒確實是一種非常大的進步，但現實問題是為什麼在這次重大突發疫情面前，國家傳染病自動化預警系統還是啞火了呢？

筆者通過仔細閱讀「疾病監測網」的相關論文和文獻，分析總結出目前我國的國家傳染病上報和預警機制對於新型的重大爆發式疫情所存在嚴重隱患，具體問題如下：

1. 傳染病報告卡其實是一種對已知的ICD-10診斷編碼的判斷結果，對於新型疾病的確認時間周期長。

從上圖大家可以看到，目前國家傳染病報告卡是依據ICD-10診斷編碼觸發的，是對已知39種傳染疾病的上報，而對於新型傳染疾病需要反覆核實和確認，上報判斷周期長。

雖然報告卡中有疑似上報選項，但每個醫生，每家醫院和當地疾控中心的每次上報都承擔著相應的個人和機構上報準確性的壓力，在沒有確定把握的情況下把疑似病例上報本身就是一種膽量。

註：國家疾控中心在2020年1月24日也才緊急上線了新型冠狀病毒肺炎感染的肺炎的檢測新功能。

2. 傳染病報告卡從發現到上報需要3級人工審批，上報是否成功，人為幹擾因素太多。

目前傳染病報告卡在臨床醫生填報完成後到上報到國家傳染病網絡直報系統，還需要3次人工審批，分別是：院內防保科醫生審核，區、縣疾控中心審核，市級疾控中心審核。

為什麼要這麼多人工審核？

主要是基於國家傳染病上報的對數據的完整性，準確性都有非常高的要求。採用多機構和人員的核實審批，是一種非常保險和穩妥的方式，但對於突發重大傳染病的爆發監測來講，這是一種重大缺陷。

傳染病一旦出現早期流行，來自當地政府的維穩，經濟和民眾壓力都可能影響上報過程的順暢。傳染病報告卡本來是為傳染病的預警監測服務的，但其結構本質確有礙於應對突發重大傳染病的監測。

3. 國家傳染病預警系統的預警模型本質上是規則模型，只能對已知疾病進行檢測和預警。

我國在2008年運行了國家傳染病自動預警系統，建立了自動預警與響應機制，預警數據來自於國家傳染病報告卡逐級上報的數據。

預警模型主要分為固定閥值法和時間模型法兩種，固定閥值法是對15種重大傳染疾病設定出現次數閥值，超過閥值就預警的一種事件模型；時間模型法分為：移動百分位數法、累積和控制圖法、聚集性疫情法，是對18種傳染疾病的探測，其本質是增加時間和空間維度的歷史統計分析，對出現比例超過一定百分比的現象產生預警。

目前我國的傳染病預警系統的預警模型並不是基於大數據分析的條件模型，而只是基於傳染病報告卡的結果規則判斷模型。規則判斷模型必須是對已知傳染病的判斷和預警，所以對新型重大傳播的傳染病基本沒有作用。

4. 國家傳染病上報是逐級審核匯總上報，缺乏透明性，應對突發大規模傳染病流行有缺陷

國家傳染病上報是在臨床醫生發現並填報傳染病報告卡後，通過醫院審核—>區CDC審核—>市CDC審核—>三級數據交換平臺—>國家直報系統的逐級匯總的方式，匯總層次多，人工補充數據和審核流程麻煩，這用於日常數據管理還行，應對突發傳染病流行就捉襟見肘了。

另外，醫院之間缺乏相同症狀病人的數據對比，傳染病報告卡只縱向上傳，並沒有橫向信息共享，對於對其他醫院的提示和預警只能靠國家傳染病自動預警系統，手段單一。

三、改進型建議

優化目前的逐級垂直單向國家傳染病上報網絡，利用區塊鏈分片機制，建立區、市、省和國家四級區塊鏈自動化數據同步網絡，在四級網絡中依託各級的疾控中心，建立突發傳染病數據採集和實時預警自治能力，不完全依賴國家級傳染病預警系統。

利用目前已有的公共衛生數據交換平臺作為每級數據的交換節點，形成實時自動化的數據交換機制。各區之間的傳染病報告數據在市級防疫鏈同步；各市之間的傳染病報告數據在省級防疫鏈中同步；以此類推，到國家級同步全國的防疫數據。

四級防疫鏈像四個車輪一樣，在自動化完成各區、市、省的內部防疫預警工作的同時通過國家級防疫鏈不斷更新和補充其他省份的數據。形成具備一定區域自治能力的防疫網絡。

四級防疫鏈

具體細節如下：

1. 建立傳染病報告卡初次登記上報和人工核實、事後補充雙線異步並行流程

改當前傳染病報告卡填寫、補充、核實、審批、上報的串行流程為：傳染病報告卡初次登記上報和補充、核實、審批雙線異步並行流程。

傳染病報告卡異步並行流程

目前國家傳染病上報體系中對傳染病報告的數據完整性、準確性要求太高，故只能逐級核實，補充資料和審核，以至於耽誤了傳染病上報的最佳時機。

我們都知道：傳染病的誤報會對當地政府的經濟和社會穩定帶來很大影響，這也是為什麼現在我們寧願選用更加穩妥的串行審核上報模式的主要原因。但串行審核上報模式的上報責任和壓力都在醫生，醫院和當地CDC中，故極有可能受政府和人為幹預影響，瞞報和延遲上報。

眾所周知，基於大數據的預警模型對單例數據的完整性和準確性並不做嚴格要求，數據的規模、範圍和時效才是傳染病大數據預警的核心，所以建議一開始放寬傳染病初次上報的權限，醫生和基層醫療機構可以直接上報初次傳染病報告卡。

之後再由防保醫生和區，市CDC人員核實和補充該報告卡。而國家傳染病大數據預警可以利用初次傳染病報告卡提前計算傳染病暴發和擴散趨勢，從而開展預警和準備工作。

2. 分離病歷和檢查報告數據，增加採集傳染病風險性症狀數據

傳染病報告卡本質上是結論性數據，無論疑似或確診都需要花大量時間人為確定。在建立大數據的條件預警模型後，除了採集傳染病報告卡數據，傳染病風險性症狀數據也可以從病歷和檢查報告中分離出來，自動化識別和上報。

建議國家傳染病直報系統增加傳染病風險性症狀數據的採集，傳染病風險性症狀數據，例如：發燒，胸片描述，咳嗽，生化指標等，可通過非結構化數據分析分離和識別，關鍵傳染病風險性症狀標籤，通過四級衛生健康數據交換節點自動上傳，由於並不是直接上傳傳染病報告卡，所以對社會穩定和經濟並沒有直接影響，而對於大數據預警來說可以增加數據的範圍和規模，提高預警精度。

而且傳染病風險性症狀數據的上報把壓力從醫生，醫院和當地CDC那裡轉移到四級衛生健康數據交換節點，用自動化代替人工填報，減少了基層的擔責壓力。

3. 採用大數據條件分析模型，補充原有的規則事件模型，建立國家和基層的雙層預警網絡

上面已經講過，目前國家傳染病自動化預警模型其實是規則模型，規則模型只有預警作用，沒有預測作用。

建議國家傳染病自動化預警系統建立一套「大數據條件分析模型」作為離線預測、預警支持庫，採集除「傳染病報告卡」以外的「傳染病風險性症狀數據」和「網際網路數據」，例如：機票預訂、藥品供應、搜索數據等，構建國家級的傳染病頂層離線預警網絡。同時依託於四級防疫鏈數據實時同步能力，通過區塊鏈智能合約建立基於規則模型的數據實時判斷預警能力。

將目前的國家傳染病自動預警功能下沉到各區，市和省級的防疫鏈中，形成基層實時預警網絡。國家級的傳染病頂層離線預警網絡和基層實時預警網絡雙層同時作用，可以兼顧預警的實時性和預測的大數據分析能力。

4. 建立基於醫院和當地CDC的分布式，點對點，傳染病報告數據共享網絡

區、縣級醫院，區CDC，市級CDC目前是傳染病報告的基本窗口，醫院和CDC有上報傳染病病例的義務和責任，是國家統籌監測、預警和控制疫情的基礎。但對於醫院判斷當前疫情的整體態勢來講，卻只能通過各地逐級匯總後的傳染病報告，經CDC統計後由上至下的統一告知。

我們知道：重大疫情的爆發往往具備突髮型的特徵，而在疫情早期，在第一時間、多醫院、多區域橫向同步報告數據，將極大增強醫生，醫院勇於上報疫情的信心，為一線醫護工作者提供疫情態勢感知，提前準備物資防護提供了基礎保障。建議構建區、市、省、國家級區塊鏈防疫鏈，實現跨醫院，跨區域的疫情數據自動化同步能力，在四級防疫鏈中通過四級衛生健康數據交換節點實現跨區域和層級的數據交換。

單鏈通過區塊鏈自動化節點數據同步能力實現區域內的數據同步；四級防疫鏈通過智能合約可以實現一定基層自治預警能力，可以在疫情爆發早期，在區域內提前控制疫情和範圍。

基層自治型預警

5. 建立基於區塊鏈的防篡改和透明性的上報數據追責存儲機制

我們不希望有重大疫情爆發，但爆發後除了積極控制疫情，治癒患者，清除疫情所給社會和經濟帶來的不良影響，還要積極總結經驗教訓，我們需要一套完善的追責體系，需要給老百姓提供一個透明化監督和事件追責的數據依據，無論是醫院、當地CDC、還是政府管理者可以通過區塊鏈的防篡改和透明性特徵自證一二。

無論接診，疑似處理，確診處理，死亡還是報告上報，都可以在老百姓和上級主管政府的監督下開展，一旦重大疫情追責，可以依託區塊鏈數據可溯源的特性形成完整的，防篡改的責任鏈條，可以極大增強政府的公信力，為防疫和控制疫情提供堅實的群眾基礎。

四、總結

筆者經歷過2003年的SARS疫情，這17年以來看到國家在信息化技術和移動網際網路技術建設方面突飛猛進，不相信以目前的技術手段我們不能充分應對重大傳染病疫情的早期預警和控制（要知道這次疫情和SARS時代處於完全不同的兩個信息化和自動化技術層面）。

我們國家相關行政部門要敢於接受和勇於嘗試新技術，用技術來武裝重大疫情的防疫體系，畢竟：在人命關天面前，其他的都是次要的。

參考文獻：

張洪龍，曾令佳，賴聖傑，王麗萍，李中傑 2016 年國家傳染病自動預警信息系統運行情況分析 1003-9961(2018)02-0159-09

孔園園，高桂玲，張清慧，郭曉芹 基於醫院電子病歷直推的傳染病疫情報告與管理信息系統的實踐 1003−9961(2019)06−0576−05

丁克琴，張良，易波，陳奕，董紅軍，許國章 2018 基於三級信息平臺的寧波市傳染病智能直報模式效果評價 1003−9961(2018)09−0758−04

趙自雄，趙嘉，馬家奇 2018 我國傳染病監測信息系統發展與整合建設構想 1003-9961(2018)05-0423-05

曾令佳，徐莉立，楊雯雯，耿夢傑，王麗萍，李中傑，餘宏傑 2016 新形勢下我國傳染病疫情監測管理現狀調查 1003-9961(2016)11-0949-04

焦鋒 董蓬玉 劉曉強 徐鵬 楊光 劉宏 張舒惟 何國忠 2018 傳染病預警方法及應用概述 DOI :10.3969/j.issn.1673‐5625.2018.04.005

 

本文由 @烏士兒 原創發布於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議