healthcare processes

Modeling healthcare processesas service orchestrations

and choreographiesMorad Benyoucef, Craig Kuziemsky, Amir Afrasiabi Rad and

Ali ElsabbahiTelfer School of Management, University of Ottawa, Ottawa, Canada

Abstract

Purpose – Service-oriented architecture is becoming increasingly important for healthcare deliveryas it assures seamless integration internally between various teams and departments, and externallybetween healthcare organizations and their partners. In order to make healthcare more efficient andeffective, we need to understand and evaluate its processes, and one way of achieving that is throughprocess modeling. Modeling healthcare processes within a service-oriented environment opens up newperspectives and raises challenging questions. The purpose of this paper is to investigate one of thesequestions, namely the suitability of web service orchestration and choreography, two closely relatedbut fundamentally different methodologies for modeling web service-based healthcare processes.

Design/methodology/approach – The authors use a case-based approach that first developed a setof 12 features for modeling healthcare processes and then used the features to compare orchestrationand choreography for modeling part of the scheduled workflow.

Findings – The findings show that neither methodology can, by itself, meet all healthcare modelingrequirements in the context of the case study. The appropriate methodology must be selected afterconsideration of the specific modeling needs. The authors identified usability, capabilities, andevolution as three key considerations to assist with selection of a methodology for healthcare processmodeling. Further, sometimes one method will not meet all modeling needs and hence the authorsrecommend combining the two methodologies in order to harness the benefits of modeling healthcareprocesses 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 comparisonof the two leading service composition methodologies within the healthcare context. This paperprovides some necessary formalization for process modeling in healthcare.

Keywords Healthcare, Process modeling, Web service, Orchestration, Choreography, Work flow,Internet

Paper type Research paper

1. IntroductionHealthcare delivery is becoming increasingly complex as it shifts from care delivered bya single provider and setting to collaborative care delivered by multiple providersacross multiple settings. The Institute of Medicine’s (2001) study “Crossing the QualityChasm” claims that team-based care delivery is the future of healthcare and healthcaresystem redesign includes effective use of information technology (IT) and coordinationof care across patient conditions, services, and sites of care over time (The Committee onQuality of Healthcare in America of the Institute of Medicine, 2001). Yet, currenthealthcare systems are not designed to support integrated team-based care delivery thatspans multiple providers and settings. IT is set to play a significant role in coordinatinghealthcare teams who are often separated by time and space.

The current issue and full text archive of this journal is available at

www.emeraldinsight.com/1463-7154.htm

BPMJ17,4

568

Business Process ManagementJournalVol. 17 No. 4, 2011pp. 568-597q Emerald Group Publishing Limited1463-7154DOI 10.1108/14637151111149438

However, introducing IT into healthcare has proven to be challenging owing to theunderlying complexity of healthcare processes and the number of actors involved inthose processes (Berg, 2003). Nevertheless, healthcare delivery is becoming moredigitized 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 healthcaredelivery before we can design IT to support it. However, modeling healthcare delivery iscomplex as there are different aspects of it which can be modeled. Healthcare deliverycan 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 flows througha hospital or through an emergency unit; while the micro-level represents processes atthe individual patient care level. Although they are interrelated, the micro- andmacro-levels require different modeling approaches owing to the different levels ofgranularity between them. While we have made significant progress at modeling themacro-level, examples being simulation and Markov models, we are far less advanced atmicro-level modeling using formalized methodologies and languages.

As we redesign the healthcare system and design IT to support it, we need to movefrom delivering individual products to delivering integrated services (Coiera andHovenga, 2007). From the perspective of healthcare IT, this means moving away fromdeveloping IT for separate tasks (e.g. decision support, order entry) to developingintegrated systems that support the continuity of healthcare delivery over time. Theservice-oriented architecture (SOA) paradigm and its ability to connect multiplesystems across different settings is a candidate for developing integrated healthcare ITto support micro-level team-based care delivery across different settings.

Before we can develop SOA-based systems to support team-based healthcare, weneed to model micro-level healthcare delivery to identify its automation needs. Existingresearch on SOA in healthcare has largely looked at technical and interoperabilityaspects of SOA implementation such as Mykkanen et al. (2007). Anzbock and Dustdar(2005) developed a modeling process for medical web services, but their work focusedon technical aspects of modeling and middleware development for implementing webservices. Existing research has enhanced our ability to design SOA architectures thatare interoperable at the system or technical level but there is still a need to developapproaches for SOA modeling to represent micro-level healthcare delivery. In otherwords, we need to make sure we can develop systems that are interoperable at the workprocess level. A first step to achieving that is to model healthcare delivery usingdifferent web service methodologies and languages to assess the modeling capabilitiesof these languages. That would enable us to answer basic questions such as “how do weknow a web service composition methodology is suitable for modeling a particularscenario?”

Essentially, we see three shortcomings with existing process modeling research inhealthcare. First, is that much of the existing micro-level modeling has involved ad hocmodels rather than formal methodologies and languages. Second, existing SOAresearch in healthcare has focused on technical interoperability and implementationand not modeling the actual healthcare processes. Third, there are no criteria forevaluating the suitability of web service methodologies or their languages for modelingmicro-level healthcare processes.

Modelinghealthcareprocesses

569

The overall objective of this paper is to address the above three shortcomings inorder to enhance our ability to model web services to support healthcare delivery.Specifically, we investigate the suitability of web service orchestration andchoreography, two closely related but fundamentally different methodologies formodeling micro-level healthcare processes and data flows in a service-orientedenvironment. We provide both theoretical and practical results in order to achieve ourobjective. We define 12 essential features necessary for modeling micro-level careprocesses (theoretical contribution). We then use the 12 features to illustrate thestrengths and weaknesses of orchestration and choreography and their languages formodeling a case study scenario (practical contribution).

The paper is organized as follows. Sections 2 and 3 present relevant literature. Section 2discusses business process modeling (BPM), both in general and in healthcare, and alsodiscusses the leading web service composition methodologies, orchestration, andchoreography along with their associated languages. Section 3 discusses modelingrequirements for micro-level healthcare information systems (HIS) and introduces theIntegrating the Healthcare Enterprise (IHE) initiative. Section 4 presents our findings.First, we propose a set of three categories and 12 features for modeling healthcareprocesses (theoretical contribution). Second, we use an IHE case study which isrepresentative of micro-level healthcare processes and compare the modeling capabilitiesof orchestration and choreography (practical contribution). The comparison is based uponthe 12 features from Section 3. Implications of our findings are discussed in Section 5, andconcluding remarks are presented in Section 6.

2. BPM meets web service compositionIn this section, we provide a background on BPM in the context of web servicecomposition both in general and in healthcare. We then introduce, compare, and contrastthe concepts of web service orchestration and choreography and briefly introduce theleading web service composition languages.

2.1 Business process modelingAs an extension of classical workflow management systems and approaches(Van Der Aalst et al., 2003), BPM includes methods, techniques, and tools to supportthe 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, humaninteractions or both, business process management systems provide the technologiesand standards used to implement and/or support one or more of these BPM corefunctions (Newcomer and Lomow, 2005). BPM is known to increase employeeproductivity and to reduce operational costs by automating and streamliningbusiness processes. It helps reduce development cost and effort by offeringhigh-level graphical modeling languages that allow business analysts and technicaldevelopers to quickly build and update IT systems within a particular domain ofactivity (LANDesk Software Ltd, 2006).

