ORIONHEALTH?Orion醫院信息集成平臺解決方案OrionHealthSolutionConsultingAPAC文件歷史版本時間作者&注1.02015-01-24謝欣初始版本2.02015-07-26謝欣添加產品優勢、硬件需求、容災方案和實例解析TOC\o"1-5"\h\z\o"CurrentDocument"1引言 52系統建設目標及設計要求\o"CurrentDocument"解決問題一：醫療臨床信息連續性及相關性 5\o"CurrentDocument"解決問題二：醫療臨床信息標準化及再利用 5\o"CurrentDocument"設計要求 5\o"CurrentDocument"3OrionHealth公司及其系^￡用性 6\o"CurrentDocument"3.1 Orion產品優勢 6\o"CurrentDocument"4方案描述 7\o"CurrentDocument"5硬件需求 8\o"CurrentDocument"醫院規模定義 8\o"CurrentDocument"小型醫院 8\o"CurrentDocument"中型醫院 9\o"CurrentDocument"大型醫院 9\o"CurrentDocument"6容災方案 10\o"CurrentDocument"7實例解析 11\o"CurrentDocument"8案例展示 14\o"CurrentDocument"上海市公共衛生臨床中心 14\o"CurrentDocument"復旦大學附屬兒科醫院 15\o"CurrentDocument"InlandEmpireHealthInformationExchange 15\o"CurrentDocument"加拿大阿爾伯塔州 151引言一個完善的醫院信息系統通常由數十個甚至上百個子系統組成，牽涉眾多的專業領域。這么龐大的系統需要非常專業化的軟件開發分工，整合不同廠商有特色的專業系統是醫院信息系統的發展趨勢，醫院信息化能夠取得成功必須保證這些系統的有效集成和數據的高度共享。 然而這些系統通常是隨著醫院的發展需求逐步建設的，它們來源于不同的廠家，基于不同的技術，缺乏統一的信息交換標準，這些系統的集成整合已經逐漸成為醫院數字化發展亟待解決的主要問題。Orion醫院信息集成平臺的構建方案著眼于在醫院內部實現醫療臨床信息的集成重組，利用先進的技術手段，在最大程度保護醫院已有IT系統投資的基礎上，建立面向臨床面向科研面向集團化管理的信息技術平臺，實現醫療臨床信息的統一訪問和深層次利用，促進醫院內部信息流的通暢，從而實現醫療服務質量、醫療管理質量和醫療科研水平的提高，更好的為患者服務。在實現醫院內部臨床信息整合的同時，統一設計和實現臨床信息的對外交換共享的模型，從而方便地實現與社區醫療、區域醫療和公衛系統的銜接。系統建設目標及設計要求系統間的整合、集成和擴展一直都是制約醫院數字化發展的主要障礙，由于不同廠商之間的產品不兼容，使得醫院整體信息化步履維艱。通過建設一個規范的系統集成平臺，在IHE、HL7等國際標準的基礎上，制定覆蓋醫療所有業務流程的系統集成規范，開發基于規范的系統集成平臺，為遺留的、當前的以及將來的系統提供了一個統一且標準的數據交換和工作流協同的平臺。通過本方案的實施，我們準備著重解決如下兩個關鍵問題和達到相應的設計要求：解決問題一：醫療臨床信息連續曲相關性基于現有的HIS、CIS、LIS、PACS等應用系統，實現醫療機構內部及之間信息的互操作性，需要在醫院內部的各個分立的業務系統之間構建基于信息交換標準（如HL7）的醫療臨床信息集成平臺。該平臺建成后，實現規范系統集成的信息交換標準及相應的接口規范標準，以信息技術的手段，在更高的層面上進行信息集成?？紤]到當前各個醫院內部的HIS、LIS、PACS、電子病歷等醫療信息管理系統和醫療輔助系統都已基本成型，因此醫療服務信息技術共享平臺與這些已建成系統的業務關聯性主要表現在集成層面，除非必要，不強制要求原有系統進行根本性改造，而是以信息服務的方式或標準映射的方式與醫療服務信息技術共享平臺進行信息服務級銜接。解決問題二：醫療臨床信息標準化及再利用建立以病人為中心，以優化流程為向導，以信息標準為基礎的醫療臨床信息標準化、電子化、語義化處理平臺，在實現臨床信息采集與存儲的基礎上，實現臨床信息的深度利用。醫療臨床信息標準化及電子化，就是將各類臨床信息整合成一個標準化、可計算的模型。該模型不是一個簡單的醫囑電子化，而是一個能夠應用先進的數據分析技術的臨床信息模型，從而使得醫務人員可以針對具體的疾病和患者情況，選擇最佳的醫療計劃和技術。醫療臨床信息標準化及電子化的另一個重點就是以病人為中心，將所有電子化的醫療臨床信息進行組織，形成以患者為核心的統一信息視圖。借助上面提及的醫療信息集成平臺，結合病人的主索引機制（EMPI），對HIS、CIS、LIS、PACS等信息系統進行信息集成，以提供完整而準確的病人臨床信息。設計要求針對集團醫院運作的實際需要，實現系統間的互聯互通及互操作性，集成平臺的設計具體要求包括以下幾個方面。一是先進性：系統必須嚴格遵循IHEITI技術框架及衛生部“基于電子病歷的醫院信息平臺技術規范”要求，符合國際醫療信息交換技術發展潮流；二是可擴展性：系統規劃設計必須站在醫院的全局高度，充分考慮到醫院內各個業務系統接入甚至協作醫院接入等互聯互通需要，并按照國際標準設計接口，確保今后和新增業務系統或其它院區信息平臺的銜接；三是可靠性：系統應具有高可用性，支持7x24小時工作模式。同時系統提供完備的容災技術，以利于抗干擾運行；提供系統運行日志，以利于及時糾錯排障；四是安全性：系統提供嚴謹的用戶權限管理和重要操作監控記錄，保證系統使用的安全性；提供可靠的數據傳輸技術和患者隱私保護措施，保證數據安全。OrionHealth公司及其系統適用性OrionHealth是新西蘭的一家100%專注于醫療健康領域的軟件上市公司。它成立20多年來為全球醫療市場提供了世界一流的解決方案。方案通過異構系統之間的醫療信息交換以及將健康信息在一個統一門戶上的整合，解決了“信息孤島”和“信息煙囪”的問題，進而提高了醫療質量和臨床決策的精度和速度。OrionHealth醫院系統為臨床醫護人員展示了一個清晰，合理的病人記錄，并可在其現有的臨床工作流程中使用。OrionHealth醫院系統能提供準確和關聯的完整病人信息，可優化臨床應用工作流程。與其他醫療產品進行集成之后，就可以很容易地在這些系統之間共享信息。OrionHealth醫院系統利用強大的集成引擎OrionHealthRhapsody對所有現有和老舊系統的數據進行了無縫集成。Rhapsody強大的集成能力允許新的系統和模塊成功地集成到現有的系統中。OrionHealth醫院系統本身可以很容易地被集成到現有的系統架構內，而不需要更換現有的臨床系統，如實驗室信息系統，放射科信息系統或其他專業系統。OrionHealth醫院系統的靈活性，使得醫療機構能夠根據不斷變化的需求，對它迅速進行改動，使實施新的醫護模式成為可能，并且可以與其他醫療機構合作對病人進行醫療協同服務。3.1 Orion產品優勢OrionHealth公司作為全球化的、獨立運營的電子健康軟件公司，已經在互連互通和互操作性的解決方案上為醫療機構/醫院和區域提供過其公認且可靠的經驗。公司的Rhapsody集成引擎更是以集成平臺的核心軟件成為享譽全球的品牌，常年居于美國KLAS排名的三甲位置。選擇新西蘭奧聯公司作為集成平臺的原廠商，將獲得以下優勢：OrionHealth公司是全球最突出的醫療保健互操作性解決方案的供應商，也是美國健康信息交換的主要供應商。公司的業務遍及全球30多個國家，并在27個國家設有分公司及辦事處；OrionHealth公司擁有全球最專業的醫療信息服務團隊，其全球服務中心能全天候為客戶提供支持服務;OrionHealth公司的集成引擎獲得了美國MU、FDA和英國ITK體系的認證；美國有49個州的聯邦疾控中心選擇OrionHealth公司的集成引擎作為首要的消息傳送軟件；美國馬薩諸塞州聯手OrionHealth公司打造州級醫療信息交換平臺，并獲得奧巴馬政府特批的醫療信息建設資金；新加坡選擇OrionHealth公司的醫院解決方案（包括集成引擎）建成全球首個國家電子檔案；中國有130多家醫院（大多為三甲醫院）在使用OrionHealth公司的軟件。在幫助醫院實現醫療信息系統的全面互連互通和互操作性的同時，OrionHealth的Rhapsody集成引擎還通過以下的特性提升用戶的使用體驗：易于使用，支持復雜的集成要求：集成引擎的開發實施都封裝成各種控件模塊，絕大部分通過配置即可完成，僅有少量部分需要用到簡單的JavaScript腳本和SQL語句；集成引擎可獨立安裝及運行，本身不依托任何數據庫系統。引擎的消息存儲庫是基于文件系統，穩定、快速；支持標準化，內置多種國際主流的醫療信息交換標注，如HL7和其最新的FHIR標準。同時集成引擎提供圖形化的映射組件，無需業務系統進行接口改造即可完成標準轉換；集成引擎支持IHE標準，包含IHE交換工具；集成引擎內置集成測試功能，可以對流程中的每一個節點的配置進行對比測試代碼的語法及邏輯錯誤。集成引擎提供簡化的日常監控：提供可通過網絡瀏覽器訪問的中文監控界面，基于安卓和iOS系統的手機終端監控和將多個引擎的監控集中在同一個頁面上進行展示的儀表盤；集成引擎內置版本控制，可以監控和回滾業務邏輯配置上的修改；集成引擎的配置遷移簡單迅速，可以通過導出/導入單一的配置文件來實現。方案描述方案設計的數字化集成平臺利用消息中間件的企業服務總線，實現各業務系統的數據級整合。它主要包括如下建設內容：建立一個IT基礎平臺：建立一個符合SOA設計理念的，可擴展的IT基礎架構，為醫院內部多業務系統的接入提供底層支撐。規范臨床數據的收集、存儲和共享方式確立以HL7CDA為標準的臨床信息模型，實現基于IHE的臨床數據共享交換架構。同時基于先進的語義分析技術，實現臨床數據的深度利用。規范業務數據交換標準和系統接入方式確立以HL7為標準的業務數據交換，支持HL7標準業務數據與非HL7標準業務數據的轉化機制，形成一套規范的集成接口的設計要求規范，指導未來的系統接入。提供統一的醫療數據訪問服務使用一個統一視圖對醫院的病人信息進行訪問，確保醫院內的臨床醫生能夠無縫訪問完整的病人記錄并獲得相同的病人診療信息。如上圖所示，在整個系統架構中，Orion的解決方案主要分為以下幾個層次：集成服務層：以總線的方式構建集成平臺，負責實現各個接入系統之間的信息交換功能。數據服務層：負責整個數據中心庫的數據管理，即數據中心庫。頁面展現層：構建業務門戶，實現單點登錄和個性化處理。根據對需求的分析和理解，本項目的建設應該分成兩個關鍵部分：醫療信息集成平臺使用Rhapsody引擎為醫院內各個業務系統建立一個集成平臺，規范臨床信息模型及信息共享接口標準，規范系統集成的信息交換標準及相應的接口規范標準，以及建立對外的統一數據交換接口。此集成平臺在信息交互的過程中將有效臨床數據存入數據中心庫CDR中，并通過配套的Portal進行展示。外部交換平臺形成基于標準的外部信息交換，形成院間交換，同時預留與公衛、醫保等信息的交換接

