由于醫療環境的復雜性, 異構系統集成是醫院信息化建設中的難點和關鍵。但目前, 在醫療信息系統集成過程中, 集成各方往往基于自由文檔等形式進行溝通和實現, 效率低且很難適應需求的及時變更。論文提出一種基于業務流程建模標記(BPMN)模型對集成需求進行建模, 并將其轉化為可執行集成配置的集成開發方法。在此基礎上, 論文實現了一種醫療信息系統集成需求場景建模與配置轉換的工具, 并以醫院放射科集成場景為例對方法的有效性進行了驗證。
引用本文： 李沙沙, 聶鴻超, 呂旭東, 段會龍. 基于協作模型的醫療信息系統集成開發方法. 生物醫學工程學雜志, 2015, 32(1): 202-208. doi: 10.7507/1001-5515.20150037 復制
引言
由于醫院環境的復雜性，單個開發商的產品很難覆蓋所有醫療專業領域，故醫院內存在大量來自不同廠商的異構系統[1]。為滿足醫療整體信息化需求，實現無紙化、無膠片化，多個系統往往需要協同工作實現特定的醫療業務。為實現該目的，各類異構系統的集成是關鍵[2]。目前醫療信息系統集成有基于數據庫、基于標準消息、基于接口引擎等多種解決方案，而基于接口引擎的解決方案可以同時兼顧標準化和遺留系統集成問題，為其它方案提供了一個平臺，綜合了各種解決方案的優點[3]。
當前基于接口引擎的集成方案通常從醫院業務流程開始分析，確定系統之間為實現某業務而進行的復雜交互，這些交互進一步細化為系統之間的接口通信，最終通過接口引擎來實現異構系統間的消息傳輸。在集成需求分析階段，集成業務流程、系統接口定義往往以自由文檔形式表達，需求定義的不全面不準確導致集成各方溝通不暢，拖延項目周期。在集成實施階段，集成人員參考由前期各方溝通約定的需求文檔，對接口引擎進行配置開發，從而實現系統集成。在整個集成項目開發過程中，集成實施依賴集成人員對約定文檔的理解，集成配置與需求定義分離，效率低且難以自適應需求調整。因此，用一種統一的模型表達集成需求，并將需求分析與集成實施實現銜接具有重要意義。
業務流程建模和標記(business process model and notation，BPMN)是業務流程建模領域的事實標準[4]，BPMN將業務與技術結合，可從業務流程層到接口層精確定義集成需求[5]。其次，BPMN協作業務流程模型定義消息流Message Flow來表達多個系統間的交互，而接口引擎以消息傳輸為其實現機制，與之對應。
本文提出一種基于BPMN的醫療信息系統集成開發方法，利用BPMN模型元素對集成需求進行建模，并研究需求模型與接口引擎配置模型的共同點，實現需求模型到集成配置的自動轉換，從而有效銜接需求分析和集成實施過程。在此基礎上，該研究研發了一種醫療信息系統集成需求建模和配置轉換的工具。
1 相關知識
1.1 BPMN簡介
BPMN通過簡單易懂的圖形化標記對業務流程進行建模，消除溝通障礙。業務流程建模分為編制與編排，兩者區別在于：編制基于控制流，主要用來對單個企業或實體能夠集中控制的流程進行建模；而編排是基于消息交換的，并且有兩個以上企業或實體在編排中協作[6]。通常意義上的業務流程建模指可被流程引擎驅動的流程編制建模，而編排是一系列獨立系統交互行為的聲明，表達的是多系統協作的業務流程。系統集成解決的是多系統協作的流程編排問題。BPMN2.0用協作視圖對流程編排進行建模，其用Message Flow表達參與者之間的交互，包含交互的接口定義等細節信息。另外BPMN2.0還提供一種非正式的表現形式-會話視圖，將系統之間一系列相關的Message Flow定義為會話，從更高層次上對集成需求進行描述[7]。本文關注可對集成需求進行建模的BPMN協作視圖和會話視圖。
1.2 接口引擎配置
接口引擎是目前醫療信息系統集成的主流技術，典型的接口引擎代表有Corepoint、Ensemble、Mirth Connect等。Mirth Connect是國際上比較成熟的專注于醫療領域集成的開源接口引擎[8]，其定義通道模型“Channel”描述集成實施方案，通道由4個核心組件構成[9]，如圖 1所示：①源連接器(Source Connector)：從外部系統接收各種協議傳輸的消息；②過濾器(Filter)：基于一系列規則對消息進行驗證，決定拒絕還是接收消息；③轉換器(Transformer)：通過一系列步驟將源消息轉換為目標消息；④目標連接器(Destination Connector)：發送經過轉換的消息至一個或多個目標系統。
圖1
Mirth Connect通道配置模型
Figure1.
Channel configuration model of Mirth Connect
Mirth Connect提供友好界面使抽象的通道模型可配置，通道配置的過程就是集成開發實施的過程。其提供HL7、Web Service、Database等多種連接器，用戶根據系統接口類型配置源/目標連接器，保證消息能被接口引擎接收并以目標系統能識別的格式發送出去。除了對核心組件Connector、Filter、Transformer進行配置外，用戶還需對通道本身運行、管理等屬性進行配置。配置完成后，便可部署、運行通道，實現消息的轉換和路由。通道配置以XML格式保存，可導入導出實現復用。
2 基于BPMN的系統集成開發方法
BPMN協作視圖可從業務層到接口層逐步對集成需求進行直觀表達。會話視圖作為協作視圖的非正式表達形式，便于集成各方在需求分析初期溝通，描繪集成需求鳥瞰圖。用標準化的BPMN模型表達集成需求，避免了以傳統自由文檔形式定義集成需求造成的溝通障礙。且從BPMN協作視圖自動獲取集成配置，將有效銜接集成需求分析和集成實施過程，提高集成效率并可動態適應需求調整。
故本文提出如圖 2所示的基于BPMN的集成開發方法。首先是集成需求建模，在集成需求分析初期，用BPMN會話視圖建模來描述整個集成項目需求鳥瞰圖；然后針對具體的醫療業務，對多系統協作的業務流程進行建模。其次將BPMN協作視圖自動轉化為接口引擎可執行的集成配置。最后在集成實施階段，將自動轉換所得的集成配置導入接口引擎，完善配置確認無誤后便可部署、運行。下面對每一步進行詳細介紹。
圖2
基于BPMN的集成開發流程
Figure2.
Process of integration development based on BPMN
2.1 集成需求建模
2.1.1 集成需求鳥瞰圖
在集成需求分析初期，用BPMN會話視圖表達集成需求鳥瞰圖，可幫助集成各方在較高層次上理解集成項目需求。鳥瞰圖忽視系統之間交互的具體消息流，系統之間交互事務用會話表示[10]。如圖 3所示，集成系統用矩形符號——池(Pool)表達，系統之間的交互事務用六邊形——會話(Conversation)表示，清晰表達了有哪些系統需要集成以及各系統之間的交互事務。
圖3
集成需求鳥瞰圖
Figure3.
Bird's-eye view of integration requirement
2.1.2 業務協作流程
會話視圖從較高層次表達集成需求，便于理解。而協作視圖則具體到多系統協作的流程和接口來描述集成需求，是集成實施的前提。用于描述集成需求的BPMN協作視圖模型主要由多個參與者(Participant)及Message Flow構成，Participant引用其內部活動流程(Process)，Process由一系列流結點(Flow Node)通過序列流(Sequence Flow)順序連接構成。Flow Node有事件(Event)、活動(Activity)和網關(Gateway)三種類型。Event指發生在流程執行過程中的事情，如開始事件(Start Event)和結束事件(End Event)表示流程的開始和結束。Gateway控制流程的分支和聚合，基本類型有排他網關(Exclusive)、事件網關(Event-based)等。Activity是系統在流程執行過程中執行的工作，包含Send Task、Receive Task、User Task、Manual Task等多種任務類型。Message Flow用于連接Send Task和Receive Task，實現消息交換。
在集成場景下，我們主要關注執行消息發送和接收任務的Send/Receive Task。Send/Receive Task通過屬性messageRef和operationRef引用接口模型元素Service下的operation和message，通過implementation屬性定義具體實現技術[11-12]。Service由一系列Interface組成，Interface是參與者對外提供一組Operation的組合，Interface通過EndpointRef屬性定義接口訪問地址Endpoint。Operation由一個輸入In Message和可選的一個輸出Out Message構成。Message引用ItemDefinition定義消息類型，ItemDefinition通過屬性structureRef以XML Schema格式定義具體消息結構。由Web Service技術實現的接口，Operation和Interface通過implementationRef屬性定義二者的具體實現。
BPMN默認采用Web Service技術實現接口，但允許用戶自定義實現技術[11-12]。HL7(Health Level 7)是最常用的醫療消息交換標準，故擴展implementation支持HL7實現，此時消息結構采用標準HL7消息格式序列化后的XML結構表達。由Web Service技術實現的Send/Receive Task, Endpoint定義為服務的WSDL地址，而HL7實現的消息接口，也統一采用“protocol://host:port”的URI形式表達。其中protocol為HL7消息采用的通訊協議(HL7 V2.X默認采用LLP/MLLP協議)，host及port分別為HL7消息發送或接收系統的IP地址和端口。用BPMN協作視圖表達的多系統協作業務流程圖例圖如圖 4所示：集成系統用長矩形Pool表示，虛箭頭Message Flow連接Send Task和Receive Task，圖下方為所用的BPMN圖形化元素。
圖4
業務協作流程圖
Figure4.
Business collaboration process diagram
2.2 BPMN協作視圖轉為集成配置
BPMN協作視圖用Message Flow連接Send Task和Receive Task，二者可采用不同的接口實現，一個Send Task實例可向多個系統發送消息。圖 5為BPMN協作視圖表達的常見集成場景及其對應的接口引擎Mirth Connect的集成通道配置模式。Mirth Connect的配置基于其通道模型的參數化表達，通道的各個組件通過定義可執行屬性被接口引擎執行，不同類型的Connector連接器有不同的執行屬性。本文考慮醫療信息系統集成中常用的HL7、Web Service兩種接口類型，分別對應LLP、Web Service兩種協議的連接器。
圖5
BPMN表達集成場景與其對應通道配置模式
(a)源端:目的端=1 :1；(b)源端:目的端=1 :
(a) Source :Destination=1 :1; (b) Source :Destination=1 :
BPMN協作視圖用Message Flow連接Send Task和Receive Task，Send/Receive Task獨立聲明其接口信息。通道模型通過源端Source Connector接收系統消息，通過目的端Destination Connector將消息發送至目標系統。Source/Destination Connector的屬性配置依賴于集成需求分析時在接口層面的定義，與BPMN協作視圖中的Send/Receive Task接口信息匹配。當Send/Receive Task兩端消息結構異構時，兩端消息結構映射為通道模型Transformer組件兩端的消息模板inboundTemplate和outboundTemplate。
從BPMN協作視圖自動獲取通道配置的算法用可擴展樣式表轉換語言(Extensible Stylesheet Language Transformations, XSLT)實現，通過通道配置樣式表定義BPMN協作視圖的轉換輸出格式, 其中與具體集成需求場景無關的消息處理設置、通道部署運行等配置在樣式表中預設默認值。Message Flow到通道配置文件的轉換，一個協作視圖通常包括多條Message Flow，故可導出一系列配置文件。當多條Message Flow從同一個Send Task發出時，合并轉換得到的配置文件，得到Source :Destination=1 :n的通道配置模式。BPMN協作視圖和接口引擎通道配置均采用XML格式持久化保存。
2.3 集成實施
BPMN協作視圖表達了集成需求，交互系統接口信息映射到集成配置的Source/Destination Connector配置，但并未包含接口引擎通道配置的所有信息。故由BPMN自動轉換所得的配置文件導入接口引擎后，需由接口引擎工程師根據輸入輸出消息模板補充定義映射步驟、添加過濾規則等，還要確認轉換時預設的消息處理、通道部署運行等配置是否合適，確認配置完整無誤后方可部署、運行接口引擎。
基于以上方法，本研究設計實現了一種基于BPMN模型的集成開發工具，實現對醫療信息系統集成需求的建模及其向集成配置的轉換(見圖 6)。
圖6
基于BPMN模型的集成開發工具
Figure6.
Integration development tool based on BPMN model
工具基礎架構基于Eclipse RCP平臺開發，在模型層利用建模框架EMF(Eclipse Modeling Framework)將BPMN2.0模型代碼化，在其之上利用Eclipse圖形化框架Graphiti實現模型的圖形化表達，在可視化開發層，用戶利用圖形化編輯器對集成需求進行建模并編輯屬性。BPMN模型視圖按照標準序列化為XML文件，其向接口引擎通道配置的轉換由XSLT引擎實現。下面利用該工具結合具體集成案例對方法進行驗證。
3 方法驗證及結果
放射科作為醫院的重要科室，要實現放射科業務流程，醫院信息系統(Hospital Information System, HIS)與放射科信息系統(Radiology Information system, RIS)的集成是關鍵[13]。HIS一般采用Web Service接口，而RIS往往遵循HL7標準，HIS與RIS集成能充分提高放射科工作效率，實現無紙化、無膠片化的工作流程[14]。此部分以放射科集成場景為例對方法進行驗證。
3.1 集成需求鳥瞰圖
要實現放射檢查業務，初步分析HIS與RIS的集成主要包括三方面內容：HIS向RIS提供患者基本信息；HIS向RIS發送檢查醫囑信息；HIS從RIS查詢獲取檢查圖像和報告。在開發工具中用BPMN會話視圖建模集成需求的鳥瞰圖如圖 7所示，可從較為宏觀的層面描述集成系統及其之間的交互。
圖7
集成需求鳥瞰圖界面
Figure7.
Interface of bird's-eye view of integration requirement
3.2 協作業務流程
進一步，分析放射檢查的具體業務流程。HIS與RIS協同工作實現放射科檢查的流程為：患者掛號登記，HIS登記系統將患者基本信息(如ID、姓名等)發送到HIS醫生工作站和RIS；患者到醫生處就診后，醫生開檢查申請單，申請信息(如檢查項目、檢查部位、疾病診斷等)由醫生工作站發送至RIS。RIS預約安排檢查，采集、存儲圖像并提供檢查診斷報告，報告存儲確認后RIS通知醫生工作站醫囑執行完畢。隨后醫生便可在醫生工作站系統調閱RIS存儲的影像及報告。用BPMN協作視圖建模系統協作實現放射科檢查的業務流程如圖 8所示。
圖8
放射科檢查業務系統協作流程圖界面
Figure8.
Interface of system collaboration diagram of radiology order process
流程設計好后，便可對系統接口進行定義。聲明系統的接口實現技術，消息結構，引用operation，operation所調用的interface、service以及接口訪問地址endpoint。這些屬性均在Send/Receive Task元素的屬性編輯區定義。
3.3 集成配置轉換
接口配置完畢后，協作視圖保存為XML，放射科檢查業務實現6條消息的傳遞，經XSLT轉換產生6個通道配置文件。將通道配置文件導入Mirth Connect，由接口引擎工程師根據輸入輸出消息模板補充定義消息映射規則、過濾規則等，確認配置完整無誤后便可部署、運行接口引擎。
4 結論
目前，國外已有研究者[15]將BPMN應用在面向服務架構(service-oriented architecture, SOA)集成方案的需求分析和服務接口聲明中。但目前在醫療領域，信息系統仍主要基于消息傳輸實現集成，SOA并不常用。并且已有研究僅僅是基于BPMN模型表達集成需求，并未將集成需求與集成實踐銜接。
本文提出一種基于BPMN模型對集成需求進行建模，并將其轉化為可執行集成配置的醫療信息系統集成開發方法。基于該方法，設計實現了集成開發工具，并用放射科集成案例對該方法進行了驗證。結果表明BPMN能清晰表達集成需求：會話視圖從較為宏觀的層面表達集成鳥瞰圖，而協作視圖則具體到消息流描述集成場景。BPMN協作視圖可轉換為接口引擎配置，將集成需求分析與配置實施過程銜接，實現集成配置隨需而變。由于異構系統消息映射依賴人的理解，通道配置的Transformer仍需進一步由人工編碼實現，集成配置的轉換是半自動化的。但當集成項目涉及大量消息傳輸時，通道兩端的Connector以及Transformer的消息模板等配置信息的自動轉換仍能有效提高集成效率。
本文的研究針對醫療領域常見的兩種接口：HL7和Web Service，實際集成還存在Database、File等接口，這些接口通過BPMN如何表達還需進一步研究。
引言
由于醫院環境的復雜性，單個開發商的產品很難覆蓋所有醫療專業領域，故醫院內存在大量來自不同廠商的異構系統[1]。為滿足醫療整體信息化需求，實現無紙化、無膠片化，多個系統往往需要協同工作實現特定的醫療業務。為實現該目的，各類異構系統的集成是關鍵[2]。目前醫療信息系統集成有基于數據庫、基于標準消息、基于接口引擎等多種解決方案，而基于接口引擎的解決方案可以同時兼顧標準化和遺留系統集成問題，為其它方案提供了一個平臺，綜合了各種解決方案的優點[3]。
當前基于接口引擎的集成方案通常從醫院業務流程開始分析，確定系統之間為實現某業務而進行的復雜交互，這些交互進一步細化為系統之間的接口通信，最終通過接口引擎來實現異構系統間的消息傳輸。在集成需求分析階段，集成業務流程、系統接口定義往往以自由文檔形式表達，需求定義的不全面不準確導致集成各方溝通不暢，拖延項目周期。在集成實施階段，集成人員參考由前期各方溝通約定的需求文檔，對接口引擎進行配置開發，從而實現系統集成。在整個集成項目開發過程中，集成實施依賴集成人員對約定文檔的理解，集成配置與需求定義分離，效率低且難以自適應需求調整。因此，用一種統一的模型表達集成需求，并將需求分析與集成實施實現銜接具有重要意義。
業務流程建模和標記(business process model and notation，BPMN)是業務流程建模領域的事實標準[4]，BPMN將業務與技術結合，可從業務流程層到接口層精確定義集成需求[5]。其次，BPMN協作業務流程模型定義消息流Message Flow來表達多個系統間的交互，而接口引擎以消息傳輸為其實現機制，與之對應。
本文提出一種基于BPMN的醫療信息系統集成開發方法，利用BPMN模型元素對集成需求進行建模，并研究需求模型與接口引擎配置模型的共同點，實現需求模型到集成配置的自動轉換，從而有效銜接需求分析和集成實施過程。在此基礎上，該研究研發了一種醫療信息系統集成需求建模和配置轉換的工具。
1 相關知識
1.1 BPMN簡介
BPMN通過簡單易懂的圖形化標記對業務流程進行建模，消除溝通障礙。業務流程建模分為編制與編排，兩者區別在于：編制基于控制流，主要用來對單個企業或實體能夠集中控制的流程進行建模；而編排是基于消息交換的，并且有兩個以上企業或實體在編排中協作[6]。通常意義上的業務流程建模指可被流程引擎驅動的流程編制建模，而編排是一系列獨立系統交互行為的聲明，表達的是多系統協作的業務流程。系統集成解決的是多系統協作的流程編排問題。BPMN2.0用協作視圖對流程編排進行建模，其用Message Flow表達參與者之間的交互，包含交互的接口定義等細節信息。另外BPMN2.0還提供一種非正式的表現形式-會話視圖，將系統之間一系列相關的Message Flow定義為會話，從更高層次上對集成需求進行描述[7]。本文關注可對集成需求進行建模的BPMN協作視圖和會話視圖。
1.2 接口引擎配置
接口引擎是目前醫療信息系統集成的主流技術，典型的接口引擎代表有Corepoint、Ensemble、Mirth Connect等。Mirth Connect是國際上比較成熟的專注于醫療領域集成的開源接口引擎[8]，其定義通道模型“Channel”描述集成實施方案，通道由4個核心組件構成[9]，如圖 1所示：①源連接器(Source Connector)：從外部系統接收各種協議傳輸的消息；②過濾器(Filter)：基于一系列規則對消息進行驗證，決定拒絕還是接收消息；③轉換器(Transformer)：通過一系列步驟將源消息轉換為目標消息；④目標連接器(Destination Connector)：發送經過轉換的消息至一個或多個目標系統。
圖1
Mirth Connect通道配置模型
Figure1.
Channel configuration model of Mirth Connect
Mirth Connect提供友好界面使抽象的通道模型可配置，通道配置的過程就是集成開發實施的過程。其提供HL7、Web Service、Database等多種連接器，用戶根據系統接口類型配置源/目標連接器，保證消息能被接口引擎接收并以目標系統能識別的格式發送出去。除了對核心組件Connector、Filter、Transformer進行配置外，用戶還需對通道本身運行、管理等屬性進行配置。配置完成后，便可部署、運行通道，實現消息的轉換和路由。通道配置以XML格式保存，可導入導出實現復用。
2 基于BPMN的系統集成開發方法
BPMN協作視圖可從業務層到接口層逐步對集成需求進行直觀表達。會話視圖作為協作視圖的非正式表達形式，便于集成各方在需求分析初期溝通，描繪集成需求鳥瞰圖。用標準化的BPMN模型表達集成需求，避免了以傳統自由文檔形式定義集成需求造成的溝通障礙。且從BPMN協作視圖自動獲取集成配置，將有效銜接集成需求分析和集成實施過程，提高集成效率并可動態適應需求調整。
故本文提出如圖 2所示的基于BPMN的集成開發方法。首先是集成需求建模，在集成需求分析初期，用BPMN會話視圖建模來描述整個集成項目需求鳥瞰圖；然后針對具體的醫療業務，對多系統協作的業務流程進行建模。其次將BPMN協作視圖自動轉化為接口引擎可執行的集成配置。最后在集成實施階段，將自動轉換所得的集成配置導入接口引擎，完善配置確認無誤后便可部署、運行。下面對每一步進行詳細介紹。
圖2
基于BPMN的集成開發流程
Figure2.
Process of integration development based on BPMN
2.1 集成需求建模
2.1.1 集成需求鳥瞰圖
在集成需求分析初期，用BPMN會話視圖表達集成需求鳥瞰圖，可幫助集成各方在較高層次上理解集成項目需求。鳥瞰圖忽視系統之間交互的具體消息流，系統之間交互事務用會話表示[10]。如圖 3所示，集成系統用矩形符號——池(Pool)表達，系統之間的交互事務用六邊形——會話(Conversation)表示，清晰表達了有哪些系統需要集成以及各系統之間的交互事務。
圖3
集成需求鳥瞰圖
Figure3.
Bird's-eye view of integration requirement
2.1.2 業務協作流程
會話視圖從較高層次表達集成需求，便于理解。而協作視圖則具體到多系統協作的流程和接口來描述集成需求，是集成實施的前提。用于描述集成需求的BPMN協作視圖模型主要由多個參與者(Participant)及Message Flow構成，Participant引用其內部活動流程(Process)，Process由一系列流結點(Flow Node)通過序列流(Sequence Flow)順序連接構成。Flow Node有事件(Event)、活動(Activity)和網關(Gateway)三種類型。Event指發生在流程執行過程中的事情，如開始事件(Start Event)和結束事件(End Event)表示流程的開始和結束。Gateway控制流程的分支和聚合，基本類型有排他網關(Exclusive)、事件網關(Event-based)等。Activity是系統在流程執行過程中執行的工作，包含Send Task、Receive Task、User Task、Manual Task等多種任務類型。Message Flow用于連接Send Task和Receive Task，實現消息交換。
在集成場景下，我們主要關注執行消息發送和接收任務的Send/Receive Task。Send/Receive Task通過屬性messageRef和operationRef引用接口模型元素Service下的operation和message，通過implementation屬性定義具體實現技術[11-12]。Service由一系列Interface組成，Interface是參與者對外提供一組Operation的組合，Interface通過EndpointRef屬性定義接口訪問地址Endpoint。Operation由一個輸入In Message和可選的一個輸出Out Message構成。Message引用ItemDefinition定義消息類型，ItemDefinition通過屬性structureRef以XML Schema格式定義具體消息結構。由Web Service技術實現的接口，Operation和Interface通過implementationRef屬性定義二者的具體實現。
BPMN默認采用Web Service技術實現接口，但允許用戶自定義實現技術[11-12]。HL7(Health Level 7)是最常用的醫療消息交換標準，故擴展implementation支持HL7實現，此時消息結構采用標準HL7消息格式序列化后的XML結構表達。由Web Service技術實現的Send/Receive Task, Endpoint定義為服務的WSDL地址，而HL7實現的消息接口，也統一采用“protocol://host:port”的URI形式表達。其中protocol為HL7消息采用的通訊協議(HL7 V2.X默認采用LLP/MLLP協議)，host及port分別為HL7消息發送或接收系統的IP地址和端口。用BPMN協作視圖表達的多系統協作業務流程圖例圖如圖 4所示：集成系統用長矩形Pool表示，虛箭頭Message Flow連接Send Task和Receive Task，圖下方為所用的BPMN圖形化元素。
圖4
業務協作流程圖
Figure4.
Business collaboration process diagram
2.2 BPMN協作視圖轉為集成配置
BPMN協作視圖用Message Flow連接Send Task和Receive Task，二者可采用不同的接口實現，一個Send Task實例可向多個系統發送消息。圖 5為BPMN協作視圖表達的常見集成場景及其對應的接口引擎Mirth Connect的集成通道配置模式。Mirth Connect的配置基于其通道模型的參數化表達，通道的各個組件通過定義可執行屬性被接口引擎執行，不同類型的Connector連接器有不同的執行屬性。本文考慮醫療信息系統集成中常用的HL7、Web Service兩種接口類型，分別對應LLP、Web Service兩種協議的連接器。
圖5
BPMN表達集成場景與其對應通道配置模式
(a)源端:目的端=1 :1；(b)源端:目的端=1 :
(a) Source :Destination=1 :1; (b) Source :Destination=1 :
BPMN協作視圖用Message Flow連接Send Task和Receive Task，Send/Receive Task獨立聲明其接口信息。通道模型通過源端Source Connector接收系統消息，通過目的端Destination Connector將消息發送至目標系統。Source/Destination Connector的屬性配置依賴于集成需求分析時在接口層面的定義，與BPMN協作視圖中的Send/Receive Task接口信息匹配。當Send/Receive Task兩端消息結構異構時，兩端消息結構映射為通道模型Transformer組件兩端的消息模板inboundTemplate和outboundTemplate。
從BPMN協作視圖自動獲取通道配置的算法用可擴展樣式表轉換語言(Extensible Stylesheet Language Transformations, XSLT)實現，通過通道配置樣式表定義BPMN協作視圖的轉換輸出格式, 其中與具體集成需求場景無關的消息處理設置、通道部署運行等配置在樣式表中預設默認值。Message Flow到通道配置文件的轉換，一個協作視圖通常包括多條Message Flow，故可導出一系列配置文件。當多條Message Flow從同一個Send Task發出時，合并轉換得到的配置文件，得到Source :Destination=1 :n的通道配置模式。BPMN協作視圖和接口引擎通道配置均采用XML格式持久化保存。
2.3 集成實施
BPMN協作視圖表達了集成需求，交互系統接口信息映射到集成配置的Source/Destination Connector配置，但并未包含接口引擎通道配置的所有信息。故由BPMN自動轉換所得的配置文件導入接口引擎后，需由接口引擎工程師根據輸入輸出消息模板補充定義映射步驟、添加過濾規則等，還要確認轉換時預設的消息處理、通道部署運行等配置是否合適，確認配置完整無誤后方可部署、運行接口引擎。
基于以上方法，本研究設計實現了一種基于BPMN模型的集成開發工具，實現對醫療信息系統集成需求的建模及其向集成配置的轉換(見圖 6)。
圖6
基于BPMN模型的集成開發工具
Figure6.
Integration development tool based on BPMN model
工具基礎架構基于Eclipse RCP平臺開發，在模型層利用建模框架EMF(Eclipse Modeling Framework)將BPMN2.0模型代碼化，在其之上利用Eclipse圖形化框架Graphiti實現模型的圖形化表達，在可視化開發層，用戶利用圖形化編輯器對集成需求進行建模并編輯屬性。BPMN模型視圖按照標準序列化為XML文件，其向接口引擎通道配置的轉換由XSLT引擎實現。下面利用該工具結合具體集成案例對方法進行驗證。
3 方法驗證及結果
放射科作為醫院的重要科室，要實現放射科業務流程，醫院信息系統(Hospital Information System, HIS)與放射科信息系統(Radiology Information system, RIS)的集成是關鍵[13]。HIS一般采用Web Service接口，而RIS往往遵循HL7標準，HIS與RIS集成能充分提高放射科工作效率，實現無紙化、無膠片化的工作流程[14]。此部分以放射科集成場景為例對方法進行驗證。
3.1 集成需求鳥瞰圖
要實現放射檢查業務，初步分析HIS與RIS的集成主要包括三方面內容：HIS向RIS提供患者基本信息；HIS向RIS發送檢查醫囑信息；HIS從RIS查詢獲取檢查圖像和報告。在開發工具中用BPMN會話視圖建模集成需求的鳥瞰圖如圖 7所示，可從較為宏觀的層面描述集成系統及其之間的交互。
圖7
集成需求鳥瞰圖界面
Figure7.
Interface of bird's-eye view of integration requirement
3.2 協作業務流程
進一步，分析放射檢查的具體業務流程。HIS與RIS協同工作實現放射科檢查的流程為：患者掛號登記，HIS登記系統將患者基本信息(如ID、姓名等)發送到HIS醫生工作站和RIS；患者到醫生處就診后，醫生開檢查申請單，申請信息(如檢查項目、檢查部位、疾病診斷等)由醫生工作站發送至RIS。RIS預約安排檢查，采集、存儲圖像并提供檢查診斷報告，報告存儲確認后RIS通知醫生工作站醫囑執行完畢。隨后醫生便可在醫生工作站系統調閱RIS存儲的影像及報告。用BPMN協作視圖建模系統協作實現放射科檢查的業務流程如圖 8所示。
圖8
放射科檢查業務系統協作流程圖界面
Figure8.
Interface of system collaboration diagram of radiology order process
流程設計好后，便可對系統接口進行定義。聲明系統的接口實現技術，消息結構，引用operation，operation所調用的interface、service以及接口訪問地址endpoint。這些屬性均在Send/Receive Task元素的屬性編輯區定義。
3.3 集成配置轉換
接口配置完畢后，協作視圖保存為XML，放射科檢查業務實現6條消息的傳遞，經XSLT轉換產生6個通道配置文件。將通道配置文件導入Mirth Connect，由接口引擎工程師根據輸入輸出消息模板補充定義消息映射規則、過濾規則等，確認配置完整無誤后便可部署、運行接口引擎。
4 結論
目前，國外已有研究者[15]將BPMN應用在面向服務架構(service-oriented architecture, SOA)集成方案的需求分析和服務接口聲明中。但目前在醫療領域，信息系統仍主要基于消息傳輸實現集成，SOA并不常用。并且已有研究僅僅是基于BPMN模型表達集成需求，并未將集成需求與集成實踐銜接。
本文提出一種基于BPMN模型對集成需求進行建模，并將其轉化為可執行集成配置的醫療信息系統集成開發方法。基于該方法，設計實現了集成開發工具，并用放射科集成案例對該方法進行了驗證。結果表明BPMN能清晰表達集成需求：會話視圖從較為宏觀的層面表達集成鳥瞰圖，而協作視圖則具體到消息流描述集成場景。BPMN協作視圖可轉換為接口引擎配置，將集成需求分析與配置實施過程銜接，實現集成配置隨需而變。由于異構系統消息映射依賴人的理解，通道配置的Transformer仍需進一步由人工編碼實現，集成配置的轉換是半自動化的。但當集成項目涉及大量消息傳輸時，通道兩端的Connector以及Transformer的消息模板等配置信息的自動轉換仍能有效提高集成效率。
本文的研究針對醫療領域常見的兩種接口：HL7和Web Service，實際集成還存在Database、File等接口，這些接口通過BPMN如何表達還需進一步研究。