Organizations typically use diverse applications supported by various technologies.Sharing information among those applications can be difficult due to the differencesbetween technology platforms and data models. However, moving to a combination ofBPM, SOA, and web services introduces a service layer consisting of:

BPMJ17,4

570

. line of business services that can be aligned on a particular business domain;

. reusable technical services that can be delivered and shared across multiplebusiness domains; and

. a web services platform that permits the definition and utilization of servicesindependently from the underlying application and the technology platform.

What makes this combination unique is that it lets organizations explicitly separatebusiness process logic from other business rules (Menon and Mishra, 2007). This is incontrast with other forms of systems development where the process logic is deeplyembedded in the code of the application. In fact, separating the process logic frombusiness rules and representing business processes in a form that is easy to change andmaintain allow organizations to be more agile and flexible by quickly responding tomarket changes and seizing competitive advantage (Behara, 2006). Another benefit ofthe combination is the reduction of the impedance mismatch between IT systems andbusiness requirements, allowing business users to model business processes and thenhave the IT department provide the infrastructure to execute and control theseprocesses.

2.2 BPM in healthcareBPM has been used in healthcare to help us represent healthcare processes so we candesign systems to support those processes. Jun et al. (2009) point out that a betterapplication of process modeling is needed to provide safe, effective, timely, andpatient-centered healthcare services. Process modeling (particularly simulation models)has been helpful for evaluating and understanding healthcare processes at themacro-level by developing models such as bed usage and emergency room (ER) flows(Mohamed and Alkhamis, 2009, Sobolev et al., 2008). However, micro-level modeling atthe individual patient’s level is far less advanced. One possible reason is the difficulty ofmicro-level modeling compared to macro-level modeling. Micro-level models requireexplicit details about the data and communication flows that take place acrossprocesses and healthcare providers. An example of micro-level modeling is the work ofMalholtra et al. (2007) who developed a comprehensive model of the providers,activities, and data flows in the intensive care unit in order to identify, characterize, andreduce medical errors in that unit. But one shortcoming with their work is that it wasad hoc and did not use a formal modeling language or methodology, which makes itdifficult to implement. With ad hoc and non-standard models, it is not easy to identifyspecific 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 servemultiple purposes including systems design, education, evaluation of best practices,and communicating domain details between designers and stakeholders (Laguna andMarklund, 2004; Gemino and Wand, 2004). Aside from specific purposes of models,there are general features of healthcare delivery that models must also accuratelyrepresent. Healthcare is a very dynamic domain and process exceptions are verycommon (Eze et al., 2010). So, models must be able to evolve through extensions torepresent the changing needs of healthcare delivery. Finally, despite the automation ofhealthcare delivery, there are still numerous processes performed using multiplemodalities (i.e. manual and automated) (Blackwell, 2008). Those modalities will exist forthe foreseeable future and therefore processes need to be modeled to represent them.


571

2.3 BPM methodologies and languagesThe terms “orchestration” and “choreography” have been used interchangeably todescribe the composition of web services into business processes (Pelz, 2003; Fredlund,2006; Arroyo, 2006; Ross-Talbot, 2005). However, orchestration and choreography aredifferent with regard to their structure and application. The fundamental distinctionbetween orchestration and choreography is that the former relies on a central entity thatcontrols almost every facet of a business process, while the latter is decentralized andmore collaborative in nature with control being shared among the differentcollaborating participants involved in a business process.

2.3.1 Orchestration. Orchestration refers to an executable part of an organizationalprocess that is provided by one party and controlled locally (Mendling and Hafner,2008). Orchestration can be explained using the analogy of an orchestra consisting ofone conductor and several musicians. Being aware of the piece of music, the musicalguide or plan to be performed, the conductor leads and guides the individual instrumentplayers accordingly. The main point behind orchestration is the existence of a centralentity (i.e. the conductor), which is in complete control of the progression of the piece ofmusic. Away from analogies, orchestration refers to composing web services intobusiness processes by describing how web services may interact with each other at themessage level – including the message exchange order and the business logic of theinteraction – from the perspective and under the control of one of the participantsinvolved in a business process. Orchestration describes an executable business processthat may span departmental and organizational boundaries.

Web services orchestration defines the services that compose the orchestration andthe order in which these services should be executed. The orchestrated process can beconsidered as a simple process that is itself a web service. The flow of an orchestrationtypically includes control points for branching, parallel processing, human responsesteps, and predefined 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 processexecution language (BPEL) (Alves et al., 2007). BPEL is attracting the most attentionboth in academic research and industry and is likely to become the de facto standard forweb service orchestration (Mendling and Hafner, 2008). Although BPEL does notsupport all constructs and features of the orchestration methodology, it is one of themost complete languages for modeling business processes as orchestrations (Huang,2005).

2.3.2 Choreography. Choreography refers to the message sequences betweendifferent parties in an organizational business process (Pelz, 2003). Choreography can beexplained through the analogy of dancers, assuming that there is a group consisting oftwo or more dancers who perform certain dance patterns jointly. All dancers act on thesepatterns 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 whochecks for compliance with the patterns in question. Choreography refers to linkingsub-processes (web services) for achieving a business process in a collaborative manner.It is typically associated with the public message exchanges, agreements, andinteraction rules between multiple business process participants rather than a specificbusiness process that is executed by a single participant. More specifically,choreography tracks the sequence of messages that may involve multiple parties

BPMJ17,4

572

and multiple sources (e.g. customers, suppliers, and applications) where each partyparticipating in the process describes the part it plays in the interaction and no partyowns the conversation. Choreography is a common view used to determine a specificdeployment implementation for each individual business process participant.Furthermore, since choreography offers a mean by which the rules of collaborationcan be clearly defined and agreed to jointly, each participant can implement its portion ofthe choreography as described in the agreed upon common view.

Web services choreography defines business interactions by formalizingdescriptions of the peer-to-peer message exchange protocols. Such formalizationspecifies the visible message exchange behavior of each peer without revealing internalimplementation details. The public and private aspects of the business process aretherefore separated. This enables organizations to hide their internal business processesand data management from their business partners, and allows for changing privatedetails of the internal process without affecting the protocol or the collaborationagreement.

Several languages have been proposed for choreography including WSCL (Banerjiet al., 2002), WSCI (Arkin, 2002) or BPSS (Clark et al., 2001). The World Wide WebConsortium has recommended WS-CDL (Kavantzas et al., 2004) as a new standard forthe specification of global choreographies based on web services.

Note that while choreography focuses on defining how multiple parties collaborate ina peer-to-peer manner by exchanging messages with trading partners and externalorganizations, the focus of orchestration is on defining composite services and internalprocesses that use existing web services.

3. Modeling micro-level healthcare systemsAs described in Section 1, the micro-level of healthcare delivery represents processes atthe individual patient level. Developing HIS to support micro-level healthcare delivery isdifficult because processes such as decision making or information exchange arecomplex and must support highly integrated and personalized healthcare viamultidisciplinary teams located in different settings (Avison and Young, 2007).The micro-level is largely based on collaborative healthcare delivery consisting ofmultiple providers, locations, and information flows that span diverse organizations andgroups. The complexity of micro-level processes is owed to the integration of healthcareworkflows, the collaboration between the diverse medical departments, and the largenumber of data transactions which take place between healthcare units andcollaborating actors.

