Modeling ad-hoc medical imaging workflows with BPEL4WS

Transcription

1 Modeling ad-hoc medical imaging workflows with BPEL4WS Rainer Anzböck 1, Schahram Dustdar 2, and Masoud Gholami 3 1, 3 D.A.T.A. Corporation, Invalidenstrasse 5-7/10, 1030 Wien, Austria {ar gm}@data.at 2 Distributed Systems Group, Vienna University of Technology Argentinierstrasse 8/184-1, 1040 Wien, Austria dustdar@infosys.tuwien.ac.at Abstract. Web services workflows are increasingly gaining attention. With the advent of emerging standards such as the Business Process Execution Language for Web Services (BPEL4WS) medical organizations are investigating the options for modeling ad-hoc workflows. In this paper we analyze a highly relevant ad-hoc workflow in the medical imaging domain: the second opinion workflow. Since this workflow, by its nature, involves other (increasingly ubiquitous) information systems (e.g. imaging equipment), it may serve as a test candidate for the applicability and suitability of BPEL4WS in the medical imaging domain. The workflow model covers implementation relevant aspects of the DICOM and HL7 protocol while maintaining an abstract domain model. The paper provides a separation of a basic workflow and the extended ad-hoc workflow. Further it abstracts the communication protocols by implementing sub-workflows for the service interfaces. The paper also analyzes mapping problems between the workflow and the communication layer and points out further ad-hoc workflow specifications for the medical imaging domain. 1 Introduction With recent work in the field of ad-hoc workflows it is possible to define more flexible business models than in traditional workflows based on the Workflow reference model (WFMC) [1]. With the standardization of the Business Process Execution Language (BPEL4WS, short BPEL) [2] a new implementation method for Web service based scenarios is available. The medical imaging domain is currently in a dynamic evolution to digitally connected networks. Standardization in the field of medical imaging has been covered by the HL7 [3] and DICOM [4] standards. A related standardization process for health informatics is enforced by the European Union with the CEN/TC 251 work program [5] which is out of the scope of this paper but is recognized as an important research area. The goal of this paper is to analyze a highly relevant ad-hoc workflow [6] in the medical imaging domain: the second opinion workflow. Since this workflow, by its nature, involves other (increasingly ubiquitous) information systems (e.g. imaging

2 equipment), it may serve as a test case for the applicability and suitability of BPEL in the medical imaging domain. The workflow model covers implementation relevant aspects of the DICOM and HL7 protocol while maintaining an abstract domain model. The contribution of this paper is as follows: First it introduces current research issues in loosely coupled ad-hoc workflow models and defines a formal basis for simple workflow pattern. Secondly, it provides a separation of a basic workflow and the extended ad-hoc (second opinion) workflow. In the next step it abstracts the communication protocols by implementing sub-workflows for the service interfaces. Furthermore we analyze mapping problems between the workflow and the communication layer and point out the relationships to ad-hoc workflow specifications for the medical imaging domain. Finally we provide a WSDL [7] and BPEL specification of the second opinion workflow. To summarize, our paper (i) analyzes the second opinion ad-hoc workflow in the medical imaging domain and analyzes the requirements for modeling such workflows, (ii) suggests flexible communication semantics not covered in recent work of workflow management and Web services technology and (iii) investigates whether the current BPEL definition is applicable and suitable for the medical imaging domain. The paper is structured as follows. Section 2 introduces ad-hoc workflows and provides definitions of workflow patterns. Section 3 provides an introduction to. Section 4 introduces the ad-hoc workflow and its ad-hoc mechanism required for modeling. Section 5 discusses the relationship between the workflow model and the implementation protocols and suggests a mapping terminology. It extends the discussion to current standardization processes. Section 6 concludes the results and provides information about related work. 2 Medical Imaging In this section a brief introduction to the medical imaging domain is provided. A more detailed discussion can be found in [8], [9], [10], [11] and [12]. Next, two sample workflows are introduced to be inspected further. 2.1 HIS, RIS and PACS Three systems, the HIS (Hospital Information System) [13], the RIS (Radiology Information System) [12] and the PACS (Picture Achieving and Communication system) [10] are the backbone of current information systems in the hospital and medical imaging environment, comparable to ERP (Enterprise Resource Planning) and SCM (Supply Chain Management) systems. The HIS is an enterprise-wide system mostly used for administrative tasks like patient and visit management, bed reservations, patient referrals, operation planning, other scheduling tasks and billing management. The RIS is a patient- management system required for all organizational tasks of a medical imaging facility (whether in- or outside a hospital) like examination scheduling, patient registration, worklist generation, examination control, report generation (using digital dictation equipment and speech recognition) report transcription and