口，從而實現基于標準的區域醫療信息共享交換體系。為保證院內對同一個患者，但分布在不同系統中的個人信息采集的完整性和準確性，需要建立患者主索引(EnterpriseMasterPatientIndex，EMPI)服務，從而達到通過唯一的患者標識將多個醫療信息系統有效地關聯在一起。建立患者主索引是實現大型醫院內部系統集成以及醫院集團內資源共享的必要條件。同時院內需要建立一套完善的術語服務，以消除醫院各業務系統間的術語差異性，實現對醫療術語的統一管理。綜上所述，醫院信息平臺的總體架構可參考下圖所示：醫院伯總平ti醫院伯總平ti硬件需求5.1 醫院規模定義醫院規模床位消息接收/天消息處理/天小型醫院1-199~30,000~300,000中型醫院200-499~100,000~1,000,000大型(或集團)醫院500+~1,000,000+~3,000,000+5.2 小型醫院預計醫院規模：醫院少于200張床位醫院業務系統大約接收30,000條消息高峰時期的數據負載量大約為平常時期的4倍每日引擎處理的消息量約為300,000條，或者是每秒4條硬件推薦：WindowsServer或者LinuxoCPU:8核IntelXeono內存：8GBo36GB的硬盤空間用于安裝操作系統和引擎（RAID1）o200GB用于Rhapsody的數據存儲（RAID1）o64位操作系統oUPS電源中型醫院預計醫院規模：醫院擁有200-500張床位醫院業務系統大約接收100,000條消息高峰時期的數據負載量大約為平常時期的4倍每日引擎處理的消息量約為1,000,000條硬件推薦：WindowsServer或者LinuxoCPU：8核IntelXeono內存：8GBo36GB的硬盤空間用于安裝操作系統和引擎（RAID1）o200GB用于Rhapsody的數據存儲（RAID1）o64位操作系統oUPS電源大型醫院預計醫院規模：醫院擁有1200張以上床位醫院業務系統大約接收1,000,000條以上的消息高峰時期的數據負載量大約為平常時期的4倍每日引擎處理的消息量約為15,000,000條硬件推薦：LinuxoCPU：16核IntelXeono內存：16GBo36GB的硬盤空間用于安裝操作系統和引擎（RAID1）o200GB用于Rhapsody的數據存儲（RAID10）o200GB用于其它數據（RAID10）o64位操作系統oUPS電源SolarisoCPU：8核UltraSPARC或者SPARC64o內存：16GBo36GB的硬盤空間用于安裝操作系統和引擎（RAID1）o200GB用于Rhapsody的數據存儲（RAID10）o200GB用于其它數據（RAID10）o64位操作系統oUPS電源HP-UXoCPU:8核IntelItaniumo內存：16GBo36GB的硬盤空間用于安裝操作系統和引擎（RAID1）o200GB用于Rhapsody的數據存儲（RAID10）o200GB用于其它數據（RAID10）o64位操作系統oUPS電源AIXoCPU：8核PowerProcessoro內存：16GBo36GB的硬盤空間用于安裝操作系統和引擎（RAID1）o200GB用于Rhapsody的數據存儲（RAID10）o200GB用于其它數據（RAID10）o64位操作系統oUPS電源容災方案根據醫院信息平臺的實際需求，一套良好的容災方案可以更好的保證院內系統的平穩運行。OrionHealth的Rhapsody集成引擎支持主備模式的架構部署（active-passive）。在使用此種架構的時候，主被兩臺服務器上的引擎將共享引擎消息存儲庫（物理文件夾，通常放置于存儲區域網絡上［StorageAreaNetwork,SAN］）,如下圖所示：