Micro-level collaboration has been represented by conceptual frameworks such asthose of D’Amour et al. (2005), D’Amour et al. (2008) and Leggat (2008). Studies have alsopresented frameworks for collaborative healthcare needs from a software engineeringperspective (Kuziemsky et al., 2010). These frameworks are helpful in that they identifythe process and data needs of collaborative healthcare delivery. In particular, theyidentify two key aspects that must be represented in process models to characterizemicro-level healthcare delivery: data exchange and process flows. Those two aspectsare essential because healthcare process modeling must define the processes that takeplace, the data exchange within the processes, and how the processes and data relate(Kuziemsky and Lau, 2010). Process considerations include integration, exceptions, andcollaboration across different providers while data exchange considerations include


573

security, privacy, and modularity. However, one shortcoming of these frameworks isthat they have not been formally represented as a set of modeling requirements nor havethey been modeled with modeling methodologies and languages.

An essential aspect of micro-level healthcare delivery is the need for integration ofboth data and processes (Kuziemsky et al., 2010). The SOA approach is an effective wayto provide that integration (Dang et al., 2008). Although research has done a good job ofdesigning SOA-based applications that are interoperable at the system or technicallevel, there is still a need to develop approaches for modeling SOA based applications torepresent micro-level healthcare delivery.

In the remainder of this section, we describe data exchange and process flows andelaborate on their importance for modeling micro-level healthcare delivery. We thenpresent the IHE initiative as a framework for modeling the complexity of micro-levelhealthcare delivery.

3.1 Data exchangeData are the lifeblood of healthcare and it is essential that the right data be available forthe right task at the right time. A challenge to data exchange in healthcare is that thereexist many different types of HIS including picture archiving and communicationsystems (PACS), radiology information systems, laboratory information systems,dietary, pharmacy, and billing systems, electronic medical record (EMR), and electronichealth record (EHR) systems. Each HIS acts as a different channel for data exchangeand thus data integration between the different HIS is essential and is typicallyachieved by the use of protocols or communication standards such as digital imagingand communications in medicine (DICOM), and Health Level Seven (HL7). DICOM wasdeveloped by the American College of Radiologists and the National ElectricalManufacturers Association for the purpose of handling imaging data with a focus onthe workflow of medical images (Oosterwijk, 2004). HL7 provides protocols forexchanging information between various non-imaging medical applications by definingthe format and the content of the messages that these applications ought to use whenexchanging data with each other. HL7 provides for interoperability between differenttypes of HIS including PACS, PAS, and EMR or EHR systems[1].

3.2 Process flowsA large part of micro-level healthcare delivery consists of the clinical processes that takeplace as part of day-to-day healthcare delivery. It is essential that such processes beadequately represented in process models. However, developing micro-level processmodels can be difficult given the multiple providers that interact as part of team-basedhealthcare delivery. Thus, we need to be able to represent the complex process flows ofindividual providers while also promoting interoperability between different systemsand 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 healthcareprocesses are very tight with each other. An evolution of one process belonging to onedepartment will have an incremental effect on other processes whether they belong tothe same department or not.

BPMJ17,4

574

3.3 The IHE initiativeThe IHE initiative was created for improving the way HIS interoperate and share data.IHE is a set of healthcare workflows including the data and processes within theworkflows. It is intended to drive the adoption of data standards such as HL7 andDICOM to facilitate daily clinical and healthcare operations (IHE Inc., 2007).

The IHE technical framework contains three main concepts: actors, transactions, andintegration profiles. These are detailed below:

(1) Actors. HIS that produce, manage or act on information are represented by IHEas functional units called actors. Each actor supports a specific set of IHEtransactions. A given HIS may support one or more IHE actors.

(2) Transactions. Exchanges of information between actors using messages basedon established standards such as HL7 and DICOM are called transactions.

(3) Integration profiles. An integration profile is a set of IHE actors and transactionsrequired to address a particular clinical task or need. Integration profiles areorganized by healthcare domains (e.g. radiology, radiation oncology, researchand public health, patient care devices) (IHE Inc., 2007). Each domain consists ofa set of workflows, for instance the radiology domain encompasses a total of18 workflows.

The IHE initiative is a good representation of complex healthcare workflows includingthe data and process integration inherent to those workflows. In particular, the IHEworkflows represent day-to-day clinical care and thus capture micro-level healthcaredelivery. Developing and implementing healthcare systems in accordance to the IHEtechnical frameworks and workflow profiles not only permits different systems tocommunicate with each other but also enables different healthcare providers to usemedical information more effectively[2] (IHE Inc., 2007).

An example of an IHE integration profile is the scheduled workflow (SWF) whichincorporates all the process steps in a typical scheduled patient encounter fromregistration, ordering of diagnostic images, image acquisition, and examination andviewing. The SWF specifies a number of transactions related to patient and orderinginformation in addition to defining the scheduling and imaging acquisition proceduresteps. The SWF also provides temporal reasoning of workflows such as determiningwhether images associated with a particular procedure have been archived and areavailable to enable subsequent workflow steps, such as reporting (IHE Inc., 2007). TheSWF 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 dataexchange within micro-level healthcare delivery. Figure 1 shows the eight actorsinvolved in the SWF and how they are connected to each other through varioustransactions (e.g. RAD-1, RAD-49). The SWF example will be revisited in the followingsection as a case study.

4. ResultsOur findings are presented in two sections. First, we identify a list of three categoriesand 12 essential features for modeling healthcare processes. Second, we use the list ofcategories and features to compare and contrast the modeling of the SWF usingorchestration and choreography. We summarize the results in Section 4.3 with a tablethat compares the modeling of orchestration and choreography.


575

4.1 Essential features for modeling healthcare processesIn this section, we identify 12 features that we believe are essential for modelingmicro-level healthcare processes. The features are a compilation of the literature fromSections 2 and 3 based on the strengths and weaknesses of modeling languages in areasinside and outside of healthcare, as well as existing frameworks for collaborativehealthcare delivery. The features address the shortcoming identified 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 D’Amour et al.(2005), D’Amour et al. (2008), Leggat (2008) and Kuziemsky et al. (2010).

As we compiled the list of features, we realized that there were three essential needsthat a modeling language must have: usability, capabilities, and evolution. We usedthose three needs as categories to group the 12 features. Each category and its featuresare described below.

Category 1: usability. Drawing on usability in the information systems and softwareengineering literature, this category refers to how easy it is to use and understand amodeling language (Nielsen, 1992). The complexity of healthcare delivery has led toincreased application of user involved analysis and design methods such as participatorydesign (Spinuzzi, 2005). User involved methods call for an ongoing collaboration betweenthe developers and end-users of the system, including the development of business

Figure 1.SWF actors andtransactions betweenactors

ADTPatient

registration

Departmentsystem

scheduler/orderfiller

RAD 1.RAD 12

RAD-5 RAD-3,RAD 48

RAD-6,RAD-7

RAD-10,RAD-8

RAD-20,RAD-21

RAD-10,RAD-18

RAD-12,RAD-13,RAD-4,RAD-42

RAD-11,RAD-42,RAD-49

Imagedisplay

RAD-14,RAD-16

Imagemanager/archive

Source: Taken from the IHE web site (IHE Inc., 2007)



Evidencecreator

Performedprocedure

stepmanager

RAD-2

Orderplacer

Acquisitionmodality

RAD 1.RAD 12

BPMJ17,4

576

process models. Therefore, language usability across different players is necessary.With respect to modeling languages for healthcare, we identified the following fourusability features:

(1) Tool Support. Languages will be more widely used if user friendly tools areavailable to assist with modeling. A modeler’s ability to create models throughgraphical tools will positively impact the use of the language. This is especiallytrue in healthcare where most model users are neither tech savvy nor ITspecialists. Thus, the availability of graphical tools will definitely increase theuse of the modeling language within healthcare.

(2) Ease of use. If a modeling language is overly complex it will negatively impact amodeler’s desire and ability to use the language. Part of the reason ad hoc modelsare appealing is because they are easy to design and share with people. Modelsmust also be understandable by physicians, nurses, administrators, and otherhealthcare personal. Modeling languages with cryptic syntax will not have theappeal of less complex languages. As more participatory design methods areused for designing healthcare IT, there will be a need for languages to beunderstandable by both systems designers and users. Although languagestructure and syntax have a huge impact on ease of use, the tools that support alanguage will usually determine (to a certain degree) how easy it is to use.

(3) Scalability. Healthcare enterprises involve complex processes that span diversegroups and organizations. These processes involve clinical and administrativetasks, large volumes of data, and large numbers of patients and personnel.Moreover, the healthcare sector is dynamic in nature and is known for itsconstantly changing behavior. As such, healthcare delivery and the IT thatsupports it are not static but rather they grow and evolve as needs change (Coieraand Hovenga, 2007). In such an environment, only scalable languages can beeffectively used. Whether or not a language is able to represent a range of simpleto complex systems, can keep up with the growing nature of the business, andallows adding new features and components, will certainly impact its usability.

(4) Ease of monitoring. Monitoring deals with the analysis of workflow instances atrun-time. Active monitoring of the current state of workflow instances can servenumerous purposes, such as the generation of exception reports for overduework items or early warning reports for potentially overdue work items(zurMuehlen and Rosemann, 2000). Performance management is becoming anecessity for healthcare delivery (Coiera and Hovenga, 2007). Since unusual andundesired situations are common in healthcare, process monitoring seemsnecessary so that managers can easily be kept informed of those situations. Theextent to which a language supports process monitoring impacts its usability.

Category 2: capabilities. Capabilities refer to the features a modeling language musthave to adequately represent healthcare processes. These capabilities were derivedfrom the literature presented in Section 3 on collaborative healthcare delivery at boththe process and data levels, particularly the need to support collaborative healthcaredelivery where multiple healthcare providers are involved. The capability featuresinclude both technical features such as abstraction, security, and privacy, as well ascollaborative features needed to represent the processes of micro-level healthcare


577

delivery such as exception handing, peer-to-peer representation, and distinguishinghuman vs automation task completion. With respect to modeling languages forhealthcare, we identified the following six capability features:

(5) Abstraction. Here, abstraction means the ability to focus on processes at theabstract level rather than at the detail level (e.g. programming constructs). Theability to represent processes while hiding their detailed information helps indelivering a global view of the workflow. This happens to be a requirement inmost domains but even more so in healthcare where individuals from variousdisciplines require an abstract way to represent (i.e. model) processes. With ahigh 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 forhealthcare systems development. Since models are the blueprint of systems, theyshould represent security features as well. Security is even more critical whendeveloping systems based on SOA principles. Indeed, interactions which areinherent 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 growingdemand for embedding privacy features in modeling languages. Privacy is vitalin healthcare as most processes involving interactions with other organizationssuch as insurance companies, police departments, external laboratories, andother healthcare enterprises, carry private patients’ data as well as privateimplementation details about internal processes.

(8) Exception handling. Healthcare processes do not always follow a structuredsequence because exceptions are common. If models are to accurately representhealthcare delivery then modeling languages must be able to representexceptions 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 modelinglanguage to represent collaborations (e.g. collaboration between different careproviders, departments, suppliers, and insurance companies). The ability torepresent collaboration is crucial as more and more healthcare services aredelivered by teams. Further, individual processes may have multiple users andprocesses as part of collaborative care delivery. To date the modeling andimplementation of team-based IT has proven to be challenging because we donot have the means of accurately modeling collaboration.

(10) Human vs automation. This feature refers to the language’s suitability formodeling healthcare processes involving both computer and humaninteractions. Although healthcare is becoming increasingly automated, thereare still and likely always will be processes that are performed by humans.Human interactions in a business workflow can be as simple as approving a taskor as complex as a chain of interactions and decision making among severalparticipants. Most modeling languages are capable of representing the simpleinteractions that involve one human actor and require basic actions such asapproval or confirmation, but the ability of modeling languages varies when itcomes to more complex tasks involving multiple human actors. In some cases,different actors perform tasks which are assigned to others. As a result, human

BPMJ17,4

578

tasks are not normally assigned to users but rather to roles, and human actorstake those roles.

Category 3: model evolution. Model evolution is the extent to which a model can evolvein its domain of use. Models are often reused in order to share successfulimplementations and they should also be maintainable at a reasonable cost. The twoevolution features are explained below:

(11) Reusability. This feature allows modelers to describe a large set of interactionsspanning multiple healthcare actors by a relatively small number of reusablemodeling constructs. This, along with modularity and the language’s support forloose coupling and composability, make it possible to create reusable healthcareprocess models quickly and with less effort. Note that reusability is an SOAprinciple that is necessary to enable the transfer of successful models acrossdifferent sites (Wright and Sittig, 2008). The need to build reusable processmodels is crucial in order to avoid the time, cost, and effort needed each time aprocess has to be rebuilt from scratch, or each time a similar process model has tobe created. Reusability in healthcare modeling is driven by the principle of loosecoupling and has a positive effect on process maintainability.

(12) Maintainability. Healthcare processes and their underlying data can change veryquickly. Thus, the following types of maintenance are required for healthcaresystems 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 fulfill a model’s maintainability requirements is theability of a modeling language to allow the internal and external integration of modelsafter they have been developed. This feature enables modelers and applicationdevelopers to specify interactions between different healthcare services within one ormore healthcare entities, while leaving implementation decisions in the hands of eachhealthcare entity modeler. This fosters the creation of global healthcare models.

4.2 Case study – modeling the SWFIn this section, we use the 12 features described previously to compare and contrastmodeling of the SWF using orchestration and choreography. The SWF being a largeworkflow, we have limited our modeling to the “admission process”, one of the SWF’sinternal processes. We started by modeling the interactions of healthcare units fromFigure 1 as a UML sequence diagram (Figure 2). The sequence diagram captures theinteraction flow and its timing between services on patient admission when a request ismade to perform an imaging procedure on a patient. UML sequence diagrams are usedto represent workflows, especially when there are many transactions involved.In addition, knowing the transmitted messages and their flow will help create robust


579

communication protocols in a choreographed model. Knowing the process actors andinteractions enables us to map the entities to the actors.

Figure 3 shows the steps we followed for developing the models. These steps aredetailed here. After identifying the actors and the flow of messages in the SWF, thechallenge is to identify the most suitable language and tool that support mostrequirements for modeling the SWF. We chose BPEL (NetBeans-BPEL as a tool) andWS-CDL (Pi4SOA[3] as a tool) because they are the most prominent web servicesmodeling languages as described in Sections 2.3.1 and 2.3.2. Next, to model theorchestrated process, we needed to determine the central process responsible forcoordinating the workflow. The central process usually has the highest amount ofcommunication and the highest number of connected processes. But sometimes, as inthe case of the SWF, no single process can act as a central process; hence the need to

Figure 2.The SWF’s administrativeand procedureperformance process flows

ADTADT Order PlacerDepartment system scheduler/order filler

Image manager/Imange archive

Acquisition modality

Register/admit patient

Patient

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)

