2019年醫療信息建模方法與開放式電子病歷系統開發平臺.pdf

1、醫療信息建模方法 與開放式電子病歷系統開發平臺報告目錄Contents醫療信息化需求和現狀醫療信息化需求和現狀軟件工程角度理論分析軟件工程角度理論分析臨床業務建模臨床業務建模開放電子病歷平臺的業務架構開放電子病歷平臺的業務架構開放電子病歷平臺的技術架構開放電子病歷平臺的技術架構技術路徑與愿景技術路徑與愿景醫療信息化現狀和需求目錄醫療大數據政策醫療數據特征臨床電子病歷問題信息化需求醫療信息化愿景醫療信息化現狀和需求醫療大數據政策2014年2015年9月2016年6月2017年1月 2014年，國家衛計委制定國家衛生、計生資源整合頂層設計規劃-“46312”工程 2015年，關于促進大數據發展的行

2、動綱要 2016年，關于促進和規范健康醫療大數據應用發展的指導意見 2017年，十三五全國人口健康信息化發展規劃 2018年，國家健康醫療大數據標準、安全和服務管理辦法（試行）2018年9月醫療信息化現狀和需求醫療數據特征醫療數據的特點醫療數據的特點醫療大數據具備一般的大數據特征：規模大、結構多樣、增長快速、價值巨大。另外作為醫療領域產生的數據具備醫療領域的特點：多態數據類型多樣隱私隱私泄漏風險時效時效性強冗余重復數據醫療信息化現狀和需求臨床電子病歷問題現狀比喻現狀比喻現在的醫療信息化系統好比是一座橋，橋上走的和跑的是患者，橋上的石獅子、花紋等裝飾是大數據、人工智能和物聯網。院長們和領導們喜歡

3、看的，往往是橋上的華麗產物，卻忽視了橋下的基礎。橋下是信息科和軟件開發商的人在苦苦支撐，東修西補來維持橋梁的正常運作。針對不斷變化的臨床業務需求，信息科的人對軟件開發商怨聲不絕，而開發商也是苦不堪言，陷入惡性循環。創建一套擁有強大擴展能力的富有彈性的信息化系統，成為解決問題的關鍵。非結構化或半結構化真實性數據后補互聯互通信息孤島科研難數據在廠家手中醫療信息化現狀和需求標準化的數據標準化的數據同一領域內的信息有統一的標準不同領域的信息有一致的接口信息互通信息互通基于醫療術語的同一患者信息在不同醫院互通患者信息在整個生命周期過程中的醫療數據互通軟件延續性和擴展性軟件延續性和擴展性減少軟件廠商因素導

4、致系統無法維護避免使用不良架構導致系統擴展缺陷快速響應快速響應減少用戶需求溝通時間，快速響應臨床需求減少維護人員的學習時間醫療信息化需求醫療信息化現狀和需求醫療信息化愿景構建與供應商無關的，由臨床專家主導的?？茟皿w系；減少信息化的重復投入和系統維護投入，增加需求響應速度和提高系統穩定性；通過多方參與、共同運營臨床模型倉庫、醫療數據存儲等服務，實現醫療信息的標準化并互聯互通。報告目錄Contents醫療信息化需求和現狀醫療信息化需求和現狀軟件工程角度理論分析軟件工程角度理論分析臨床業務建模臨床業務建模開放電子病歷平臺的業務架構開放電子病歷平臺的業務架構開放電子病歷平臺的技術架構開放電子病歷平臺

5、的技術架構技術路徑與愿景技術路徑與愿景軟件工程角度理論分析目錄傳統瀑布開發模式迭代和敏捷模式Luna模式軟件工程角度理論分析傳統瀑布式開發01需求調研需求調研02需求分析需求分析03系統設計系統設計04開發編碼開發編碼多次評審多次評審06系統上線系統上線05系統測試系統測試07系統維護系統維護軟件工程角度理論分析傳統瀑布式開發模式特點模式特點強調文檔強調文檔前一個階段的輸出就是下一個階段的輸入，文檔是階段銜接的唯一信息接口。所以很多開發人員好像是在開發文檔，而不是開發軟件，因為要到軟件開發的后期，我們才可以看到軟件的“模樣”。缺乏迭代與反饋缺乏迭代與反饋電子病歷操作繁瑣，醫生在錄入數據時，難免

