Healthcare Processes

The current issue and full text archive of this journal is available at www.emeraldinsight.com/1463-7154.
htm
BPMJ 17,4
Modeling healthcare processes as service orchestrations and choreographies

Morad Benyoucef, Craig Kuziemsky, Amir Afrasiabi Rad and Ali Elsabbahi
Telfer School of Management, University of Ottawa, Ottawa, Canada
Abstract
Purpose Service-oriented architecture is becoming increasingly important for healthcare delivery as it assures seamless integration internally between various teams and departments, and externally between healthcare organizations and their partners. In order to make healthcare more efcient and effective, we need to understand and evaluate its processes, and one way of achieving that is through process modeling. Modeling healthcare processes within a service-oriented environment opens up new perspectives and raises challenging questions. The purpose of this paper is to investigate one of these questions, namely the suitability of web service orchestration and choreography, two closely related but fundamentally different methodologies for modeling web service-based healthcare processes. Design/methodology/approach The authors use a case-based approach that rst developed a set of 12 features for modeling healthcare processes and then used the features to compare orchestration and choreography for modeling part of the scheduled workow. Findings The ndings show that neither methodology can, by itself, meet all healthcare modeling requirements in the context of the case study. The appropriate methodology must be selected after consideration of the specic modeling needs. The authors identied usability, capabilities, and evolution as three key considerations to assist with selection of a methodology for healthcare process modeling. Further, sometimes one method will not meet all modeling needs and hence the authors recommend combining the two methodologies in order to harness the benets of modeling healthcare processes in a service-oriented environment. Originality/value Although literature exists on process modeling of web services for healthcare, there are no criteria describing necessary features for micro-level modeling, nor is there a comparison of the two leading service composition methodologies within the healthcare context. This paper provides some necessary formalization for process modeling in healthcare. Keywords Healthcare, Process modeling, Web service, Orchestration, Choreography, Work ow, Internet Paper type Research paper
568
Business Process Management Journal Vol. 17 No. 4, 2011 pp. 568-597 q Emerald Group Publishing Limited 1463-7154 DOI 10.1108/14637151111149438
1. Introduction Healthcare delivery is becoming increasingly complex as it shifts from care delivered by a single provider and setting to collaborative care delivered by multiple providers across multiple settings. The Institute of Medicines (2001) study Crossing the Quality Chasm claims that team-based care delivery is the future of healthcare and healthcare system redesign includes effective use of information technology (IT) and coordination of care across patient conditions, services, and sites of care over time (The Committee on Quality of Healthcare in America of the Institute of Medicine, 2001). Yet, current healthcare systems are not designed to support integrated team-based care delivery that spans multiple providers and settings. IT is set to play a signicant role in coordinating healthcare teams who are often separated by time and space.
However, introducing IT into healthcare has proven to be challenging owing to the underlying complexity of healthcare processes and the number of actors involved in those processes (Berg, 2003). Nevertheless, healthcare delivery is becoming more digitized as physical processes are being replaced and supported by electronic means. An informatics axiom says that before we can automate something we need to model it (Berg and Toussaint, 2003). Thus, we need to do a better job of modeling healthcare delivery before we can design IT to support it. However, modeling healthcare delivery is complex as there are different aspects of it which can be modeled. Healthcare delivery can be represented as a continuum that moves from micro-level to macro-level (Balka, 2003). The macro-level represents system level processes such as patient ows through a hospital or through an emergency unit; while the micro-level represents processes at the individual patient care level. Although they are interrelated, the micro- and macro-levels require different modeling approaches owing to the different levels of granularity between them. While we have made signicant progress at modeling the macro-level, examples being simulation and Markov models, we are far less advanced at micro-level modeling using formalized methodologies and languages. As we redesign the healthcare system and design IT to support it, we need to move from delivering individual products to delivering integrated services (Coiera and Hovenga, 2007). From the perspective of healthcare IT, this means moving away from developing IT for separate tasks (e.g. decision support, order entry) to developing integrated systems that support the continuity of healthcare delivery over time. The service-oriented architecture (SOA) paradigm and its ability to connect multiple systems across different settings is a candidate for developing integrated healthcare IT to support micro-level team-based care delivery across different settings. Before we can develop SOA-based systems to support team-based healthcare, we need to model micro-level healthcare delivery to identify its automation needs. Existing research on SOA in healthcare has largely looked at technical and interoperability aspects of SOA implementation such as Mykkanen et al. (2007). Anzbock and Dustdar (2005) developed a modeling process for medical web services, but their work focused on technical aspects of modeling and middleware development for implementing web services. Existing research has enhanced our ability to design SOA architectures that are interoperable at the system or technical level but there is still a need to develop approaches for SOA modeling to represent micro-level healthcare delivery. In other words, we need to make sure we can develop systems that are interoperable at the work process level. A rst step to achieving that is to model healthcare delivery using different web service methodologies and languages to assess the modeling capabilities of these languages. That would enable us to answer basic questions such as how do we know a web service composition methodology is suitable for modeling a particular scenario? Essentially, we see three shortcomings with existing process modeling research in healthcare. First, is that much of the existing micro-level modeling has involved ad hoc models rather than formal methodologies and languages. Second, existing SOA research in healthcare has focused on technical interoperability and implementation and not modeling the actual healthcare processes. Third, there are no criteria for evaluating the suitability of web service methodologies or their languages for modeling micro-level healthcare processes.
Modeling healthcare processes 569
BPMJ 17,4
570
The overall objective of this paper is to address the above three shortcomings in order to enhance our ability to model web services to support healthcare delivery. Specically, we investigate the suitability of web service orchestration and choreography, two closely related but fundamentally different methodologies for modeling micro-level healthcare processes and data ows in a service-oriented environment. We provide both theoretical and practical results in order to achieve our objective. We dene 12 essential features necessary for modeling micro-level care processes (theoretical contribution). We then use the 12 features to illustrate the strengths and weaknesses of orchestration and choreography and their languages for modeling a case study scenario (practical contribution). The paper is organized as follows. Sections 2 and 3 present relevant literature. Section 2 discusses business process modeling (BPM), both in general and in healthcare, and also discusses the leading web service composition methodologies, orchestration, and choreography along with their associated languages. Section 3 discusses modeling requirements for micro-level healthcare information systems (HIS) and introduces the Integrating the Healthcare Enterprise (IHE) initiative. Section 4 presents our ndings. First, we propose a set of three categories and 12 features for modeling healthcare processes (theoretical contribution). Second, we use an IHE case study which is representative of micro-level healthcare processes and compare the modeling capabilities of orchestration and choreography (practical contribution). The comparison is based upon the 12 features from Section 3. Implications of our ndings are discussed in Section 5, and concluding remarks are presented in Section 6. 2. BPM meets web service composition In this section, we provide a background on BPM in the context of web service composition both in general and in healthcare. We then introduce, compare, and contrast the concepts of web service orchestration and choreography and briey introduce the leading web service composition languages. 2.1 Business process modeling As an extension of classical workow management systems and approaches (Van Der Aalst et al., 2003), BPM includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational business processes. While BPM addresses how organizations identify, model, develop, automate, execute, and manage business processes, whether they involve IT systems, human interactions or both, business process management systems provide the technologies and standards used to implement and/or support one or more of these BPM core functions (Newcomer and Lomow, 2005). BPM is known to increase employee productivity and to reduce operational costs by automating and streamlining business processes. It helps reduce development cost and effort by offering high-level graphical modeling languages that allow business analysts and technical developers to quickly build and update IT systems within a particular domain of activity (LANDesk Software Ltd, 2006). Organizations typically use diverse applications supported by various technologies. Sharing information among those applications can be difcult due to the differences between technology platforms and data models. However, moving to a combination of BPM, SOA, and web services introduces a service layer consisting of:
. .
line of business services that can be aligned on a particular business domain; reusable technical services that can be delivered and shared across multiple business domains; and a web services platform that permits the denition and utilization of services independently from the underlying application and the technology platform.
What makes this combination unique is that it lets organizations explicitly separate business process logic from other business rules (Menon and Mishra, 2007). This is in contrast with other forms of systems development where the process logic is deeply embedded in the code of the application. In fact, separating the process logic from business rules and representing business processes in a form that is easy to change and maintain allow organizations to be more agile and exible by quickly responding to market changes and seizing competitive advantage (Behara, 2006). Another benet of the combination is the reduction of the impedance mismatch between IT systems and business requirements, allowing business users to model business processes and then have the IT department provide the infrastructure to execute and control these processes. 2.2 BPM in healthcare BPM has been used in healthcare to help us represent healthcare processes so we can design systems to support those processes. Jun et al. (2009) point out that a better application of process modeling is needed to provide safe, effective, timely, and patient-centered healthcare services. Process modeling (particularly simulation models) has been helpful for evaluating and understanding healthcare processes at the macro-level by developing models such as bed usage and emergency room (ER) ows (Mohamed and Alkhamis, 2009, Sobolev et al., 2008). However, micro-level modeling at the individual patients level is far less advanced. One possible reason is the difculty of micro-level modeling compared to macro-level modeling. Micro-level models require explicit details about the data and communication ows that take place across processes and healthcare providers. An example of micro-level modeling is the work of Malholtra et al. (2007) who developed a comprehensive model of the providers, activities, and data ows in the intensive care unit in order to identify, characterize, and reduce medical errors in that unit. But one shortcoming with their work is that it was ad hoc and did not use a formal modeling language or methodology, which makes it difcult to implement. With ad hoc and non-standard models, it is not easy to identify specic metrics or best practices that can be considered for implementing such models. Another requirement of BPM in healthcare is the need to design models to serve multiple purposes including systems design, education, evaluation of best practices, and communicating domain details between designers and stakeholders (Laguna and Marklund, 2004; Gemino and Wand, 2004). Aside from specic purposes of models, there are general features of healthcare delivery that models must also accurately represent. Healthcare is a very dynamic domain and process exceptions are very common (Eze et al., 2010). So, models must be able to evolve through extensions to represent the changing needs of healthcare delivery. Finally, despite the automation of healthcare delivery, there are still numerous processes performed using multiple modalities (i.e. manual and automated) (Blackwell, 2008). Those modalities will exist for the foreseeable future and therefore processes need to be modeled to represent them.
BPMJ 17,4
572
2.3 BPM methodologies and languages The terms orchestration and choreography have been used interchangeably to describe the composition of web services into business processes (Pelz, 2003; Fredlund, 2006; Arroyo, 2006; Ross-Talbot, 2005). However, orchestration and choreography are different with regard to their structure and application. The fundamental distinction between orchestration and choreography is that the former relies on a central entity that controls almost every facet of a business process, while the latter is decentralized and more collaborative in nature with control being shared among the different collaborating participants involved in a business process. 2.3.1 Orchestration. Orchestration refers to an executable part of an organizational process that is provided by one party and controlled locally (Mendling and Hafner, 2008). Orchestration can be explained using the analogy of an orchestra consisting of one conductor and several musicians. Being aware of the piece of music, the musical guide or plan to be performed, the conductor leads and guides the individual instrument players accordingly. The main point behind orchestration is the existence of a central entity (i.e. the conductor), which is in complete control of the progression of the piece of music. Away from analogies, orchestration refers to composing web services into business processes by describing how web services may interact with each other at the message level including the message exchange order and the business logic of the interaction from the perspective and under the control of one of the participants involved in a business process. Orchestration describes an executable business process that may span departmental and organizational boundaries. Web services orchestration denes the services that compose the orchestration and the order in which these services should be executed. The orchestrated process can be considered as a simple process that is itself a web service. The ow of an orchestration typically includes control points for branching, parallel processing, human response steps, and predened steps such as transformation, adapters, e-mails, and web services. Web services orchestration is supported by several languages including XLANG (Thatte, 2001), WSFL (Leymann, 2001), BPML (Arkin, 2002), and Business process execution language (BPEL) (Alves et al., 2007). BPEL is attracting the most attention both in academic research and industry and is likely to become the de facto standard for web service orchestration (Mendling and Hafner, 2008). Although BPEL does not support all constructs and features of the orchestration methodology, it is one of the most complete languages for modeling business processes as orchestrations (Huang, 2005). 2.3.2 Choreography. Choreography refers to the message sequences between different parties in an organizational business process (Pelz, 2003). Choreography can be explained through the analogy of dancers, assuming that there is a group consisting of two or more dancers who perform certain dance patterns jointly. All dancers act on these patterns which were designed and agreed upon beforehand. At run time, the dancers (as partners) execute their part of the dance patterns with no central controller who checks for compliance with the patterns in question. Choreography refers to linking sub-processes (web services) for achieving a business process in a collaborative manner. It is typically associated with the public message exchanges, agreements, and interaction rules between multiple business process participants rather than a specic business process that is executed by a single participant. More specically, choreography tracks the sequence of messages that may involve multiple parties
and multiple sources (e.g. customers, suppliers, and applications) where each party participating in the process describes the part it plays in the interaction and no party owns the conversation. Choreography is a common view used to determine a specic deployment implementation for each individual business process participant. Furthermore, since choreography offers a mean by which the rules of collaboration can be clearly dened and agreed to jointly, each participant can implement its portion of the choreography as described in the agreed upon common view. Web services choreography denes business interactions by formalizing descriptions of the peer-to-peer message exchange protocols. Such formalization species the visible message exchange behavior of each peer without revealing internal implementation details. The public and private aspects of the business process are therefore separated. This enables organizations to hide their internal business processes and data management from their business partners, and allows for changing private details of the internal process without affecting the protocol or the collaboration agreement. Several languages have been proposed for choreography including WSCL (Banerji et al., 2002), WSCI (Arkin, 2002) or BPSS (Clark et al., 2001). The World Wide Web Consortium has recommended WS-CDL (Kavantzas et al., 2004) as a new standard for the specication of global choreographies based on web services. Note that while choreography focuses on dening how multiple parties collaborate in a peer-to-peer manner by exchanging messages with trading partners and external organizations, the focus of orchestration is on dening composite services and internal processes that use existing web services. 3. Modeling micro-level healthcare systems As described in Section 1, the micro-level of healthcare delivery represents processes at the individual patient level. Developing HIS to support micro-level healthcare delivery is difcult because processes such as decision making or information exchange are complex and must support highly integrated and personalized healthcare via multidisciplinary teams located in different settings (Avison and Young, 2007). The micro-level is largely based on collaborative healthcare delivery consisting of multiple providers, locations, and information ows that span diverse organizations and groups. The complexity of micro-level processes is owed to the integration of healthcare workows, the collaboration between the diverse medical departments, and the large number of data transactions which take place between healthcare units and collaborating actors. Micro-level collaboration has been represented by conceptual frameworks such as those of DAmour et al. (2005), DAmour et al. (2008) and Leggat (2008). Studies have also presented frameworks for collaborative healthcare needs from a software engineering perspective (Kuziemsky et al., 2010). These frameworks are helpful in that they identify the process and data needs of collaborative healthcare delivery. In particular, they identify two key aspects that must be represented in process models to characterize micro-level healthcare delivery: data exchange and process ows. Those two aspects are essential because healthcare process modeling must dene the processes that take place, the data exchange within the processes, and how the processes and data relate (Kuziemsky and Lau, 2010). Process considerations include integration, exceptions, and collaboration across different providers while data exchange considerations include
BPMJ 17,4
574
security, privacy, and modularity. However, one shortcoming of these frameworks is that they have not been formally represented as a set of modeling requirements nor have they been modeled with modeling methodologies and languages. An essential aspect of micro-level healthcare delivery is the need for integration of both data and processes (Kuziemsky et al., 2010). The SOA approach is an effective way to provide that integration (Dang et al., 2008). Although research has done a good job of designing SOA-based applications that are interoperable at the system or technical level, there is still a need to develop approaches for modeling SOA based applications to represent micro-level healthcare delivery. In the remainder of this section, we describe data exchange and process ows and elaborate on their importance for modeling micro-level healthcare delivery. We then present the IHE initiative as a framework for modeling the complexity of micro-level healthcare delivery. 3.1 Data exchange Data are the lifeblood of healthcare and it is essential that the right data be available for the right task at the right time. A challenge to data exchange in healthcare is that there exist many different types of HIS including picture archiving and communication systems (PACS), radiology information systems, laboratory information systems, dietary, pharmacy, and billing systems, electronic medical record (EMR), and electronic health record (EHR) systems. Each HIS acts as a different channel for data exchange and thus data integration between the different HIS is essential and is typically achieved by the use of protocols or communication standards such as digital imaging and communications in medicine (DICOM), and Health Level Seven (HL7). DICOM was developed by the American College of Radiologists and the National Electrical Manufacturers Association for the purpose of handling imaging data with a focus on the workow of medical images (Oosterwijk, 2004). HL7 provides protocols for exchanging information between various non-imaging medical applications by dening the format and the content of the messages that these applications ought to use when exchanging data with each other. HL7 provides for interoperability between different types of HIS including PACS, PAS, and EMR or EHR systems[1]. 3.2 Process ows A large part of micro-level healthcare delivery consists of the clinical processes that take place as part of day-to-day healthcare delivery. It is essential that such processes be adequately represented in process models. However, developing micro-level process models can be difcult given the multiple providers that interact as part of team-based healthcare delivery. Thus, we need to be able to represent the complex process ows of individual providers while also promoting interoperability between different systems and healthcare settings. In general, healthcare processes are highly dynamic. A change in treatments, protocols, and procedures may affect running healthcare processes or instances, requiring reparative actions (Berry and Myers, 1998). Inter-departmental healthcare processes are very tight with each other. An evolution of one process belonging to one department will have an incremental effect on other processes whether they belong to the same department or not.
3.3 The IHE initiative The IHE initiative was created for improving the way HIS interoperate and share data. IHE is a set of healthcare workows including the data and processes within the workows. It is intended to drive the adoption of data standards such as HL7 and DICOM to facilitate daily clinical and healthcare operations (IHE Inc., 2007). The IHE technical framework contains three main concepts: actors, transactions, and integration proles. These are detailed below: (1) Actors. HIS that produce, manage or act on information are represented by IHE as functional units called actors. Each actor supports a specic set of IHE transactions. A given HIS may support one or more IHE actors. (2) Transactions. Exchanges of information between actors using messages based on established standards such as HL7 and DICOM are called transactions. (3) Integration proles. An integration prole is a set of IHE actors and transactions required to address a particular clinical task or need. Integration proles are organized by healthcare domains (e.g. radiology, radiation oncology, research and public health, patient care devices) (IHE Inc., 2007). Each domain consists of a set of workows, for instance the radiology domain encompasses a total of 18 workows. The IHE initiative is a good representation of complex healthcare workows including the data and process integration inherent to those workows. In particular, the IHE workows represent day-to-day clinical care and thus capture micro-level healthcare delivery. Developing and implementing healthcare systems in accordance to the IHE technical frameworks and workow proles not only permits different systems to communicate with each other but also enables different healthcare providers to use medical information more effectively[2] (IHE Inc., 2007). An example of an IHE integration prole is the scheduled workow (SWF) which incorporates all the process steps in a typical scheduled patient encounter from registration, ordering of diagnostic images, image acquisition, and examination and viewing. The SWF species a number of transactions related to patient and ordering information in addition to dening the scheduling and imaging acquisition procedure steps. The SWF also provides temporal reasoning of workows such as determining whether images associated with a particular procedure have been archived and are available to enable subsequent workow steps, such as reporting (IHE Inc., 2007). The SWF consists of eight actors and dozens of transactions across multiple healthcare units (IHE Inc., 2007) making it a good illustration of the complexity of process and data exchange within micro-level healthcare delivery. Figure 1 shows the eight actors involved in the SWF and how they are connected to each other through various transactions (e.g. RAD-1, RAD-49). The SWF example will be revisited in the following section as a case study. 4. Results Our ndings are presented in two sections. First, we identify a list of three categories and 12 essential features for modeling healthcare processes. Second, we use the list of categories and features to compare and contrast the modeling of the SWF using orchestration and choreography. We summarize the results in Section 4.3 with a table that compares the modeling of orchestration and choreography.
BPMJ 17,4
ADT Patient registration RAD 1. RAD 12
576
RAD 1. RAD 12 RAD-5 Acquisition modality RAD-3, RAD 48 Order placer
Department system scheduler/order filler RAD-2 RAD-20, RAD-21, RAD-6, RAD-7 RAD-6, RAD-7 Evidence creator RAD-12, RAD-13, RAD-4, RAD-42 RAD-10, RAD-18 RAD-11, RAD-42, RAD-49 Image display
RAD-20, RAD-21
RAD-10, RAD-8
Performed procedure step manager RAD-20, RAD-21, RAD-6, RAD-7
RAD-14, RAD-16 Image manager/archive
Figure 1. SWF actors and transactions between actors
Source: Taken from the IHE web site (IHE Inc., 2007)
4.1 Essential features for modeling healthcare processes In this section, we identify 12 features that we believe are essential for modeling micro-level healthcare processes. The features are a compilation of the literature from Sections 2 and 3 based on the strengths and weaknesses of modeling languages in areas inside and outside of healthcare, as well as existing frameworks for collaborative healthcare delivery. The features address the shortcoming identied in Section 3, namely the need for a formalized set of requirements for micro-level healthcare delivery. Therefore, the 12 features were strongly informed by studies such as DAmour et al. (2005), DAmour et al. (2008), Leggat (2008) and Kuziemsky et al. (2010). As we compiled the list of features, we realized that there were three essential needs that a modeling language must have: usability, capabilities, and evolution. We used those three needs as categories to group the 12 features. Each category and its features are described below. Category 1: usability. Drawing on usability in the information systems and software engineering literature, this category refers to how easy it is to use and understand a modeling language (Nielsen, 1992). The complexity of healthcare delivery has led to increased application of user involved analysis and design methods such as participatory design (Spinuzzi, 2005). User involved methods call for an ongoing collaboration between the developers and end-users of the system, including the development of business
process models. Therefore, language usability across different players is necessary. With respect to modeling languages for healthcare, we identied the following four usability features: (1) Tool Support. Languages will be more widely used if user friendly tools are available to assist with modeling. A modelers ability to create models through graphical tools will positively impact the use of the language. This is especially true in healthcare where most model users are neither tech savvy nor IT specialists. Thus, the availability of graphical tools will denitely increase the use of the modeling language within healthcare. (2) Ease of use. If a modeling language is overly complex it will negatively impact a modelers desire and ability to use the language. Part of the reason ad hoc models are appealing is because they are easy to design and share with people. Models must also be understandable by physicians, nurses, administrators, and other healthcare personal. Modeling languages with cryptic syntax will not have the appeal of less complex languages. As more participatory design methods are used for designing healthcare IT, there will be a need for languages to be understandable by both systems designers and users. Although language structure and syntax have a huge impact on ease of use, the tools that support a language will usually determine (to a certain degree) how easy it is to use. (3) Scalability. Healthcare enterprises involve complex processes that span diverse groups and organizations. These processes involve clinical and administrative tasks, large volumes of data, and large numbers of patients and personnel. Moreover, the healthcare sector is dynamic in nature and is known for its constantly changing behavior. As such, healthcare delivery and the IT that supports it are not static but rather they grow and evolve as needs change (Coiera and Hovenga, 2007). In such an environment, only scalable languages can be effectively used. Whether or not a language is able to represent a range of simple to complex systems, can keep up with the growing nature of the business, and allows adding new features and components, will certainly impact its usability. (4) Ease of monitoring. Monitoring deals with the analysis of workow instances at run-time. Active monitoring of the current state of workow instances can serve numerous purposes, such as the generation of exception reports for overdue work items or early warning reports for potentially overdue work items (zurMuehlen and Rosemann, 2000). Performance management is becoming a necessity for healthcare delivery (Coiera and Hovenga, 2007). Since unusual and undesired situations are common in healthcare, process monitoring seems necessary so that managers can easily be kept informed of those situations. The extent to which a language supports process monitoring impacts its usability. Category 2: capabilities. Capabilities refer to the features a modeling language must have to adequately represent healthcare processes. These capabilities were derived from the literature presented in Section 3 on collaborative healthcare delivery at both the process and data levels, particularly the need to support collaborative healthcare delivery where multiple healthcare providers are involved. The capability features include both technical features such as abstraction, security, and privacy, as well as collaborative features needed to represent the processes of micro-level healthcare
BPMJ 17,4
578
delivery such as exception handing, peer-to-peer representation, and distinguishing human vs automation task completion. With respect to modeling languages for healthcare, we identied the following six capability features: (5) Abstraction. Here, abstraction means the ability to focus on processes at the abstract level rather than at the detail level (e.g. programming constructs). The ability to represent processes while hiding their detailed information helps in delivering a global view of the workow. This happens to be a requirement in most domains but even more so in healthcare where individuals from various disciplines require an abstract way to represent (i.e. model) processes. With a high level of abstraction, it would take modelers and developers much less time, effort, and lines of code to express a healthcare process. (6) Security. Security is among the important factors that must be considered for healthcare systems development. Since models are the blueprint of systems, they should represent security features as well. Security is even more critical when developing systems based on SOA principles. Indeed, interactions which are inherent to SOA-based systems must have security embedded in them. (7) Privacy. As most sectors of activity increasingly pay attention to privacy issues, demand for private transactions is increasing. This translates into a growing demand for embedding privacy features in modeling languages. Privacy is vital in healthcare as most processes involving interactions with other organizations such as insurance companies, police departments, external laboratories, and other healthcare enterprises, carry private patients data as well as private implementation details about internal processes. (8) Exception handling. Healthcare processes do not always follow a structured sequence because exceptions are common. If models are to accurately represent healthcare delivery then modeling languages must be able to represent exceptions so that models do not grind to a halt when an exception occurs. (9) Peer-to-peer representation. This feature determines the ability of a modeling language to represent collaborations (e.g. collaboration between different care providers, departments, suppliers, and insurance companies). The ability to represent collaboration is crucial as more and more healthcare services are delivered by teams. Further, individual processes may have multiple users and processes as part of collaborative care delivery. To date the modeling and implementation of team-based IT has proven to be challenging because we do not have the means of accurately modeling collaboration. (10) Human vs automation. This feature refers to the languages suitability for modeling healthcare processes involving both computer and human interactions. Although healthcare is becoming increasingly automated, there are still and likely always will be processes that are performed by humans. Human interactions in a business workow can be as simple as approving a task or as complex as a chain of interactions and decision making among several participants. Most modeling languages are capable of representing the simple interactions that involve one human actor and require basic actions such as approval or conrmation, but the ability of modeling languages varies when it comes to more complex tasks involving multiple human actors. In some cases, different actors perform tasks which are assigned to others. As a result, human
tasks are not normally assigned to users but rather to roles, and human actors take those roles. Category 3: model evolution. Model evolution is the extent to which a model can evolve in its domain of use. Models are often reused in order to share successful implementations and they should also be maintainable at a reasonable cost. The two evolution features are explained below: (11) Reusability. This feature allows modelers to describe a large set of interactions spanning multiple healthcare actors by a relatively small number of reusable modeling constructs. This, along with modularity and the languages support for loose coupling and composability, make it possible to create reusable healthcare process models quickly and with less effort. Note that reusability is an SOA principle that is necessary to enable the transfer of successful models across different sites (Wright and Sittig, 2008). The need to build reusable process models is crucial in order to avoid the time, cost, and effort needed each time a process has to be rebuilt from scratch, or each time a similar process model has to be created. Reusability in healthcare modeling is driven by the principle of loose coupling and has a positive effect on process maintainability. (12) Maintainability. Healthcare processes and their underlying data can change very quickly. Thus, the following types of maintenance are required for healthcare systems to ensure they continue to operate as expected (ISO/IEC 14764, 2006): . Adaptive maintenance. Making changes to increase system functionality to meet new business requirements. . Corrective maintenance. Making changes to repair system defects. . Perfective maintenance. Making changes to enhance the system and improve such things as processing performance and usability. . Preventive maintenance. Making changes to reduce the chance of future system failures. The primary feature that helps fulll a models maintainability requirements is the ability of a modeling language to allow the internal and external integration of models after they have been developed. This feature enables modelers and application developers to specify interactions between different healthcare services within one or more healthcare entities, while leaving implementation decisions in the hands of each healthcare entity modeler. This fosters the creation of global healthcare models. 4.2 Case study modeling the SWF In this section, we use the 12 features described previously to compare and contrast modeling of the SWF using orchestration and choreography. The SWF being a large workow, we have limited our modeling to the admission process, one of the SWFs internal processes. We started by modeling the interactions of healthcare units from Figure 1 as a UML sequence diagram (Figure 2). The sequence diagram captures the interaction ow and its timing between services on patient admission when a request is made to perform an imaging procedure on a patient. UML sequence diagrams are used to represent workows, especially when there are many transactions involved. In addition, knowing the transmitted messages and their ow will help create robust
BPMJ 17,4
ADT Register/admit patient
Order Placer
Department system scheduler/order filler
Image manager/ Imange archive
Acquisition modality
Patient
580
Registration (RAD 1)
Create Order Placer Order Mgmt New (RAD 2)
Scheduler procedure and/or assign protocol Procedure scheduled (RAD 4)
Query modality worklist (RAD 5) Modality procedure step in progress (RAD 6) Modality procedure step in progress (RAD 6) Perform acquisition Modality image stored (RAD 8) Modality presentation state stored (RAD 9)
Modality procedure step completed (RAD 7) Modality procedure step completed (RAD 7)
Stage commitment (RAD 10)
Images availability query (RAD 11)
Figure 2. The SWFs administrative and procedure performance process ows
Order status update (RAD3)
communication protocols in a choreographed model. Knowing the process actors and interactions enables us to map the entities to the actors. Figure 3 shows the steps we followed for developing the models. These steps are detailed here. After identifying the actors and the ow of messages in the SWF, the challenge is to identify the most suitable language and tool that support most requirements for modeling the SWF. We chose BPEL (NetBeans-BPEL as a tool) and WS-CDL (Pi4SOA[3] as a tool) because they are the most prominent web services modeling languages as described in Sections 2.3.1 and 2.3.2. Next, to model the orchestrated process, we needed to determine the central process responsible for coordinating the workow. The central process usually has the highest amount of communication and the highest number of connected processes. But sometimes, as in the case of the SWF, no single process can act as a central process; hence the need to
Define central process Orchestration Identify message flow Choreography Model processes and interfaces Define communication protocols Select modeling languages and tools Develop model
Define orchestrated processes
Identify system actors
Model assessment
Modeling healthcare processes
Figure 3. Process for developing the models
581
BPMJ 17,4
582
create one. For choreographies, there is no such problem as each process acts individually. However, the difculty is to introduce and implement communication protocols which all processes have to obey. The protocols should be exible enough to limit the extent of modication during maintenance. Finally, the developed models are assessed to verify their suitability for their intended purpose. In the following sections, the SWF is orchestrated (Section 4.2.1) then choreographed (Section 4.2.2). The modeling follows the steps shown in Figure 3. Both types of modeling are discussed according to the 12 features introduced in the previous section. 4.2.1 Orchestrating the SWF. The rst step in modeling a workow-based orchestration process is to analyze the business requirements of the project. The goal of this step is to understand the business requirements, and to determine the services and processes that are involved in the workow as well as types of interactions between processes. However, the ultimate result of this step is to gain a thorough understanding of the requirements for the orchestrating process in order to produce a complete plan for its development (Zhong, 2008). The second step involves determining the communication method between orchestrating and orchestrated processes which includes dening information types, variables, interfaces, communication channels, and message types. Since orchestration is all about partners, and how they interact with the orchestrating process, the rst two steps are key for modeling the workow (Zhong, 2008). The selection of a modeling language depends on the complexity of workow and the model requirements. For the purpose of our case study, we selected BPEL as the modeling language. BPEL provides both graphical and textual development interfaces, and it is supported by many development environments. We now describe orchestration of the SWF using BPEL according to the three categories and 12 features from Section 4.1. Category 1: usability: (1) Tool support. BPEL is supported by numerous tools including eclipse BPEL Designer (www.eclipse.org/bpel), Netbeans (www.netbeans.org), ActiveBPEL Designer (www.activevos.com), and Oracle BPEL Process Manager (www. oracle.com). The wide variety of tools supporting BPEL increases its accessibility, encourages its evolution, and helps improve its functionality. (2) Ease of use. When using orchestration, a central process coordinates the ow of interactions and workows in the whole process model. Other related processes appear as services and business partners. For instance, we can map an IHE actor such as SWF Order Placer to a BPEL business partner, and an IHE ow such as patient registration process ow to a BPEL process. The fact that one of the systems internal processes (patient admission in the SWF) acts as the central process contributes to the clarity of the whole process. This increases the languages ease of use. Similar to procedural programming, orchestration lowers the modeling languages learning curve. It makes the modeling language easier to understand and facilitates model development even in the absence of sophisticated tools. (3) Scalability. Healthcare process sizes range from very small to very large, the SWF being one of the large processes. Orchestration and BPEL have been tested for small to medium processes but there is no evidence that they adequately support large processes. Considering the fact that orchestration
requires signicant resources at the central entity, the central process can become overloaded when modeling a large process. Moreover, orchestration does not properly support the dynamic growth of workows due to the increase in required resources and the eventual need to modify the central process to embed new activities. (4) Ease of monitoring. Orchestration allows for easier monitoring of healthcare process activities since there is a single entity in control. This enables the efcient monitoring of message exchanges between the parties involved in a particular healthcare process. Category 2: capabilities: (5) Abstraction. BPEL, being an execution language, is not designed to provide all the process ow features necessary for representing abstract entities. Lack of full support for abstraction adds to the complexity of the models. Orchestrating processes in BPEL requires a signicant effort since every part of the model is rst analyzed and designed with a predened structure. From a top level view, the model contains a central process and transactions with sub-processes representing healthcare units and departments. Sub-processes themselves are implemented as central processes and are shown in Figure 4. Developing all execution-related variables for a process model where we only seek to represent a global view is difcult and time consuming. (6) Security. BPEL contains no constructs to represent task-level or process-level security in models; neither does it provide a complete secure collaborative basis in the execution. Although WS-Security (Nadalin et al., 2004) can be embedded in messages transmitted between services, it does not provide representational aspects. As a language designed for executing services, BPEL can leverage extensions (plug-ins) that offer added security features. However, these extensions, which contain representational aspects, require extra learning time and effort. Moreover, not all orchestration tools support extensions. Finally, and to the best of our knowledge, none of the proposed extensions is complete enough to be certied by the organizations supporting BPEL. (7) Privacy. In most healthcare scenarios, processes carry patients private data as well as details about the implementation of internal processes. In this context, orchestration has a drawback since all involved processes and even external services should share a reasonable amount of design information with the orchestrating process, so the organizations internal structure and business processes must be exposed to other parties. It should be noted that BPEL does not provide constructs for modeling privacy. (8) Exception handling. BPELs basic features (Alves et al., 2007) and activities can be used to model the environmental attributes, the IHE actors and their relevant transactions. The transactions between processes are managed by the , invoke . and , receive . activities in addition to a set of other constructs. For a large process like the SWF, some consideration should be given to exception handling. In the SWF, the HL7 A11 and A01 messages are dened to handle exceptions and control errors. BPEL provides some features for exception handling through its compensation constructs (Tai et al., 2004).
BPMJ 17,4
584
Figure 4. Scheduling procedure (part of department system scheduler) in BPEL
Fault handlers were introduced in the BPEL specication to cope with exceptional situations during process modeling and execution. Exception handling mechanisms introduced in BPEL are rather complex since BPEL supports fault handling at different levels (i.e. activity, process, and scope). In addition to BPELs fault handling features, other extensions add exceptional handling features such as prepackaged BPEL error handling (www.karmaticit. com/). (9) Peer-to-peer representation. Although BPEL can represent choreographies to some extent, it lacks the semantics of peer-to-peer interactions. BPEL can only dene the information formats exchanged by one participant. Moreover, BPEL only takes the perspective of one party in the collaboration, and that party should coordinate
the actions of all participants, which is in contrast with peer-to-peer concepts. Hence BPEL is not well suited for representing peer-to-peer collaborative healthcare processes. (10) Human vs automation. Although BPEL specication by itself does not directly address human interactions, BPEL can still be used for modeling human workows as part of the main process. People and their assigned tasks are seen as separate asynchronous services or processes from the viewpoint of the orchestrating process. BPEL supports human interactions by extensions to the language specication such as BPEL4People (Agrawal et al., 2007). Note that extensions increase the complexity of the modeling language and decrease the readability of models. Category 3: model evolution: (11) Reusability. Orchestrated and orchestrating processes are tightly related, in a way that orchestrated processes may share their internal processes with the orchestrating process in order for the central process to manage the process ow. This interdependency limits the ability to reuse the processes in different models because they are designed to complete each other. Healthcare systems are dynamic and new technologies are frequently introduced. As a result, models often change, and reusing previous models becomes important. But, due to the tightly connected nature of orchestration, BPEL does not provide reusable models and model components. (12) Maintainability. The fact that there always exists a central process (here, patient admission in the SWF) in orchestrated systems contributes to the clarity of the overall process. However, any changes to the services that interact with the central process will often result in modications in the central process. This situation is more challenging when new services are added to the system during maintenance. New services introduce many interactions with the system likely resulting in remodeling the central process. Since the central process is the largest and most complex process in the system and it coordinates the functionality and interactions of the services, alternating and remodeling it can be costly. Therefore, the existence of a central process limits the exibility of the model and increases the difculty and cost of its maintenance. 4.2.2 Choreographing the SWF. Before modeling a process using a choreography language such as WS-CDL, the process participants, their roles, and their relationships must be clearly identied. The next step is to develop interactions, information and information types, tokens and token locators, channels and channel types, variables, and choreographies (Hangli et al., 2006). To build our choreographies of the SWF process we used Pi4SOA[3], a plug-in which creates a WS-CDL modeling environment for eclipse[4]. Pi4SOA provides graphical features for modeling roles and relationships in systems. Figure 5 shows the relationship types dened for the model representing the SWF. The nal step is to create variables and values and to generate the choreography description. Figure 6 shows the graphical representation of the choreography generated by Pi4SOA for the selected part of the SWF. The resulting model provides an example of the high-level view of processes expected in a choreographed model. This high-level view inuences the composability
BPMJ 17,4
586
Figure 5. Relationship type denition for the SWF
and reusability of choreographed models; allowing for a models high-level view and a detailed view depending on the purpose of modeling. We now describe choreography of the SWF according to the three categories and 12 features from Section 4.1. Category 1: usability: (1) Tool support. To the best of our knowledge, choreography has not been extensively used in the context of healthcare process modeling. One possible reason is that there are few modeling tools that support WS-CDL. (2) Ease of use. The peer-to-peer nature of choreography allows for different processes to be developed separately, and WS-CDL fosters ease of use by dening the interaction protocols of these processes. However, the lengthy WS-CDL documents can be hard to understand and analyze by non-IT healthcare participants. (3) Scalability. The decentralized nature of choreography permits the realization of higher scalability levels since it allows for nding partners independently, negotiating, and deploying service orchestration denitions without the need of a
Figure 6. Graphical choreography description for the SWF generated in Pi4SOA
BPMJ 17,4
588
central entity. Therefore, if the overall business process is highly resource demanding, the load will be shared among the involved parties. This will facilitate the modeling of large and resource demanding processes. Also, the distributed nature of choreography makes it easy to handle the growth of the process. However, to the best of our knowledge, WS-CDL has not been extensively tested for its support of very large processes. (4) Ease of monitoring. Process monitoring in choreographed models is difcult for two reasons. First, since choreographies consist of several standalone processes and their communication protocols, the negotiated choreography scripts must always be available to be interpreted and compared to the actual ow sequence by all involved parties. Thereby, monitoring the ow of the process becomes complicated and the risk of errors may increase. The second problem is that, as a modeling language, WS-CDL is not designed to support process execution, so monitoring processes in WS-CDL is not part of its expected capabilities. Category 2: capabilities: (5) Abstraction. Different components of the choreographed process model are developed independently and no entity is aware of the internal processes of the other entities. In fact, hiding detailed information of the entities involved in a process is one of the features of WS-CDL which allows for developing high-level abstract views of the complete workow where needed. (6) Security. The lack of security representation is a major drawback of WS-CDL. Even though WS-CDL is partially integrated with the WS-Security framework, and the security failures may be reected as security exceptions, WS-CDL, as a modeling language for healthcare processes, should represent secure communications. (7) Privacy. Since choreographies dene communication protocols among processes and involved processes are completely standalone, a healthcare organization can separate the public aspects of its processes from their private aspects. Choreography enables healthcare organizations to not reveal their internal business processes and data management to their business partners, thus allowing for higher levels of privacy. (8) Exception handling. WS-CDL provides a complete set of exception handling features. It can recognize and handle as much as six types of errors that mostly occur at the message passing and interaction phase of a model. WS-CDL, however, does not provide complete support for errors happening inside choreographed entities. But, choreographed entities, themselves, consist of choreographies. Therefore, it is legitimate to conclude that the exception handling feature of WS-CDL provides enough support for the healthcare domain. (9) Peer-to-peer representation. Choreography is naturally based on peer-to-peer interaction, and therefore WS-CDL as a choreography language is capable of representing these interactions. (10) Human vs automation. Like BPEL, WS-CDL does not support human interaction in its original version. Human tasks can be represented in the model in the form of services or processes. However, since WS-CDL does not provide any execution feature, it can be easily extended to support additional capabilities. As a result,
many research initiatives proposed extensions to incorporate human interactions in WS-CDL models. There are also proposals to combine WS-CDL with other modeling languages such as UML to overcome this limitation. Category 3: model evolution: (11) Reusability. WS-CDL denes the interaction protocols of independent entities along with their descriptions. Since the components have been developed independently, they can easily be separated from the workow and be added to other models or systems, or integrated with new protocols. Overall, WS-CDL fosters a high level of reusability. (12) Maintainability. WS-CDL choreographies are composed of reusable entities with their associated interaction protocols. Thanks to WS-CDLs loose coupling, all four types of maintenance can be performed on WS-CDL models by modifying the related parts of the models without affecting other components. 4.3 Summary of results In Table I, we show a comparison of BPEL and WS-CDL based on the 12 essential features for modeling healthcare processes identied in Section 4.1. The comparison is based on the ability of each language to model the SWF admission process as described in Sections 4.2.1 and 4.2.2. 5. Discussion This is the rst paper to analyze the ability of orchestration and choreography and their associated languages for modeling healthcare processes. For that, and based on an extended analysis of the literature, we developed a set of three categories and 12 features that we believe are essential for modeling healthcare processes, particularly micro-level processes. We then used the proposed features to assess orchestration and choreography for modeling a case study scenario from the IHE framework. Our ndings have both research and practical implications. For research implications, we showed that there is no perfect web service modeling language for
Business process execution language (BPEL) Satisfactory Partially satisfactory Unsatisfactory Satisfactory Unsatisfactory Unsatisfactory Unsatisfactory Satisfactory Unsatisfactory Unsatisfactory Unsatisfactory Unsatisfactory Web services choreography description language (WS-CDL) Unsatisfactory Partially satisfactory Partially satisfactory Unsatisfactory Satisfactory Unsatisfactory Partially satisfactory Satisfactory Satisfactory Unsatisfactory Satisfactory Satisfactory
Category Usability
Feature
1. Tool support 2. Ease of use 3. Scalability 4. Ease of monitoring Capabilities 5. Abstraction 6. Security 7. Privacy 8. Exception handling 9. Peer-to-peer representation 10. Manual vs automated processing Model evolution 11. Reusability 12. Maintainability
Table I. Comparison of BPEL and WS-CDL for modeling the SWF admission process
BPMJ 17,4
590
healthcare. BPEL and WS-CDL both have their strengths and weaknesses as outlined in Table I. The appropriate methodology must be selected after consideration of the specic healthcare modeling needs. For practical implications, our ndings have provided insight for understanding and modeling micro-level healthcare delivery. In particular, a key practical implication is that we have formalized modeling requirements for micro-level healthcare systems. Although other studies (Leggat, 2008; Kuziemsky et al., 2010) have described the need for micro-level support, these needs have not been represented through formalized modeling approaches. However, detailed micro-level models are necessary to serve as requirements for the design of clinical information systems to support micro-level healthcare delivery. Micro-level modeling requires attention to be paid to the individual processes, the characteristics of the processes (i.e. exceptions, peer-to-peer exchange, security) and the different types of users (i.e. clinical, administrative) who take part in those processes. A key step in healthcare process modeling is the identication of an appropriate modeling methodology. The three categories and 12 essential features for modeling healthcare processes that we identied can assist with the selection of a methodology for healthcare process modeling. We suggest they provide some formalization for healthcare process modeling and can serve as a meta-model for analyzing modeling situations in order to identify an appropriate modeling language. We now discuss these three categories (usability, capabilities, and model evolution) and their respective features in the context of orchestration and choreography and their associated languages for different healthcare process modeling situations. i. Usability Healthcare process modeling is used for a broad range of applications and purposes such as building descriptive models for training and learning. These types of models are usually meant for users like nurses, physicians or administrative personnel who have limited or no modeling experience. Hence models must be understandable by multiple users and useable for different purposes. Healthcare processes are complex and their modeling, and later on, monitoring and maintenance are challenging tasks. One way to cope with this complexity is to think of processes as problems that can be divided into smaller and less complicated ones. In that sense, choreography seems better suited for coping with complexity as it enables breaking down the overall process into sub-processes that can be described graphically or textually with fewer technical details. Too much detail in a model can be confusing for non-expert users, consequently reducing the usability of the model. Also, linked to the complexity of models (in building, analyzing and monitoring them) is the way the two web service modeling languages represent control ow. Studies in Decker et al. (2006)[5] indicate that BPEL and WS-CDL do not represent control ow, communication, and data ow patterns. A lack of support for certain patterns limits the ease of use and scalability of modeling languages and models. A study in Afrasiabi Rad et al. (2009) tested the capabilities of BPEL and WS-CDL to represent workow and ontological patterns required for healthcare modeling, showing that not all patterns are directly supported, and some patterns cannot be modeled at all. The study concludes that both languages are still incomplete, and some constructs needed for modeling healthcare workows and processes are missing. The study however shows that WS-CDL supports more patterns than BPEL.
When building models for process execution and implementation, orchestration through BPEL has an advantage over choreography through WS-CDL because the models are meant to be deployed and enacted. BPEL models are executable and less challenging to implement by IT staff, while very few tools are available to technical people for implementing WS-CDL models. However, it should be noted that there are far more choices for BPEL model development tools than there are for WS-CDL, so the probability of nding the right modeling tool that supports all the process and workow needs increases with the choice of BPEL as the modeling language. ii. Capabilities From a departmental structure point of view, a key capability decision is the level of peer-to-peer representation, specically whether intra-departmental or inter-departmental workow and communication are needed. Choreography and WS-CDL are better if the process to be modeled is inter-departmental and spans multiple departmental and organizational boundaries. However, if the process to be modeled is intra-departmental (i.e. the scope of the process remains inside a specic department) then orchestration and BPEL are better for modeling. The implementation of capabilities such as peer-to-peer representation also differs across the two modeling methodologies. Using choreography means that the web services used to compose healthcare processes will be published and interconnected independently from central instances. Healthcare partner retrieval, the negotiated choreography, and the peer process creation are performed in a peer-to-peer manner. So, the choreography approach requires all healthcare units involved in a particular process to install a software package locally (which includes process and sub-process templates, templates, repositories, and possibly BPEL generation tools) in order to ensure the seamless interoperability of the corresponding local applications. Thus, the complexity inherent to partners applications is relatively high since local installations may be major hurdles to the rapid adoption of choreography designed systems. The orchestration approach frees healthcare units or departments from the installation of any local applications (only the data adapters and the encapsulation of applications as web services are required in this case) since a BPEL orchestration engine (central entity) is usually responsible for invoking the different partners services consumed by a particular healthcare process. From that aspect, orchestration is a simpler implementation. Security and privacy also differ across the two methodologies. When using choreography, the privacy of each departments internal processes should be ensured while developing abstract process interfaces. Meanwhile, the security and integrity of communicated data should be considered in the development of interaction protocols. In orchestration, the seamless interoperability across healthcare departmental borders is facilitated by the existence of an orchestration engine. Healthcare processes and data templates are stored in one place (e.g. the BPEL server) where they can be changed quickly if needed. However, this is an important drawback in most healthcare processes where processes contain internal private workows and the process owners want to preserve process privacy. Another capability requirement is the ability to manage the integrity and consistency of healthcare interactions and to deal with compensation and exception handling. Both BPEL and WS-CDL provide correlation and message persistence techniques and they both support the asynchronous interactions that may happen between healthcare
BPMJ 17,4
592
processes exposed as web services. Although both languages have embedded features for compensation and exception handling, their capabilities in this area are inadequate. Healthcare processes require adequate support in terms of exception handling for emergency and mission-critical processes. BPEL has limitations when it comes to exception handling since it has no support for direct process cancellation. In other words, we cannot terminate a BPEL process instantly; rather we always need to wait for the process to reach its ending point. The situation is not better with WS-CDL where exception handling specications are rather weak and not clearly specied (Fredlund, 2006; Kang et al., 2007). However, as mentioned earlier in this paper, neither one of the two languages supports the patterns that enable easy switching between manual and automatic tasks. iii. Model evolution The main concern one can think of when adopting an orchestration-centric approach to healthcare process modeling is the risk of a single point of failure. Any software or hardware failure or any error that might occur at the single controlling partys side may affect a whole healthcare process which may be stopped until the issue is resolved. Once the problem is xed, the overall process needs to be restarted or reinitiated. In contrast, a choreography-centric approach is decentralized in nature. If an error occurs at one specic partys side, other parties may locate the malfunctioning party and possibly continue the process in a peer-to-peer manner if there is no more need for the failing partys inputs. There is also an issue when a process component has to be modied for maintenance. In case of BPEL, even a single small change in one of the orchestrated processes may result in modications in the central orchestrating process. On the other hand, in choreographed processes the only modications are needed in the process itself and its interface. Considering the above-mentioned factors, choreography and WS-CDL are more suitable for modeling critical processes as they provide an environment where a failed process or a frequently changing one can be replaced by a substitute one whereas in orchestration the substitution is not always possible since the central entity should merge with the newly replaced process. Moreover, lengthy termination time and the fact that failure or modication of the central entity disables the whole system add to the problems associated with orchestration when it comes to modeling critical processes. 6. Conclusion SOA and web services can support distributed healthcare delivery at the micro-level as they allow the development and implementation of services that can be invoked in different system architectures. However, before we can design IT applications to support micro-level healthcare delivery, we need to adequately represent it through formal models. The overall objective of this paper was to investigate the suitability of web service orchestration and choreography for modeling web service-based healthcare processes. The specicities of healthcare process modeling were identied and discussed then matched with the features of the two modeling methodologies and languages. The key take away result from this paper is that neither modeling methodology is ideal for all situations but rather the ideal methodology will vary by context. The key decision in
choosing a methodology is the centralized/decentralized difference. Centralized processes (e.g. admission) are better modeled with orchestration while decentralized processes (e.g. interdisciplinary team communication across multiple settings) are better modeled with choreography. Further, some modeling situations have a mixture of processes (i.e. both centralized and decentralized) and require a hybrid modeling approach. Processes in the ER are an example of processes that need a hybrid modeling approach as ER processes often contain both a centralized and decentralized component. Therefore, we recommend a combination of the two methodologies for ER modeling to harness the benets of both methodologies. Since orchestration and choreography implement SOA principles, they both enable interoperability and integration between healthcare departments and organizations (Juneja et al., 2009) and help healthcare enterprises leverage shared services to automate business processes while reducing the need for data synchronization between isolated systems. They both bring visibility to the data that drive healthcare processes. Differences between the two methods include their implementation. Orchestration relies on an engine for the execution of the central service, while choreography encourages implementing healthcare processes in a peer-to-peer manner. The strengths and weaknesses of the two approaches with regard to error rectication as well as the possibility of continuing some process activities in spite of a malfunction are worth investigating. Although orchestration and choreography support the modeling of the IHE frameworks, further research is needed to ensure the frameworks are representative of real micro-level healthcare delivery. Future research will involve using orchestration and choreography to model micro-level processes and data exchange in actual healthcare settings. As described above, there are instances when a hybrid language is needed. Future research will also explore that approach. We also intend to validate our framework of modeling categories and features using empirical healthcare cases. That will enable us to say for certain how well the methods can model micro-level healthcare delivery, how well the IHE frameworks represent micro-level healthcare delivery, and to what extent can we use SOAs to automate micro-level healthcare delivery.
Notes 1. Health Level 7. available at: www.hl7.org (accessed 3 October 2010). 2. IHE web site, available at: www.ihe.net (accessed 3 January 2010). 3. Available at: pi4soa.sourceforge.net (accessed 3 October 2010). 4. Available at: www.eclipse.org (accessed 21 September 2009). 5. Workow Patterns Initiative, Workow Patterns: Standards Evaluations, available at: www.workowpatterns.com/evaluations/standard (accessed 3 October 2010). References Afrasiabi Rad, A., Benyoucef, M. and Kuziemsky, C.E. (2009), Web Service Based Process Modeling for Healthcare, University of Ottawa, Ottawa. Agrawal, A., Adobe Mike Amend, B.E.A. and Manoj Das, O. (2007), WS-BPEL Extension for People (BPEL4People), Version 1.0, June available at: http://xml.coverpages.org/ BPEL4People-V1-200706.pdf (accessed 3 October 2010).
BPMJ 17,4
594
Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B., Curbera, F., Ford, M., Goland, Y., Guizar, A. and Kartha, N. (2007), Web Services Business Process Execution Language Version 2.0, OASIS.org, available at: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf (accessed 3 October 2010). Anzbock, R. and Dustdar, S. (2005), Modeling and implementing medical web services, Data & Knowledge Engineering, Vol. 55, pp. 203-36. Arkin, A. (2002), Business Process Modeling Language (BPML), Specication, available at: http:// xml.coverpages.org/WD-BPML-20010308.pdf (accessed 19 August 2009). Arroyo, S. (2006), Basic concepts in choreography, in Cardoso, J. and Sheth, A.P. (Eds), Semantic Web and Beyond Semantic Web Services Processes and Applications, Vol. 3, Springer, New York, NY, pp. 138-59. Avison, D. and Young, T. (2007), Time to rethink healthcare and ICT?, Communications of the ACM, Vol. 50 No. 6, pp. 69-74. Balka, E. (2003), Getting the big picture: the macro-politics of information system development (and failure) in a Canadian hospital, Methods Inf. Med., Vol. 42 No. 4, pp. 324-54. Banerji, A., Bartolini, C., Beringer, D., Chopella, V., Govindarajan, K., Karp, A., Kuno, H., Lemon, M., Pogossiants, G., Sharma, S. and Williams, S. (2002), Web Services Conversation Language (WSCL), W3C, available at: www.w3.org/TR/wscl10 (accessed 4 February 2010). Behara, G.K. (2006), BPM and SOA: A Strategic Alliance, BPTrends, available at: www.bptrends. com/publicationles/05-06-WP-BPM-SOA-Behara.pdf (accessed 13 June 2009). Berg, M. (2003), The search for synergy: interrelating medical work and patient care information systems, Methods Inf. Med., Vol. 42 No. 4, pp. 337-44. Berg, M. and Toussaint, P. (2003), The mantra of modeling and the forgotten powers of paper: a sociotechnical view on the development of process-oriented ICT in healthcare, International Journal of Medical Informatics, Vol. 69, pp. 223-34. Berry, P.M. and Myers, K.L. (1998), Adaptive process management: an AI perspective, paper presented at the ACM Conference on Computer Supported Cooperative Work, Towards Adaptive Workow, Seattle, WA. Blackwell, G. (2008), The future of IT in healthcare, Informatics for Health & Social Care, Vol. 33 No. 4, pp. 211-326. Clark, J., Casanave, C., Kanaskie, K., Harvey, B., Clark, J., Smith, N., Yunker, J. and Riemer, K. (2001), ebXML Business Process Specication Schema Version 1.01, UN/CEFACT and OASIS Specication, available at: www.ebxml.org/specs/ebBPSS.pdf (accessed 8 April 2009). Coiera, E. and Hovenga, E.J. (2007), Building a sustainable health system, Yearbook of Medical Informatics, IMIA, Geneva, pp. 11-18. DAmour, D., Ferrada-Videla, M., San Martin Rodriguez, L. and Beaulieu, M.-D. (2005), The conceptual basis for interprofessional collaboration: core concepts and theoretical frameworks, Journal of Interprofessional Care, Vol. 19, pp. 116-31 (supplement 1). n-Rodriguez, L. and Pineault, R. (2008), A model DAmour, D., Goulet, L., Labadie, J.F., San Mart and typology of collaboration between professionals in healthcare organizations, BMC Health Services Research, Vol. 8, p. 188. Dang, J., Hedayati, A., Hampel, K. and Toklu, C. (2008), An ontological knowledge framework for adaptive medical workow, Journal of Biomedical Informatics, Vol. 41 No. 5, pp. 829-36.
Decker, G., Overdick, H. and Zaha, J.M. (2006), On the Suitability of WS-CDL for Choreography Modeling (Extended Version), Plattner Institute, University of Potsdam, German, and Queensland University, Brisbane. Eze, B., Kuziemsky, C., Peyton, L., Middleton, G. and Mouttham, A. (2010), Policy-based data integration for e-health monitoring processes in a B2B environment: experiences from Canada, Journal of Theoretical and Applied Electronic Commerce Research, Vol. 5 No. 1, pp. 56-70. Fredlund, L.A. (2006), Implementing WS-CDL, Proceedings of the Second Spanish Workshop on Web Technologies, in Santiago de Compostela, Spain, pp. 107-13. Gemino, A. and Wand, Y. (2004), A framework for empirical evaluation of conceptual modeling techniques, Requirements Engineering, Vol. 9 No. 4, pp. 248-60. Hongli, Y., Xiangpeng, Z., Zongyan, Q., Geguang, P. and Shuling, W. (2006), A formal model for web service choreography description language (WS-CDL), ICWS Proceedings of the IEEE International Conference on Web Services, Chicago, IL, USA, pp. 893-4. Huang, D. (2005), Semantic policy-based security framework for business processes, Proceeding of the 4th Semantic Web and Policy Workshop, Galway, Ireland, pp. 142-7. IHE Inc. (2007), IHE Technical Framework, Vol. I, Integration Proles, available at: www.ihe.net/ Technical_Framework/upload/IHE_PAT_TF_Rev2-0_Vol1_TI_2010-07-23.pdf (accessed 3 October 2010). ISO/IEC 14764 (2006), Software Engineering-Software Life Cycle Processes Maintenance, International Organization of Standardization, Geneva. Institute of Medicine (2001), Crossing the Quality Chasm: A New Health System for the Twenty-rst Century, National Academies Press, Washington, DC. Juneja, G., Dournaee, B., Natoli, J. and Birkel, S. (2009), SOA in healthcare (Part II), SOA Magazine, XXVII, available at: www.soamag.com/I27/0309-1.php (accessed 3 October 2010). Jun, G.T., Ward, J., Morris, Z. and Clarkson, J. (2009), Healthcare process modelling: which method when?, International Journal for Quality in Healthcare, Vol. 21 No. 3, pp. 214-24. Kang, Z., Wang, H. and Hung, P.C.K. (2007), WS-CDL for web service collaboration, Journal of Information System Frontiers, Vol. 9 No. 2, pp. 375-89. Kavantzas, N., Burdett, D., Ritzinger, G. and Lafon, Y. (2004), Web Services Choreography Description Language Version 1.0, W3C Working Draft, available at: www.w3.org/TR/ ws-cdl-10 (accessed 13 June 2009). Kuziemsky, C.E. and Lau, F. (2010), A four stage approach for ontology based health information system design, Articial Intelligence in Medicine, Vol. 50 No. 3, pp. 133-48. Kuziemsky, C.E., Borycki, E.M. and Brasset-Latulippe, A. (2010), A typology to support his design for collaborative healthcare delivery, Proceedings, International Conference on Software Engineering workshop on Software Engineering in Healthcare, ACM Press, New York, NY, USA, pp. 29-38. LANDesk Software Ltd (2006), Business process management (BPM), realizing ROI from automating business processes, White Paper, available at: www.landesk.fr/docs/ whitepapers/wp_BPM_en-US.pdf (accessed 9 January 2010). Laguna, M. and Marklund, J. (2004), Business Process Modeling, Simulation, and Design, Prentice-Hall, Upper Saddle River, NJ. Leggat, S.G. (2008), Effective healthcare teams require effective team members: dening teamwork competencies, BMC Health Services Research, Vol. 7 No. 17, pp. 1-10.
BPMJ 17,4
596
Leymann, F. (2001), Web Services Flow Language (WSFL), IBM Corp., Armonk, NY, Specication, available at: xml.coverpages.org/WSFL-Guide-200110.pdf (accessed 9 July 2009). Malholtra, S., Jordan, D., Shortliffe, E. and Patel, V. (2007), Workow modeling in critical care: piecing together your own puzzle, Journal of Biomedical Informatics, Vol. 40 No. 2, pp. 81-92. Mendling, J. and Hafner, M. (2008), From WS-CDL choreography to BPEL process orchestration, Journal of Enterprise Information Management, Vol. 21 No. 5, pp. 525-42. Menon, D.A. and Mishra, R. (2007), Role of BPM in Business Transformation, Infosys Technologies Limited, available at: www.infosys.com/BPM-EAI/resource-center/BPMbusiness-transformation.pdf (accessed 28 April 2009). Mohamed, A.A. and Alkhamis, T.M. (2009), Simulation optimization for an emergency department healthcare unit in Kuwait, European Journal of Operational Research, Vol. 98 No. 3, pp. 936-42. Mykkanen, J., Riekkinen, A., Sormunen, M., Karhunen, H. and Laitinen, P. (2007), Designing web services in health information systems: from process to application level, International Journal of Medical Informatics, Vol. 76, pp. 89-95. Nadalin, A., Kaler, C., Monzillo, R. and Hallam-Baker, B. (2004), Web Services Security: SOAP Message Security 1.1, WSS: SOAP Message Security, available at: http://docs.oasis-open. org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf (accessed 9 July 2009). Newcomer, E. and Lomow, G. (2005), Understanding service-oriented architecture (SOA) with web services, Addison-Wesley, Boston, MA. Nielsen, J. (1992), The usability engineering life cycle, Computer, Vol. 25 No. 3, pp. 12-22. Oosterwijk, O. (2004), The DICOM standard, overview and characteristics, Ringholm White Papers, Version 1.2, available at: www.ringholm.de/docs/02010_en.htm (accessed 24 April 2009). Pelz, C. (2003), Web services orchestration and choreography, IEEE Computer, Vol. 36 No. 10, pp. 46-52. Ross-Talbot, S. (2005), Orchestration and choreography: standards, tools and technologies for distributed workows, paper presented at the NETTAB Workshop Workows Management: New Abilities for the Biological Information Overow, Naples, Italy, October. Sobolev, B., Harel, D., Vasilakis, C. and Levy, A. (2008), Using the statecharts paradigm for simulation of patient ow in surgical care, Healthcare Management Science, Vol. 11 No. 1, pp. 79-86. Spinuzzi, C. (2005), The methodology of participatory design, Technical Communications, Vol. 52 No. 2, pp. 163-74. Tai, S., Khalaf, R. and Mikalsen, T. (2004), Composition of coordinated web services, Proceedings of the 5th ACM/IFIP/USENIX International Conference on Middlewar, Springer, New York, NY, USA, Vol. 78, pp. 294-310. Thatte, S. (2001), XLANG: Web Services for Business Process Design, Specication, Microsoft Corp., Redmond, WA, available at: www.gotdotnet.com/team/xml_wsspecs/xlang-c/ default.htm (accessed 3 January 2009). The Committee on Quality of Healthcare in America of the Institute of Medicine (2001), The Institute of Medicine Report on The Quality of Healthcare Crossing the Quality Chasm: A New Health System for the 21st Century, National Academy Press, Washington, DC. Van Der Aalst, W.M.P., ter Hofstede, A.H.M. and Weske, M. (2003), Business process management: a survey, in van der Aalst, W., ter Hofstede, A. and Weske, M. (Eds),
Proceedings of the 1st International Conference on Business Process Management in Eindhoven, Vol. LNCS 2678, Springer, Berlin, pp. 1-12. Wright, A. and Sittig, D.F. (2008), SANDS: a service-oriented architecture for clinical decision support in a National Health Information Network, Journal of Biomedical Informatics, Vol. 41, pp. 962-81. Zhong, J. (2008), Process orchestration design principles and best practices, white paper, Active endpoints, available at: http://www.activevos.com/indepth/c_technology/bestPracticesfor Design/AEDesignPrinciplesAndBestPractice.pdf (accessed 14 November 2010). zurMuehlen, M. and Rosemann, M. (2000), Workow-based process monitoring and controlling $ technical and organizational issues, in Sprague, R. (Ed.), Proceedings of the 33rd Hawaii International Conference on System Science (HICSS-33), IEEE Computer Society Press, Los Alamitos, CA, pp. 1-10. Further reading Fonseca, F. (2007), The double role of ontologies, Information Science Research Journal of the American Society for Information Science and Technology, Vol. 58 No. 6, pp. 786-93. Maglogiannis, I., Skianis, C. and Anderson, J.G. (2007), Preface: special issue on performance modeling and simulation in healthcare information systems, Simulation, Vol. 83 No. 4, pp. 307-9. Corresponding author Morad Benyoucef can be contacted at: benyoucef@telfer.uottawa.ca
To purchase reprints of this article please e-mail: reprints@emeraldinsight.com Or visit our web site for further details: www.emeraldinsight.com/reprints