3 transfer and billing management for insurance companies. As can be seen, both systems have overlapping tasks to fulfill, own on an enterprise the other on an office level. The second main software system in medical imaging is called PACS and is responsible for all image management tasks. It transfers patient data to examination facilities (modalities), announces finished procedures and stores, prints, burns CDs, archives or transfers the generated image data. 2.2 DICOM and HL7 The most relevant protocol standards for these applications are HL7 for the RIS and DICOM for the PACS. PACS and RIS both implement a workflow model and cover implementations of the standard. Both systems have to be tightly integrated to perform tasks efficiently. The DICOM 3 standard covers Client/Server communications used to exchange Patient and Examination information. The standard covers objects like patients, visits, medical procedures, images, films, printers, and examination modalities. Additionally, notifications, data query, and exchange services based on these objects are defined. The HL7 standard is used for data exchange between different healthcare providers and is more suited for non-radiological institutions. Some functionality overlaps with DICOM for example the scheduling process and the patient and result management. Other functionality such as the exchange of image data is not part of HL7. More detailed information on DICOM can be found in [14] and [15]. 2.3 Medical Imaging Workflow Figure 1 provides an overview on the main parts of the overall medical imaging workflow in UML [16], [17] Use-Case notation.

4 Fig. 1. Medical imaging use-cases follow medical and administrative tasks. The RIS supports nearly all of these tasks with proprietary implementations and through the DICOM and HL7 standards. It consists of seven different tasks regarding all aspects of a medical imaging facility. These interactions should now be modeled in ad-hoc workflows. A more detailed description can be found in [11], [12] and [13]. In this paper we focus on the patient registration and second opinion tasks to investigate further. The tasks should be modeled in BPEL and correspond to the responsibilities of the DICOM and HL7 standard as introduced above. The next section also relates the sample workflows to these communication protocols. In Figure 2 a closer look to the external environment is taken. It shows the relationship between two medical imaging facilities and a Hospital. Fig. 2. In the HIS/RIS and RIS/RIS environment several Use-cases are performed in a loosely coupled manner. The implementation use standard protocols, where HL7 is more HIS related and DICOM is more inter-ris related. The many-to-many relationship results from multiple facilities communicating with each other depending on the Use-case. The Radiology Information System (RIS) and Hospital Information System (HIS) are the major applications maintained in a Hospital and medical imaging facility environment. The two tasks are independent from each other and some facilities share both or none of them. Further the communication semantics implemented for the tasks can be different depending on the functionality of the HIS and RIS system (ex. DICOM

5 might be supported by a node or not). Both systems have to provide an interface based on the BPEL workflow definition. To create a workflow model using BPEL it is necessary to define separate services for patient registration and second opinion as shown in Figure 3 and 4. Fig. 3. In the patient registration workflow the HIS normally performs the service provider role and the RIS the service user role (this might change in special situations). Both applications implement a scheduling or registration module with a HL7 interface. For the patient registration normally the HIS application is the user and the RIS is the provider, rarely the reverse is the case. Additionally the Use-case has some specific scenarios where pre-registrations in case of emergencies are required. This paper concentrates on the second opinion Use-case and has to leave this discussion to further research. Fig. 4. In the patient registration workflow the HIS normally performs the service provider role and the RIS the service user role (this might change in special situations). Both applications implement a scheduling or registration module with a HL7 interface. For the second opinion the relationship is rather symmetric, therefore both partners play the roles of provider and user of the service. Further DICOM and HL7 are re-