6、會出現疲倦與懈怠，錄入的數據的準確性會存有疑問。不適合客戶需求不斷變化的軟件開發不適合客戶需求不斷變化的軟件開發“唯一不變的是用戶變化的需求”，用戶業務需求隨著市場變化而改變，在軟件初期的設計時需求可能已經發生變化，而后期的需求更改成本是開始的10倍工作量。在過去的醫療軟件市場里，一方面市場帶動需求變化，另一方面初期客戶對需求描述不清楚，這些客觀因素都為瀑布模型的使用團隊帶來困難與障礙。軟件工程角度理論分析迭代、敏捷開發01需求需求02設計設計03開發開發04測試測試05交付一交付一05交付二交付二05交付交付N N01需求需求02設計設計03開發開發04測試測試第一迭代期第一迭代期第二迭代期

7、第二迭代期第第N N迭代期迭代期軟件工程角度理論分析迭代、敏捷開發模式特點模式特點敏捷就是敏捷就是“快快”可以適應目前社會的快節奏與變化的用戶需求?？蛻魠⑴c開發過程客戶參與開發過程以人為本，客戶是軟件的使用者，是業務領域的專家，沒有客戶的參與，開發者很難理解客戶的真實需求?！拜p輕”文檔文檔強調軟件開發的產品是軟件，而不是文檔。文檔是為軟件開發服務的，而不是開發的主體。迭代、小版本迭代、小版本對迭代的強調是縮短了整個軟件版本的周期。軟件工程角度理論分析開發模式對比項目敏捷開發傳統開發用戶需求迭代獲取，通常由簡到繁開發前獲取詳盡的需求變更成本較低高測試每次迭代編碼階段完成后客戶參與度高低開發人員要

8、求技術技能、業務技能、溝通能力技術技能適合的項目規模小型或中型的軟件大型的軟件軟件工程角度理論分析Luna開發模式的提出3管理工具2開發工具1開發模式 信息化軟件開發開銷大 響應臨床業務變化速度慢 總體開發周期長 需求溝通難度大 技術和專業知識耦合性強痛點LunaLuna根本上就是分層體系架構，將信息模型與業務模型分離。根本上就是分層體系架構，將信息模型與業務模型分離。軟件工程角度理論分析Luna開發模式的設計理念標準 OR標準應用解決信息孤島自由or約束不能支持完整數據互通的接口，單層模式的系統（業務數據與數據庫一一對應的硬編碼架構）都屬于信息孤島。系統將支持相關的標準互聯互通的接口。用一個

9、例子來說明標準和應用的關系。電子郵件系統有各種服務端、客戶端應用，形態、功能差異巨大，但大家遵循的SMTP標準協議。每個應用有不同的形態，同樣的郵件（類比醫療數據）用不同的客戶端（類比不同的供應商開發的系統），可以呈現不同的系統功能。自由與約束是辨證統一的。自由的實現是以付出巨大代價為前提的?，F階段的luna主要任務是順利走通開發流程，因而將約束數據結構、控件類型、查詢路徑等。軟件工程角度理論分析Luna的架構體系數據存儲結構和軟件底層組件如安全審計等不隨需求變化和知識更新而頻繁變動的部分抽象出來，構成Luna平臺抽象的“底層”。底層架構組件底層架構組件臨床業務模型臨床業務模型“把臨床醫生放回