Healthcare Processes

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Healthcare Processes

Hochgeladen von

Copyright:

Verfügbare Formate

The current issue and full text archive of this journal is available at www.emeraldinsight.com/1463-7154.

Modeling healthcare processes as service orchestrations and choreographies

Modeling healthcare processes 569

Modeling healthcare processes 571

Modeling healthcare processes 573

Modeling healthcare processes 575

ADT Patient registration RAD 1. RAD 12

RAD 1. RAD 12 RAD-5 Acquisition modality RAD-3, RAD 48 Order placer

Performed procedure step manager RAD-20, RAD-21, RAD-6, RAD-7

RAD-14, RAD-16 Image manager/archive

Figure 1. SWF actors and transactions between actors

Modeling healthcare processes 577

Modeling healthcare processes 579

ADT Register/admit patient

Department system scheduler/order filler

Image manager/ Imange archive

Create Order Placer Order Mgmt New (RAD 2)

Scheduler procedure and/or assign protocol Procedure scheduled (RAD 4)

Stage commitment (RAD 10)

Images availability query (RAD 11)

Figure 2. The SWFs administrative and procedure performance process ows

Order status update (RAD3)

Define orchestrated processes

Identify system actors

Modeling healthcare processes

Figure 3. Process for developing the models

Modeling healthcare processes 583

Figure 4. Scheduling procedure (part of department system scheduler) in BPEL

Modeling healthcare processes 585

Figure 5. Relationship type denition for the SWF

Modeling healthcare processes 587

Figure 6. Graphical choreography description for the SWF generated in Pi4SOA

Modeling healthcare processes 589

Modeling healthcare processes 591

Modeling healthcare processes 593

Modeling healthcare processes 595

Modeling healthcare processes 597

Das könnte Ihnen auch gefallen