Order status update (RAD3)

BPMJ17,4

580

Figure 3.Process for developing

the models

Iden

tify

syst

emac

tors

Iden

tify

mes

sage

flo

w

Sele

ctm

odel

ing

lang

uage

s an

dto

ols

Orc

hest

ratio

n

Cho

reog

raph

y

Def

ine

cent

ral

proc

ess

Def

ine

orch

estr

ated

proc

esse

s

Dev

elop

mod

elM

odel

asse

ssm

ent

Mod

elpr

oces

ses

and

inte

rfac

es

Def

ine

com

mun

icat

ion

prot

ocol

s


581

create one. For choreographies, there is no such problem as each process actsindividually. However, the difficulty is to introduce and implement communicationprotocols which all processes have to obey. The protocols should be flexible enough tolimit the extent of modification during maintenance. Finally, the developed models areassessed 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 ofmodeling are discussed according to the 12 features introduced in the previous section.

4.2.1 Orchestrating the SWF. The first step in modeling a workflow-basedorchestration process is to analyze the business requirements of the project. The goal ofthis step is to understand the business requirements, and to determine the services andprocesses that are involved in the workflow as well as types of interactions betweenprocesses. However, the ultimate result of this step is to gain a thorough understandingof the requirements for the orchestrating process in order to produce a complete plan forits development (Zhong, 2008). The second step involves determining thecommunication method between orchestrating and orchestrated processes whichincludes defining information types, variables, interfaces, communication channels, andmessage types. Since orchestration is all about partners, and how they interact with theorchestrating process, the first two steps are key for modeling the workflow (Zhong,2008). The selection of a modeling language depends on the complexity of workflow andthe model requirements. For the purpose of our case study, we selected BPEL as themodeling 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 threecategories and 12 features from Section 4.1.

Category 1: usability:

(1) Tool support. BPEL is supported by numerous tools including eclipse BPELDesigner (www.eclipse.org/bpel), Netbeans (www.netbeans.org), ActiveBPELDesigner (www.activevos.com), and Oracle BPEL Process Manager (www.oracle.com). The wide variety of tools supporting BPEL increases itsaccessibility, encourages its evolution, and helps improve its functionality.

(2) Ease of use. When using orchestration, a central process coordinates the flow ofinteractions and workflows in the whole process model. Other related processesappear as services and business partners. For instance, we can map an IHE actorsuch as “SWF Order Placer” to a BPEL business partner, and an IHE flow suchas “patient registration process flow” to a BPEL process. The fact that one of thesystem’s internal processes (patient admission in the SWF) acts as the centralprocess contributes to the clarity of the whole process. This increases thelanguage’s ease of use. Similar to procedural programming, orchestration lowersthe modeling language’s learning curve. It makes the modeling language easierto understand and facilitates model development even in the absence ofsophisticated tools.

(3) Scalability. Healthcare process sizes range from very small to very large, theSWF being one of the large processes. Orchestration and BPEL have beentested for small to medium processes but there is no evidence that theyadequately support large processes. Considering the fact that orchestration

BPMJ17,4

582

requires significant resources at the central entity, the central process canbecome overloaded when modeling a large process. Moreover, orchestrationdoes not properly support the dynamic growth of workflows due to theincrease in required resources and the eventual need to modify the centralprocess to embed new activities.

(4) Ease of monitoring. Orchestration allows for easier monitoring of healthcareprocess activities since there is a single entity in control. This enables theefficient monitoring of message exchanges between the parties involved in aparticular healthcare process.

Category 2: capabilities:

(5) Abstraction. BPEL, being an execution language, is not designed to provide allthe process flow features necessary for representing abstract entities. Lack offull support for abstraction adds to the complexity of the models. Orchestratingprocesses in BPEL requires a significant effort since every part of the model isfirst analyzed and designed with a predefined structure. From a top level view,the model contains a central process and transactions with sub-processesrepresenting healthcare units and departments. Sub-processes themselves areimplemented as central processes and are shown in Figure 4. Developing allexecution-related variables for a process model where we only seek to representa global view is difficult and time consuming.

(6) Security. BPEL contains no constructs to represent task-level or process-levelsecurity in models; neither does it provide a complete secure collaborative basisin the execution. Although WS-Security (Nadalin et al., 2004) can be embedded inmessages transmitted between services, it does not provide representationalaspects. As a language designed for executing services, BPEL can leverageextensions (plug-ins) that offer added security features. However, theseextensions, which contain representational aspects, require extra learning timeand effort. Moreover, not all orchestration tools support extensions. Finally, andto the best of our knowledge, none of the proposed extensions is complete enoughto be certified by the organizations supporting BPEL.

(7) Privacy. In most healthcare scenarios, processes carry patients’ private data aswell as details about the implementation of internal processes. In this context,orchestration has a drawback since all involved processes and even externalservices should share a reasonable amount of design information with theorchestrating process, so the organization’s internal structure and businessprocesses must be exposed to other parties. It should be noted that BPEL doesnot provide constructs for modeling privacy.

(8) Exception handling. BPEL’s basic features (Alves et al., 2007) and activities canbe used to model the environmental attributes, the IHE actors and their relevanttransactions. The transactions between processes are managed by the, invoke . and , receive . activities in addition to a set of otherconstructs. For a large process like the SWF, some consideration should begiven to exception handling. In the SWF, the HL7 A11 and A01 messages aredefined to handle exceptions and control errors. BPEL provides some featuresfor exception handling through its compensation constructs (Tai et al., 2004).


583

Fault handlers were introduced in the BPEL specification to cope withexceptional situations during process modeling and execution. Exceptionhandling mechanisms introduced in BPEL are rather complex since BPELsupports fault handling at different levels (i.e. activity, process, and scope). Inaddition to BPEL’s fault handling features, other extensions add exceptionalhandling features such as prepackaged BPEL error handling (www.karmaticit.com/).

(9) Peer-to-peer representation. Although BPEL can represent choreographies to someextent, it lacks the semantics of peer-to-peer interactions. BPEL can only define theinformation formats exchanged by one participant. Moreover, BPEL only takesthe perspective of one party in the collaboration, and that party should coordinate

Figure 4.Scheduling procedure(part of departmentsystem scheduler) inBPEL

BPMJ17,4

584

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 collaborativehealthcare processes.

(10) Human vs automation. Although BPEL specification by itself does not directlyaddress human interactions, BPEL can still be used for modeling humanworkflows as part of the main process. People and their assigned tasks are seenas separate asynchronous services or processes from the viewpoint of theorchestrating process. BPEL supports human interactions by extensions to thelanguage specification such as BPEL4People (Agrawal et al., 2007). Note thatextensions increase the complexity of the modeling language and decrease thereadability of models.

Category 3: model evolution:

(11) Reusability. Orchestrated and orchestrating processes are tightly related, in away that orchestrated processes may share their internal processes with theorchestrating process in order for the central process to manage the process flow.This interdependency limits the ability to reuse the processes in different modelsbecause they are designed to complete each other. Healthcare systems aredynamic and new technologies are frequently introduced. As a result, modelsoften change, and reusing previous models becomes important. But, due to thetightly connected nature of orchestration, BPEL does not provide reusablemodels and model components.