6 quired for an efficient second opinion workflow. Because of its usefulness in quality management, the more homogenous environment and the precise requirements definition we choose this Use-case to investigate further. The next section provides a detailed description of an ad-hoc workflow model for this service. 3 AD-HOC Workflows In this section a brief introduction to ad-hoc workflows is provided. First we introduce the loosely coupled workflow model and current research topics for ad-hoc workflows. Then we provide a description and formal definition of common workflow pattern together with samples of our second opinion Use-case. This frame supports the definition of a workflow model in the next chapter. 3.1 Loosely coupled workflow model Figure 5 shows the loosely coupled workflow model, a model where each participant implements its own workflow. The model has been introduced and is described in more detail in [18] and [19]. Fig. 5. In the loosely coupled workflow model each participant implements its own workflow and maintains an infrastructure, like workflow engine, etc. At defined synchronization points work items can be exchanged to constitute an inter-organizational workflow. Additionally the workflows are connected on certain points of interaction. In an adhoc environment the participants should be selected dynamically leading to a more flexible way of interaction. To allow for a dynamic assignment, the process definition has to be stored as a template as introduced in [18] and evaluated in [20]. The template defines the process states, activities and roles of the workflow. When the process is instantiated a specific participant is chosen for a role in the workflow. For example the radiologist generating the report for a specific case is dynamically selected based on availability, expertise on the case and other modeled attributes of the activity. All attributes, connection parameters, etc. should be stored as metadata in the messages of a service specification. Another advantage over traditional workflow models is the extension of models through escalations [20]. An escalation defines additional activities and is inserted into the process model at certain escalation points. It can be triggered by a participant that is defined as an expert with respect to the process definition (ex. a radiologist for

7 requesting a second opinion on a case). Escalations extend the running process instance and participants filling the roles that perform the activities are again dynamically assigned. These extensions are also based on the WFMC reference model and extend the model with dynamic aspects. In [20] it is concluded that current workflow systems don t support dynamic assignment of participants or extensions of workflow instances. Therefore a complete new framework has been designed on top of a WFMC reference model implementation. It should be assumed that extensions to the reference model are required to provide ad-hoc semantics. The system environment for medical imaging workflows has to be investigated further, but is out of the scope of this paper. An event-based approach to extend the reference model with dynamic aspects is suggested in [21]. 3.2 Workflow pattern The workflow patterns (also called control flow constructs) used in this paper correspond to the taxonomy proposed in [22] and [23]. As an introduction we provide the formal definition of the Standard Workflow Model as defined in [24]. A Standard Workflow Model is a tuple W = p J, J, S, S, A, T N where P is a set of process ( ), o 1 a 1 o 1 a 1, elements which can be further divided into disjoint sets of OR-Joins J o1, AND- Joins J a1, XOR-Splits S o1, AND-Splits S a1, and activities A; Trans T P P is a transition relation between process elements and A N N is a function assigning names to activities taken from some given set of names N containing special label λ. (1) Based on this definition we examine simple workflow pattern introduced in [24]. The simple start, end and sequence pattern are described in Figure 6. Fig. 6. On the left side the basic workflow pattern sequence, initial activity and final activity are shown; to the right samples from a patient examination and diagnosis workflow. The diagnosis starts with finishing the examination and ends with the final diagnosis. Between a preliminary and secondary diagnosis can be created. For these workflow patterns we additionally provide a formal definition that references to the Petri-net notation of Figure 6.

