orion醫(yī)院信息集成平臺解決方案v20docxdocx(已改無錯字)
2022-08-12 11:40:50 本頁面
【正文】 16GBo 36GB的硬盤空間用于安裝操作系統(tǒng)和引擎（RAID1）o 200GB用于Rhapsody的數(shù)據(jù)存儲（RAID10）o 200GB用于其它數(shù)據(jù)（RAID10）o 64位操作系統(tǒng)o UPS電源l HPUXo CPU：8核Intel Itaniumo 內(nèi)存：16GBo 36GB的硬盤空間用于安裝操作系統(tǒng)和引擎（RAID1）o 200GB用于Rhapsody的數(shù)據(jù)存儲（RAID10）o 200GB用于其它數(shù)據(jù)（RAID10）o 64位操作系統(tǒng)o UPS電源l AIXo CPU：8核Power Processoro 內(nèi)存：16GBo 36GB的硬盤空間用于安裝操作系統(tǒng)和引擎（RAID1）o 200GB用于Rhapsody的數(shù)據(jù)存儲（RAID10）o 200GB用于其它數(shù)據(jù)（RAID10）o 64位操作系統(tǒng)o UPS電源6 容災(zāi)方案根據(jù)醫(yī)院信息平臺的實際需求，一套良好的容災(zāi)方案可以更好的保證院內(nèi)系統(tǒng)的平穩(wěn)運行。Orion Health的Rhapsody集成引擎支持主備模式的架構(gòu)部署（activepassive）。在使用此種架構(gòu)的時候，主被兩臺服務(wù)器上的引擎將共享引擎消息存儲庫（物理文件夾，通常放置于存儲區(qū)域網(wǎng)絡(luò)上［Storage Area Network，SAN］），如下圖所示：當主服務(wù)器上的Rhapsody引擎發(fā)生異常時，備用服務(wù)器的引擎隨即啟動接管主服務(wù)器引擎的工作。由于兩臺服務(wù)器使用的是相同的消息存儲庫，因此正在處理過程中的消息將會被繼續(xù)處理而不會造成丟失或者需要原業(yè)務(wù)系統(tǒng)重新發(fā)送。同時，所有的引擎連接都是通過一個虛擬IP完成，而這個IP永遠指向正常工作的那臺引擎服務(wù)器。7 實例解析任何級別的區(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的TCP Server通信點：引擎通過此通信點監(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或者NACKEmail客戶端通信點：引擎通過此通信點向系統(tǒng)監(jiān)控人員或者相關(guān)管理人員發(fā)送消息交互的狀態(tài)信息，特別是在發(fā)生錯誤的時候，及時通知相關(guān)人員垃圾箱通信點：引擎通過此通信點回收不需要保存的LIS系統(tǒng)回執(zhí)HL7回執(zhí)生成器：引擎通過此控件在成功接收消息以后生成HL7標準回執(zhí)消息，并傳遞給HIS的TCP Server通信點JavaScript過濾器Handle NACK：引擎通過此控件處理從LIS系統(tǒng)發(fā)回的NACK回執(zhí)Nooperation過濾器：引擎通過此控件將消息進行分流，在分流路徑上的消息為原消息的一個副本依上圖所示，引擎將從HIS接收收到的ADT消息分流成兩份，一份發(fā)給HL7回執(zhí)生成器，然后將生成的回執(zhí)發(fā)還給HIS系統(tǒ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)，如下圖所示當LIS系統(tǒng)將回執(zhí)返回給引擎的LIS TCP代理通信點的時候，引擎又將這份回執(zhí)分流成兩份，一份是正常的ACK，直接發(fā)送給垃圾箱通信點丟棄，如下圖所示另一份為錯誤回執(zhí)NACK（如果存在）的副本，將其使用JavaScript過濾
研究報告相關(guān)推薦
鄂ICP備17016276號-1