醫院網絡Rhapsody國以IP主服務器醫院網絡Rhapsody國以IP主服務器 *各服務器消息存儲庫fSAN）當主服務器上的Rhapsody引擎發生異常時，備用服務器的引擎隨即啟動接管主服務器引擎的工作。由于兩臺服務器使用的是相同的消息存儲庫，因此正在處理過程中的消息將會被繼續處理而不會造成丟失或者需要原業務系統重新發送。同時，所有的引擎連接都是通過一個虛擬IP完成，而這個IP永遠指向正常工作的那臺引擎服務器。實例解析任何級別的區域醫療平臺的信息初始來源都是醫療機構（醫院），而醫院信息系統對信息進行處理的第一步就是收集和傳遞信息。通常信息流是伴隨著各式各樣窗口業務處理過程發生的，醫療事務就是其中一個典型的例子。對于整個醫院信息系統來說，窗口事務處理的計算機系統就是一個完整的HIS數據收集端口。它們是HIS伸向信息發源地的觸角、感受器。以病人掛號、之后在就診過程中需要進行血檢的流程為例，信息流（以下稱為“消息”）就需要從HIS發送到LIS。

HanderRncpertyPop□alkinErrarHandingHanderRncpertyPop□alkinErrarHandingrendla上圖是一個簡單的將ADT（入院/掛號、出院和轉院）消息通過Rhapsody引擎從HIS系統發送至LIS系統的簡單流程圖。圖中包括HIS的TCPServer通信點：引擎通過此通信點監聽一個端口，接收從HIS系統傳來的ADT消息；同時也用它向HIS系統發送收到消息的回執ACK或者NACKLIS的TCP代理的通信點：引擎通過此通信點向LIS系統開放的TCP端口發送從HIS系統收集到的消息；同時等待LIS系統發送的消息回執ACK或者NACKE-mail客戶端通信點：引擎通過此通信點向系統監控人員或者相關管理人員發送消息交互的狀態信息，特別是在發生錯誤的時候，及時通知相關人員垃圾箱通信點：引擎通過此通信點回收不需要保存的LIS系統回執HL7回執生成器：引擎通過此控件在成功接收消息以后生成HL7標準回執消息，并傳遞給HIS的TCPServer通信點JavaScript過濾器HandleNACK：引擎通過此控件處理從LIS系統發回的NACK回執No-operation過濾器：引擎通過此控件將消息進行分流，在分流路徑上的消息為原消息的一個副本依上圖所示，引擎將從HIS接收收到的ADT消息分流成兩份，一份發給HL7回執生成器，然后將生成的回執發還給HIS系統，如下圖所示