8 Sequence ( S ): Sequence transition: Initial activity: Initial places: Final activity: Final places: { a, b } P, in ( l, ) { a }, out l ) { b } T s l a, b in T a b = =, T { L a trans b } s a, b ( l, ) { r }, { r a } P r a = (, (2) a b = = (3),, S S I, out l ) { a } = { L r trans a }, P { r x I } s I r, a P I r I x (, (4) r a = =, a P, S M S, a P, m P M (6) P M = { r x M }, T { L a trans m } x S M a, m (5) = (7) (2): A sequence S consists of a and b, both elements of the set of Petri-net places P. The in-operation contains all elements of the places set where there is a link l a,b to a transition t. The out-operation contains all elements of the places set where there is a link l a,b from a transition t. The in-operation of l a,b therefore contains element a and the out-operation element b. (3): The sequence transition T consists of the links between a and b. (4+5): The initial activity is a special Sequence with an in-operation set that consists of elements from the set of initial places P I (similar for transitions). (6+7): The final activity is a special Sequence with an out-operation set that consists of elements from the set of finale places P M (similar for transitions). Basic workflow pattern describe simple flows of control. Sequences are used for activities that occur in a specific order. Initial and final activities are start and end points in the workflow. The samples correspond to the workflow introduced in section 4. Beside the basic structures the flow can also be controlled through XOR and OR split and join operations, which will be described next, see Figure 7. Fig. 7. On the left side the XOR Split pattern is shown. On the right side a sample from a patient examination and diagnosis workflow is provided. Depending on an emergency attribute, different patient registration processes are performed. Again we provide a formal definition for this workflow pattern that references to the Petri-net notation of Figure 7. XOR-Split ( S o ): S S 01 o, o 1 S { a b, c } P, (8)

9 ( S 1 ) { a }, out ( S o 1 ) = { b } { c } X y out ( S ) { t t } in o = { } T S 1 S 1, y o 1 = 1, o o t 1 = X S o 1, b t 2 = X S o 1, c =, (8): The XOR Split S 0 is defined with an in-operation of element a and an outoperation with elements b or c (exclusively). The set of transitions T s0 consists of two elements, one for the transition a-b and one for a-c. The XOR Split is defined as a point in the workflow process where, based on a decision or workflow control data, one of several branches is chosen [22]. A sample for this construct is the split after a finish examination where a preliminary diagnosis is created before a second opinion is required (see also Section 4). Corresponding to the Split an OR join control flow construct is defined as shown in Figure 8. 2 Fig. 8. On the left side the OR Join pattern is shown. On the right side a sample from a patient examination and diagnosis workflow is provided. After the registration of a patient multiple execution threads are converged. The formal definition for the Petri-net notation of Figure 8 is as follows. OR-Join ( J o ): J o 1 J o { a, b, c } P, T = { Q x J y in ( )} J o x, y o x ( J 1 ) = { a } { b }, out ( J o 1 ) = { c } = { Q y in ( J ) { t t } in o T J 1 J 1, y o 1 = 1, o o t = Q, 1 J t = o 1, b 2 Q J o 1, a 2 (9) (9): The OR Join J 0 is defined with an in-operation of element a or b and an outoperation with element c. The set of transitions T J0 consists of two elements, one for the transition a-c and one for b-c. This definition can be extended to multiple input places. The OR join is defined as a point in the workflow process where two or more alternative branches come together without synchronization. In other words the merge will be triggered once any of the incoming transitions are triggered [22]. The next construct is the AND split as shown in Figure 9.

10 Fig. 9. On the left side the AND Split pattern is shown. On the right side a sample from a patient examination and diagnosis workflow is provided. When requesting a second opinion there is a DICOM and a HL7 thread, both can be executed in parallel. The formal definition for the Petri-net notation of Figure 9 is as follows. AND- Split ( S a ): S S a 1 a, { a, b, c } P ( S 1 ) { a }, out ( S a 1 ) = { b, c } in a = T s a { R S S } = S 1 a 1 a 1 a, t 1 = r S a 1 (10): The AND Split S a is defined by an in-operation that consists of the element a and an out-operation that consists of the elements b and c. S a has only one transition t 1 from a to b and c. The AND Split can be described as a point in the workflow process where a single thread of control splits into multiple treads of control which can be executed in parallel, thus allowing activities to be executed simultaneously or in any order [22]. Finally the corresponding AND Join is shown in Figure 10. (10) Fig. 10. On the left side the AND Join pattern is shown. On the right side a sample from a patient examination and diagnosis workflow is provided. When requesting a second opinion there is a DICOM and a HL7 thread, both can be executed in parallel. The formal definition for the Petri-net notation of Figure 10 is as follows. AND- JOIN ( J a ): J T J a 1 a, { a, b, c } P J = K a Ja J a 1 J a { } 1, t 1 = K J a 1 (11)

11 (11): The AND Join J a is defined by an in-operation that consists of the elements a and b an out-operation that consists of the element c. J a has only one transition t 1 from a and b to c. The AND Join can be described as a point in the workflow process where multiple parallel sub-processes/activities converge into one single thread of control, thus synchronizing multiple threads. In this section we provided an overview of ad-hoc workflow and basic workflow pattern. These constructs will be used for defining a workflow model in section 4 and a BPEL specification in section 5. 4 Second opinion workflow In this section we describe the second opinion ad-hoc workflow. The definition is based on UML activity diagrams as a well understood technique. In respect to a BPEL implementation there is currently no generally used graphical notation of workflows. Several different semantics are found in the literature. All of them have some limitations and use syntactical extensions to define workflow behavior. Such extensions (ex. branch conditions) are also used here. Requirements for and a detailed analysis of pros and cons of modeling techniques can be found in [6] and [24]. The second opinion scenario is chosen, because it is currently discussed, addresses quality management and the support for the DICOM and HL7 standards is well defined and can be interrelated by mapping protocol messages to the workflow model. In the scenario for a second opinion, two medical imaging facilities perform an ad-hoc workflow process. First an institution implements its own workflow for performing a diagnosis on a patient. In certain complicate cases, the radiologist decides to request a second opinion on a case. This ad-hoc behavior can also be compared to the escalation scenario described in [20]. 4.1 Second opinion workflow activities The basis workflow and the ad-hoc extension are shown in Figure 11. The second opinion workflow is executed between two medical imaging facilities. One is the initiator (RIS Site 1) or user the other one is the provider (RIS Site 2) of the second opinion. The required data exchange is handled by the DICOM and HL7 protocol. Of special interest is also the mapping between the workflow model in Figure 11 and the protocol implementation shown in Figures 12 and 13. First this mapping creates a hierarchical workflow model, where the activities in Figure 11 form super-activities (like super-states in terms of state diagrams) of the protocol communication in the other Figures. Further, a second opinion case requires a workflow implementation for each RIS site. In real-world scenarios one has to deal with legacy applications and equipment that is not workflow-aware, but support DICOM and HL7 protocols. For those scenarios proxy mechanisms should be used to

12 simulate workflow behavior. We recognize these topics as import research areas, which are out of the scope of this paper. Fig. 11. The second opinion workflow consists of a local workflow (along the no decision in the second opinion branch) and an ad-hoc workflow between both sites in the other case. In both cases a diagnosis for a patient examination is created and the workflow continues seamlessly. Next we describe the workflow activities and point out workflow pattern as suggested in [22] and [23]. The patterns also help specifying the workflow in BPEL and will therefore be reused in section 5. Of special interest is the modeling as a BPEL request/reply construct and the definition of a split and a merge in the workflow model that is also correspondingly supported in BPEL [25]. The standalone part of the workflow is executed within a medical imaging facility and corresponds to a local RIS functionality. As an extension it is possible to split the create diagnosis activity and perform a preliminary step that is later merged with results from the second opinion workflow. In Figure 11 after the first activity finish examination there is a pattern called Exclusive Choice (one of several branches is chosen). This pattern is referenced as WP4 (Workflow Pattern) in [22]. The booleanvalued branch condition is based on an attribute second opinion necessary that can be mapped to a corresponding BPEL transition condition. The user of the RIS application

13 decides to instantiate a second opinion workflow case by case. Such metadata is part of the message exchange and is used as routing information in a Web service based implementation. Further and not shown here the second opinion workflow can be executed several times per case with different business partners. At another point down in the diagram, before the create final diagnosis activity, there is a pattern called Simple Merge (WP5 - two or more alternative branches come together without synchronization). After execution of the second opinion the workflow process continues as in the non ad-hoc scenario by creating a final diagnosis on the case. Another control flow between activities is called Sequence (WP1 - activity enabled after the completion of another activity in the same process). Such sequences are the standard pattern and used throughout the scenario. For example the create second opinion and response second opinion are sequentially, the results of the first activity are inputs in the next processing step. 4.2 Second opinion request activities Figure 12 and 13 show the details of the HL7 and DICOM message exchange in this workflow. Two phases of interactions occur. In the first phase the patient and image data is provided to RIS Site 2, while in the second phase the diagnosis results are sent back to RIS Site 1. The DICOM and HL7 messages are defined in the standard documents [3], [4]. The selection of the messages has also been based on realworld scenarios already found in data exchange of industry products like Tiani [26] and D.A.T.A. [27]. Again, the used workflow patterns are directly supported by BPEL constructs. What makes this model different from just specifying a message exchange is that these messages are already grouped together meaningfully and can be reused in other BPEL service links. In the first phase (Figure 12) RIS Site 1 communicates patient information using HL7 patient registration messages. The images are transmitted using the DICOM C-Store service class implementing a Client/Server model.

14 Fig. 12. The first detailed view of Figure 11 shows the message exchange between the request second opinion and create second opinion activities of the workflow. The HL7 and DICOM protocols are used to transfer patient and image data between both sites. Depending on the protocol support different interaction scenarios are implemented. In Figure 12 the first point after the activities request second opinion is a Parallel Split (WP2 - single thread splits into threads executed in parallel). The HL7 and DICOM activities are allowed to be executed simultaneously and in any order. The branch conditions use boolean-valued expressions for the protocol support of the implementation. The workflow model also works without one of these protocols. Additionally it is possible to define a proprietary protocol providing the same semantic behavior pointed out for the high-level view. At point emergency there is an Exclusive Choice (WP4) using a corresponding expression. Depending on the case more or less detailed patient information is provided for the remote site. In case of emergency only

15 a short pre-registration tasks place. Between the HL7 A01 acknowledge and HL7 A04 acknowledge activities there is a Simple Merge (WP5) unifying these cases. Afterwards there is a Synchronization point (WP3 - multiple parallel branches converge synchronizing multiple threads). The HL7 and DICOM message exchange is synchronized before proceeding creating a second opinion. All other control flows are of the simple pattern type Sequence (WP1). 4.3 Second opinion response activities Figure 13 contains details of the second part of the workflow. The second opinion created by RIS Site 2 is communicated using HL7 observation messages. The DICOM protocol is not required in this scenario. The scenario could be extended to consider image annotations created during the second opinion process on the remote site. Fig. 13. A further detailed view of Figure 11 shows the message exchange between the response second opinion and merge second opinion activities of the workflow. Because results for a diagnosis are provided in text format only the HL7 protocol is most appropriate for this situation. Next we will examine the workflow pattern. In Figure 13 at the first point between activities response second opinion and HL7 R01 unsolicited observation message there is an Exclusive Choice (WP4) pattern. Depending on the protocol support the

16 HL7 protocol is used. Again proprietary protocols can be implemented in accordance to the workflow model. At another point, shown before the merge second opinion activity, there is a Simple Merge (WP5) that synchronizes the cases of protocol support. All other control flows are Sequence pattern (WP1). For example the HL7 A01 admit visit notification and the HL7 A01 acknowledge build such a pattern. As a conclusion the second opinion workflow can be described using UML activity diagrams. A two level hierarchy with one overview and two detail flows has been defined. In the next section a BPEL specification is provided for the second opinion workflow. 5 BPEL implementation In this section we provide a BPEL definition of the second opinion workflow. An introduction to BPEL and its terminology is given. We further provide sample mappings between activity diagrams and BPEL code for higher readability and an annotated BPEL and WSDL specification. Because WSDL defines the structure and BPEL the flow of data exchange both definitions are required to provide a good understanding of the workflow model s formal description. 5.1 Introduction and Terminology BPEL has been designed for modeling workflows. It additionally focuses on current Web service based environments and is based on XML notation and WSDL service descriptions as well understood concepts. In workflow terminology BPEL defines activities and their relationship in a flow style of XPath [28] or a directed graph style of WSFL [29]. Several language constructs for branching and merging are provided that support the pattern used in the second opinion workflow definition. BPEL defines the partners interacting in a workflow, the services and the roles each partner has. Business processes specified via BPEL prescribe the exchange of messages between Web services. These messages are WSDL messages of operations of the port types involved in the roles of the service links established between the process and its partners [17]. For a better orientation we shortly introduce major terms used in the WSDL and BPEL specification. Partners, Roles, Port Types and Service Link Types WSDL and BPEL define business partners that provide and consume services and can take several roles in a workflow model. Services partition the workflow model of partners and their activities normally into two or more partners and one or more activities. The port types (service interfaces) are defined by operations and the exchange of messages. Normally services use producer/consumer or client/server semantics, leading for example to a producer and consumer port definition and a client and server role. A service link type relates such services to the workflow model. It defines which

17 business partner performs which role and the port types it communicates through. During runtime specific ports, corresponding to a port type, are used to define additional connection parameters, security properties, etc. What s sometimes misleading is that WSDL provides interface definitions through port types and service link types. The services themselves are not explicitly defined. Operations, Messages, Context Each port type defined in a WSDL file consists of one or several operations performed between the partners. The flow of operations is defined in the BPEL file. An operation consists of one or more input and output messages. Each message consists of workflow data and context data for security, transactions, etc. Variables, Expressions, Conditions, Correlations Variables are used to store message data of stateful workflow interactions. X-Path [30] like expressions (boolean, deadline-based, general) can be defined using variable definitions. These expressions can be used for branch conditions and other dependent operations. Message parts can be correlated by defining relations between variables in two or more messages. The variable content can also be copied for message ID-like semantics. Simple and complex activities Activities are the building blocks of the BPEL workflow definition. Simple activities like receive, reply, invoke, wait define communication pattern for initiating or waiting for operations, time triggered operations, etc.; further more are defined. Complex activities like flow (for ordering activities), link (for graph-like linking of activities), scope (for grouping activities), sequence, switch and while (for flow control) provide workflow pattern for relating simple activities. 5.3 BPEL patterns With BPEL we have a basis for a detailed workflow specification. However BPEL doesn t provide a graphical representation and common representations for workflows have their pros and cons [6], [24]. We have chosen activity diagrams because it is well understood and supports BPEL language constructs. We are therefore able to derive BPEL language pattern from the workflow pattern identified in section 4. We provide a short pattern analysis as suggested in [25]. The approach chosen here suggests that the mapping of workflow patterns can be automated. Such automation would enhance integrity and consistency of the workflow model and its implementation specification similar to techniques used for class diagrams in software development.

18 AND Split and Join pattern, flow construct The first patterns we examine is the AND Split and the AND Join. As shown in Figure 12 such constructs are used to execute the DICOM and HL7 implementation in parallel. The BPEL language provides the flow statement to define this relationship between activities. Figure 14 compares the workflow patterns with the BPEL construct. <! AND Split --> <flow> <!-- HL7 flow --> </flow> <flow> <!-- DICOM flow --> </flow> Fig. 14. shows a sample comparison of AND Split and AND Join workflow patterns and the BPEL flow construct. The sample shows the split for HL7 and DICOM protocol support. The corresponding BPEL file consists of two parallel flows for each implementation. On the left side the workflow patterns enable parallel execution of tasks. This functionality is reached using the flow construct in BPEL. In our case the HL7 and DICOM support are executed in parallel. The constructs are used like in programming languages and can be nested, have conditions, etc. XOR Split and OR Join pattern, switch construct The next patterns compared are the XOR Split and OR Join. As shown in Figure 12 such constructs are used to specify DICOM and HL7 protocol support. The BPEL language provides the switch statement to define this relationship between activities. Figure 15 compares the workflow patterns with the BPEL construct. <switch> <!-- switching HL7 support --> <case hl7support=false> <!-- HL7 flow empty --> </case> <case hl7support=true> <!-- HL7 flow continues --> </case> </switch> <!-- HL7 support --> Fig. 15. shows a sample comparison of XOR split and OR join workflow patterns and the

19 BPEL switch construct. The sample describes the alternative threads for a registration of a patient in case or without an emergency. The BPEL file implements this behavior with the switch construct. On the left side the workflow patterns enable exclusively one execution of two or more tasks. This functionality is reached using the switch construct in BPEL. In our case depending whether HL7 is supported by the application or not the corresponding workflow functionality is executed. 5.4 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 <!-- HIGH-LEVEL Workflow of Figure 11 --> <!-- WSDL definition --> <definitions targetnamespace=" xmlns:wf=" <!-- message definitions --> <message name="request Second Opinion"> <part name="wf SO metadata" type="wf_so_meta"> <part name="wf SO data" type="wf_so"> </message> <message name="response Second Opinion"> <part name="wf SO metadata" type="wf_so_meta"> <part name="wf SO data" type="wf_so"> </message> > <!-- port type definitions (SO abbreviates second opinion) -- <porttype name="sosecondarywfport"> <operation name="request Second Opinion">

20 <input message="request Second Opinion"> </operation> </porttype> <porttype name="soprimarywfcallbackport"> <operation name="response Second Opinion"> <input message="response Second Opinion"> </operation> </porttype> <!-- service link type definitions --> <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 <!-- BPEL definition --> <process name="secondopinion" targetnamespace=" xmlns=" xmlns:wf=" xmlns:lns=" <!-- partner definitions --> <partners> <partner name="secondarysite" servicelinktype="secondaryopinionlt" myrole="soprimary"

21 partnerrole="sosecondary"/> </partners> <!-- variable definitions --> <variables> <variable name="wf_so_req" messagetype="wf:request Second Opinion"> <variable name="wf_so_resp" messagetype="wf:response Second Opinion"> </variables> <!-- workflow definition --> <sequence> <! - serializing request / response messages --> <invoke partner="secondarysite" porttype="sosecondarywfport" operation="request Second Opinion" inputvariable="wf_so_req"> <correlations> <correlation set="wf_so"> </correlations> </invoke> <invoke partner="secondarysite" porttype="soprimarywfcallbackport" operation="response Second Opinion" inputvariable="wf_so_resp"> <correlations> <correlation set="wf_so"> </correlations> </invoke> </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. 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.

22 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 --> <!-- WSDL definition --> <definitions targetnamespace=" xmlns:hl7=" xmlns:dicom=" xmlns:ris=" <!-- message definitions --> <message name="hl7 A04 register a patient"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A04 data" type="hl7_a04"> </message> <message name="hl7 A04 acknoledge"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A04 data" type="hl7_a04"> </message> <message name="hl7 A01 admit visit notification"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A01 data" type="hl7_a01"> </message> <message name="hl7 A01 acknoledge"> <part name="ris HL7 metadata" type="ris_hl7"> <part name="hl7 A01 data" type="hl7_a01"> </message> <message name="dicom Association Request"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom Association Request data" type="dicom:associationrequest"> </message> <message name="dicom Association Response"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom Association Response data" type="dicom:associationresponse"> </message> <message name="dicom C-STORE">

23 <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom C-STORE data" type="dicom_cstore"> </message> <message name="dicom Study End"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom Study End data" type="dicom_studyend"> </message> <message name="dicom Association Release"> <part name="ris DICOM metadata" type="ris_dicom"> <part name="dicom Association Release" type="dicom_associationrelease"> </message> 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) <!-- port type definitions (SO abbreviates second opinion) --> <porttype name="sosecondaryhl7port"> <operation name="hl7 A04 register a patient"> <input message="hl7 A04 register a patient"> </operation> <operation name="hl7 A01 admit visit notification"> <input message="hl7 A01 admit visit notification"> </operation> </porttype> <porttype name="soprimaryhl7callbackport"> <operation name="hl7 A04 acknoledge"> <input message="hl7 A04 acknoledge"> </operation> <operation name="hl7 A01 acknoledge"> <input message="hl7 A01 acknoledge"> </operation> </porttype> <porttype name="sosecondarydicomport"> <operation name="dicom Association Request"> <input message="dicom Association Request"> </operation> <operation name="dicom C-STORE"> <input message="dicom C-STORE"> </operation> </porttype>

24 <porttype name="soprimarydicomcallbackport"> <operation name="dicom Association Response"> <input message="dicom Association Response"> </operation> </porttype> <!-- service link type definitions --> <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) <!-- BPEL definition --> <process name="secondopinionrequest" targetnamespace=" xmlns=" xmlns:hl7=" xmlns:dicom=" xmlns:ris=" xmlns:lns=" <!-- partner definitions --> <partners> <partner name="secondarysite" servicelinktype="sorequestsecondarysitelt" myrole="sorequestsecondarysiteuser"/>

