Orion醫(yī)院信息集成平臺解決實施方案v2

./Orion醫(yī)院信息集成平臺解決方案OrionHealthSolutionConsultingAPAC文件歷史版本時間作者備注1.02015-01-24謝欣初始版本2.02015-07-26謝欣添加產(chǎn)品優(yōu)勢、硬件需求、容災(zāi)方案和實例解析目錄TOC\o"2-5"\h\z\t"Heading1,1"1引言42系統(tǒng)建設(shè)目標及設(shè)計要求42.1解決問題一：醫(yī)療臨床信息連續(xù)性及相關(guān)性42.2解決問題二：醫(yī)療臨床信息標準化及再利用42.3設(shè)計要求43OrionHealth公司及其系統(tǒng)適用性53.1Orion產(chǎn)品優(yōu)勢54方案描述65硬件需求75.1醫(yī)院規(guī)模定義75.2小型醫(yī)院75.3中型醫(yī)院85.4大型醫(yī)院86容災(zāi)方案97實例解析108案例展示128.1上海市公共衛(wèi)生臨床中心128.2復(fù)旦大學(xué)附屬兒科醫(yī)院138.3InlandEmpireHealthInformationExchange138.4加拿大阿爾伯塔州14引言一個完善的醫(yī)院信息系統(tǒng)通常由數(shù)十個甚至上百個子系統(tǒng)組成,牽涉眾多的專業(yè)領(lǐng)域。這么龐大的系統(tǒng)需要非常專業(yè)化的軟件開發(fā)分工,整合不同廠商有特色的專業(yè)系統(tǒng)是醫(yī)院信息系統(tǒng)的發(fā)展趨勢,醫(yī)院信息化能夠取得成功必須保證這些系統(tǒng)的有效集成和數(shù)據(jù)的高度共享。然而這些系統(tǒng)通常是隨著醫(yī)院的發(fā)展需求逐步建設(shè)的,它們來源于不同的廠家,基于不同的技術(shù),缺乏統(tǒng)一的信息交換標準,這些系統(tǒng)的集成整合已經(jīng)逐漸成為醫(yī)院數(shù)字化發(fā)展亟待解決的主要問題。Orion醫(yī)院信息集成平臺的構(gòu)建方案著眼于在醫(yī)院內(nèi)部實現(xiàn)醫(yī)療臨床信息的集成重組,利用先進的技術(shù)手段,在最大程度保護醫(yī)院已有IT系統(tǒng)投資的基礎(chǔ)上,建立面向臨床面向科研面向集團化管理的信息技術(shù)平臺,實現(xiàn)醫(yī)療臨床信息的統(tǒng)一訪問和深層次利用,促進醫(yī)院內(nèi)部信息流的通暢,從而實現(xiàn)醫(yī)療服務(wù)質(zhì)量、醫(yī)療管理質(zhì)量和醫(yī)療科研水平的提高,更好的為患者服務(wù)。在實現(xiàn)醫(yī)院內(nèi)部臨床信息整合的同時,統(tǒng)一設(shè)計和實現(xiàn)臨床信息的對外交換共享的模型,從而方便地實現(xiàn)與社區(qū)醫(yī)療、區(qū)域醫(yī)療和公衛(wèi)系統(tǒng)的銜接。系統(tǒng)建設(shè)目標及設(shè)計要求系統(tǒng)間的整合、集成和擴展一直都是制約醫(yī)院數(shù)字化發(fā)展的主要障礙,由于不同廠商之間的產(chǎn)品不兼容,使得醫(yī)院整體信息化步履維艱。通過建設(shè)一個規(guī)范IHE、HL7業(yè)務(wù)流程的系統(tǒng)集成規(guī)范,開發(fā)基于規(guī)范的系統(tǒng)集成平臺,為遺留的、當(dāng)前的以及將來的系統(tǒng)提供了一個統(tǒng)一且標準的數(shù)據(jù)交換和工作流協(xié)同的平臺。通過本方案的實施,我們準備著重解決如下兩個關(guān)鍵問題和達到相應(yīng)的設(shè)計要求：解決問題一：醫(yī)療臨床信息連續(xù)性及相關(guān)性基于現(xiàn)有的HIS、CIS、LIS、PACS等應(yīng)用系統(tǒng),實現(xiàn)醫(yī)療機構(gòu)內(nèi)部及之間信息的互操作性,需要在醫(yī)院內(nèi)部的各個分立的業(yè)務(wù)系統(tǒng)之間構(gòu)建基于信息交換標準〔如HL7的醫(yī)療臨床信息集成平臺。該平臺建成后,實現(xiàn)規(guī)范系統(tǒng)集成的信息交換標準及相應(yīng)的接口規(guī)范標準,以信息技術(shù)的手段,在更高的層面上進行信息集成?？紤]到當(dāng)前各個醫(yī)院內(nèi)部的HIS、LIS、PACS、電子病歷等醫(yī)療信息管理系統(tǒng)和醫(yī)療輔助系統(tǒng)都已基本成型,因此醫(yī)療服務(wù)信息技術(shù)共享平臺與這些已建成系統(tǒng)的業(yè)務(wù)關(guān)聯(lián)性主要表現(xiàn)在集成層面,除非必要,不強制要求原有系統(tǒng)進行根本性改造,而是以信息服務(wù)的方式或標準映射的方式與醫(yī)療服務(wù)信息技術(shù)共享平臺進行信息服務(wù)級銜接。解決問題二：醫(yī)療臨床信息標準化及再利用建立以病人為中心,以優(yōu)化流程為向?qū)?以信息標準為基礎(chǔ)的醫(yī)療臨床信息標準化、電子化、語義化處理平臺,在實現(xiàn)臨床信息采集與存儲的基礎(chǔ)上,實現(xiàn)臨床信息的深度利用。醫(yī)療臨床信息標準化及電子化,就是將各類臨床信息整合成一個標準化、可計算的模型。該模型不是一個簡單的醫(yī)囑電子化,而是一個能夠應(yīng)用先進的數(shù)據(jù)分析技術(shù)的臨床信息模型,從而使得醫(yī)務(wù)人員可以針對具體的疾病和患者情況,選擇最佳的醫(yī)療計劃和技術(shù)。醫(yī)療臨床信息標準化及電子化的另一個重點就是以病人為中心,將所有電子化的醫(yī)療臨床信息進行組織,形成以患者為核心的統(tǒng)一信息視圖。借助上面提及的醫(yī)療信息集成平臺,結(jié)合病人的主索引機制〔EMPI,對HIS、CIS、LIS、PACS等信息系統(tǒng)進行信息集成,以提供完整而準確的病人臨床信息。設(shè)計要求針對集團醫(yī)院運作的實際需要,實現(xiàn)系統(tǒng)間的互聯(lián)互通及互操作性,集成平臺的設(shè)計具體要求包括以下幾個方面。一是先進性：系統(tǒng)必須嚴格遵循IHEITI技術(shù)框架及衛(wèi)生部"基于電子病歷的醫(yī)院信息平臺技術(shù)規(guī)范"要求,符合國際醫(yī)療信息交換技術(shù)發(fā)展潮流；二是可擴展性：系統(tǒng)規(guī)劃設(shè)計必須站在醫(yī)院的全局高度,充分考慮到醫(yī)院內(nèi)各個業(yè)務(wù)系統(tǒng)接入甚至協(xié)作醫(yī)院接入等互聯(lián)互通需要,并按照國際標準設(shè)計接口,確保今后和新增業(yè)務(wù)系統(tǒng)或其它院區(qū)信息平臺的銜接；三是可靠性：系統(tǒng)應(yīng)具有高可用性,支持7x24小時工作模式。同時系統(tǒng)提供完備的容災(zāi)技術(shù),以利于抗干擾運行；提供系統(tǒng)運行日志,以利于及時糾錯排障；四是安全性：系統(tǒng)提供嚴謹?shù)挠脩魴?quán)限管理和重要操作監(jiān)控記錄,保證系統(tǒng)使用的安全性；提供可靠的數(shù)據(jù)傳輸技術(shù)和患者隱私保護措施,保證數(shù)據(jù)安全。OrionHealth公司及其系統(tǒng)適用性O(shè)rionHealth是新西蘭的一家100%專注于醫(yī)療健康領(lǐng)域的軟件上市公司。它成立20多年來為全球醫(yī)療市場提供了世界一流的解決方案。方案通過異構(gòu)系統(tǒng)之間的醫(yī)療信息交換以及將健康信息在一個統(tǒng)一門戶上的整合,解決了"信息孤島"和"信息煙囪"的問題,進而提高了醫(yī)療質(zhì)量和臨床決策的精度和速度。OrionHealth醫(yī)院系統(tǒng)為臨床醫(yī)護人員展示了一個清晰,合理的病人記錄,并可在其現(xiàn)有的臨床工作流程中使用。OrionHealth醫(yī)院系統(tǒng)能提供準確和關(guān)聯(lián)的完整病人信息,可優(yōu)化臨床應(yīng)用工作流程。與其他醫(yī)療產(chǎn)品進行集成之后,就可以很容易地在這些系統(tǒng)之間共享信息。OrionHealth醫(yī)院系統(tǒng)利用強大的集成引擎OrionHealth?Rhapsody?對所有現(xiàn)有和老舊系統(tǒng)的數(shù)據(jù)進行了無縫集成。Rhapsody強大的集成能力允許新的系統(tǒng)和模塊成功地集成到現(xiàn)有的系統(tǒng)中。OrionHealth醫(yī)院系統(tǒng)本身可以很容易地被集成到現(xiàn)有的系統(tǒng)架構(gòu)內(nèi),而不需要更換現(xiàn)有的臨床系統(tǒng),如實驗室信息系統(tǒng),放射科信息系統(tǒng)或其他專業(yè)系統(tǒng)。OrionHealth醫(yī)院系統(tǒng)的靈活性,使得醫(yī)療機構(gòu)能夠根據(jù)不斷變化的需求,對它迅速進行改動,使實施新的醫(yī)護模式成為可能,并且可以與其他醫(yī)療機構(gòu)合作對病人進行醫(yī)療協(xié)同服務(wù)。Orion產(chǎn)品優(yōu)勢OrionHealth公司作為全球化的、獨立運營的電子健康軟件公司,已經(jīng)在互連互通和互操作性的解決方案上為醫(yī)療機構(gòu)／醫(yī)院和區(qū)域提供過其公認且可靠的經(jīng)驗。公司的Rhapsody集成引擎更是以集成平臺的核心軟件成為享譽全球的品牌,常年居于美國KLAS排名的三甲位置。選擇新西蘭奧聯(lián)公司作為集成平臺的原廠商,將獲得以下優(yōu)勢：OrionHealth公司是全球最突出的醫(yī)療保健互操作性解決方案的供應(yīng)商,也是美國健康信息交換的主要供應(yīng)商。公司的業(yè)務(wù)遍及全球30多個國家,并在27個國家設(shè)有分公司及辦事處；OrionHealth公司擁有全球最專業(yè)的醫(yī)療信息服務(wù)團隊,其全球服務(wù)中心能全天候為客戶提供支持服務(wù)；OrionHealth公司的集成引擎獲得了美國MU、FDA和英國ITK體系的認證；美國有49個州的聯(lián)邦疾控中心選擇OrionHealth公司的集成引擎作為首要的消息傳送軟件；美國馬薩諸塞州聯(lián)手OrionHealth公司打造州級醫(yī)療信息交換平臺,并獲得奧巴馬政府特批的醫(yī)療信息建設(shè)資金；新加坡選擇OrionHealth公司的醫(yī)院解決方案〔包括集成引擎建成全球首個國家電子檔案；中國有130多家醫(yī)院〔大多為三甲醫(yī)院在使用OrionHealth公司的軟件。在幫助醫(yī)院實現(xiàn)醫(yī)療信息系統(tǒng)的全面互連互通和互操作性的同時,OrionHealth的Rhapsody集成引擎還通過以下的特性提升用戶的使用體驗：易于使用,支持復(fù)雜的集成要求：集成引擎的開發(fā)實施都封裝成各種控件模塊,絕大部分通過配置即可完成,僅有少量部分需要用到簡單的JavaScript腳本和SQL語句；集成引擎可獨立安裝及運行,本身不依托任何數(shù)據(jù)庫系統(tǒng)。引擎的消息存儲庫是基于文件系統(tǒng),穩(wěn)定、快速；支持標準化,內(nèi)置多種國際主流的醫(yī)療信息交換標注,如HL7和其最新的FHIR標準。同時集成引擎提供圖形化的映射組件,無需業(yè)務(wù)系統(tǒng)進行接口改造即可完成標準轉(zhuǎn)換；集成引擎支持IHE標準,包含IHE交換工具；集成引擎內(nèi)置集成測試功能,可以對流程中的每一個節(jié)點的配置進行對比測試代碼的語法及邏輯錯誤。集成引擎提供簡化的日常監(jiān)控：提供可通過網(wǎng)絡(luò)瀏覽器訪問的中文監(jiān)控界面,基于安卓和iOS系統(tǒng)的手機終端監(jiān)控和將多個引擎的監(jiān)控集中在同一個頁面上進行展示的儀表盤；集成引擎內(nèi)置版本控制,可以監(jiān)控和回滾業(yè)務(wù)邏輯配置上的修改；集成引擎的配置遷移簡單迅速,可以通過導(dǎo)出／導(dǎo)入單一的配置文件來實現(xiàn)。方案描述方案設(shè)計的數(shù)字化集成平臺利用消息中間件的企業(yè)服務(wù)總線,實現(xiàn)各業(yè)務(wù)系統(tǒng)的數(shù)據(jù)級整合。它主要包括如下建設(shè)內(nèi)容：建立一個IT基礎(chǔ)平臺：建立一個符合SOA設(shè)計理念的,可擴展的IT基礎(chǔ)架構(gòu),為醫(yī)院內(nèi)部多業(yè)務(wù)系統(tǒng)的接入提供底層支撐。規(guī)范臨床數(shù)據(jù)的收集、存儲和共享方式：確立以HL7CDA為標準的臨床信息模型,實現(xiàn)基于IHE的臨床數(shù)據(jù)共享交換架構(gòu)。同時基于先進的語義分析技術(shù),實現(xiàn)臨床數(shù)據(jù)的深度利用。規(guī)范業(yè)務(wù)數(shù)據(jù)交換標準和系統(tǒng)接入方式：確立以HL7為標準的業(yè)務(wù)數(shù)據(jù)交換,支持HL7標準業(yè)務(wù)數(shù)據(jù)與非HL7標準業(yè)務(wù)數(shù)據(jù)的轉(zhuǎn)化機制,形成一套規(guī)范的集成接口的設(shè)計要求規(guī)范,指導(dǎo)未來的系統(tǒng)接入。提供統(tǒng)一的醫(yī)療數(shù)據(jù)訪問服務(wù)：使用一個統(tǒng)一視圖對醫(yī)院的病人信息進行訪問,確保醫(yī)院內(nèi)的臨床醫(yī)生能夠無縫訪問完整的病人記錄并獲得相同的病人診療信息。如上圖所示,在整個系統(tǒng)架構(gòu)中,Orion的解決方案主要分為以下幾個層次：集成服務(wù)層：以總線的方式構(gòu)建集成平臺,負責(zé)實現(xiàn)各個接入系統(tǒng)之間的信息交換功能。數(shù)據(jù)服務(wù)層：負責(zé)整個數(shù)據(jù)中心庫的數(shù)據(jù)管理,即數(shù)據(jù)中心庫。頁面展現(xiàn)層：構(gòu)建業(yè)務(wù)門戶,實現(xiàn)單點登錄和個性化處理。根據(jù)對需求的分析和理解,本項目的建設(shè)應(yīng)該分成兩個關(guān)鍵部分：醫(yī)療信息集成平臺：使用Rhapsody引擎為醫(yī)院內(nèi)各個業(yè)務(wù)系統(tǒng)建立一個集成平臺,規(guī)范臨床信息模型及信息共享接口標準,規(guī)范系統(tǒng)集成的信息交換標準及相應(yīng)的接口規(guī)范標準,以及建立對外的統(tǒng)一數(shù)據(jù)交換接口。此集成平臺在信息交互的過程中將有效臨床數(shù)據(jù)存入數(shù)據(jù)中心庫CDR中,并通過配套的Portal進行展示。外部交換平臺：形成基于標準的外部信息交換,形成院間交換,同時預(yù)留與公衛(wèi)、醫(yī)保等信息的交換接口,從而實現(xiàn)基于標準的區(qū)域醫(yī)療信息共享交換體系。為保證院內(nèi)對同一個患者,但分布在不同系統(tǒng)中的個人信息采集的完整性和準確性,需要建立患者主索引〔EnterpriseMasterPatientIndex,EMPI服務(wù),從而達到通過唯一的患者標識將多個醫(yī)療信息系統(tǒng)有效地關(guān)聯(lián)在一起。建立患者主索引是實現(xiàn)大型醫(yī)院內(nèi)部系統(tǒng)集成以及醫(yī)院集團內(nèi)資源共享的必要條件。同時院內(nèi)需要建立一套完善的術(shù)語服務(wù),以消除醫(yī)院各業(yè)務(wù)系統(tǒng)間的術(shù)語差異性,實現(xiàn)對醫(yī)療術(shù)語的統(tǒng)一管理。綜上所述,醫(yī)院信息平臺的總體架構(gòu)可參考下圖所示：硬件需求醫(yī)院規(guī)模定義醫(yī)院規(guī)模床位消息接收/天消息處理/天小型醫(yī)院1-199~30,000~300,000中型醫(yī)院200-499~100,000~1,000,000大型〔或集團醫(yī)院500+~1,000,000+~3,000,000+小型醫(yī)院預(yù)計醫(yī)院規(guī)模：醫(yī)院少于200張床位醫(yī)院業(yè)務(wù)系統(tǒng)大約接收30,000條消息高峰時期的數(shù)據(jù)負載量大約為平常時期的4倍每日引擎處理的消息量約為300,000條,或者是每秒4條硬件推薦：WindowsServer或者LinuxCPU：8核IntelXeon內(nèi)存：8GB36GB的硬盤空間用于安裝操作系統(tǒng)和引擎〔RAID1200GB用于Rhapsody的數(shù)據(jù)存儲〔RAID164位操作系統(tǒng)UPS電源中型醫(yī)院預(yù)計醫(yī)院規(guī)模：醫(yī)院擁有200-500張床位醫(yī)院業(yè)務(wù)系統(tǒng)大約接收100,000條消息高峰時期的數(shù)據(jù)負載量大約為平常時期的4倍每日引擎處理的消息量約為1,000,000條硬件推薦：WindowsServer或者LinuxCPU：8核IntelXeon內(nèi)存：8GB36GB的硬盤空間用于安裝操作系統(tǒng)和引擎〔RAID1200GB用于Rhapsody的數(shù)據(jù)存儲〔RAID164位操作系統(tǒng)UPS電源大型醫(yī)院預(yù)計醫(yī)院規(guī)模：醫(yī)院擁有1200張以上床位醫(yī)院業(yè)務(wù)系統(tǒng)大約接收1,000,000條以上的消息高峰時期的數(shù)據(jù)負載量大約為平常時期的4倍每日引擎處理的消息量約為15,000,000條硬件推薦：LinuxCPU：16核IntelXeon內(nèi)存：16GB36GB的硬盤空間用于安裝操作系統(tǒng)和引擎〔RAID1200GB用于Rhapsody的數(shù)據(jù)存儲〔RAID10200GB用于其它數(shù)據(jù)〔RAID1064位操作系統(tǒng)UPS電源SolarisCPU：8核UltraSPARC或者SPARC64內(nèi)存：16GB36GB的硬盤空間用于安裝操作系統(tǒng)和引擎〔RAID1200GB用于Rhapsody的數(shù)據(jù)存儲〔RAID10200GB用于其它數(shù)據(jù)〔RAID1064位操作系統(tǒng)UPS電源HP-UXCPU：8核IntelItanium內(nèi)存：16GB36GB的硬盤空間用于安裝操作系統(tǒng)和引擎〔RAID1200GB用于Rhapsody的數(shù)據(jù)存儲〔RAID10200GB用于其它數(shù)據(jù)〔RAID1064位操作系統(tǒng)UPS電源AIXCPU：8核PowerProcessor內(nèi)存：16GB36GB的硬盤空間用于安裝操作系統(tǒng)和引擎〔RAID1200GB用于Rhapsody的數(shù)據(jù)存儲〔RAID10200GB用于其它數(shù)據(jù)〔RAID1064位操作系統(tǒng)UPS電源容災(zāi)方案根據(jù)醫(yī)院信息平臺的實際需求,一套良好的容災(zāi)方案可以更好的保證院內(nèi)系統(tǒng)的平穩(wěn)運行。OrionHealth的Rhapsody集成引擎支持主備模式的架構(gòu)部署〔active-passive。在使用此種架構(gòu)的時候,主被兩臺服務(wù)器上的引擎將共享引擎消息存儲庫〔物理文件夾,通常放置于存儲區(qū)域網(wǎng)絡(luò)上［StorageAreaNetwork,SAN］,如下圖所示：當(dāng)主服務(wù)器上的Rhapsody引擎發(fā)生異常時,備用服務(wù)器的引擎隨即啟動接管主服務(wù)器引擎的工作。由于兩臺服務(wù)器使用的是相同的消息存儲庫,因此正在處理過程中的消息將會被繼續(xù)處理而不會造成丟失或者需要原業(yè)務(wù)系統(tǒng)重新發(fā)送。同時,所有的引擎連接都是通過一個虛擬IP完成,而這個IP永遠指向正常工作的那臺引擎服務(wù)器。實例解析任何級別的區(qū)域醫(yī)療平臺的信息初始來源都是醫(yī)療機構(gòu)〔醫(yī)院,而醫(yī)院信息系統(tǒng)對信息進行處理的第一步就是收集和傳遞信息。通常信息流是伴隨著各式各樣窗口業(yè)務(wù)處理過程發(fā)生的,醫(yī)療事務(wù)就是其中一個典型的例子。對于整個醫(yī)院信息系統(tǒng)來說,窗口事務(wù)處理的計算機系統(tǒng)就是一個完整的HIS數(shù)據(jù)收集端口。它們是HIS伸向信息發(fā)源地的觸角、感受器。以病人掛號、之后在就診過程中需要進行血檢的流程為例,信息流〔以下稱為"消息"就需要從HIS發(fā)送到LIS。上圖是一個簡單的將ADT〔入院／掛號、出院和轉(zhuǎn)院消息通過Rhapsody引擎從HIS系統(tǒng)發(fā)送至LIS系統(tǒng)的簡單流程圖。圖中包括HIS的TCPServer通信點：引擎通過此通信點監(jiān)聽一個端口,接收從HIS系統(tǒng)傳來的ADT消息；同時也用它向HIS系統(tǒng)發(fā)送收到消息的回執(zhí)ACK或者NACKLIS的TCP代理的通信點：引擎通過此通信點向LIS系統(tǒng)開放的TCP端口發(fā)送從HIS系統(tǒng)收集到的消息；同時等待LIS系統(tǒng)發(fā)送的消息回執(zhí)ACK或者NACKE-mail客戶端通信點：引擎通過此通信點向系統(tǒng)監(jiān)控人員或者相關(guān)管理人員發(fā)送消息交互的狀態(tài)信息,特別是在發(fā)生錯誤的時候,及時通知相關(guān)人員垃圾箱通信點：引擎通過此通信點回收不需要保存的LIS系統(tǒng)回執(zhí)HL7回執(zhí)生成器：引擎通過此控件在成功接收消息以后生成HL7標準回執(zhí)消息,并傳遞給HIS的TCPServer通信點JavaScript過濾器HandleNACK：引擎通過此控件處理從LIS系統(tǒng)發(fā)回的NACK回執(zhí)No-operation過濾器：引擎通過此控件將消息進行分流,在分流路徑上的消息為原消息的一個副本依上圖所示,引擎將從HIS接收收到的ADT消息分流成兩份,一份發(fā)給HL7回執(zhí)生成器,然后將生成的回執(zhí)發(fā)還給HIS系統(tǒng),如下圖所示當(dāng)HIS系統(tǒng)接收到一個ACK回執(zhí)的時候,表明此消息已經(jīng)被引擎正常接收并開始進行處理了。設(shè)計由Rhapsody引擎發(fā)送回執(zhí)的優(yōu)勢在于減少HIS系統(tǒng)確認消息成功發(fā)送的等待時間。在點對點的消息交互模式中,HIS系統(tǒng)需要等待LIS系統(tǒng)發(fā)送回執(zhí),等待時間會相對較長,從而使后續(xù)消息的傳送發(fā)生延時。更糟糕的是,如果HIS系統(tǒng)需要將消息同時發(fā)送給多個其它系統(tǒng),如同時發(fā)送給LIS、RIS和CIS,采用點對點的交互模式,等待時間會更長,因為HIS系統(tǒng)需要分別收到三個ACK回執(zhí)才能確認消息完全發(fā)送成功。上圖的設(shè)計也就避免了這一問題的發(fā)生。同時引擎將另一份相同的ADT消息副本通過LIS的TCP代理發(fā)送去LIS系統(tǒng),如下圖所示當(dāng)LIS系統(tǒng)將回執(zhí)返回給引擎的LISTCP代理通信點的時候,引擎又將這份回執(zhí)分流成兩份,一份是正常的ACK,直接發(fā)送給垃圾箱通信點丟棄,如下圖所示另一份為錯誤回執(zhí)NACK〔如果存在的副本,將其使用JavaScript過濾器進行簡單處理以后,再通過E-mail客戶端通信點發(fā)送給相關(guān)人員,如下圖所示在很多情況下,一個高質(zhì)量的路由一般是要對傳遞過程中產(chǎn)生的錯誤進行處理,如下圖所示以上是對一個簡單的HIS->LIS路由的分解,它展示了ADT消息在醫(yī)療機構(gòu)內(nèi)的傳遞方式。其他系統(tǒng)的互通,如HIS->PACS,HIS->CIS可以以此為參照進行設(shè)置。當(dāng)LIS或者PACS系統(tǒng)將檢查報告或者影像圖片發(fā)還給HIS系統(tǒng)時,消息傳遞方式和上圖基本相同,不過路由上的邏輯將更為復(fù)雜。案例展示上海市公共衛(wèi)生臨床中心上海市公共衛(wèi)生臨床中心是復(fù)旦大學(xué)附屬三級甲等醫(yī)院,擁有金山總院與水電路分院兩個院區(qū),兩院區(qū)相隔較遠,分別使用獨立的業(yè)務(wù)系統(tǒng),兩院醫(yī)療信息無法共享,同一患者的臨床信息在兩個院區(qū)之間無法相互調(diào)閱,兩院醫(yī)療數(shù)據(jù)需要分別維護,導(dǎo)致整體上形成信息煙囪,造成了數(shù)據(jù)冗余、效率低下和資源浪費等問題。醫(yī)院通過使用Rhapsody引擎／集成平臺,將全院系統(tǒng)架構(gòu)改造如下新的架構(gòu)解決了集成平臺的建設(shè),各個系統(tǒng)直接與平臺交互,降低各系統(tǒng)之間的耦合性,HIS性能提升；兩個院區(qū)通過院內(nèi)平臺公用一個RIS系統(tǒng),檢查結(jié)果平臺分發(fā)到兩個HIS；兩個院區(qū)通過院內(nèi)平臺公用一個手麻系統(tǒng),手術(shù)申請通過平臺匯總給手麻系統(tǒng),手麻系統(tǒng)返回的收費信息,領(lǐng)藥信息通過平臺分發(fā)到各個HIS系統(tǒng)中；基礎(chǔ)數(shù)據(jù)同步：統(tǒng)一維護,統(tǒng)一分發(fā),保持系統(tǒng)的數(shù)據(jù)一致性；同一個患者在兩個院區(qū)的傳染病信息只需上報一次；兩個院區(qū)的患者統(tǒng)一管理；兩個院區(qū)的臨床信息實現(xiàn)以患者為中心共享,并且集成到醫(yī)生工作站供醫(yī)生快捷調(diào)閱；兩個院區(qū)的醫(yī)技報告實現(xiàn)共享；通過平臺,實現(xiàn)兩個院區(qū)的處方統(tǒng)一點評；實現(xiàn)兩個院區(qū)的科室、專家統(tǒng)一可以在手機上統(tǒng)一預(yù)約,并將預(yù)約信息反饋給各自的HIS系統(tǒng)。此架構(gòu)為典型的集團醫(yī)院信息集成平臺架構(gòu)。復(fù)旦大學(xué)附屬兒科醫(yī)院復(fù)旦大學(xué)附屬兒科醫(yī)院通過使用Rhapsody引擎對現(xiàn)有HIS、CIS、LIS、PACS進行基于國際醫(yī)療信息交換標準—HL7標準的集成,將醫(yī)院的歷史數(shù)據(jù)和實時產(chǎn)生數(shù)據(jù)匯總到臨床數(shù)據(jù)中心,實現(xiàn)以患者為中心的門診、住院診療過程的數(shù)據(jù)匯聚,為臨床醫(yī)護人員提供患者360視