第二部分：通用資格服務實現(xiàn)

第四章： 通用資格服務介紹

成都創(chuàng)新互聯(lián)公司專注于貢井網站建設服務及定制，我們擁有豐富的企業(yè)做網站經驗。 熱誠為您提供貢井營銷型網站建設，貢井網站制作、貢井網頁設計、貢井網站官網定制、小程序設計服務，打造貢井網絡公司原創(chuàng)品牌,更為您提供貢井網站排名全網營銷落地服務。

第五章： 查詢發(fā)送者通道

第六章：  HL7v2 to HL7v2  轉換器通道

第七章：數據記錄器通道

第八章： HL7v3  校驗通道

第九章： 應答發(fā)送者通道

第十章： HL7v3 to HL7v2  轉換器通道

第四章：通用資格服務介紹

這部分完全是假想的資格服務實現(xiàn)。這么做的原因是替代了業(yè)務或臨床需求，比如病人管理 ADT ，醫(yī)囑信息 ORM （通用訂單信息），檢驗報告 ORU （主動觀察消息），上面這些你可能已經知道了，而他們全部集成在 Mirth Connect  功能上。

注意：我們開始前，我要強調在這里顯示的交互和消息并不代表真實的實現(xiàn)，不應該直接使用。

.  資格服務介紹

資格服務由醫(yī)療健康部門使用，查詢病人是否在有效期內有支付的資格。一個可以期待的答復是，根據病人是否有保險資格給出答案：是或否。這個答復也可能是個特定的代碼和提供澄清病人狀態(tài)的附加信息。

給你提供一個真實場景怎樣工作的范例，我會引用來自 HL7v3 Normative Edition 2014 的一個故事。你也能通過 HL7v3 Standard>Universal>Eligibility Topics>Storyboards 找到原著。

當一個病人造訪驗光師時，確定這個病人是否享受眼鏡片福利。驗光師會詢問病人是否有眼鏡使用的擴展福利計劃。病人往往確定不了，但是他們認為通過保險公司有某種擴展資格。病人查看錢包，事實上，就是一張擴展福利資格卡，卡上含有計劃 ID ，團體保險號，被保險人身份正號，姓名和捐助及到期日。

驗光師詢問病人是否愿意讓秘書確認是否享受保險公司提供購買眼鏡片的擴展福利資格。病人明確表示可以，因為他們想知道購買眼鏡片是否在這個計劃下，如果不在，那么，病人這次就不能購買眼鏡片。

秘書通過病人特定識別碼，姓名， DOB 查詢擴展福利計劃，即通過病人的福利資格卡查詢計劃細節(jié)，幫病人詢問眼鏡片是否在這個計劃下。答復指明，一個每 2 年最高限額 $300.00 的眼鏡片購買資格福利告訴了病人。病人立馬意識到可以買副眼鏡了。然而，保險公司的費用承諾并不是購買眼鏡支付費用的承諾（向保險公司提出申請購買眼鏡的費用，實際上是保險索賠）。這一點，像我國醫(yī)院的報銷制度，居民拿一部分，國家拿一部分，但你得有資格享受國家的這項政策，比如：你不繳納社保，估計是沒有退休金的。

.  場景概述

故事中秘書的行為就是使用發(fā)送者應用提交查詢到保險公司端的服務應用，并接收保險公司的信息答復。這個場景，更加切合的描述為交互模型，例如接下來的創(chuàng)建、提交、處理資格查詢的處理過程。

.  交互模型

下面，我們使用序列圖，描述兩個應用之間資格服務的交互模型：

為了增加交互模型的復雜度，臨時添加了把進來的 HL7v2 查詢消息轉換為 HL7v3 查詢消息步驟，以及相反的步驟。

.  應用角色

本章應用角色并不是 HL7 標準應用角色的定義。因此，需要一個這樣的應用，使用 HL7v3 請求消息校驗病人是否有保險資格或在 HL7v3 項目中有特定的名字 FICR_AR021001UV01 。然而，下面的應用角色會影響我們以后實現(xiàn)的通道名字。

* Sender:  創(chuàng)建 HL7v2 查詢消息發(fā)送者啟動的一個請求。消息被發(fā)送到 HL7 轉換器處理。發(fā)送者也接收和處理響應消息。

* HL7 Transformer:HL7 轉換器接收發(fā)送者的查詢，校驗查詢并把它轉化成 HL7v3 查詢消息格式。新的構造消息發(fā)送給服務。 HL7 轉換器也接收來自服務的響應。 HL7 轉換器也記錄 HL7v2 消息結構校驗失敗的信息。

* Service: 服務接收查詢消息，分析和處理消息，查詢數據庫，形成響應消息，發(fā)送給 HL7 轉換器。跟 HL7 轉換器一樣，服務也記錄 HL7v3 消息架構校驗失敗的信息。