10、了駕駛員的座位上”讓醫務專業人員直接參與醫療軟件中領域知識層的設計，方便快捷地滿足醫務人員對醫療數據的采集、存儲、展示需求。Luna將傳統需要重復性的人力密集型的工作，通過解釋器加模式識別的方法自動生成，像文檔生成、ORM、UI-generator等報告目錄Contents醫療信息化需求和現狀醫療信息化需求和現狀軟件工程角度理論分析軟件工程角度理論分析臨床業務建模臨床業務建模開放電子病歷平臺的業務架構開放電子病歷平臺的業務架構開放電子病歷平臺的技術架構開放電子病歷平臺的技術架構技術路徑與愿景技術路徑與愿景臨床業務建模CDML建模語言實驗室檢查臨床業務建模建模語言&建模工具的XML輸出文件基本檢

11、查模型描述身高體重血壓診斷臨床業務建模Luna的臨床領域建模語言CDML解決核心問題：通過醫務工作者易用的工具，輸出的領域模型可讀readable（同時具備人可讀和機器可讀）與醫學數據集關聯保證語義的完整與正確表達避免岐義臨床知識可積累和復用，避免重復造輪子抽象為臨床概念根據臨床術語抽象業務需求轉為業務表單生成前端可視、可操作表單Luna建模過程：臨床業務需求開放Repository設置觸發CDS關聯Terminology構建臨床模型根據模型倉庫選取或新建模型臨床業務建模Luna預期的臨床領域模型倉庫400+醫療領域模型基于OPENEHR的全球智慧和臨床知識200+臨床表單表達90%覆蓋產科業

12、務報告目錄Contents醫療信息化需求和現狀醫療信息化需求和現狀軟件工程角度理論分析軟件工程角度理論分析臨床業務建模臨床業務建模開放電子病歷平臺的業務架構開放電子病歷平臺的業務架構開放電子病歷平臺的技術架構開放電子病歷平臺的技術架構技術路徑與愿景技術路徑與愿景開放電子病歷平臺的業務架構Luna業務架構示意圖開放的醫療信息化解決方案構建區域化標準化體系數據標準：在一定范圍內通用的標準（語言無關），包括分層模型標準、數據共享標準；開發標準：涵蓋從項目管理到測試發布的過程；不約定相關的實現技術，以適應新技術的應用。包括：應用是否應該有標準，規范有什么功能（記錄哪些字段），有什么業務（邏輯關系），用

13、什么方式展示，用什么方式存儲？開放電子病歷平臺的業務架構Luna業務組件示意圖開放的醫療信息化解決方案項目管理模式項目管理模式將項目需求、評審、開發、測試、上線固化為開發平臺流程。完整的過程記錄、自動文檔生成、審批體系、版本回滾制度。Docker集成，通過容器構建測試、開發、生成環境。數據存儲：結合SQL和文檔數據庫的特點，保證數據檢索效率和業務變更的可擴展性。服務接口：設計通用的數據查詢語言實現任意數據粒度的數據查詢與共享，支持HL7 FHIR的資源接口模式。權限與審計：統一的權限管理、電子簽名、審計模塊，作為院內基礎服務組件為其他模塊服務。全局服務組件：臨床決策模塊、隨訪模塊、事件告警模塊

14、，讓傳統醫療信息系統支持智慧醫療。提供基礎組件提供基礎組件是一種臨床業務建模規范，緊密支持醫療術語集保證臨床意義的準確表達；是醫療信息化生態的種子，如HTMLx之于WEB生態。CDMLCDMLClinical Domain ModelLanguage集項目管理、版本管理、發布管理、模型倉庫對接等功能于一體，符合臨床使用習慣，所見即所得式的簡單易操作界面。CDM StudioCDM Studio建模工作平臺共有庫+私有庫+大型醫院公開庫+第三方專業模板倉庫等運營模式，公共倉庫模型預期平均滿足專業科室應用80%的需求。CDMRCDMRClinical Domain Model Repository

