在醫療信息化行業中,關于如何進行信息化建設工作,主要有兩條建設路徑---一體化和集成化。到底應該是選擇一體化還集成化?長期以來爭議不斷。
在最近舉行的CHIMA大會第三屆HIT全國青年辯論賽上,這一議題再次被推至風口浪尖,引發了廣泛的討論與關注。對于信息化應該一體化還是集成化建設的這個論題,我們也想分別從正方和反方的角度,分享一些見解。
醫療信息化建設的目標是實現醫療服務的高效、精準和智能化。正如醫療信息化領域的先驅Dr. John Halamka(曾任哈佛醫學院的國際醫療創新教授;New England Healthcare Exchange Network Inc.的董事長;現任Mayo Clinic平臺總裁)所言:“醫療信息化的核心在于數據的流動性和可用性。”
何為一體化?
一、一體化與集成化的區別 在討論該一體化還是集成化建設之前,我們需要明確定義的是,什么是一體化,什么是集成化,以及一體化和集成化之間的區別。 首先,一體化建設我們要擯棄「一家廠商、一套系統」的認知。醫療業務復雜而又具有一定的專業壁壘,很難由一家廠商、一套系統就可以滿足所有的需求;同時,一家廠商一套系統也會制約醫院信息化發展、扼制創新,醫院作為買單方更應該有主動權。此外,一個廠商、一套系統也不一定就是一體化,我國不少一體化廠商,內部實際上也是多套系統,多套數據,無非是預先做好了業務接口,像是煙囪間接了飛線。 那該怎么定義一體化呢?從架構層面看,我們認為,真正的一體化應該要從一套核心數據、一致標準、統一底層的設計出發,具體應用系統則應該百舸爭流。正因為底層是統一的,所以數據自然可以互聯互通。而集成化的思路,則是每個應用完全自治,自己維護自己的數據結構,通過接口或者集成引擎來進行業務的互聯互通。從本質上看,一體化是通過共享數據進行通信,而集成化則是通過通信來共享數據,這是一體化和集成化的顯著區別。 二、集成化建設:數據標準之殤 那如何定義一致的數據標準,又該如何實現呢?當我們談到醫療數據標準的問題,不得不再聊聊HL7與互聯互通標準。 HL7是國際間廣泛接受的醫療信息交換規范。最早的HL7協議(HL7 V3)定義了一種基于文本符號的數據交換格式,滿足HL7 V3協議的系統可以通過socket等方式,發送HL7 消息來交換數據,這是典型的通過接口來集成。隨著醫療信息化的發展,為了更好的滿足醫療數據的標準化和交互,HL7 CDA誕生了。HL7 CDA使用XML格式定義了多種類型的臨床文檔,并基于SOAP定義了一些標準的臨床業務接口,實現了CDA的醫療系統理論上可以直接互聯互通。我國的互聯互通標準,也一定程度參考了HL7 CDA的標準并加入了一些自定義的擴展進行整體設計,到了這個階段,為了快速能夠對接標準接口和生成臨床文檔,集成引擎開始大規模投入使用。 到了2011年,HL7 FHIR(Fast Healthcare Interoperability Resources)被提出,FHIR是一個新興的國際醫療信息交換標準,旨在簡化醫療信息的交換過程,使其更加靈活和易于實施。作為全新設計的標準,FHIR擯棄了之前面向業務接口的設計模式,轉而采用了面向資源的設計模式,這是一個比較大的轉變。 圖片來源于網絡 舉個例子,之前的系統可能會設計掛號、開醫囑、收費之類的業務接口;而FHIR定義的是病人信息、醫囑、費用等數據信息格式,具體業務通過FHIR Restful API對這些資源進行增刪改查操作。FHIR推薦的模式,是使用一個中心化的FHIR Server來提供醫療信息資源的管理,并通過Restful API等方式為上層應用提供接口使用,這比較類似我們的CDR,但CDR仍然是通過接口而非數據庫進行的訪問。FHIR標準其實就是一個一體化的架構設計,即所有的應用,通過FHIR Restful API共享訪問并操作一套關鍵業務數據。 事實上,國際知名醫院和醫療機構正在積極通過HL7 FHIR標準或在其系統中實施FHIR,如梅奧診所(Mayo Clinic)、克利夫蘭診所(Cleveland Clinic)、英國NHS也正在推動FHIR標準的應用,以支持其數字健康戰略,包括患者記錄的訪問和共享等。而國際主流的信息化廠商方案,也確實在往一體化底層數據架構的方向發展。 圖片來源于網絡 三、互聯互通標準化成熟度測評與HL7 FHIR的關系 2018年6月7日在首都醫科大學附屬北京友誼醫院正式啟動了《基于FHIR的互聯互通標準研究》項目,在此之前,醫院的集成平臺和數據中心項目已基本完成符合互聯互通四甲等級的改造建設,文章詳細分析了FHIR技術方案與醫院環境的匹配度以及該標準的成熟度,為后續醫療機構使用FHIR實現互聯互通提供了參考依據。 我國醫院信息互聯互通標準化成熟度測評是通過互聯互通分級制度,明確醫院自身的發展目標和改進方向,逐步實現信息化建設的標準化和規范化。而FHIR標準更側重于醫療信息交換的標準,它提供了一套框架和工具,以便于不同的醫療信息系統之間能夠進行數據交換和集成。FHIR標準本身并不定義具體的等級,而是提供了一套豐富的資源和API,來支持醫療信息的互操作性。 一切與分布式系統有關 一、關于CAP定理 一體化建設為何會成為趨勢?醫療系統的本質是什么? 醫療業務的流程與場景繁多,構成了一個典型的分布式系統,而分布式系統本身離不開UC Berkeley的布魯爾教授在2000年提出的著名的CAP定理,CAP定理對分布式系統設計具有重要的指導意義,它幫助開發者理解在面對網絡問題時需要做出的權衡,并根據具體的應用場景和業務需求選擇合適的系統設計。 CAP分別代表一致性(Consistency)、可用性(Availability)和分區容錯性(Partition Tolerance),該定理表示,在一個分布式系統中,CAP這三個特性不能同時得到保證,它是一個不可能三角。 其中,分區容錯性是必選項,因為故障在客觀上是一定會發生的,事實上我們在做分布式系統架構設計時,只有AP和CP兩種選項。而醫療、金融等嚴肅領域更傾向于使用CP系統。因為它以犧牲極少量的可用性,來保障系統信息能做到絕對一致。CP類系統的底層采用一套數據架構來實現信息共享,而非AP類系統的分系統自治存儲,AP類系統事實上在互聯網系統設計中更為常見,這是我們強調的一體化,即底層數據架構一體化,它帶來的好處是能夠從根本上保障數據一致。 二、數據不一致問題可解決嗎? 數據不一致會帶來什么問題呢?舉個例子,醫生在醫囑系統下了一個CT預約,但是預約系統掛了,沒收到這條信息,患者以為成功預約了,結果白跑一趟。再舉個例子,如果遇到醫囑下達的高峰期,集成引擎高負載,性能受到嚴重挑戰,系統卡慢、信息延遲甚至丟失,如果涉及到收費、處方等敏感的業務,導致的后果會更加嚴重。 除了數據不一致問題,集成化建設當前所面臨還有各系統接口標準不一致、集成引擎負載過大、信息交換效率低等系統性挑戰。系統集成的核心要務是數據交換和業務協調所遵從的標準成熟度,這個標準是否可用,持續高效的迭代顯得尤為關鍵。矛盾的是,醫療信息集成有著項目高度復雜、場景不斷創新、技術不斷迭代的特征,而目前,行業缺乏標準的常態化組織進行有效管控,更多的是依靠行業協會和兼職成員按照項目的方式在運作,必然會導致標準跟不上業務需求,最后往往演變成各家自定義標準,進一步放大了集成化的問題。 當然,集成化建設可以選擇多種方案改善數據不一致問題,比如:規范接口、數據標準、選擇同步提交(2PC,2 Phase Commit)等方式。但必須要認清的事實是:高效的分布式事務本來就是業界難題,且無論如何提升,都無法達到信息的完全一致。究其根本還是因為集成化方案本身是一個類AP的系統,這是系統架構設計的取舍決定的,即:優先保障可用性,允許一定程度的數據不一致。 三、一體化能保障系統性能嗎? 在一體化架構方案設計中,技術上可以支持應用層無狀態高可用,數據庫可以使用主從切換等容災技術和良好部署的基礎設施,能夠實現數據丟失(RPO)為0,業務恢復時間(RTO)小于數十秒,在數據庫方面,現在主流的關系型數據庫(如PG)則完全可以支撐數十萬事務每秒的處理。實現在不影響診療業務的同時保障數據一致。說到這里我們不難發現,其實相比系統可用性問題,信息不一致的問題更難以解決。 當我們在做醫院大數據應用時,一體化架構的優勢也是顯而易見的。尤其在當下火熱的數據應用場景中,不同業務系統中的相關和相似數據,經常對不上或者自相矛盾,需要進行深度的、大規模的數據治理。然而數據治理成本高、難度大,非常考驗廠家綜合實力,且最終數據質量相比一套底層數據的一體化架構相去甚遠。 四、醫療系統究竟該如何取舍? 一體化架構好處如此之多,醫院能立刻實現嗎? 話還是要說回來,關于醫院信息化應該一體化還是集成化建設的命題前如果加一個時間條件,如現在、當下,那么,縱使一體化有種種好處,對于目前國內的絕大部分醫院來說,也不是立刻就能夠實現的,畢竟現實情況相對于理想總有滯后性。 一方面是歷史遺留問題多,醫院的信息化建設非一朝一夕才走到今天,很多醫院也是以“打補丁”的方式“縫縫補補又三年”,很難在不影響醫院運營的同時快速推翻重建;另一方面是信息化的發展比如HL7 FHIR的協議也剛成熟不久,本身難度也比較高,廠商之間目前也很難達成共識,需要更強有力的監管機構在互聯互通的標準中進行提升。 對于現階段的醫院來說,集成化還是更加實際的選擇,當然,新建醫院可以考慮從0-1開始一體化架構設計。 小 結 20世紀70年代上海市腫瘤醫院與復旦大學聯合研發的病案管理系統,正式開啟了醫療信息化的篇章。1995年,軍字一號工程帶動了HIS進入全面發展時期,到了21世紀,醫院已經從經濟管理為中心的系統發展到以患者和臨床為中心基于電子病歷的信息平臺。再到今天,信息系統已經向著促進醫療水平提升、降低醫療風險、減輕醫務人員負擔、改善患者就醫體驗以及精益管理方向跨越。 技術始終服務于業務,不管是趨于現實的集成化建設,還是更理想的一體化建設,我們都要擁抱變革、引領創新,醫療信息化行業才能得以向前不斷發展。
注:文章來源于網絡,如有侵權,請聯系刪除