(12) Maintainability. The fact that there always exists a central process (here, patientadmission in the SWF) in orchestrated systems contributes to the clarity of theoverall process. However, any changes to the services that interact with thecentral process will often result in modifications in the central process. Thissituation is more challenging when new services are added to the system duringmaintenance. New services introduce many interactions with the system likelyresulting in remodeling the central process. Since the central process is thelargest and most complex process in the system and it coordinates thefunctionality and interactions of the services, alternating and remodeling it canbe costly. Therefore, the existence of a central process limits the flexibility of themodel and increases the difficulty and cost of its maintenance.

4.2.2 Choreographing the SWF. Before modeling a process using a choreographylanguage such as WS-CDL, the process participants, their roles, and their relationshipsmust be clearly identified. The next step is to develop interactions, information andinformation types, tokens and token locators, channels and channel types, variables,and choreographies (Hangli et al., 2006). To build our choreographies of the SWFprocess we used Pi4SOA[3], a plug-in which creates a WS-CDL modeling environmentfor eclipse[4]. Pi4SOA provides graphical features for modeling roles and relationshipsin systems. Figure 5 shows the relationship types defined for the model representing theSWF. The final step is to create variables and values and to generate the choreographydescription. Figure 6 shows the graphical representation of the choreography generatedby Pi4SOA for the selected part of the SWF.

The resulting model provides an example of the high-level view of processesexpected in a choreographed model. This high-level view influences the composability


585

and reusability of choreographed models; allowing for a model’s high-level view and adetailed view depending on the purpose of modeling.

We now describe choreography of the SWF according to the three categories and12 features from Section 4.1.

Category 1: usability:

(1) Tool support. To the best of our knowledge, choreography has not beenextensively used in the context of healthcare process modeling. One possiblereason 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 processesto be developed separately, and WS-CDL fosters ease of use by defining theinteraction protocols of these processes. However, the lengthy WS-CDL documentscan be hard to understand and analyze by non-IT healthcare participants.

(3) Scalability. The decentralized nature of choreography permits the realization ofhigher scalability levels since it allows for finding partners independently,negotiating, and deploying service orchestration definitions without the need of a

Figure 5.Relationship typedefinition for the SWF

BPMJ17,4

586

Figure 6.Graphical choreographydescription for the SWF

generated in Pi4SOA


587

central entity. Therefore, if the overall business process is highly resourcedemanding, the load will be shared among the involved parties. This willfacilitate the modeling of large and resource demanding processes. Also, thedistributed nature of choreography makes it easy to handle the growth of theprocess. However, to the best of our knowledge, WS-CDL has not beenextensively tested for its support of very large processes.

(4) Ease of monitoring. Process monitoring in choreographed models is difficult fortwo reasons. First, since choreographies consist of several standalone processesand their communication protocols, the negotiated choreography scripts mustalways be available to be interpreted and compared to the actual flow sequenceby all involved parties. Thereby, monitoring the flow of the process becomescomplicated and the risk of errors may increase. The second problem is that, as amodeling language, WS-CDL is not designed to support process execution, somonitoring processes in WS-CDL is not part of its expected capabilities.

Category 2: capabilities:

(5) Abstraction. Different components of the choreographed process model aredeveloped independently and no entity is aware of the internal processes of theother entities. In fact, hiding detailed information of the entities involved in aprocess is one of the features of WS-CDL which allows for developing high-levelabstract views of the complete workflow 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 reflected as security exceptions, WS-CDL, as amodeling language for healthcare processes, should represent securecommunications.

(7) Privacy. Since choreographies define communication protocols among processesand involved processes are completely standalone, a healthcare organization canseparate the public aspects of its processes from their private aspects.Choreography enables healthcare organizations to not reveal their internalbusiness processes and data management to their business partners, thusallowing for higher levels of privacy.

(8) Exception handling. WS-CDL provides a complete set of exception handlingfeatures. It can recognize and handle as much as six types of errors that mostlyoccur at the message passing and interaction phase of a model. WS-CDL,however, does not provide complete support for errors happening insidechoreographed entities. But, choreographed entities, themselves, consist ofchoreographies. Therefore, it is legitimate to conclude that the exceptionhandling feature of WS-CDL provides enough support for the healthcare domain.

(9) Peer-to-peer representation. Choreography is naturally based on peer-to-peerinteraction, and therefore WS-CDL as a choreography language is capable ofrepresenting these interactions.

(10) Human vs automation. Like BPEL, WS-CDL does not support human interactionin its original version. Human tasks can be represented in the model in the formof services or processes. However, since WS-CDL does not provide any executionfeature, it can be easily extended to support additional capabilities. As a result,

BPMJ17,4

588

many research initiatives proposed extensions to incorporate humaninteractions in WS-CDL models. There are also proposals to combine WS-CDLwith other modeling languages such as UML to overcome this limitation.

Category 3: model evolution:

(11) Reusability. WS-CDL defines the interaction protocols of independent entitiesalong with their descriptions. Since the components have been developedindependently, they can easily be separated from the workflow and be added toother models or systems, or integrated with new protocols. Overall, WS-CDLfosters a high level of reusability.

(12) Maintainability. WS-CDL choreographies are composed of reusable entities withtheir associated interaction protocols. Thanks to WS-CDL’s loose coupling, allfour types of maintenance can be performed on WS-CDL models by modifyingthe related parts of the models without affecting other components.

4.3 Summary of resultsIn Table I, we show a comparison of BPEL and WS-CDL based on the 12 essentialfeatures for modeling healthcare processes identified in Section 4.1. The comparison isbased on the ability of each language to model the SWF admission process as describedin Sections 4.2.1 and 4.2.2.

5. DiscussionThis is the first paper to analyze the ability of orchestration and choreography and theirassociated languages for modeling healthcare processes. For that, and based on anextended analysis of the literature, we developed a set of three categories and12 features that we believe are essential for modeling healthcare processes, particularlymicro-level processes. We then used the proposed features to assess orchestration andchoreography for modeling a case study scenario from the IHE framework.

Our findings have both research and practical implications. For researchimplications, we showed that there is no perfect web service modeling language for

Category Feature

Business processexecution language(BPEL)

Web services choreographydescription language(WS-CDL)

Usability 1. Tool support Satisfactory Unsatisfactory2. Ease of use Partially satisfactory Partially satisfactory3. Scalability Unsatisfactory Partially satisfactory4. Ease of monitoring Satisfactory Unsatisfactory

Capabilities 5. Abstraction Unsatisfactory Satisfactory6. Security Unsatisfactory Unsatisfactory7. Privacy Unsatisfactory Partially satisfactory8. Exception handling Satisfactory Satisfactory9. Peer-to-peer representation Unsatisfactory Satisfactory

10. Manual vs automatedprocessing

Unsatisfactory Unsatisfactory

Model evolution 11. Reusability Unsatisfactory Satisfactory12. Maintainability Unsatisfactory Satisfactory

Table I.Comparison of BPEL andWS-CDL for modeling the

SWF admission process


589

healthcare. BPEL and WS-CDL both have their strengths and weaknesses as outlined inTable I. The appropriate methodology must be selected after consideration of thespecific healthcare modeling needs. For practical implications, our findings haveprovided insight for understanding and modeling micro-level healthcare delivery. Inparticular, a key practical implication is that we have formalized modelingrequirements for micro-level healthcare systems. Although other studies (Leggat,2008; Kuziemsky et al., 2010) have described the need for micro-level support, theseneeds have not been represented through formalized modeling approaches. However,detailed micro-level models are necessary to serve as requirements for the design ofclinical information systems to support micro-level healthcare delivery. Micro-levelmodeling requires attention to be paid to the individual processes, the characteristics ofthe processes (i.e. exceptions, peer-to-peer exchange, security) and the different types ofusers (i.e. clinical, administrative) who take part in those processes.

