This document contains the BPEL specification for the paper Medical Services Workflows with BPEL4WS by Rainer Anzböck and Schahram Dustdar.

Size: px

Start display at page:

Download "This document contains the BPEL specification for the paper Medical Services Workflows with BPEL4WS by Rainer Anzböck and Schahram Dustdar."

Belinda Matthews
6 years ago
Views:

1 This document contains the BPEL specification for the paper Medical Services Workflows with BPEL4WS by Rainer Anzböck and Schahram Dustdar. For more information please contact: BPEL specification In this section we provide a WSDL and BPEL specification for the second opinion workflow. The source code is commented for each section following the structure in [2]. The WSDL file is not part of the BPEL specification but improves understanding of the language constructs. The WSDL file defines the content and structure of communication. The business partners and the flow of interaction are defined in the BPEL file. Messages, port types and service link types of the WSDL definitions are referenced. WSDL and BPEL definition of high level workflow The high level workflow corresponds to Figure 11. The WSDL file contains the message, port type and service link type definition as shown in the following listing. WSDL file for the high level workflow   <definitions targetnamespace=" xmlns:wf="  <message name="request Second Opinion"> <part name="wf SO metadata" type="wf_so_meta"> <part name="wf SO data" type="wf_so"> <message name="response Second Opinion"> <part name="wf SO metadata" type="wf_so_meta"> <part name="wf SO data" type="wf_so"> <!-- port type definitions (SO abbreviates second opinion) -- >

2 <porttype name="sosecondarywfport"> <operation name="request Second Opinion"> <input message="request Second Opinion"> <porttype name="soprimarywfcallbackport"> <operation name="response Second Opinion"> <input message="response Second Opinion">  <servicelinktype name="secondaryopinionwflt"> <role name="soprimary"> <porttype name="soprimarywfcallbackport"> </role> <role name="sosecondary"> <porttype name="sosecondarywfport"> </role> </servicelinktype> On top of the file there is a namespace definition for WSDL elements. Next two message definitions for the data exchange during the Request Second Opinion and Response Second Opinion activities are defined. Both messages consist of a metadata and a message body. The metadata is intended for additional information about communication partners and other administrative data. Afterwards the port types are defined. The SOSecondaryWFPort and SOPrimaryWFCallbackPort port types correspond to the roles the RIS site hold. Important is the definition of the callback port to enable the workflow engine to execute the model with asynchronous communication behavior. While the name doesn t influence the behavior it is easier to model BPEL activities for sending and receiving operations, if the corresponding ports are clearly defined. Finally the file contains a service link type definition. Here the SecondaryOpinionWFLT link type is defined which contains a definition of two RIS sites. The sites provide the port types from above and the roles SOPrimary and SOSecondary which are equal to the RIS Site 1 and RIS Site 2 definition in Figure 11. BPEL file for the high level workflow  <process name="secondopinion" targetnamespace=" xmlns=" xmlns:wf=" xmlns:lns="

3 <partners> <partner name="secondarysite" servicelinktype="secondaryopinionlt" myrole="soprimary" partnerrole="sosecondary"/> </partners>  <variables> <variable name="wf_so_req" messagetype="wf:request Second Opinion"> <variable name="wf_so_resp" messagetype="wf:response Second Opinion"> </variables>  <sequence> <! - serializing request / response messages --> porttype="sosecondarywfport" operation="request Second Opinion" inputvariable="wf_so_req"> <correlation set="wf_so"> porttype="soprimarywfcallbackport" operation="response Second Opinion" inputvariable="wf_so_resp"> <correlation set="wf_so"> </sequence> <! - serializing request / response messages --> The BPEL file contains a namespace definition of the workflow namespace from the above WSDL file, a BPEL specific name space and a local namespace of the BPEL file. Next there is a partner definition where the secondary site is defined. For each service link type a partner and the own and the partners role are defined. In this case the primary and secondary second opinion roles are listed. Finally one variable per workflow message is defined. The second part of the definition contains the high level workflow itself, corresponding to the definition in Figure 11. The sequence construct serializes the second opinion request and response. Both operations are performed using the invoke activity. A correlation set is defined to create a logical relationship between the request and response message content.

4 With these definitions an implementation of the high level workflow can be derived. The definition corresponds to the system interface shown in Figure 10. Collaxa [31] is a very current product development that supports definition and execution of BPEL models. However, a working sample has been out of the scope of this paper. WSDL and BPEL definition of HL7/DICOM second opinion request The communication between the two radiological sites is not only based on a workflow model but also on HL7 and DICOM messages exchange. To define the corresponding interface and message exchange, a WSDL and BPEL description is provided. The source code below shows the WSDL file defined for the second opinion request. Because of the length of the definition the WSDL and BPEL files are split into two parts. WSDL file for the DICOM / HL7 Second Opinion Request (Part 1) <! - DICOM / HL7 Workflow of Figure 12 -->  <definitions targetnamespace=" xmlns:hl7=" xmlns:dicom=" xmlns:ris="  <message name="hl7 A04 register a patient"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A04 data" type="hl7_a04"> <message name="hl7 A04 acknowledge"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A04 data" type="hl7_a04"> <message name="hl7 A01 admit visit notification"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A01 data" type="hl7_a01"> <message name="hl7 A01 acknowledge"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A01 data" type="hl7_a01"> <message name="dicom Association Request"> <part name="ris DICOM metadata" type="ris_dicom">

