伴隨著醫療信息化的深入,醫療儀器的信息集成已經成為醫療信息化的一個非常重要的組成部分。為了使沒有統一標準信息接口的醫療儀器具備與信息系統互聯互通、信息共享的能力,本研究設計并實現了基于醫療健康信息集成規范-患者護理設備(IHE PCD)技術框架的醫療儀器信息集成網關,該集成網關按照IHE PCD定義的通信框架和健康信息交換第七層協議(HL7)消息格式,通過協議轉換引擎和設備驅動Javascript腳本語言,將各種格式的醫療儀器通信協議轉換為符合HL7標準的消息。本研究為醫療儀器提供了統一的HL7標準接口,使其能夠與信息系統進行無縫連接以及無障礙數據交換,降低了醫療儀器信息集成的門檻,具有良好的應用價值,對在用醫療儀器設備的信息集成尤具價值。
引用本文： 鄭建立, 廖蕓, 楊勇勇. 基于醫療健康信息集成規范的醫療儀器信息集成技術的研究. 生物醫學工程學雜志, 2014, 31(3): 671-677. doi: 10.7507/1001-5515.20140125 復制
引言
伴隨著醫療信息化的深入，信息共享需求的增大，醫療儀器的信息集成已經成為醫療信息化的一個非常重要的組成部分，為廣大醫院以及醫療器械廠商所關注。醫療儀器的研發除了關注創新或完善儀器本身的診斷或治療功能之外，如何與醫療信息系統互聯互通也成為一個共性問題。
醫學影像類的醫療儀器設備如CT、MR、US等的數據接口已經廣泛采用了醫學數字影像傳輸標準(digital imaging and communications in medicine，DICOM)，所以這類醫療儀器的集成技術相對較為成熟。而其他非影像類醫療儀器設備如監護儀、麻醉機、呼吸機等產品卻沒有采用統一的標準接口，這類醫療儀器的信息集成存在接口復雜、可擴展性差等問題。目前的狀況是廠商自行定義通信接口，不同廠商之間的設備或信息系統間沒有通用的互聯方案，只能采取Case-by-Case的辦法解決。
醫療健康信息集成協會(Integrating the Healthcare Enterprise，IHE)是醫療信息技術領域的重要國際組織。為解決醫療設備的信息集成問題，于2005年開始發布基于健康信息交換第七層協議(Health Level Seven,HL7)和ISO/IEEE 11 073的患者護理設備(Patient Care Device，PCD)技術框架。PCD技術框架規范了通信場景以及醫療設備與醫療設備數據接收單元之間的流程,從而促進醫療環境中設備數據的交換效率，加強患者信息安全，提高醫療保健質量[1-2]。該技術框架得到越來越多廠商的關注，開始在產品設計中應用IHE PCD的集成框架解決醫療儀器的信息集成問題[3]。參與美國醫療健康信息與管理系統協會(Healthcare Information and Management Systems Society，HIMSS)舉辦的IHE PCD展示的企業從2007年的6家發展到23家，包括GE、德爾格、飛利浦等。 Capsule公司研發的一套符合PCD技術框架的醫療設備信息集成解決方案，可以支持超過600種不同醫療設備的集成，并于2012年IHE 測試會上成功地進行了測試。由Intel發起的240多個業界廠商參與的Continua健康聯盟在個人遠程健康系統的研究中，將IHE PCD作為個人健康設備通信的解決方案，利用設備數據通信(Device Enterprise Communication，DEC)集成模式實現廣域網絡接口的患者數據的傳送[4]。國內在醫療儀器集成技術方面的研究相對滯后，多為單一設備的HL7接口實現方案[5-7]，對PCD的研究和應用甚少。
1 醫療儀器信息接口分析與集成框架
醫療儀器設備的信息集成存在困難的原因是其信息接口存在較大的差異，主要表現在硬件接口(串口、以太網口、CAN、WLAN、藍牙、WAN等)、幀格式(波特率、起始符、幀長度、終止符等)、校驗方式(奇偶、checksum、CRC等)、域定界方式(定長、分界符等)、編碼方式(文本、二進制、BCD等)、信息輸出方式(主動式、被動式)和指令集等的不同，如Drager的Fabius GS呼吸機，硬件接口為串口COM，采用的是其medibus通信協議，信息輸出方式為被動方式，即請求/響應模式，設備收到系統的請求命令后才會輸出信息。而另一些醫療設備的信息輸出為主動方式，如NCC X5插件式多參數監護儀采用網口輸出，通信協議為自定義等。
本研究提出一種通用醫療儀器集成網關軟硬件平臺，如圖 1所示。該平臺兼容多種廠商的設備接口和通信協議，按照IHE PCD定義的通信框架和HL7消息格式，將醫療儀器通信協議轉換為統一的IHE PCD事務協議，使得醫療設備能與信息系統進行無縫連接以及無障礙數據交換。該平臺包括可配置多接口硬件平臺(滿足不同硬件接口)、協議轉換引擎(實現醫療儀器通信協議轉換)、設備驅動(滿足不同設備工作模式)以及HL7接口通信模塊(實現與信息系統之間的HL7通信)。
圖1
醫療儀器集成網關軟硬件平臺框架
Figure1.
Framework of medical instrument integrating gateway
2 IHE PCD技術框架
IHE PCD技術框架對不同的集成需求定義了多個集成模式。其中DEC 集成模式用于規范醫療儀器設備與信息系統間的設備數據的傳輸，如血壓數據、心率數據等；波形內容模塊(waveform content module，WCM)集成模式規范了波形數據的傳輸，如心電波形數據、SPO2波形數據等；術語映射(rosetta terminology mapping，RTM)集成模式則是對DEC、WCM等集成模式中所涉及的術語進行了規定，以避免二義性。醫療儀器可按照各自的功能要求，選擇實現若干集成模式中定義的角色，即可滿足集成要求。
2.1 設備數據通信(DEC)集成模式
DEC集成模式基于ISO/IEEE 11073和HL7標準，采用一致的消息格式和設備語義內容將醫療儀器設備信息傳輸到臨床信息系統，現在涉及的儀器設備主要有輸液泵、監護儀、呼吸機和麻醉機等。DEC將信息系統與醫療儀器設備分別抽象成設備數據使用者(device observation consumer，DOC)和設備數據報告者(device observation reporter，DOR)兩個角色，圖 2為DEC的角色事務圖[8]。
圖2
DEC角色事務圖
Figure2.
Actors and transcation of DEC
DOR與DOC之間通過PCD-01事務進行交互，具體是DOR通過HL7 ORU_R01消息將采集的設備數據傳送給DOC，DOC正確接收后返回一個HL7 ACK消息給DOR。 ORU_R01消息中包含消息頭(message header，MSH)、患者標識(patient identification，PID)、觀察請求(observation request，OBR)、觀察/結果(observation/result，OBX)四個必要的段，MSH段定義了消息的意圖、來源、目的地以及一些語法定義；PID段記錄了患者的基本信息包括患者唯一識別信息如患者ID，以及人口統計學信息，如患者姓名；OBR段為觀察報告頭，記錄了相關醫囑信息以及所有觀察指標的共同屬性；OBX段記錄了一個觀察指標或一個觀察指標片斷的結果[9]。
OBX段是可重復的，一條消息可以包含多個觀察指標結果，每個觀察指標結果用一個OBX段記錄，以下是一條記錄心率和血氧值的HL7消息：
MSH|∧~\&|Monitor∧A001002003004005∧EUI-64||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID123345|P|2.5|||NE|AL|||||IHE PCD ORU-R01 210∧HL7∧2.16.840 .1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|||monitoring∧A000100020003004||||20100930095729.100+0800
OBX|1|NM|147842∧MDC_ECG_HEART_RATE∧MDC||60|264864∧MDC_DIM_BEAT_PER_MIN∧MDC|||||R||心率OBX段
OBX|2|NM|150456∧MDC_PULS_OXIM_SAT_O2∧MDC||95|262688∧MDC_DIM_PERCENT∧MDC|||||R||血氧OBX段
2.2 波形內容模塊(WCM)集成模式
WCM在一定程度上對DEC集成模式進行了擴展，它定義了波形傳輸的數據結構和語義，提供DOR向DOC傳遞實時波形數據的方法[10]。波形消息同樣采用HL7 ORU∧R01∧ORU_R01消息類型，消息中的每個波形部分采用一個OBR段標識，多個OBX段記錄波形數據和參數，其中包含兩個必要OBX段，分別是采樣率段和波形觀察結果段。以下是一個具有兩導聯心電波形的消息。
MSH|∧~\&|Monitor||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID1233456789|P|2.5|||NE|AL|||||
IHE PCD ORU-R01 210∧HL7∧2.16.840.1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|1||09780979a9879∧ACME HEALTH∧ABCD002343785379∧EUI-64|WAVEFORM|||20080515121000.100 -400|20080515121001.100-400心電波形OBR段
OBX|1|NM|0∧MDC_ATTR_SAMP_RATE∧MDC|1.1.1.1.1|256|264608∧MDC_DIM_PER_SEC心電采樣率OBX
OBX|2|NA|131329∧ MDC_ECG_LEAD_I∧MDC|1.1.1.1|24∧72∧12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)|||||||||2008051512 1000.100Ⅰ導聯波形觀察結果OBX段
OBX|3|NA|131330∧ MDC_ECG_LEAD_II∧MDC |1.1.1.2|24∧72∧ 12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)||||||||| 2008051512 1000.100Ⅱ導聯波形觀察結果OBX段
2.3 術語映射(RTM)集成模式
RTM集成模式通過“Rosetta表”提供設備數據內容到標準術語ISO/IEEE 11073-10101 MDC(medical device communication)和UCUM(Unified Code for Units of Measure)的映射，MDC規定了醫療設備通信中的標準術語，UCUM是測量值單位規范碼[11]。
Rosetta表主要用于規定HL7消息中OBX-3(觀察標識)和OBX-6(單位)字段的數據格式，OBX-3格式為CF_CODE10∧REFID∧MDC，OBX-6格式為CF_UCODE10∧ UOM_MDC∧MDC。常用的CF_CODE10和REFID如表 1所示，CF_UCODE10和UOM_MDC如表 2所示。
表1
常見設備觀察指標術語表
Table1.
Common observation codes
表2
常見設備單位術語表
Table2.
Common unit terminological codes
3 集成引擎的設計與實現
由于醫療儀器設備的輸出信息不同、格式多種多樣，難以通過一套固定的程序代碼來實現全兼容，因此本研究采用協議轉換引擎外掛設備驅動模塊來加以解決。協議轉換引擎是固定不變的，而設備驅動模塊則可以根據不同儀器設備的信息通信協議進行定制，提高其靈活性。為降低編程的難度，使得用戶也有可能自行擴充，我們選擇Javascript腳本語言作為設備驅動模塊的編程語言。
3.1 協議轉換引擎的實現
協議轉換引擎是實現醫療儀器通信協議與HL7標準之間轉換的關鍵組件。該組件通過調用設備驅動模塊的Javascript腳本，實現與醫療儀器的信息交換；同時實現DEC、WCM集成模式的DOR角色功能，通過HL7通信組件實現與醫療信息系統的PCD-01事務通信。
協議轉換引擎需要實現以下功能：① 初始化設備驅動模塊：加載編譯協議轉換腳本，獲取設備接口信息，啟動設備通信接口，等待接收設備數據；② 初始化HL7通信模塊：獲取DOC的配置信息，與信息系統建立通信連接；③ 實現DOR角色功能：將設備數據轉換為HL7 ORU-R01消息并發送，同時接收DOC的ACK消息。
協議轉換引擎采用C++語言編寫，在其中內嵌一個V8 Javscript 引擎以連接設備驅動模塊。V8 Javascript 引擎是由Google公司開發的一個開源的Javascript引擎，應用在 Google的開源瀏覽器Chrome中[12]，用C++編寫而成，加載腳本后先對腳本進行編譯，生成機器語言，因此執行效率高。
協議轉換引擎工作流程如圖 3所示，具體實現步驟如下：
(1)創建一個V8 Javascript 引擎實例，主要是創建HandleScope對象和Context對象；
(2)加載設備驅動模塊腳本文件，通過Script::Compile()編譯加載后的腳本，得到Handle＜Script＞實例script；
(3)獲取腳本中GetCommConfig、GetDOCConfig、GetDeviceId、Parse等函數的調用入口：通過當前腳本執行環境Context實例的Global()函數獲取全局對象globalObj，再將函數名作為參數分別調用globalObj-＞Get(),得到Handle＜Function＞類型的函數指針getcommconfig、getdocconfig、getdeviceid、parse等；
(4)調用getdocconfig-＞Call()，獲取信息系統所在服務器的IP地址和端口號，作為參數實例化HL7通信類hl7comm；
(5)調用getcommconfig-＞Call()，得到設備通信接口配置信息，初始化相應通信接口，接收設備數據幀，暫存入數據緩沖區中；調用getdeviceid-＞Call()，得到設備標識；
(6)從數據緩沖區中讀取一個設備數據幀；
(7)調用腳本中的全局函數parse-＞Call()，函數參數為設備數據幀字符數組，返回的字符串值即為解析結果(格式為“觀察指標1=值1，觀察指標2=值2，……”)；
(8)用步驟7得到的解析結果作為參數，依次調用hl7comm的MakeMSHSeg、MakePIDSeg、MakeOBRSeg以及MakeOBXSeg函數，將得到的段組合成HL7 ORU_R01消息；
(9)調用hl7comm.Send()函數，參數為上一步驟得到的ORU_R01消息，由HL7通信模塊完成消息發送和確認消息的接收；
(10)若繼續轉換轉步驟6，否則結束。
圖3
協議轉換引擎流程圖
Figure3.
Flow chart of protocol conversion engine
3.2 HL7通信模塊的實現
HL7通信模塊實現了HL7Comm類，封裝了HL7消息構造、HL7消息解析、MLLP通信等功能。
3.2.1 HL7消息構造
HL7 ORU_R01消息包含MSH、PID、OBR及OBX四種消息段。其中OBX段的數目可變，為靈活構造消息，HL7通信模塊中僅提供段構造函數，由調用者按需組合出HL7消息。
//MSH段構造函數
//輸入：sendingApp 發送方標識
//輸出：MSH段
string MakeMSHSeg(string sendingApp);
//PID段構造函數
//輸入：patientId 患者標識號
//?patientName 患者姓名
//輸出：PID段
string MakePIDSeg(string patientId,string patientName);
//OBR段構造函數
//輸入：orderNo 醫囑號
//?serviced 服務標識號
///?startTime波形采樣開始時間，構造DEC消息時為空串
//輸出：OBR段
string MakeOBRSeg(string orderNo,string serviceId,string startTime);
//OBX段構造函數
//輸入：index 消息段號
///?rosMDC 觀察標識
///?level 觀察層次
///?obsValue 觀察值
///? rosUCUM 單位，構造WCM消息時為空串
//輸出：OBX段
string MakeOBXSeg(string index,string rosMDC,string level,string obsValue,string rosUCUM);
3.2.2 HL7消息解析
HL7消息解析采用了正則表達式。正則表達式是對字符串操作的一種邏輯公式，通過描述字符串規則從而對字符串進行檢索、替換、匹配等操作。本研究通過調用Boost庫實現正則表達式的處理。
HL7消息分為消息段、字段、組件、子組件，分隔符分別為回車符、“|”、“∧”、“&”，據此編寫出相應的正則表達式對HL7消息進行全解析或按需解析[13]。本研究中只需要對HL7消息進行按需解析，即根據指定的字段號或組件號獲取相應的數據。
① 按需解析消息字段
一個字段可以表示為以“|”開頭(正則表達式為\|)，后面有非“|”字符(正則表達式為[∧\|])0至多個(正則表達式為*)，即\|[∧\|]*。按需解析指定“消息段名-字段號”消息字段值的正則表達式為：
消息段名(\|[∧\|]*){字段號-1}\|([∧\|]*)
以獲取PID-5(患者姓名字段)為例，主要解析過程如下:
//定義正則表達式，其中\|[∧\|]*重復4次
regex rgx(“PID(\\|[∧\\|]*){4}\\|([∧\\|]*)”);
//message：被解析消息 match：匹配結果
string PID_5 = “”;
if(regex_search(message,match,rgx))
PID_5=match[2];
② 按需解析消息組件
組件是以“∧”為分隔符的子字符串，在上述解析得到字段值的基礎上，用以下正則表達式得到指定組件號的值：
(\∧[∧\∧]*){組件號-1}\∧([∧\∧]*)
3.2.3 MLLP(Minimal Lower Layer Protocol)通信
因為在TCP/IP 上傳遞的數據是一串連續的比特流，而HL7的封裝協議要求通信代碼能夠識別每條消息的開始和結束。MLLP 是標準中規定的通過 TCP/IP網絡傳送 HL7 消息的機制，每個 HL7 消息用一個消息頭(0x0B)和一個消息尾(0x1C和0x0D)封裝，以標示消息的開始和結束。
HL7Comm構造函數傳入DOC的IP地址和端口號，創建Socket實現TCP/IP網絡通信，在此基礎上實現HL7的MLLP協議。發送時按MLLP協議對消息進行頭尾封裝，接收時按MLLP協議根據頭尾標記獲取消息。
3.3 設備驅動模塊的實現
設備驅動模塊負責集成引擎與設備端的通信連接以及設備數據的解析處理等功能。不同的醫療設備有著不同的通信接口和數據格式，因此這部分代碼的變動較大。為通用性和靈活性，在本研究中用Javascript腳本語言編寫。在集成引擎中針對COM、CAN、TCP Server、TCP Client等接口類型，實現了通用的底層通信功能，只需要從設備驅動模塊中得到設備接口的配置信息。設備驅動模塊的另一個任務是對收到的數據進行分幀、校驗、解析等處理。主要接口如下：
//獲取設備通信配置信息
//輸入：無
//輸出：設備通信配置信息，格式為“接口類型，參數1，參數2，…”。
//?如“COM,1,9600,8,n,1”表示串口1，波特率9600，8位數據位，無奇偶校驗，1位停止位；
//?“TCP Server,510”表示為TCP服務器方式，端口號為510。
function GetCommConfig ();
//獲取服務器通信配置信息
//輸入：無
//輸出：服務器通信配置信息，格式為“IP地址: 端口號”。
function GetDOCConfig ();
//獲取設備標識
//輸入：無
//輸出：設備標識，用于構成服務標識號、醫囑號、發送方標識等
function GetDeviceId();
//獲取設備數據查詢命令
//輸入：數據的MDC編碼。為空則查詢所有數據
//輸出：被動方式設備數據查詢命令幀,主動方式設備則返回空
function GetPollCmd(mdccode);
……
//解析數據
//輸入：設備數據幀字符數組
//輸出：解析結果，格式為“觀察指標1=值1，觀察指標2=值2，……”
function Parse(msg);
4 結果與討論
IHE-PCD Pre-Connetathon Test Tool為IHE官方提供的PCD測試工具[14] ，打開測試工具所在網頁，按要求配置相關參數。以NCC X5監護儀為被測設備，輸出數據經過本研究的集成網關轉換后發送給測試工具指定的服務器(IP地址129.6.24 .143 ，端口號13080)。該監護儀通過網口連接向TCP端口(如511)主動輸出信息，因此將設備驅動模塊的設備通信配置信息設置為“TCP Server，511”，服務器通信配置信息為“129.6.24.143:13080”。
圖 4為接收到的一條血壓原始數據，字節順序為低字節在前，其中第10~11字節為收縮壓，12~13字節為舒張壓，14~15字節為平均壓。
圖4
血壓原始數據
Figure4.
Raw data of blood pressure
協議轉換后的HL7 ORU_R01消息如圖 5所示。三個OBX段分別記錄了收縮壓(150 mm Hg)、舒張壓(80mm Hg)和平均壓(103 mm Hg)的測量值。在IHE-PCD Test Tool測試結果中可見正確接收到了該HL7 ORU_RO1消息并驗證成功，如圖 6所示。
圖5
協議轉換結果
Figure5.
Protocol conversion result
圖6
測試結果
Figure6.
Test result
本研究可應用于通用型中央監護系統、手術麻醉系統以及數字化手術室集中控制系統等應用系統。這些應用系統只要實現DEC和WCM集成模式的DOC角色，通過局域網連接到本研究實現的集成網關，即可接收呼吸機、麻醉機、監護儀、輸液泵等設備的數據，無需為每個設備編寫特定的通信接口，提高其通用性與可擴展性。
醫療儀器設備的信息集成是醫療信息建設的難點之一，目前國內對于這類醫療儀器與信息系統集成的研究還在發展階段。本研究提出的基于IHE PCD的醫療儀器信息集成技術，可將醫療儀器的通信協議轉換成符合HL7標準的消息格式，且不僅支持單一設備通信協議的轉換，具有一定的通用性，對醫療儀器設備的信息集成和共享具有良好的應用價值，對在用醫療儀器設備的信息集成尤具價值。
引言
伴隨著醫療信息化的深入，信息共享需求的增大，醫療儀器的信息集成已經成為醫療信息化的一個非常重要的組成部分，為廣大醫院以及醫療器械廠商所關注。醫療儀器的研發除了關注創新或完善儀器本身的診斷或治療功能之外，如何與醫療信息系統互聯互通也成為一個共性問題。
醫學影像類的醫療儀器設備如CT、MR、US等的數據接口已經廣泛采用了醫學數字影像傳輸標準(digital imaging and communications in medicine，DICOM)，所以這類醫療儀器的集成技術相對較為成熟。而其他非影像類醫療儀器設備如監護儀、麻醉機、呼吸機等產品卻沒有采用統一的標準接口，這類醫療儀器的信息集成存在接口復雜、可擴展性差等問題。目前的狀況是廠商自行定義通信接口，不同廠商之間的設備或信息系統間沒有通用的互聯方案，只能采取Case-by-Case的辦法解決。
醫療健康信息集成協會(Integrating the Healthcare Enterprise，IHE)是醫療信息技術領域的重要國際組織。為解決醫療設備的信息集成問題，于2005年開始發布基于健康信息交換第七層協議(Health Level Seven,HL7)和ISO/IEEE 11 073的患者護理設備(Patient Care Device，PCD)技術框架。PCD技術框架規范了通信場景以及醫療設備與醫療設備數據接收單元之間的流程,從而促進醫療環境中設備數據的交換效率，加強患者信息安全，提高醫療保健質量[1-2]。該技術框架得到越來越多廠商的關注，開始在產品設計中應用IHE PCD的集成框架解決醫療儀器的信息集成問題[3]。參與美國醫療健康信息與管理系統協會(Healthcare Information and Management Systems Society，HIMSS)舉辦的IHE PCD展示的企業從2007年的6家發展到23家，包括GE、德爾格、飛利浦等。 Capsule公司研發的一套符合PCD技術框架的醫療設備信息集成解決方案，可以支持超過600種不同醫療設備的集成，并于2012年IHE 測試會上成功地進行了測試。由Intel發起的240多個業界廠商參與的Continua健康聯盟在個人遠程健康系統的研究中，將IHE PCD作為個人健康設備通信的解決方案，利用設備數據通信(Device Enterprise Communication，DEC)集成模式實現廣域網絡接口的患者數據的傳送[4]。國內在醫療儀器集成技術方面的研究相對滯后，多為單一設備的HL7接口實現方案[5-7]，對PCD的研究和應用甚少。
1 醫療儀器信息接口分析與集成框架
醫療儀器設備的信息集成存在困難的原因是其信息接口存在較大的差異，主要表現在硬件接口(串口、以太網口、CAN、WLAN、藍牙、WAN等)、幀格式(波特率、起始符、幀長度、終止符等)、校驗方式(奇偶、checksum、CRC等)、域定界方式(定長、分界符等)、編碼方式(文本、二進制、BCD等)、信息輸出方式(主動式、被動式)和指令集等的不同，如Drager的Fabius GS呼吸機，硬件接口為串口COM，采用的是其medibus通信協議，信息輸出方式為被動方式，即請求/響應模式，設備收到系統的請求命令后才會輸出信息。而另一些醫療設備的信息輸出為主動方式，如NCC X5插件式多參數監護儀采用網口輸出，通信協議為自定義等。
本研究提出一種通用醫療儀器集成網關軟硬件平臺，如圖 1所示。該平臺兼容多種廠商的設備接口和通信協議，按照IHE PCD定義的通信框架和HL7消息格式，將醫療儀器通信協議轉換為統一的IHE PCD事務協議，使得醫療設備能與信息系統進行無縫連接以及無障礙數據交換。該平臺包括可配置多接口硬件平臺(滿足不同硬件接口)、協議轉換引擎(實現醫療儀器通信協議轉換)、設備驅動(滿足不同設備工作模式)以及HL7接口通信模塊(實現與信息系統之間的HL7通信)。
圖1
醫療儀器集成網關軟硬件平臺框架
Figure1.
Framework of medical instrument integrating gateway
2 IHE PCD技術框架
IHE PCD技術框架對不同的集成需求定義了多個集成模式。其中DEC 集成模式用于規范醫療儀器設備與信息系統間的設備數據的傳輸，如血壓數據、心率數據等；波形內容模塊(waveform content module，WCM)集成模式規范了波形數據的傳輸，如心電波形數據、SPO2波形數據等；術語映射(rosetta terminology mapping，RTM)集成模式則是對DEC、WCM等集成模式中所涉及的術語進行了規定，以避免二義性。醫療儀器可按照各自的功能要求，選擇實現若干集成模式中定義的角色，即可滿足集成要求。
2.1 設備數據通信(DEC)集成模式
DEC集成模式基于ISO/IEEE 11073和HL7標準，采用一致的消息格式和設備語義內容將醫療儀器設備信息傳輸到臨床信息系統，現在涉及的儀器設備主要有輸液泵、監護儀、呼吸機和麻醉機等。DEC將信息系統與醫療儀器設備分別抽象成設備數據使用者(device observation consumer，DOC)和設備數據報告者(device observation reporter，DOR)兩個角色，圖 2為DEC的角色事務圖[8]。
圖2
DEC角色事務圖
Figure2.
Actors and transcation of DEC
DOR與DOC之間通過PCD-01事務進行交互，具體是DOR通過HL7 ORU_R01消息將采集的設備數據傳送給DOC，DOC正確接收后返回一個HL7 ACK消息給DOR。 ORU_R01消息中包含消息頭(message header，MSH)、患者標識(patient identification，PID)、觀察請求(observation request，OBR)、觀察/結果(observation/result，OBX)四個必要的段，MSH段定義了消息的意圖、來源、目的地以及一些語法定義；PID段記錄了患者的基本信息包括患者唯一識別信息如患者ID，以及人口統計學信息，如患者姓名；OBR段為觀察報告頭，記錄了相關醫囑信息以及所有觀察指標的共同屬性；OBX段記錄了一個觀察指標或一個觀察指標片斷的結果[9]。
OBX段是可重復的，一條消息可以包含多個觀察指標結果，每個觀察指標結果用一個OBX段記錄，以下是一條記錄心率和血氧值的HL7消息：
MSH|∧~\&|Monitor∧A001002003004005∧EUI-64||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID123345|P|2.5|||NE|AL|||||IHE PCD ORU-R01 210∧HL7∧2.16.840 .1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|||monitoring∧A000100020003004||||20100930095729.100+0800
OBX|1|NM|147842∧MDC_ECG_HEART_RATE∧MDC||60|264864∧MDC_DIM_BEAT_PER_MIN∧MDC|||||R||心率OBX段
OBX|2|NM|150456∧MDC_PULS_OXIM_SAT_O2∧MDC||95|262688∧MDC_DIM_PERCENT∧MDC|||||R||血氧OBX段
2.2 波形內容模塊(WCM)集成模式
WCM在一定程度上對DEC集成模式進行了擴展，它定義了波形傳輸的數據結構和語義，提供DOR向DOC傳遞實時波形數據的方法[10]。波形消息同樣采用HL7 ORU∧R01∧ORU_R01消息類型，消息中的每個波形部分采用一個OBR段標識，多個OBX段記錄波形數據和參數，其中包含兩個必要OBX段，分別是采樣率段和波形觀察結果段。以下是一個具有兩導聯心電波形的消息。
MSH|∧~\&|Monitor||||20100930095730+0800||ORU∧R01∧ORU_R01|MSGID1233456789|P|2.5|||NE|AL|||||
IHE PCD ORU-R01 210∧HL7∧2.16.840.1 .113883.9.n.m∧HL7
PID|||583030||BROWN∧JAMES∧∧∧∧∧L||19501216|M|||
OBR|1||09780979a9879∧ACME HEALTH∧ABCD002343785379∧EUI-64|WAVEFORM|||20080515121000.100 -400|20080515121001.100-400心電波形OBR段
OBX|1|NM|0∧MDC_ATTR_SAMP_RATE∧MDC|1.1.1.1.1|256|264608∧MDC_DIM_PER_SEC心電采樣率OBX
OBX|2|NA|131329∧ MDC_ECG_LEAD_I∧MDC|1.1.1.1|24∧72∧12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)|||||||||2008051512 1000.100Ⅰ導聯波形觀察結果OBX段
OBX|3|NA|131330∧ MDC_ECG_LEAD_II∧MDC |1.1.1.2|24∧72∧ 12∧-24∧-56∧200∧1250∧1900∧2056∧1432…(etc.)||||||||| 2008051512 1000.100Ⅱ導聯波形觀察結果OBX段
2.3 術語映射(RTM)集成模式
RTM集成模式通過“Rosetta表”提供設備數據內容到標準術語ISO/IEEE 11073-10101 MDC(medical device communication)和UCUM(Unified Code for Units of Measure)的映射，MDC規定了醫療設備通信中的標準術語，UCUM是測量值單位規范碼[11]。
Rosetta表主要用于規定HL7消息中OBX-3(觀察標識)和OBX-6(單位)字段的數據格式，OBX-3格式為CF_CODE10∧REFID∧MDC，OBX-6格式為CF_UCODE10∧ UOM_MDC∧MDC。常用的CF_CODE10和REFID如表 1所示，CF_UCODE10和UOM_MDC如表 2所示。
表1
常見設備觀察指標術語表
Table1.
Common observation codes
表2
常見設備單位術語表
Table2.
Common unit terminological codes
3 集成引擎的設計與實現
由于醫療儀器設備的輸出信息不同、格式多種多樣，難以通過一套固定的程序代碼來實現全兼容，因此本研究采用協議轉換引擎外掛設備驅動模塊來加以解決。協議轉換引擎是固定不變的，而設備驅動模塊則可以根據不同儀器設備的信息通信協議進行定制，提高其靈活性。為降低編程的難度，使得用戶也有可能自行擴充，我們選擇Javascript腳本語言作為設備驅動模塊的編程語言。
3.1 協議轉換引擎的實現
協議轉換引擎是實現醫療儀器通信協議與HL7標準之間轉換的關鍵組件。該組件通過調用設備驅動模塊的Javascript腳本，實現與醫療儀器的信息交換；同時實現DEC、WCM集成模式的DOR角色功能，通過HL7通信組件實現與醫療信息系統的PCD-01事務通信。
協議轉換引擎需要實現以下功能：① 初始化設備驅動模塊：加載編譯協議轉換腳本，獲取設備接口信息，啟動設備通信接口，等待接收設備數據；② 初始化HL7通信模塊：獲取DOC的配置信息，與信息系統建立通信連接；③ 實現DOR角色功能：將設備數據轉換為HL7 ORU-R01消息并發送，同時接收DOC的ACK消息。
協議轉換引擎采用C++語言編寫，在其中內嵌一個V8 Javscript 引擎以連接設備驅動模塊。V8 Javascript 引擎是由Google公司開發的一個開源的Javascript引擎，應用在 Google的開源瀏覽器Chrome中[12]，用C++編寫而成，加載腳本后先對腳本進行編譯，生成機器語言，因此執行效率高。
協議轉換引擎工作流程如圖 3所示，具體實現步驟如下：
(1)創建一個V8 Javascript 引擎實例，主要是創建HandleScope對象和Context對象；
(2)加載設備驅動模塊腳本文件，通過Script::Compile()編譯加載后的腳本，得到Handle＜Script＞實例script；
(3)獲取腳本中GetCommConfig、GetDOCConfig、GetDeviceId、Parse等函數的調用入口：通過當前腳本執行環境Context實例的Global()函數獲取全局對象globalObj，再將函數名作為參數分別調用globalObj-＞Get(),得到Handle＜Function＞類型的函數指針getcommconfig、getdocconfig、getdeviceid、parse等；
(4)調用getdocconfig-＞Call()，獲取信息系統所在服務器的IP地址和端口號，作為參數實例化HL7通信類hl7comm；
(5)調用getcommconfig-＞Call()，得到設備通信接口配置信息，初始化相應通信接口，接收設備數據幀，暫存入數據緩沖區中；調用getdeviceid-＞Call()，得到設備標識；
(6)從數據緩沖區中讀取一個設備數據幀；
(7)調用腳本中的全局函數parse-＞Call()，函數參數為設備數據幀字符數組，返回的字符串值即為解析結果(格式為“觀察指標1=值1，觀察指標2=值2，……”)；
(8)用步驟7得到的解析結果作為參數，依次調用hl7comm的MakeMSHSeg、MakePIDSeg、MakeOBRSeg以及MakeOBXSeg函數，將得到的段組合成HL7 ORU_R01消息；
(9)調用hl7comm.Send()函數，參數為上一步驟得到的ORU_R01消息，由HL7通信模塊完成消息發送和確認消息的接收；
(10)若繼續轉換轉步驟6，否則結束。
圖3
協議轉換引擎流程圖
Figure3.
Flow chart of protocol conversion engine
3.2 HL7通信模塊的實現
HL7通信模塊實現了HL7Comm類，封裝了HL7消息構造、HL7消息解析、MLLP通信等功能。
3.2.1 HL7消息構造
HL7 ORU_R01消息包含MSH、PID、OBR及OBX四種消息段。其中OBX段的數目可變，為靈活構造消息，HL7通信模塊中僅提供段構造函數，由調用者按需組合出HL7消息。
//MSH段構造函數
//輸入：sendingApp 發送方標識
//輸出：MSH段
string MakeMSHSeg(string sendingApp);
//PID段構造函數
//輸入：patientId 患者標識號
//?patientName 患者姓名
//輸出：PID段
string MakePIDSeg(string patientId,string patientName);
//OBR段構造函數
//輸入：orderNo 醫囑號
//?serviced 服務標識號
///?startTime波形采樣開始時間，構造DEC消息時為空串
//輸出：OBR段
string MakeOBRSeg(string orderNo,string serviceId,string startTime);
//OBX段構造函數
//輸入：index 消息段號
///?rosMDC 觀察標識
///?level 觀察層次
///?obsValue 觀察值
///? rosUCUM 單位，構造WCM消息時為空串
//輸出：OBX段
string MakeOBXSeg(string index,string rosMDC,string level,string obsValue,string rosUCUM);
3.2.2 HL7消息解析
HL7消息解析采用了正則表達式。正則表達式是對字符串操作的一種邏輯公式，通過描述字符串規則從而對字符串進行檢索、替換、匹配等操作。本研究通過調用Boost庫實現正則表達式的處理。
HL7消息分為消息段、字段、組件、子組件，分隔符分別為回車符、“|”、“∧”、“&”，據此編寫出相應的正則表達式對HL7消息進行全解析或按需解析[13]。本研究中只需要對HL7消息進行按需解析，即根據指定的字段號或組件號獲取相應的數據。
① 按需解析消息字段
一個字段可以表示為以“|”開頭(正則表達式為\|)，后面有非“|”字符(正則表達式為[∧\|])0至多個(正則表達式為*)，即\|[∧\|]*。按需解析指定“消息段名-字段號”消息字段值的正則表達式為：
消息段名(\|[∧\|]*){字段號-1}\|([∧\|]*)
以獲取PID-5(患者姓名字段)為例，主要解析過程如下:
//定義正則表達式，其中\|[∧\|]*重復4次
regex rgx(“PID(\\|[∧\\|]*){4}\\|([∧\\|]*)”);
//message：被解析消息 match：匹配結果
string PID_5 = “”;
if(regex_search(message,match,rgx))
PID_5=match[2];
② 按需解析消息組件
組件是以“∧”為分隔符的子字符串，在上述解析得到字段值的基礎上，用以下正則表達式得到指定組件號的值：
(\∧[∧\∧]*){組件號-1}\∧([∧\∧]*)
3.2.3 MLLP(Minimal Lower Layer Protocol)通信
因為在TCP/IP 上傳遞的數據是一串連續的比特流，而HL7的封裝協議要求通信代碼能夠識別每條消息的開始和結束。MLLP 是標準中規定的通過 TCP/IP網絡傳送 HL7 消息的機制，每個 HL7 消息用一個消息頭(0x0B)和一個消息尾(0x1C和0x0D)封裝，以標示消息的開始和結束。
HL7Comm構造函數傳入DOC的IP地址和端口號，創建Socket實現TCP/IP網絡通信，在此基礎上實現HL7的MLLP協議。發送時按MLLP協議對消息進行頭尾封裝，接收時按MLLP協議根據頭尾標記獲取消息。
3.3 設備驅動模塊的實現
設備驅動模塊負責集成引擎與設備端的通信連接以及設備數據的解析處理等功能。不同的醫療設備有著不同的通信接口和數據格式，因此這部分代碼的變動較大。為通用性和靈活性，在本研究中用Javascript腳本語言編寫。在集成引擎中針對COM、CAN、TCP Server、TCP Client等接口類型，實現了通用的底層通信功能，只需要從設備驅動模塊中得到設備接口的配置信息。設備驅動模塊的另一個任務是對收到的數據進行分幀、校驗、解析等處理。主要接口如下：
//獲取設備通信配置信息
//輸入：無
//輸出：設備通信配置信息，格式為“接口類型，參數1，參數2，…”。
//?如“COM,1,9600,8,n,1”表示串口1，波特率9600，8位數據位，無奇偶校驗，1位停止位；
//?“TCP Server,510”表示為TCP服務器方式，端口號為510。
function GetCommConfig ();
//獲取服務器通信配置信息
//輸入：無
//輸出：服務器通信配置信息，格式為“IP地址: 端口號”。
function GetDOCConfig ();
//獲取設備標識
//輸入：無
//輸出：設備標識，用于構成服務標識號、醫囑號、發送方標識等
function GetDeviceId();
//獲取設備數據查詢命令
//輸入：數據的MDC編碼。為空則查詢所有數據
//輸出：被動方式設備數據查詢命令幀,主動方式設備則返回空
function GetPollCmd(mdccode);
……
//解析數據
//輸入：設備數據幀字符數組
//輸出：解析結果，格式為“觀察指標1=值1，觀察指標2=值2，……”
function Parse(msg);
4 結果與討論
IHE-PCD Pre-Connetathon Test Tool為IHE官方提供的PCD測試工具[14] ，打開測試工具所在網頁，按要求配置相關參數。以NCC X5監護儀為被測設備，輸出數據經過本研究的集成網關轉換后發送給測試工具指定的服務器(IP地址129.6.24 .143 ，端口號13080)。該監護儀通過網口連接向TCP端口(如511)主動輸出信息，因此將設備驅動模塊的設備通信配置信息設置為“TCP Server，511”，服務器通信配置信息為“129.6.24.143:13080”。
圖 4為接收到的一條血壓原始數據，字節順序為低字節在前，其中第10~11字節為收縮壓，12~13字節為舒張壓，14~15字節為平均壓。
圖4
血壓原始數據
Figure4.
Raw data of blood pressure
協議轉換后的HL7 ORU_R01消息如圖 5所示。三個OBX段分別記錄了收縮壓(150 mm Hg)、舒張壓(80mm Hg)和平均壓(103 mm Hg)的測量值。在IHE-PCD Test Tool測試結果中可見正確接收到了該HL7 ORU_RO1消息并驗證成功，如圖 6所示。
圖5
協議轉換結果
Figure5.
Protocol conversion result
圖6
測試結果
Figure6.
Test result
本研究可應用于通用型中央監護系統、手術麻醉系統以及數字化手術室集中控制系統等應用系統。這些應用系統只要實現DEC和WCM集成模式的DOC角色，通過局域網連接到本研究實現的集成網關，即可接收呼吸機、麻醉機、監護儀、輸液泵等設備的數據，無需為每個設備編寫特定的通信接口，提高其通用性與可擴展性。
醫療儀器設備的信息集成是醫療信息建設的難點之一，目前國內對于這類醫療儀器與信息系統集成的研究還在發展階段。本研究提出的基于IHE PCD的醫療儀器信息集成技術，可將醫療儀器的通信協議轉換成符合HL7標準的消息格式，且不僅支持單一設備通信協議的轉換，具有一定的通用性，對醫療儀器設備的信息集成和共享具有良好的應用價值，對在用醫療儀器設備的信息集成尤具價值。