A key step in healthcare process modeling is the identification of an appropriatemodeling methodology. The three categories and 12 essential features for modelinghealthcare processes that we identified can assist with the selection of a methodologyfor healthcare process modeling. We suggest they provide some formalization forhealthcare process modeling and can serve as a meta-model for analyzing modelingsituations 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 theirassociated languages for different healthcare process modeling situations.

i. UsabilityHealthcare process modeling is used for a broad range of applications and purposessuch as building descriptive models for training and learning. These types of modelsare usually meant for users like nurses, physicians or administrative personnel whohave limited or no modeling experience. Hence models must be understandable bymultiple users and useable for different purposes. Healthcare processes are complex andtheir 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 bedivided into smaller and less complicated ones. In that sense, choreography seemsbetter suited for coping with complexity as it enables breaking down the overall processinto sub-processes that can be described graphically or textually with fewer technicaldetails. Too much detail in a model can be confusing for non-expert users, consequentlyreducing the usability of the model.

Also, linked to the complexity of models (in building, analyzing and monitoringthem) is the way the two web service modeling languages represent control flow.Studies in Decker et al. (2006)[5] indicate that BPEL and WS-CDL do not representcontrol flow, communication, and data flow patterns. A lack of support for certainpatterns 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 torepresent workflow and ontological patterns required for healthcare modeling, showingthat 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 constructsneeded for modeling healthcare workflows and processes are missing. The studyhowever shows that WS-CDL supports more patterns than BPEL.

BPMJ17,4

590

When building models for process execution and implementation, orchestrationthrough BPEL has an advantage over choreography through WS-CDL because themodels are meant to be deployed and enacted. BPEL models are executable and lesschallenging to implement by IT staff, while very few tools are available to technicalpeople for implementing WS-CDL models. However, it should be noted that there are farmore choices for BPEL model development tools than there are for WS-CDL, so theprobability of finding the right modeling tool that supports all the process andworkflow needs increases with the choice of BPEL as the modeling language.

ii. CapabilitiesFrom a departmental structure point of view, a key capability decision is thelevel of peer-to-peer representation, specifically whether intra-departmental orinter-departmental workflow and communication are needed. Choreography andWS-CDL are better if the process to be modeled is inter-departmental and spans multipledepartmental and organizational boundaries. However, if the process to be modeled isintra-departmental (i.e. the scope of the process remains inside a specific department)then orchestration and BPEL are better for modeling.

The implementation of capabilities such as peer-to-peer representation also differsacross the two modeling methodologies. Using choreography means that the web servicesused to compose healthcare processes will be published and interconnected independentlyfrom central instances. Healthcare partner retrieval, the negotiated choreography, and thepeer process creation are performed in a peer-to-peer manner. So, the choreographyapproach requires all healthcare units involved in a particular process to install a softwarepackage locally (which includes process and sub-process templates, templates,repositories, and possibly BPEL generation tools) in order to ensure the seamlessinteroperability of the corresponding local applications. Thus, the complexity inherent topartners’ applications is relatively high since local installations may be major hurdles tothe rapid adoption of choreography designed systems. The orchestration approach freeshealthcare units or departments from the installation of any local applications (only thedata adapters and the encapsulation of applications as web services are required in thiscase) since a BPEL orchestration engine (central entity) is usually responsible forinvoking 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 usingchoreography, the privacy of each department’s internal processes should be ensuredwhile developing abstract process interfaces. Meanwhile, the security and integrity ofcommunicated data should be considered in the development of interaction protocols. Inorchestration, the seamless interoperability across healthcare departmental borders isfacilitated by the existence of an orchestration engine. Healthcare processes and datatemplates are stored in one place (e.g. the BPEL server) where they can be changedquickly if needed. However, this is an important drawback in most healthcare processeswhere processes contain internal private workflows and the process owners want topreserve process privacy.

Another capability requirement is the ability to manage the integrity and consistencyof healthcare interactions and to deal with compensation and exception handling.Both BPEL and WS-CDL provide correlation and message persistence techniques andthey both support the asynchronous interactions that may happen between healthcare


591

processes exposed as web services. Although both languages have embedded featuresfor compensation and exception handling, their capabilities in this area are inadequate.Healthcare processes require adequate support in terms of exception handling foremergency and mission-critical processes. BPEL has limitations when it comes toexception 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 theprocess to reach its ending point. The situation is not better with WS-CDL whereexception handling specifications are rather weak and not clearly specified (Fredlund,2006; Kang et al., 2007). However, as mentioned earlier in this paper, neither one of thetwo languages supports the patterns that enable easy switching between manual andautomatic tasks.

iii. Model evolutionThe main concern one can think of when adopting an orchestration-centric approach tohealthcare process modeling is the risk of a “single point of failure”. Any software orhardware failure or any error that might occur at the single controlling party’s side mayaffect a whole healthcare process which may be stopped until the issue is resolved. Oncethe problem is fixed, the overall process needs to be restarted or reinitiated. In contrast, achoreography-centric approach is decentralized in nature. If an error occurs at onespecific party’s side, other parties may locate the malfunctioning party and possiblycontinue the process in a peer-to-peer manner if there is no more need for the failingparty’s inputs.

There is also an issue when a process component has to be modified for maintenance.In case of BPEL, even a single small change in one of the orchestrated processes mayresult in modifications in the central orchestrating process. On the other hand, inchoreographed processes the only modifications are needed in the process itself and itsinterface.

Considering the above-mentioned factors, choreography and WS-CDL are moresuitable for modeling critical processes as they provide an environment where a failedprocess or a frequently changing one can be replaced by a substitute one whereas inorchestration the substitution is not always possible since the central entity shouldmerge with the newly replaced process. Moreover, lengthy termination time and the factthat failure or modification of the central entity disables the whole system add to theproblems associated with orchestration when it comes to modeling critical processes.

6. ConclusionSOA and web services can support distributed healthcare delivery at the micro-level asthey allow the development and implementation of services that can be invoked indifferent system architectures. However, before we can design IT applications tosupport micro-level healthcare delivery, we need to adequately represent it throughformal models. The overall objective of this paper was to investigate the suitability ofweb service orchestration and choreography for modeling web service-based healthcareprocesses. The specificities of healthcare process modeling were identified anddiscussed then matched with the features of the two modeling methodologies andlanguages.

The key take away result from this paper is that neither modeling methodology is idealfor all situations but rather the ideal methodology will vary by context. The key decision in

BPMJ17,4

592

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 modeledwith 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 asER processes often contain both a centralized and decentralized component. Therefore,we recommend a combination of the two methodologies for ER modeling to harness thebenefits of both methodologies.

Since orchestration and choreography implement SOA principles, they both enableinteroperability and integration between healthcare departments and organizations(Juneja et al., 2009) and help healthcare enterprises leverage shared services to automatebusiness processes while reducing the need for data synchronization between isolatedsystems. They both bring visibility to the data that drive healthcare processes.Differences between the two methods include their implementation. Orchestration relieson an engine for the execution of the central service, while choreography encouragesimplementing healthcare processes in a peer-to-peer manner. The strengths andweaknesses of the two approaches with regard to error rectification as well as thepossibility of continuing some process activities in spite of a malfunction are worthinvestigating.