5 <part name="dicom Association Request data" type="dicom:associationrequest"> <message name="dicom Association Response"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom Association Response data" type="dicom:associationresponse"> <message name="dicom C-STORE"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom C-STORE data" type="dicom_cstore"> <message name="dicom Study End"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom Study End data" type="dicom_studyend"> <message name="dicom Association Release"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom Association Release" type="dicom_associationrelease"> The WSDL definition again contains a namespace definition for the RIS, the HL7 and the DICOM implementation. Then the message definition contains everything required by the activity diagram in Figure 12. Every message is named in consistence to the protocol standard specification. As above two message parts for metadata and application data are considered. The following source code contains port type and service link type specifications. WSDL file for the DICOM / HL7 Second Opinion Request (Part 2)  <porttype name="sosecondaryhl7port"> <operation name="hl7 A04 register a patient"> <input message="hl7 A04 register a patient"> <operation name="hl7 A01 admit visit notification"> <input message="hl7 A01 admit visit notification"> <porttype name="soprimaryhl7callbackport"> <operation name="hl7 A04 acknowledge"> <input message="hl7 A04 acknowledge"> <operation name="hl7 A01 acknowledge">

6 <input message="hl7 A01 acknowledge"> <porttype name="sosecondarydicomport"> <operation name="dicom Association Request"> <input message="dicom Association Request"> <operation name="dicom C-STORE"> <input message="dicom C-STORE"> <porttype name="soprimarydicomcallbackport"> <operation name="dicom Association Response"> <input message="dicom Association Response">  <servicelinktype name="secondaryopiniondicomlt"> <role name="soprimary"> <porttype name="soprimarydicomcallbackport"> </role> <role name="sosecondary"> <porttype name="sosecondarydicomport"> </role> </servicelinktype> <servicelinktype name="secondaryopinionhl7lt"> <role name="soprimary"> <porttype name="soprimaryhl7callbackport"> </role> <role name="sosecondary"> <porttype name="sosecondaryhl7port"> </role> </servicelinktype> WSDL ports and service link types for the second opinion request are defined. For both sites a HL7 and a DICOM port is specified, resulting in four port type definitions. Two of which are for the initiating operations and two for a callback interface on the secondary site. The callback interface is required for the asynchronous response Finally there is a HL7 and a DICOM service link type linking the primary and the secondary site together based on the defined port types for each protocol. Interesting is the workflow definition which is presented as source code next. BPEL file for the DICOM / HL7 Second Opinion Request (Part 1)

7  <process name="secondopinionrequest" targetnamespace=" xmlns=" xmlns:hl7=" xmlns:dicom=" xmlns:ris=" xmlns:lns="  <partners> <partner name="secondarysite" servicelinktype="sorequestsecondarysitelt" myrole="sorequestsecondarysiteuser"/> </partners>  <variables> <variable name="hl7_a04_rap" messagetype="hl7:hl7 A04 register a patient"> <variable name="hl7_a04_ack" messagetype="hl7:hl7 A04 acknowledge"> <variable name="hl7_a01_avn" messagetype="hl7:hl7 A01 admit visit notification"> <variable name="hl7_a01_ack" messagetype="hl7:hl7 A01 acknowledge"> <variable name="dicom_assoc_req" messagetype="dicom:dicom Association Request"> <variable name="dicom_assoc_resp" messagetype="dicom:dicom Association Response"> <variable name="dicom_c-store" messagetype="dicom:dicom C- STORE"> <variable name="dicom_c-store_study_end" messagetype="dicom:dicom C-STORE Study End"> <variable name="dicom_assoc_rel" messagetype="dicom:dicom Association Release"> </variables> The BPEL definitions start with the namespace specification which has to fit to the corresponding WSDL file. Afterwards the secondary partner and variables for every exchanged DICOM and HL7 message are defined. BPEL file for the DICOM / HL7 Second Opinion Request (Part 2)  <sequence>  <flow>  <switch>