25 </partners> <!-- variable definitions --> <variables> <variable name="hl7_a04_rap" messagetype="hl7:hl7 A04 register a patient"> <variable name="hl7_a04_ack" messagetype="hl7:hl7 A04 acknoledge"> <variable name="hl7_a01_avn" messagetype="hl7:hl7 A01 admit visit notification"> <variable name="hl7_a01_ack" messagetype="hl7:hl7 A01 acknoledge"> <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) <!-- workflow definition --> <sequence> <!-- parallelizing of DICOM and HL7 support --> <flow> <!-- HL7 flow --> <switch> <!-- switching HL7 support --> <case WF_SO_REQ.hl7support=false> <!-- HL7 flow empty --> </case> <case WF_SO_REQ.hl7support=true> <!-- HL7 flow continue --> <switch> <!-- switching emergency --> <case WF_SO_REQ.emergency=true> <!-- HL7 emergency flow --> <invoke partner="secondarysite" porttype="sosecondaryhl7port" operation="hl7 A04 register a patient" inputvariable="hl7_a04_rap" <correlations> <correlation set="hl7_a04"> </correlations> </invoke> <receive partner="secondarysite"

26 porttype="soprimaryhl7callbackport" operation="hl7 A04 acknoledge" inputvariable="hl7_a04_ack" <correlations> <correlation set="hl7_a04"> </correlations> </receive> </case> <case emergency=false> <!-- HL7 normal flow --> <invoke partner="secondarysite" porttype="secondaryopinionhl7port" operation="hl7 A01 admit visit notification" inputvariable="hl7_a01_avn"> <correlations> <correlation set="hl7_a01"> </correlations> </invoke> <receive partner="secondarysite" porttype="primaryopinionhl7callbackport" operation="hl7 A01 acknoledge" inputvariable="hl7_a01_ack"> <correlations> <correlation set="hl7_a01"> </correlations> </receive> </case> </switch> <!-- emergency --> </switch> <!-- hl7support --> </flow> <!-- HL7 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> <!-- DICOM flow --> <switch> <!-- switching DICOM support --> > <case WF_SO_REQ.dicomsupport=false> <!-- DICOM flow empty -- </case>