當HIS系統接收到一個ACK回執的時候，表明此消息已經被引擎正常接收并開始進行處理了。設計由Rhapsody引擎發送回執的優勢在于減少HIS系統確認消息成功發送的等待時間。在點對點的消息交互模式中，HIS系統需要等待LIS系統發送回執，等待時間會相對較長，從而使后續消息的傳送發生延時。更糟糕的是，如果HIS系統需要將消息同時發送給多個其它系統，如同時發送給LIS、RIS和CIS，采用點對點的交互模式，等待時間會更長，因為HIS系統需要分別收到三個ACK回執才能確認消息完全發送成功。上圖的設計也就避免了這一問題的發生。同時引擎將另一份相同的ADT消息副本通過LIS的TCP代理發送去LIS系統，如下圖所示當LIS系統將回執返回給引擎的LISTCP代理通信點的時候，引擎又將這份回執分流成兩份，一份是正常的ACK，直接發送給垃圾箱通信點丟棄，如下圖所示另一份為錯誤回執NACK（如果存在）的副本，將其使用JavaScript過濾器進行簡單處理以后，再通過E-mail客戶端通信點發送給相關人員，如下圖所示在很多情況下，一個高質量的路由一般是要對傳遞過程中產生的錯誤進行處理，如下圖所示以上是對一個簡單的HIS->LIS路由的分解，它展示了ADT消息在醫療機構內的傳遞方式。其他系統的互通，如HIS->PACS，HIS->CIS可以以此為參照進行設置。當LIS或者PACS系統將檢查報告或者影像圖片發還給HIS系統時，消息傳遞方式和上圖基本相同，不過路由上的邏輯將更為復雜。案例展示8.1 上海市公共衛生臨床中心上海市公共衛生臨床中心是復旦大學附屬三級甲等醫院，擁有金山總院與水電路分院兩個院區，兩院區相隔較遠，分別使用獨立的業務系統，兩院醫療信息無法共享，同一患者的臨床信息在兩個院區之間無法相互調閱，兩院醫療數據需要分別維護，導致整體上形成信息煙囪，造成了數據冗余、效率低下和資源浪費等問題。醫院通過使用Rhapsody引擎/集成平臺，將全院系統架構改造如下EMPI患者主素引CMVEMPI患者主素引CMV受控醫學詞匯摩臨昧數據中心(OrionHealthCorepacka^e)HISLISRISEMRHI3LI3RIS新的架構解決了集成平臺的建設，各個系統直接與平臺交互，降低各系統之間的耦合性，HIS性能提升；兩個院區通過院內平臺公用一個RIS系統，檢查結果平臺分發到兩個HIS;兩個院區通過院內平臺公用一個手麻系統，手術申請通過平臺匯總給手麻系統，手麻系統返回的收費信息，領藥信息通過平臺分發到各個HIS系統中；基礎數據同步：統一維護，統一分發，保持系統的數據一致性；同一個患者在兩個院區的傳染病信息只需上報一次；兩個院區的患者統一管理；兩個院區的臨床信息實現以患者為中心共享，并且集成到醫生工作站供醫生快捷調閱；兩個院區的醫技報告實現共享；通過平臺，實現兩個院區的處方統一點評；實現兩個院區的科室、專家統一可以在手機上統一預約，并將預約信息反饋給各自的HIS系統。此架構為典型的集團醫院信息集成平臺架構。

?旦大學附屬兒科醫院復旦大學附屬兒科醫院通過使用Rhapsody引擎對現有HIS、CIS、LIS、PACS進行基于國際醫療信息交換標準一HL7標準的集成，將醫院的歷史數據和實時產生數據匯總到臨床數據中心，實現以崽者為中心的門診、住院診療過程的數據匯聚，為臨床醫護人員提供患者360視圖。其