15、為解決信息孤島，達到任意粒度及其組合的數據檢索，提供一種融合SQL+節點存儲優點的臨床數據持久層服務。CDPCDP服務服務臨床數據存儲服務開放電子病歷平臺的業務架構Luna業務組件組成報告目錄Contents醫療信息化需求和現狀醫療信息化需求和現狀軟件工程角度理論分析軟件工程角度理論分析臨床業務建模臨床業務建模開放電子病歷平臺的業務架構開放電子病歷平臺的業務架構開放電子病歷平臺的技術架構開放電子病歷平臺的技術架構技術路徑與愿景技術路徑與愿景腳手架框架開源EHR服務商EHR服務商方法論基礎重要存儲方案后端框架醫療資源管理及共享標準前端框架，也包括electron等開放電子病歷平臺的技術架構參考方

16、案與技術棧領域與信息模型分離臨床領域建模：綁定醫療術語集，支持LOINC、SNOMED、ICD.x信息模型：基礎數據支持、數據關系支持、CDS表達式語言、統一查詢語言前后端分離前端呈現：支持pc和移動端樣式后端：在數據持久層上提供Rest層作為數據檢索接口組件式開發后臺組件：權限管理、審計管理、組織管理、模型管理、集成管理前端組件：表單組件、報表組件、路由組件以模型為中心，自動生成持久層數據體系和Rest接口，結合表單編輯自動生成前端頁面自動化腳手架開放電子病歷平臺的技術架構Luna總體架構邏輯示意圖領域與信息分層模型自動化腳手架組件式開發前后端分離開放電子病歷平臺的技術架構Rest 接口服務

17、層Restful共享接口管理根據數據集成要求通過模型選擇元素，設計數據查詢條件和相關的數據結構為第三方集成設置API key自動生成接口和接口文檔設置接口CRUD權限接口訪問可審計開放電子病歷平臺的技術架構持久層存儲-ER圖動態臨床數據存儲方案根據模型生成存儲索引，無需變更表結構。數據類型符合臨床數據需求和數據分析需要。開放電子病歷平臺的技術架構Luna的相關技術可視化建模工具可視化建模工具計劃開發面向領域專家的所見即所得的數據應用模板編輯器，能提供簡單易用的可視化編輯界面，由領域專家以所見即所得的方式編輯臨床應用模板文件。安全基礎組件安全基礎組件數據安全是醫療信息化的前提條件架構提供數據庫安

18、全、傳輸安全、角色權限管理、審查管理的基礎功能組件醫療前端組件醫療前端組件通過數據綁定技術棧，隱藏掉平臺的差異，實現跨平臺，技術棧有非常好的伸縮性能，在水平和垂直方面均有良好的擴展性。使用的工具有專業的團隊或者社區提供持續的技術支持統一查詢語言統一查詢語言通過臨床模型或資源模型的數據查詢語言可生成任何粒度和結構的數據集，便于數據集成和數據分析，將醫療數據掌握在醫院自己手中。開放電子病歷平臺的技術架構Luna技術模塊特點 Bjson數據靈活擴展數據倉庫可直連數據分析平臺數據驅動應對數據類型變更和數據分析響應速度快高性能高健壯分層模型，各司其職自動化腳手架，減少重復開發Spring Boot底層微

19、服務架構前后端分離應對臨床業務快速更新應對單點故障或難以水平擴容報告目錄Contents醫療信息化需求和現狀醫療信息化需求和現狀軟件工程角度理論分析軟件工程角度理論分析臨床業務建模臨床業務建模開放電子病歷平臺的業務架構開放電子病歷平臺的業務架構開放電子病歷平臺的技術架構開放電子病歷平臺的技術架構技術路徑與愿景技術路徑與愿景技術路徑與愿景技術路徑與愿景產科?？频膶嵺`FHIR支持業務模型技術路徑與愿景前端效果展示 主要功能：p ?？漆t生工作站p 續診報導模式，自動提示新出報告p 產科高危管理、產前篩查管理p 檢查套餐，異常檢查數據提醒p CDS支持，臨床路徑支持多些技術和設計，少些人員和時間讓數據驅動醫療信息化，通過開放領域模型消除信息孤島醫學專家構建電子病歷領域模型倉庫CDM工作平臺完成應用開發與自動化部署感謝大家的聆聽！謝謝！