Although orchestration and choreography support the modeling of the IHEframeworks, further research is needed to ensure the frameworks are representative ofreal micro-level healthcare delivery. Future research will involve using orchestrationand choreography to model micro-level processes and data exchange in actualhealthcare settings. As described above, there are instances when a hybrid language isneeded. Future research will also explore that approach. We also intend to validate ourframework of modeling categories and features using empirical healthcare cases. Thatwill enable us to say for certain how well the methods can model micro-level healthcaredelivery, how well the IHE frameworks represent micro-level healthcare delivery, and towhat 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. Workflow Patterns Initiative, “Workflow Patterns: Standards Evaluations”, available at:www.workflowpatterns.com/evaluations/standard (accessed 3 October 2010).

References

Afrasiabi Rad, A., Benyoucef, M. and Kuziemsky, C.E. (2009), Web Service Based ProcessModeling for Healthcare, University of Ottawa, Ottawa.

Agrawal, A., Adobe Mike Amend, B.E.A. and Manoj Das, O. (2007), WS-BPEL Extension forPeople (BPEL4People), Version 1.0, June available at: http://xml.coverpages.org/BPEL4People-V1-200706.pdf (accessed 3 October 2010).


593

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 (accessed3 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), Specification, 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 theACM, 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 ConversationLanguage (WSCL), W3C, available at: www.w3.org/TR/wscl10 (accessed 4 February2010).

Behara, G.K. (2006), BPM and SOA: A Strategic Alliance, BPTrends, available at: www.bptrends.com/publicationfiles/05-06-WP-BPM-SOA-Behara.pdf (accessed 13 June 2009).

Berg, M. (2003), “The search for synergy: interrelating medical work and patient care informationsystems”, 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”, paperpresented at the ACM Conference on Computer Supported Cooperative Work, TowardsAdaptive Workflow, 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 Specification Schema Version 1.01, UN/CEFACT andOASIS Specification, available at: www.ebxml.org/specs/ebBPSS.pdf (accessed 8 April2009).

Coiera, E. and Hovenga, E.J. (2007), “Building a sustainable health system”, Yearbook of MedicalInformatics, IMIA, Geneva, pp. 11-18.

D’Amour, D., Ferrada-Videla, M., San Martin Rodriguez, L. and Beaulieu, M.-D. (2005),“The conceptual basis for interprofessional collaboration: core concepts and theoreticalframeworks”, Journal of Interprofessional Care, Vol. 19, pp. 116-31 (supplement 1).

D’Amour, D., Goulet, L., Labadie, J.F., San Martı́n-Rodriguez, L. and Pineault, R. (2008), “A modeland typology of collaboration between professionals in healthcare organizations”, BMCHealth Services Research, Vol. 8, p. 188.

Dang, J., Hedayati, A., Hampel, K. and Toklu, C. (2008), “An ontological knowledge frameworkfor adaptive medical workflow”, Journal of Biomedical Informatics, Vol. 41 No. 5,pp. 829-36.

BPMJ17,4

594

Decker, G., Overdick, H. and Zaha, J.M. (2006), On the Suitability of WS-CDL for ChoreographyModeling (Extended Version), Plattner Institute, University of Potsdam, German, andQueensland University, Brisbane.

Eze, B., Kuziemsky, C., Peyton, L., Middleton, G. and Mouttham, A. (2010), “Policy-based dataintegration for e-health monitoring processes in a B2B environment: experiences fromCanada”, 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 onWeb Technologies, in Santiago de Compostela, Spain, pp. 107-13.

Gemino, A. and Wand, Y. (2004), “A framework for empirical evaluation of conceptual modelingtechniques”, Requirements Engineering, Vol. 9 No. 4, pp. 248-60.

Hongli, Y., Xiangpeng, Z., Zongyan, Q., Geguang, P. and Shuling, W. (2006), “A formal model forweb service choreography description language (WS-CDL)”, ICWS Proceedings of theIEEE 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 Profiles, available at: www.ihe.net/Technical_Framework/upload/IHE_PAT_TF_Rev2-0_Vol1_TI_2010-07-23.pdf (accessed3 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 theTwenty-first Century, National Academies Press, Washington, DC.

Juneja, G., Dournaee, B., Natoli, J. and Birkel, S. (2009), “SOA in healthcare (Part II)”, SOAMagazine,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: whichmethod 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”, Journalof Information System Frontiers, Vol. 9 No. 2, pp. 375-89.

Kavantzas, N., Burdett, D., Ritzinger, G. and Lafon, Y. (2004), Web Services ChoreographyDescription 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 healthinformation system design”, Artificial 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 hisdesign for collaborative healthcare delivery”, Proceedings, International Conference onSoftware 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 fromautomating 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: definingteamwork competencies”, BMC Health Services Research, Vol. 7 No. 17, pp. 1-10.


595

Leymann, F. (2001), Web Services Flow Language (WSFL), IBM Corp., Armonk, NY,Specification, available at: xml.coverpages.org/WSFL-Guide-200110.pdf (accessed 9 July2009).

Malholtra, S., Jordan, D., Shortliffe, E. and Patel, V. (2007), “Workflow 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 processorchestration”, 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, InfosysTechnologies Limited, available at: www.infosys.com/BPM-EAI/resource-center/BPM-business-transformation.pdf (accessed 28 April 2009).

Mohamed, A.A. and Alkhamis, T.M. (2009), “Simulation optimization for an emergencydepartment healthcare unit in Kuwait”, European Journal of Operational Research, Vol. 98No. 3, pp. 936-42.

Mykkanen, J., Riekkinen, A., Sormunen, M., Karhunen, H. and Laitinen, P. (2007), “Designing webservices in health information systems: from process to application level”, InternationalJournal of Medical Informatics, Vol. 76, pp. 89-95.

Nadalin, A., Kaler, C., Monzillo, R. and Hallam-Baker, B. (2004), Web Services Security: SOAPMessage 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 webservices, 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 fordistributed workflows”, paper presented at the NETTAB Workshop – WorkflowsManagement: New Abilities for the Biological Information Overflow, Naples, Italy,October.

Sobolev, B., Harel, D., Vasilakis, C. and Levy, A. (2008), “Using the statecharts paradigm forsimulation of patient flow 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, Specification, MicrosoftCorp., 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 processmanagement: a survey”, in van der Aalst, W., ter Hofstede, A. and Weske, M. (Eds),

BPMJ17,4

596

Proceedings of the 1st International Conference on Business Process Management inEindhoven, Vol. LNCS 2678, Springer, Berlin, pp. 1-12.

Wright, A. and Sittig, D.F. (2008), “SANDS: a service-oriented architecture for clinical decisionsupport 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, Activeendpoints, available at: http://www.activevos.com/indepth/c_technology/bestPracticesforDesign/AEDesignPrinciplesAndBestPractice.pdf (accessed 14 November 2010).

zurMuehlen, M. and Rosemann, M. (2000), “Workflow-based process monitoring and controlling$– technical and organizational issues”, in Sprague, R. (Ed.), Proceedings of the 33rdHawaii International Conference on System Science (HICSS-33), IEEE Computer SocietyPress, Los Alamitos, CA, pp. 1-10.

Further reading

Fonseca, F. (2007), “The double role of ontologies”, Information Science Research Journal of theAmerican 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 performancemodeling and simulation in healthcare information systems”, Simulation, Vol. 83 No. 4,pp. 307-9.

Corresponding authorMorad Benyoucef can be contacted at: [email protected]


597

To purchase reprints of this article please e-mail: [email protected] visit our web site for further details: www.emeraldinsight.com/reprints

healthcare processes

Documents