盡可能的嘗試給定場景范圍內更多的功能，資格查詢交互模型的實際實現(xiàn)可能超出這三個應用角色（就是通道）。

.  消息和交互概述

HL7v2 標準把消息定義為兩個系統(tǒng)間數據交互模型的必要部分。每個消息由消息類型和觸發(fā)器事件 ( 就是特定識別消息的函數 ) 來確認。消息體是由預定義順序的一組片段組成。

類似的， HL7v3 標準把交互定義為：特定消息類型（信息傳遞）、啟動或觸發(fā)轉換的特定觸發(fā)器事件，與交互憑據關聯(lián)的接受者職責之間的一個特定關聯(lián)。簡單點兒，就是觸發(fā)器事件與接受者之間的關聯(lián)互動。

由于兩種標準的不同，所以 HL7v2 是通過消息類型和觸發(fā)事件來展現(xiàn)，而 HL7v3 通過交互名稱來展現(xiàn)。

場景實現(xiàn)使用的消息：

* QBP^E22 —— HL7v2 查詢授權請求狀態(tài)——提供者使用資格查詢請求消息查詢授權請求或在授權請求里特定產品 / 服務行項的支付者。

* RSP^E22 —— HL7v2 授權請求狀態(tài)查詢應答——支付者使用資格查詢應答消息把響應提交給提供者（就是提交 QBP^E22 消息的提供者）。

* QUCR_IN200101UV01  —— HL7v3 資格查詢請求通用——這個消息請求病人服務資格的狀態(tài)。

* QUCR_IN210101UV01  —— HL7v3 資格查詢應答通用——這個消息被當做一個提供關于病人資格服務的應答。

即使消息對的目的是相似的，也不意味著它們的內容有很好的相似度。有些字段在另一個消息對里沒有關聯(lián)，在消息對鍵傳遞信息也可能產生數據丟失。

.  這個查詢通道概述在 Mirth Connect 里有許多方法完成同樣的任務。下圖演示了本書這部分的游戲計劃（見圖 4-1 ）。主要的思想不是實現(xiàn)一個正確的服務，但是盡可能多的曝露 Mirth Connect  的選項。

模擬向服務發(fā)送資格查詢請求，并接收返回來的應答：

* Query Sender ——擔當處理和把原始的 QBP^E22 消息送入管道，該管道使用 MLLP( 類似于 Socket 協(xié)議層通訊 ) 消息傳輸協(xié)議。

* v2-v3 Transformer  該通道是轉換器的角色，接收 HL7v2 請求消息，校驗它，創(chuàng)建 HL7v3 消息，并把數據從 HL7v2 映射成 HL7v3 消息。如果接收到驗證失敗的消息，由數據記錄器執(zhí)行記錄此錯誤。

* v3  校驗——這個通道接收 HL7v3 請求消息，校驗它，分解它，并把數據存進數據庫。如果接收到校驗失敗的消息，由數據記錄器執(zhí)行記錄此錯誤。

* Response Sender ——扮演服務的角色。周期性的查詢數據庫，根據從數據庫拿到的數據，創(chuàng)建 HL7v3 響應消息，并通過 Web Service ，發(fā)送消息給查詢發(fā)送者。

* v3-v2 Transformer ——這個通道扮演轉換器的角色，處理 HL7v3 應答消息，創(chuàng)建 HL7v2 消息，把數據從 HL7v3 映射成 HL7v2 消息，并把 RSP^E22 消息結果存成文件。

* Data Logger ——接收產生校驗錯誤的消息，并錯誤細節(jié)存于日志文件里或數據庫里。

圖 4-1  資格查詢服務通道架構

整個實現(xiàn)過程里，我們會看到各種連接器： Channel Reader, TCP/IP Listener  和 Sender ,Database Writer, Reader, Web Service Listener  和  Sender, File Writer 。

我們會用到本書先前學到的所有技術，包括但不限于過濾器、轉換器、代碼模板、全局和通道腳本。

在這一點上，假設你已經非常熟悉 Mirth Connect Administrator 了。

.  推薦的工具和包

為使開發(fā)比較容易，不乏味，這里有工具和包的推薦列表。他們當中的一些，在先前特定通道實現(xiàn)上已經被安裝了，例如 PostgreSQL 。

§  HL7v2  視圖器，比如：由 Inner Harbour Software 出品的 HL7Spy

§  HL7v3  視圖器 比如：由 Altova GmbH  出品的 Altova XMLSpy

§  MS Access  和 MS Access ODBC  驅動器 或者類似的數據庫（包含驅動）

§  PostgreSQL  或 Mirth Connect  支持的數據庫

§  JDBC Level 4 driver for PostgreSQL  或已選數據庫驅動

§  由 Philip Helger  提供的  phLOC Schematron  java 庫。