orion醫(yī)院信息集成平臺(tái)解決方案v20docxdocx(參考版)
2025-07-18 11:40本頁(yè)面
【正文】 Copyright 169。目前，阿爾伯塔州的電子健康檔案（EHR）系統(tǒng)已通過(guò)Orion Health 的臨床門(mén)戶整合了藥品、檢查檢驗(yàn)報(bào)告、放射影響、就診歷史、病人列表等信息，同時(shí)提供PACS影像瀏覽功能。 加拿大阿爾伯塔州加拿大的阿爾伯塔州選用了Orion Health 的臨床門(mén)戶來(lái)展示整個(gè)州的電子健康檔案（EHR）。在該工程中，Orion Health平臺(tái)的Rhapsody 引擎提供了強(qiáng)健的可擴(kuò)展的互操作性和數(shù)據(jù)集成；平臺(tái)的臨床門(mén)戶提供了快速的標(biāo)準(zhǔn)化數(shù)據(jù)查詢；同時(shí)平臺(tái)本身也具備了高度的延展性，為未來(lái)需求的增加提供了整合的可能。該項(xiàng)目使用了Orion Health的集成平臺(tái)，其中包括Rhapsody集成引擎，臨床數(shù)據(jù)庫(kù)CDR和臨床門(mén)戶Portal。 復(fù)旦大學(xué)附屬兒科醫(yī)院復(fù)旦大學(xué)附屬兒科醫(yī)院通過(guò)使用Rhapsody引擎對(duì)現(xiàn)有HIS、CIS、LIS、PACS進(jìn)行基于國(guó)際醫(yī)療信息交換標(biāo)準(zhǔn)—HL7標(biāo)準(zhǔn)的集成，將醫(yī)院的歷史數(shù)據(jù)和實(shí)時(shí)產(chǎn)生數(shù)據(jù)匯總到臨床數(shù)據(jù)中心，實(shí)現(xiàn)以患者為中心的門(mén)診、住院診療過(guò)程的數(shù)據(jù)匯聚，為臨床醫(yī)護(hù)人員提供患者360視圖。醫(yī)院通過(guò)使用Rhapsody引擎／集成平臺(tái)，將全院系統(tǒng)架構(gòu)改造如下新的架構(gòu)解決了l 集成平臺(tái)的建設(shè)，各個(gè)系統(tǒng)直接與平臺(tái)交互，降低各系統(tǒng)之間的耦合性，HIS性能提升；l 兩個(gè)院區(qū)通過(guò)院內(nèi)平臺(tái)公用一個(gè)RIS系統(tǒng)，檢查結(jié)果平臺(tái)分發(fā)到兩個(gè)HIS；l 兩個(gè)院區(qū)通過(guò)院內(nèi)平臺(tái)公用一個(gè)手麻系統(tǒng)，手術(shù)申請(qǐng)通過(guò)平臺(tái)匯總給手麻系統(tǒng)，手麻系統(tǒng)返回的收費(fèi)信息，領(lǐng)藥信息通過(guò)平臺(tái)分發(fā)到各個(gè)HIS系統(tǒng)中；l 基礎(chǔ)數(shù)據(jù)同步：統(tǒng)一維護(hù)，統(tǒng)一分發(fā)，保持系統(tǒng)的數(shù)據(jù)一致性；l 同一個(gè)患者在兩個(gè)院區(qū)的傳染病信息只需上報(bào)一次；l 兩個(gè)院區(qū)的患者統(tǒng)一管理；l 兩個(gè)院區(qū)的臨床信息實(shí)現(xiàn)以患者為中心共享，并且集成到醫(yī)生工作站供醫(yī)生快捷調(diào)閱；l 兩個(gè)院區(qū)的醫(yī)技報(bào)告實(shí)現(xiàn)共享；l 通過(guò)平臺(tái)，實(shí)現(xiàn)兩個(gè)院區(qū)的處方統(tǒng)一點(diǎn)評(píng)；l 實(shí)現(xiàn)兩個(gè)院區(qū)的科室、專家統(tǒng)一可以在手機(jī)上統(tǒng)一預(yù)約， 并將預(yù)約信息反饋給各自的HIS系統(tǒng)。當(dāng)LIS或者PACS系統(tǒng)將檢查報(bào)告或者影像圖片發(fā)還給HIS系統(tǒng)時(shí)，消息傳遞方式和上圖基本相同，不過(guò)路由上的邏輯將更為復(fù)雜。同時(shí)引擎將另一份相同的ADT消息副本通過(guò)LIS的TCP代理發(fā)送去LIS系統(tǒng)，如下圖所示當(dāng)LIS系統(tǒng)將回執(zhí)返回給引擎的LIS TCP代理通信點(diǎn)的時(shí)候，引擎又將這份回執(zhí)分流成兩份，一份是正常的ACK，直接發(fā)送給垃圾箱通信點(diǎn)丟棄，如下圖所示另一份為錯(cuò)誤回執(zhí)NACK（如果存在）的副本，將其使用JavaScript過(guò)濾器進(jìn)行簡(jiǎn)單處理以后，再通過(guò)Email客戶端通信點(diǎn)發(fā)送給相關(guān)人員，如下圖所示在很多情況下，一個(gè)高質(zhì)量的路由一般是要對(duì)傳遞過(guò)程中產(chǎn)生的錯(cuò)誤進(jìn)行處理，如下圖所示以上是對(duì)一個(gè)簡(jiǎn)單的HISLIS路由的分解，它展示了ADT消息在醫(yī)療機(jī)構(gòu)內(nèi)的傳遞方式。更糟糕的是，如果HIS系統(tǒng)需要將消息同時(shí)發(fā)送給多個(gè)其它系統(tǒng)，如同時(shí)發(fā)送給LIS、RIS和CIS，采用點(diǎn)對(duì)點(diǎn)的交互模式，等待時(shí)間會(huì)更長(zhǎng)，因?yàn)镠IS系統(tǒng)需要分別收到三個(gè)ACK回執(zhí)才能確認(rèn)消息完全發(fā)送成功。設(shè)計(jì)由Rhapsody引擎發(fā)送回執(zhí)的優(yōu)勢(shì)在于減少HIS系統(tǒng)確認(rèn)消息成功發(fā)送的等待時(shí)間。上圖是一個(gè)簡(jiǎn)單的將ADT（入院／掛號(hào)、出院和轉(zhuǎn)院）消息通過(guò)Rhapsody引擎從HIS系統(tǒng)發(fā)送至LIS系統(tǒng)的簡(jiǎn)單流程圖。它們是HIS伸向信息發(fā)源地的觸角、感受器。通常信息流是伴隨著各式各樣窗口業(yè)務(wù)處理過(guò)程發(fā)生的，醫(yī)療事務(wù)就是其中一個(gè)典型的例子。同時(shí)，所有的引擎連接都是通過(guò)一個(gè)虛擬IP完成，而這個(gè)IP永遠(yuǎn)指向正常工作的那臺(tái)引擎服務(wù)器。在使用此種架構(gòu)的時(shí)候，主被兩臺(tái)服務(wù)器上的引擎將共享引擎消息存儲(chǔ)庫(kù)（物理文件夾，通常放置于存儲(chǔ)區(qū)域網(wǎng)絡(luò)上［Storage Area Network，SAN］），如下圖所示：當(dāng)主服務(wù)器上的Rhapsody引擎發(fā)生異常時(shí)，備用服務(wù)器的引擎隨即啟動(dòng)接管主服務(wù)器引擎的工作。綜上所述，醫(yī)院信息平臺(tái)的總體架構(gòu)可參考下圖所示：5 硬件需求 醫(yī)院規(guī)模定義醫(yī)院規(guī)模床位消息接收/天消息處理/天小型醫(yī)院1199~30,000~300,000中型醫(yī)院200499~100,000~1,000,000大型（或集團(tuán)）醫(yī)院500 +~1,000,000 +~3,000,000 + 小型醫(yī)院預(yù)計(jì)醫(yī)院規(guī)模：l 醫(yī)院少于200張床位l 醫(yī)院業(yè)務(wù)系統(tǒng)大約接收30,000條消息l 高峰時(shí)期的數(shù)據(jù)負(fù)載量大約為平常時(shí)期的4倍l 每日引擎處理的消息量約
研究報(bào)告相關(guān)推薦
鄂ICP備17016276號(hào)-1