8 <case WF_SO_REQ.hl7support=false>  </case> <case WF_SO_REQ.hl7support=true>  <switch>  <case WF_SO_REQ.emergency=true>  porttype="sosecondaryhl7port" operation="hl7 A04 register a patient" inputvariable="hl7_a04_rap" <correlation set="hl7_a04"> <receive partner="secondarysite" porttype="soprimaryhl7callbackport" operation="hl7 A04 acknowledge" inputvariable="hl7_a04_ack" <correlation set="hl7_a04"> </receive> </case> <case emergency=false>  porttype="secondaryopinionhl7port" operation="hl7 A01 admit visit notification" inputvariable="hl7_a01_avn"> <correlation set="hl7_a01"> <receive partner="secondarysite" porttype="primaryopinionhl7callbackport" operation="hl7 A01 acknowledge" inputvariable="hl7_a01_ack"> <correlation set="hl7_a01"> </receive> </case> </switch>

9 </switch>  </flow>  The second part of the file contains the workflow definition and starts with the sequence tag. Together with two flow tags the HL7 and DICOM support can be parallelized. Therefore the flow tag for the HL7 follows and a switch for the HL7 support and the emergency case are considered. Depending on these parameters the corresponding HL7 messages are exchanged using invoke and receive activities. The communication is synchronous like the protocol implementation. The ports are defined as callback ports to distinguish between acting and reacting behavior in the workflow. The following sample contains the rest of this BPEL file. BPEL file for the DICOM / HL7 Second Opinion Request (Part 3) <flow>  <switch>  > <case WF_SO_REQ.dicomsupport=false>  porttype="sosecondarydicomport" operation="dicom Association Request" inputvariable="dicom_assoc_req"> <correlation set="dicom_assoc"> <receive partner="secondarysite" porttype="soprimarydicomcallbackport" operation="dicom Association Response" inputvariable="dicom_assoc_resp"> <correlation set="dicom_assoc"> </receive> porttype="sosecondarydicomport" operation="dicom C-STORE" inputvariable="dicom_c-store"> <correlation set="dicom_c-store">

10 porttype="sosecondarydicomport" operation="dicom C-STORE Study End" inputvariable="dicom_c-store_study_end"> <correlation set="dicom_c-store"> porttype="sosecondarydicomport" operation="dicom Association Release" inputvariable="dicom_assoc_rel"> <correlation set="dicom_assoc"> </case>  </switch>  </flow>  </sequence>  </process> The DICOM part of the definition is similar to the HL7 specification. The operations are performed using invoke and receive activities and a switch distinguishes between protocol support. WSDL and BPEL definition of HL7/DICOM second opinion response Finally the third definition is provided. The WSDL and BPEL files for the Response Secondary Opinion part of the workflow are defined in this section. WSDL file for the DICOM / HL7 Second Opinion Response <! - DICOM / HL7 Workflow of Figure 13 -->  <definitions targetnamespace=" xmlns:hl7=" xmlns:dicom=" xmlns:ris=" >  <message name="hl7 R01 unsolicited observation message">

11 <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 R01 data" type="hl7_r01"> <message name="hl7 R01 acknowledge"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 R01 data" type="hl7_r01">  <porttype name="soprimaryhl7callbackport"> <operation name="hl7 R01 unsolicited observation message"> <input message="hl7 R01 unsolicited observation message"> <porttype name="sosecondaryhl7port"> <operation name="hl7 R01 acknowledge"> <input message="hl7 R01 acknowledge"> First the namespaces for the RIS, HL7 and DICOM parts are defined. Next the HL7 observation messages are defined. Finally two port types for the primary callback interface and the secondary interface are listed. Again the communication is synchronous, but this way it is easier to distinguish acting behavior in the workflow. Finally the workflow of the response is provided. BPEL file for the DICOM / HL7 Second Opinion Response  <process name="secondopinionresponse" targetnamespace=" xmlns=" xmlns:hl7=" xmlns:dicom=" xmlns:ris=" xmlns:lns="  <partners> <partner name="secondarysite" servicelinktype="soresponsesecondarysitelt" myrole="soresponsesecondarysiteuser"/> </partners>  <variables>

12 <variable name="hl7_r01_uom" messagetype="hl7:hl7 R01 unsolicited observation message"> <variable name="hl7_r01_ack" messagetype="hl7:hl7 R01 acknowledge"> </variables>  <flow>  <switch>  <case WF_SO_REQ.hl7support=false>  </case>  <case hl7support=true>  <receive partner="secondarysite" porttype="soprimaryhl7callbackport" operation="hl7 R01 unsolicited observation message" inputvariable="hl7_r01_uom"> <correlation set="hl7_r01"> </receive> porttype="sosecondaryhl7port" operation="hl7 R01 acknowledge" inputvariable="hl7_r01_ack"> <correlation set="hl7_r01"> </case>  </switch>  </flow>  </process> The workflow definition distinguishes the case of HL7 support, performs a R01 operation and requires its acknowledge. Again a callback port describes the communication direction. The partners and variables are consistent with the definitions above.

BPEL specification (Paper: Towards an Abstract Layered Model for Medical Services Workflows)

BPEL specification (Paper: Towards an Abstract Layered Model for Medical Services Workflows) In this section we provide a WSDL and BPEL specification for the second opinion workflow. The source code is