功能規范和業務中臺
對應基本業務處理類應用大多可以參考國家衛健委發布的一系列功能規范《醫院信息系統軟件基本功能規范》以及《國家基本公共衛生服務規范》中提出功能規范。在建設信息共享和業務聯動類應用時可以參考。
01
醫院信息系統軟件基本功能規范
02
智慧醫院中臺架構設計
1. 智慧醫院中臺架構背景
十幾年來,中國醫院已經歷了信息化的3個階段。
第一階段,是2000年之后的醫院信息系統建設。
許多醫院開啟了一波以數據庫、HIS為主的底層IT建設。這類系統從部署到更新、淘汰,生命周期一般在5年左右;第二次的更替也需要同等時長。于是,2015年前后,中國許多醫院都基本完成了內部核心業務的信息化建設,做到了“將一部分業務沉淀為數據”。這為數據中臺的出現提供了第一個先決條件:底層IT架構的完善和初步的“業務數據化”。
和第一階段部分重疊進行的第二階段,是2004年到2017年,全醫療行業萌發的“互聯網思維”。醫院信息化從業者被深深植入了一個信念:互聯網思維。而互聯網思維中,尤為重要的就是數據思維。這為數據中臺準備了第二個條件:醫院開始意識到數據的巨大價值。
第三階段是2017年之后,國家針對互聯網+醫療健康的大力發展和推動,為醫療行業提供了大量數據通道?;ヂ摼W+醫療健康從虛擬世界的互聯網集團醫院走向線上線下深度融合。對于場景多在線下的傳統行業而言,低門檻的數據渠道成為了可能。通過APP、小程序和蓬勃發展的各類傳感器,更多行業積累了原生于移動醫療時代的量級遠超以往的多維度海量數據。而新的數據渠道又帶來新的業務需求。比如,以數據為支撐的臨床輔助決策、精準醫學等業務,讓許多醫院近年內開始了醫療大數據平臺的建設。這為數據中臺準備了第三個條件:更深程度的“業務數據化”,和對自有數據價值的更深認知。
隨著以上三階段的發展,中國醫院信息化上開始涌現兩大相似痛點:
1).醫療管理穩定性和醫療業務變動性之間的矛盾加劇。
醫療管理求穩。而國家推行互聯網+醫療健康的戰略以來,面臨著場景、業務增多且快速變動的情況。上層的業務需要靈活性,醫院的管理和戰略又需要相對穩定,二者的矛盾越發不可調和。這個矛盾達到一定程度時,就是數據中臺興起的時機。
2).新舊HIS系統沉淀的數據之間難以打通。
醫院內外部數據難以連接,以集成平臺為手段的只能解決業務的集成,而針對各煙囪系統的數據很難達到統一利用和適應業務對數據日益增長的需求。
為了滿足新業務的即時需求,許多醫院同時使用著包括小程序、微信公眾號在內的多種SaaS,不同工具有如一個個林立的煙囪互不連通;又和醫院底層“差著輩分”的老一代HIS、數據庫等IT系統有著交流“代溝”。醫院中臺的核心需求正在于此:老系統和不斷變化的醫療新業務之間,需要快速的結合,同時需要不斷的重構和復用已經形成的醫療數字業務,這就是智慧醫院中臺的空間。
智慧醫院中臺架構是基于微服務和大數據技術構建的生態體系,通過對醫院業務進行梳理和重構為醫院提供各種智慧化的服務,滿足業務流程優化、業務閉環、各種評審評級的要求,擁抱醫療業務變化,提升醫療能力復用,最終使醫院真正做到“智慧”。面向醫務人員,通過業務中臺滋養和診療知識庫的沉淀,構建“智慧醫療”;面向醫院管理,以閉環服務提高醫療質量,構建“智慧管理”;面向患者和大眾,迅速構建基于業務中臺支撐的敏捷應變的互聯網+醫療健康應用體系,全面提升患者服務能力和患者的獲得感,實現“智慧服務”;同時,在互聯網集團醫院建設方向,提供面向單體醫院、面向醫聯體和醫療集團、面向區域的完整解決方案,全面助力互聯網集團醫院的落地。 醫院信息系統的實現既要考慮適合于現有需求,又考慮未來發展的總體技術要求,從而保證系統的可持續發展的需求。醫院信息系統采用面向服務的體系結構的總體技術路線。依賴由SOA和微服務組成的總體技術路線,為醫院信息系統及應用實現提供技術支撐。 其中所涉及的主要技術如下描述: 采用基于行業標準或得到廣泛使用的事實上的行業標準的技術和架構,有利于降低技術風險和對特定供應商的依賴性;采用的開放系統架構,有利于保持系統的向后兼容性、可集成性和可擴展性。 微服務是一種架構風格,一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署,各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下,每個任務代表著一個小的業務能力。 通過服務實現應用的組件化:微服務架構中將組件定義為可被獨立替換和升級的軟件單元,在應用架構設計中通過將整體應用切分成可獨立部署及升級的微服務方式進行組件化設計。 “去中心化”治理:整體式應用往往傾向于采用單一技術平臺,微服務架構則鼓勵使用合適的工具完成各自的任務,每個微服務可以考慮選用最佳工具完成(如不同的編程語言)。微服務的技術標準傾向于尋找其他開發者已成功驗證解決類似問題的技術。 “去中心化”數據管理:微服務架構倡導采用多樣性持久化的方法,讓每個微服務管理其自有數據庫,并允許不同微服務采用不同的數據持久化技術。 面向對象技術的發展已經成熟,基于面向對象技術的開發語言和應用框架,已經得到證明可以大大提高信息系統開發和建設的效率,提高架構的合理性和可擴展性。 分層從邏輯上將子系統劃分成許多集合,而層間關系的形成要遵循一定的規則。通過分層,可以限制子系統間的依賴關系,使系統以更松散的方式耦合,從而更易于建設、維護和進化。 由于醫療數據具有法律效應,對安全性要求非常高,和傳統數據庫應用中的普通數據,有非常大的差別,因此,在數據存儲方面,不能夠按照傳統數據管理和應用的模式進行管理。在平臺設計必須支持各種主流數據庫系統的應用,由系統提供的腳本文件可以自動生成支撐平臺運行的數據庫系統。主流的數據庫系統包括:Oracle,SQLServer,DB2等。平臺的數據庫模型設計獨立于特定的數據庫產品,我們通過xml技術實現跨數據庫,平臺數據可通過數據傳輸工具實現在不同數據庫間的遷移。保證了數據存儲的獨立性和靈活性。 我們系統本身可以在多種數據庫上應用,但對于本系統來講,由于系統的數據量比較大,管理范圍較廣,我們支持傳統數據庫存儲,也支持Hadoop大數據分布式存儲,依據不同量級選擇不同的數據管理。 基于組件的開發是普通應用程序開發的變體,它具有如下特點: · 應用程序由各自獨立的組件組成,這些組件的開發和部署保持相對的獨立性,而且很可能是由不同的團隊開發和部署的。 · 通過僅對這種應用程序的某些組件進行升級,從而對其進行小幅度的升級。 · 組件可以在不同應用程序之間共享,因此可對它們復用,但同時也產生了項目之間的依賴關系。 盡管并非與基于組件完全密不可分,但基于組件的應用程序傾向于分布式結構。 由各類前臺系統組成的前端平臺。每個前臺系統就是一個用戶觸點,即醫院的最終用戶直接使用或交互的系統,是醫院與最終用戶的交點。例如醫院各業務部門使用的系統,用戶直接使用的網站,手機App,微信公眾號等都屬于前臺范疇。因為醫院后臺往往并不能很好的支撐前臺快速創新響應用戶的需求,后臺更多解決的是醫院管理效率問題,而中臺要解決的才是前臺的創新問題. 隨著醫院業務的發展壯大,和國家對互聯網+醫療健康的戰略部署,因為后臺修改的成本和風險較?,所以驅使我們會盡量選擇保持后臺系統的穩定性,但還要響應用戶持續不斷的需求,自然就會將大量的業務邏輯(業務能力)直接塞到了前臺系統中,引入重復的同時還會致使前臺系統不斷膨脹,變得臃腫,形成了一個個?泥球的“煙囪式單體應用”。漸漸拖垮了前臺系統的“?戶響應?”,用戶滿意度降低,醫院競爭力也隨之不斷下降,因此本方案構建的業務前端是跨平臺、跨終端、跨區域的全生態解決方案。 基于醫療本體論原則對醫療領域模型進行重構,本體可以分為四種類型:領域、通用、應用和表示。領域本體包含著特定類型領域(如電子、機械、醫藥、教學)等的相關知識,或者是某個學科、某門課程中的相關知識;通用本體則覆蓋了若干個領域,通常也稱為核心本體;應用本體包含特定領域建模所需的全部知識;表示本體不只局限于某個特定的領域,還提供了用于描述事物的實體,如“框架本體”,其中定義了框架、槽等概念。 Studer等人的本體論定義包含四層含義:概念模型、明確、形式化和共享?!案拍钅P汀笔侵竿ㄟ^抽象出客觀世界中一些現象的相關概念而得到的模型,其表示的含義獨立于具體的環境狀態;“明確”是指所使用的概念及使用這些概念的約束都有明確的定義;“形式化”是指本體論是計算機可讀的,也就是計算機可處理的;“共享”是指本體論中體現的是共同認可的知識,反映的是相關領域中公認的概念集,它所針對的是團體而非個體。本體論的目標是捕獲相關領域的知識,提供對該領域知識的共同理解,確定該領域內共同認可的詞匯,并從不同層次的形式化模式上給出這些術語和術語之間相互關系的明確定義。 從內涵上來看,本體論是領域內部不同主體(人、機器、軟件系統等)之間進行交流(對話、互操作、共享等)的一種語義基礎或共識,更主要的是為機器服務。因此,在計算機領域討論本體論,就要討論如何表達共識,也就是概念的形式化問題。圖例:是全面覆蓋醫院各系統各場景的可擴展的患者診療模型。 醫療行業的整體分析需從主營業務開始。 按照國家的產業劃分,醫療行業是第三產業(不生產物質產品的行業,即服務業)的一種,服務業的主營業務共性在于建立明確的服務關系,服務提供者使用特定資源,通過增值服務過程實現顧客的需求,基本流程如下: 醫療行業的主營業務是醫療服務,是醫院基本功能的體現,是在建立有效醫患關系的基礎上完成一項或多項醫療服務,從而實現患者的就診需求,基本流程如下: 在醫療服務中,患者處于一個“軸”的位置,因為患者是所有醫療服務的最終接受者,區分一項發生在醫療系統內的業務是否屬于醫療服務,關鍵在于它的直接服務對象是否是患者。這也是患者主索引EPMI得以實現的客觀基礎。 如前所述,醫療核心主營流程是指代表醫院競爭力的業務流程,需要比支撐流程更細粒度地分解,以獲得最大的靈活性。很顯然,醫療服務是醫療行業的核心流程,需要進一步的細化。 醫療輔助業務實現醫療服務提出的資源申請需求,它的直接服務對象是一個或一組醫療服務。它通常是醫療行業內與醫療資源直接相關的職能科室如收費、物資、設備、后勤等的主要業務之一。 醫療管理業務實現對醫療服務、醫療輔助業務所產生信息的數據挖掘需求。如科室管理、科研、財務、人事等。它通常是我們所說的臨床決策支持系統,區域醫療中的垂直業務系統等的主要業務之一。2. 智慧醫院中臺架構
3. 基于微服務和大數據的技術中臺
1). 采用標準、開放的微服務架構
2). 采用面向對象的技術
3). 采用分層的架構
4). 跨數據庫設計
5). 采用基于組件的架構
4. 擁抱醫療業務變化的業務前端
5. 提升醫療能力復用的業務中臺
1). 醫療行業主營業務
2). 醫療輔助業務
3). 醫療管理業務