27 <case dicomsupport=true> <!-- DICOM flow continues --> <invoke partner="secondarysite" porttype="sosecondarydicomport" operation="dicom Association Request" inputvariable="dicom_assoc_req"> <correlations> <correlation set="dicom_assoc"> </correlations> </invoke> <receive partner="secondarysite" porttype="soprimarydicomcallbackport" operation="dicom Association Response" inputvariable="dicom_assoc_resp"> <correlations> <correlation set="dicom_assoc"> </correlations> </receive> <invoke partner="secondarysite" porttype="sosecondarydicomport" operation="dicom C-STORE" inputvariable="dicom_c-store"> <correlations> <correlation set="dicom_c-store"> </correlations> </invoke> <invoke partner="secondarysite" porttype="sosecondarydicomport" operation="dicom C-STORE Study End" inputvariable="dicom_c-store_study_end"> <correlations> <correlation set="dicom_c-store"> </correlations> </invoke> <invoke partner="secondarysite" porttype="sosecondarydicomport" operation="dicom Association Release" inputvariable="dicom_assoc_rel"> <correlations> <correlation set="dicom_assoc"> </correlations> </invoke> </case> <!-- DICOM flow continues --> </switch> <!-- switching DICOM support -- > </flow> <!-- DICOM flow --> </sequence> <!-- parallelizing of DICOM and HL7 support --> </process>