MODELLING AND INTEGRATION OF LOCAL PROCESS VIEWS
WITHIN HUMAN COLLABORATION PROCESSES: AN
APPLICATION IN THE HEALTHCARE DOMAIN
University of Groningen
Faculty of Economics and Business
Master Thesis – Technology Management
MODELLING AND INTEGRATION OF LOCAL PROCESS VIEWS
WITHIN HUMAN COLLABORATION PROCESSES: AN
APPLICATION IN THE HEALTHCARE DOMAIN
BASTIAAN DIJKSTRA
University of Groningen
Faculty of Economics and Business
Master Thesis – Technology Management
Preface
This report describes the master research I conducted at the faculty of Economics and Business on behalf of the master program Technology Management at the University of Groningen. The research is performed in cooperation with a researcher (first supervisor) in a predefined area connected with the research focus of the workgroup Business and ICT.
To conduct my research here was merely logical, because, I was familiar with this workgroup through prior work. First, I conducted research for the bachelor program Technology Management. In that bachelor research a literature study has been executed about the identification of business rules. Second, I was appointed as a student assistant for the period of six months. During this period, I supported the first supervisor with programming a software tool. This tool is named Email Interaction Miner and implements an email mining method. Both, Email Interaction Miner and the email mining method are described in Stuit & Wortmann (2010).
This research can merely be interesting for academics that are interested in the field of business processes and/or human collaboration processes in particular. Furthermore, it can also be of interest for business analysts who are performing process analysis in contexts with a high degree of collaboration between humans.
First of all, I want to thank the first supervisor M. Stuit, MSc, for the collaboration during the research project. Moreover, for all the discussions and feedback given that helped me to develop this report. Also, many thanks to dr. N. B. Szirbik for reading this report and the constructive feedback that was given.
Management summary
In the last decade, organizational structures with a more collaborative nature have emerged. Traditional business process approaches are able to model business processes that display complex flows, but are less appropriate for modelling business processes that involve the collaboration between several actors. To capture the interactions between actors, the TALL modelling language has been developed. TALL is a modelling language for human collaboration processes (HCP). A HCP is a distinct collaborative business process, wherein people cooperate with a variety of colleagues through multiple intermittent interactions in order to leverage each other’s expertise, experience and resources, and to reach individual and joint business goals.
The application of TALL in a distributed and complex business setting poses several challenges to the modelling exercise. To overcome these challenges, it is important to model each actor’s local process view. A novel multi-view modelling method has been developed and evaluated which (1) allow that local interaction views to be explicitly captured and represented in local interaction representations and (2) that is able to integrate multiple local interaction representations into a coherent global IS diagram, which provides an overall view of the HCP. The goal of the method is to produce a global output diagram in which overlapping views are merged and complementary views persist. The method consists of three sequential executed algorithms, that is, the global construction algorithm, the constraint algorithm, and the pruning algorithm.
The case study is used as a test case to validate the multi-view modelling method based on its application to the HCP of the UMCG. The scope of the case study is the workgroup head and neck oncology at the University Medical Center Groningen (UMCG).
The designed multi-view modelling method has been evaluated in a validation case study. The scope of the case study is the workgroup head and neck oncology at the UMCG. The case study is used as a test case to validate the multi-view modelling method based on its application to the HCP of the UMCG.
their own local viewpoint. They were asked about interactions, the involved roles for each interaction, and the relationship between interactions. Next to that, the interviewees were explicitly asked to describe potential constraint situations. Based on the recorded interviews, 43 local IS diagrams were modelled.
Index
1 Introduction ... 1 1.1 Preliminaries ... 1 1.2 Research motives ... 3 1.3 Contribution ... 4 1.4 Problem statement ... 4 1.5 Research method ... 5 1.6 Outline ... 6 2 Theoretical background ... 72.1 Human collaboration processes ... 7
2.2 The TALL modelling language ... 8
2.2.1 Interaction structure diagram ...9
2.2.2 Attributes ... 10
3 Multi-view modelling method ... 12
3.1 Illustrative example: dental visit ... 12
3.1.1 IS diagrams ... 12
3.2 Global construction algorithm ... 14
3.2.1 Joining stage ... 15
3.2.2 Integration stage ... 19
3.2.3 No action ... 21
3.2.4 Merge ... 21
3.2.5 Dummy ... 22
3.2.6 Applying the global construction algorithm ... 23
3.3 Constraint algorithm ... 26
3.3.1 Constraints ... 26
3.3.3 Algorithm ... 32
3.3.4 Applying the constraint algorithm ... 34
3.4 Pruning algorithm ... 37
3.4.1 Redundancy ... 37
3.4.2 Overhead ... 39
3.5 Tool support ... 41
4 Case study ... 43
4.1 Workgroup head and neck oncology ... 43
4.2 Data Collection ... 44
4.3 Application ... 45
5 Evaluation ... 47
5.1 Explicit business process models ... 47
5.1.1 Communication ... 47 5.1.2 Flexibility ... 48 5.1.3 Expressing knowledge ... 48 5.1.4 Process improvement ... 49 6 Discussion ... 50 6.1 Limitations ... 51 7 Conclusions ... 53 8 References ... 56
Appendix A Disciplines head and neck oncology UMCG ... 58
Appendix B Part of global IS diagram of HCP head neck oncology ... 60
1
1 Introduction
1.1 Preliminaries
Due to the free market system in the care sector, hospitals are stimulated to work more efficient and effective (Schaepkens, 2004). Improving organizational efficiency and effectiveness inevitably involves business process management (Dalmaris, Tsui, Hall, & Smith, 2007).
The first goal of business process management is a better understanding of the operations a company performs and their relationships. The explicit representation of business processes is the core concept in achieving this better understanding. Identifying the activities and their relationships and representing them in business process models allows stakeholders to communicate about these processes in an efficient and effective manner. Using business process models as common communication artefacts, business processes can be analyzed, and potentials for improving them can be developed (Weske, 2007). Globally, there are two types of business processes: production workflows and collaborative business processes. Production workflows are well structured and highly repetitive. Traditional business process modelling languages (e.g. BPMN, Petri nets, UML, and Activity diagrams) are well suited for representing production workflows. On the other end of the continuum, there are collaborative business processes. These business processes have low automation, are not repetitive and are less structured. The actors in a collaborative business process can be thought of as knowledge workers. Knowledge workers are equipped with detailed knowledge of the application domain, and they can perform activities, or even parts of business processes, autonomously. Traditional business process approaches are less suited for representing collaborative business processes (Weske, 2007).
2
business processes that involve the collaboration between several actors (i.e. collaborative business processes) (Stuit & Szirbik, 2009; Stuit & Wortmann, 2010). Furthermore, traditional process modelling techniques present the same process for all participating actors (i.e. organizations, teams, departments, and humans etc) and therefore neutralizes the diversity of participants in terms of authority levels and perception scopes. The autonomous partners in a collaborative business process can be seen as agents that execute certain tasks locally, while the interactions between the partners can be seen as interactions in a multi-agent system (Stuit & Meyer, 2009). To capture these interactions, the TALL modelling language has been developed. TALL (The Agent Lab Language) is a modelling language for human collaboration processes (HCPs). A HCP is a distinct collaborative business process, wherein people cooperate with a variety of colleagues through multiple intermittent interactions in order to leverage each other’s expertise, experience and resources, and to reach individual and joint business goals (Stuit & Wortmann, 2010).
TALL is based on the proposition that to properly model HCPs, interaction needs to be recognized and represented as an essential part of a company’s business process (Stuit & Szirbik, 2009; Stuit, Szirbik & de Snoo, 2007). Moreover, the local process views of the actors should be explicitly represented and not be verified out of the model.
With TALL, interaction is recognized as the core of collaborative organizational work. In the language, the modelling exercise therefore starts with the explicit modelling of the interactions in a HCP. This is a paradigm shift since traditional modelling languages focus on task specification. In TALL, the interactions in a HCP are modelled in the Interaction Structure (IS) diagram in which the interactions are related by composition (one interaction being part of another) and dependency (one interaction must be completed before the other) in a tree layout (Stuit & Szirbik, 2009).
3
Groningen (UMCG) that threats patients with cancer in the head and neck area. Throughout the patient’s care trajectory, a HCP occurs between the team members that originate from over 40 different (para)medical disciplines. The interactions between these team members like meetings, consultations, and discussions are mostly informal and in many cases are only known to the participants. These interactions are not documented, so there is no clear overview of the complete interaction structure of the HCP. Consequently, it is also difficult to manage or improve these interactions from a process perspective. The team interaction process within the care trajectory is a typical example of a HCP, and consists of several knowledge workers each with their focus areas and local process views. The next section elaborates on research motive.
1.2 Research motives
The application of TALL in a distributed and complex business setting, of which the UMCG care trajectory is a good example, poses several challenges to the modelling exercise. More specifically, the creation of an IS diagram of the entire care trajectory requires the domain knowledge of the team members to be captured and represented. The traditional way to do this is to have interviews with all process participants. Then, the process designer creates, from a central observer perspective, a single process model based on the collected data. In a HCP, the knowledge, expertise, and experience of the humans are quite distinct and different. The humans have their own local (i.e. personal, individual) view or perception of the process. The disadvantage of a centralistic model is that local process views are lost at the choice of the process designer(Stuit & Wortmann, 2010). According to Liu et al. (2008) such a centralistic approach neutralizes the diversity of participants in term of perception scopes. A shortcoming of a centralistic model is that it lacks locality (Stuit & Wortmann, 2010). The process model reflects the generic perspective of the process designer who aims to increase process standardization. When the goal is to have a model that accurately fits reality and captures real-life nuances (this applies to the case study), it is important to model each actor’s local process view.
4
the creation of a business model (Bridgeland & Zahavi, 2009). The chairman (i.e. process designer) then creates an IS diagram based on the input of the participants. However, this approach has several disadvantages when applied to model HCPs. First, at the UMCG the participants from different disciplines are not willing to sit together. Second, the setting makes it difficult to make sure everyone has its input. The group setting of a workshop may intimidate some participants. As a result, some participants may be afraid to speak up and voice an own opinion (Buelens, van den Broeck, Vanderheyden, & Kinicki, 2006). As a result, the model created in the workshop does not adequately reflect all local process views. If the goal is to have a process model fast then a workshop is suitable because it does not require individual interviews with all participants. The main disadvantage of a workshop is that the input obtained from each participant is usually less detailed than in a one-to-one interview (Morgan, 1996).
1.3 Contribution
Based on section 1.2, the TALL modelling effort should capture local process information from the participants through interviews (requirement 1). The captured local information is to be represented in a local IS diagram for each interviewee (requirement 2). Finally, a global IS diagram should be created based on the set of local IS diagrams in order to provide a complete overview of the HCP under consideration (requirement 3). A new TALL modelling method that meets these requirements is the main contribution of this thesis.
1.4 Problem statement
5 The research question addressed in this thesis is:
How to develop a multi-view modelling method that can integrate local interaction views into one coherent global interaction view of a human collaboration process?
1.5 Research method
This research requires the development and application of a novel method that has practical utility. Therefore, a design science approach is used. Design-science addresses research through the design and evaluation of artefacts intended to solve identified organizational problems. The focus in design-science is on situated utility.
Awareness of Problem Suggestion Development Evaluation Conclusion Proposal Tentative Design Artefact Performance Measures Results
Process Steps Output
Figure 1, the design science research framework. Source: Vaishnavi & Kuechler (2004).
This thesis follows the iterative design-science framework of Vaishnavi & Kuechler (2004). The design-science framework consists of five process steps (i.e. awareness of problem, suggestion, development, evaluation, and conclusion).
In the first phase, the problems are identified. Based on an analysis of business process literature, shortcomings of existing methods are identified. These shortcomings form the proposal of a research effort. The suggestion phase follows immediately. Suggestion is an essentially creative step wherein new functionality is envisioned based on a novel configuration of either existing or new and existing elements. The output is a tentative design.
6
method or instantiation. The output artefact of this research is an extension of the TALL modelling framework. This is a multi-view modelling method. The design of this artefact builds on prior research into interaction-centric modelling of collaborative business processes.
Next, the developed artefact is evaluated. According to Yin (2003) there are three conditions which determine the choice of evaluation strategy. These conditions consist of (1) the type of research question posed, (2) the extent of control an investigator has over actual behavioural events, and (3) the degree of focus on contemporary as opposed to historical events. In this research (1) the type of research question posed is a “How” question, (2) the actual behavioural events are already performed, and (3) the focus lies on historical events. So, a case study is the most suitable evaluation technique to evaluate the designed artefact. This will be done in the above mentioned workgroup at the UMCG. The case study acts as the context to apply and develop the method in a real-life business setting. Finally, evaluation results are to be discussed in the form of practical experiences, lessons learnt and theory development.
1.6 Outline
7
2 Theoretical background
This section covers theoretical background. Section 2.1 begins with a description about HCPs and the concept of process views. Following, section 2.2 explains the TALL modelling language.
2.1 Human collaboration processes
Modern business process management expands to cover the partner organisations’ business processes across organisational boundaries, and thereby supports organisations to coordinate the flow of information among organisations and link their business processes. With collaborative business processes, organisations can create dynamic and flexible collaborations to synergically adapt to changing conditions, and stay competitive in the global market (Liu, Li, & Zhao, 2008).
In the last decade, organizational structures with a more collaborative nature have emerged, like the knowledge organization, horizontal organization, networked organization, and virtual organization. A common characteristic of these organizations is that human work is executed across internal (e.g. team, departmental) and external (e.g. organizational) boundaries (Stanford, 2005).
8
In the current report, an individual IS diagram is created for each process participant, which shows the interactions that the specific person has with its colleagues (Stuit & Szirbik, 2009; Stuit, Szirbik & de Snoo, 2007).
2.2 The TALL modelling language
TALL (The Agent Lab Language) is a modelling language for collaborative processes (Stuit & Szirbik, 2009; Stuit, Szirbik & de Snoo, 2007). The organizational context in which a HCP occurs is seen as a multi-agent environment in which different agents behave in interactions to coordinate their work. The language is based on the premise that human collaborative work is not about carrying out steps in a pre-defined sequence but instead requires a higher-level notion of process. Therefore, it explicitly recognizes interaction as the core of collaborative organizational work.
To properly model human collaboration processes, interaction needs to be recognized and represented as an essential part of a company’s business processes. Therefore, the language centers on the interactions that are relevant to the collaboration process.
With TALL, collaborative business processes are addressed in two ways. First, on a high level an interaction diagram is used to visualize inter-agent interactions in a branching tree. In the interaction diagram, the collaborative business process is conceived as a structure of role-based interactions through which agents cooperate and coordinate their work. Interactions are modelled in the Interaction Structure (IS) diagram in which the interactions are related by composition (one interaction being part of another) and dependency (one interaction must be completed before the other).
9 2.2.1 Interaction structure diagram
Figure 2 shows an IS diagram with the abstract symbols that represent the essential components of the language for this report. Ellipses represent roles, hexagons represent interactions, and circles represent routing types. Both roles and interactions have their names as labels. Furthermore, roles are attached to the lines outgoing the interaction.
Interaction 1
Routing Type
Interaction 2 Role B Interaction 3 Role C
Role A Role B
Role C Role A
Role B
Figure 2, IS diagram with abstract symbols
As mentioned earlier, interactions are related by composition. This means that an individual interaction is completed after its children are carried out. For instance, “Interaction 1” is completed after its children (i.e. “Interaction 2” and “Interaction 3”) are carried out.
Furthermore, to complete an individual interaction their respectively roles have to be played. “Interaction 2” has to be carried out through “Role A” and “Role B” (see figure 2). In TALL, an interaction does not exist without at least two roles being bound to it. Because, a role that does not interact with other roles is of no interest.
10
Finally, an IS diagram consists of different levels of hierarchy. For instance, figure 2 consists of two levels, namely level 0 (i.e. “Interaction 1”) which is the root interaction1 and level 1 (i.e. “Interaction 2” and “Interaction 3”).
2.2.2 Attributes
The symbols interaction (i.e. hexagon) and role (i.e. ellipse) carry attributes. These attributes are presented in table 1.
Attribute Symbol Example
Interaction Label Interaction Treat Cavity
Routing Type Interaction SEQ
Start Time Interaction 13:00
End Time Interaction 13:20
Duration Interaction 20 minutes
Parent Interaction Treatment
Children Interaction Drill Cavity; Fill Cavity
Role Label Role Dentist
Initiator Role True
Table 1, attributes symbols TALL. Based on: Stuit & Wortman (2009).
As mentioned before, an interaction can be performed in sequence or in parallel. For sequential interactions, the start time of the second interaction is greater than the end time of the first interaction. For parallel interactions, the end time of the first interaction is greater or equal than the start time of the second interaction (Stuit & Wortman, 2009). The difference between the start time and end time is the duration of an interaction. An initiator attribute can be assigned to those roles that initiate a certain interaction. This can only be specified for elementary interactions (i.e. interactions without children).
11
12
3 Multi-view modelling method
In this section, the multi-view modelling method is described. Throughout the sections, the design decisions are discussed using an illustrative example which is introduced in section 3.1. The goal of the method is to produce a global output diagram (i.e. global IS diagram) in which overlapping views are merged and complementary views persist. To produce the global IS diagram, the method applies three algorithms. First, the global construction algorithm (GCA) is executed which is capable of integrating multiple local IS diagrams (see section 3.2). After that, two newly introduced algorithms, that is, the constraint algorithm (CA) and the pruning algorithm (PA) are performed. These algorithms are described, respectively, in section 3.3 and section 3.4. In each section, the output model is discussed. Finally, section 3.5 describes tool support for the multi-view modelling method in which the three different algorithms are implemented.
3.1 Illustrative example: dental visit
This section presents a case example of a dental visit. The scenario is a simplified HCP of a dental care trajectory. The purpose of the example is not to reflect reality but to illustrate the different algorithms of the multi-view modelling method. As explained, each agent involved in a HCP has its own process perspective. In this example there are three different perspectives of human agents (i.e. dentist, dental assistant, and secretary), resulting in three local IS diagrams. The different perspectives are modelled by interviewing each participating human agent.
3.1.1 IS diagrams
13 Dental Visit SEQ Treatment Dental Assistant Patient Treatment Room Patient Dental Assistant SEQd Dental Assistant
X-Ray Remove Tartar
Dental Assistant Patient Patient Setup Dental Assistant SEQ Dental Assistant Clean Treatment Room Place Dental Instruments Dental Assistant Treatment Room Treatment Room Treatment Room Treatment Dental Assistant Patient
Figure 3, the IS diagram of the care trajectory from the dental assistants’ viewpoint
In cases where an excess of tartar exists on the patients’ teeth the assistant is asked to remove tartar. Because, the execution of these interactions depends on the fulfilment of certain conditions (i.e. x-ray is necessary and tartar exists) the routing type of the parent interaction is set to “SEQd”.
Dental Visit
SEQd
Check-up Dentist Treatment
Patient Patient Dentist
Agenda Patient
Dentist
SEQ
Cavity Treatment Dentist Patient
PAR
Patient Cavity Drilling
Dentist
Cavity Filling Patient
Dentist Appointment Dentist Patient SEQ Referral Appointment Dentist Patient Agenda Agenda
Figure 4, the IS diagram of the care trajectory from the dentist’s viewpoint
14
there are cavities subsequent treatment is started. Also, here a routing type “SEQd” is set to illustrated the condition that the treatment is executed depending on the check-up. Furthermore, the cavity treatment is performed simultaneous. This is represented with the routing type “PAR”. Lastly, the dentist can refer a patient to the hospital in cases of severe problems in the patient’s teeth. An appointment can directly be made in the agenda of a dental surgeon.
Finally, figure 5 shows the local IS diagram of the care trajectory from the secretary’s viewpoint. The secretary has the most limited view on the process, because he or she only participates in the support activity of managing appointments.
Patient Dental Visit SEQ Appointment Secretary Agenda Patient Agenda Sectretary XOR Secreatry Follow-up Appointment Patient Agenda Patient Periodical Appointment Secretary Agenda
Figure 5, the IS diagram of the care trajectory from the secretary’s viewpoint
Before the patient leaves the dentist, he or she makes an appointment. The secretary can make one of two types of appointment. These are a follow-up appointment in cases where additional treatment is necessary or a periodical appointment for a general check-up. This is visualised with the routing type “XOR”. An agenda is used for planning purposes. 3.2 Global construction algorithm
15
of the interactions in the process while taking into account all the local views of the participants. An algorithm has been developed which is capable of doing so. This algorithm is called the global construction algorithm (GCA) (Stuit & Meyer, 2009)2 and serves as the starting point for the method developed in this report. GCA expects a set of local IS diagrams based on the same root interaction as input. The root interaction represents the common shared goal of the HCP. The GCA consists of two stages, namely the joining stage and the integration stage (see figure 6). Both stages of the GCA are elaborated in the following subsections.
Joining Stage
Integration Stage Set local IS diagrams
Figure 6, global construction algorithm
3.2.1 Joining stage
Before the different local IS diagrams can be integrated they have to be joined into one model. So, the goal of the joining stage is to tie the local IS diagrams under consideration together in one global IS diagram. Because, each local IS diagram has the same root interaction which represents the common shared goal of the HCP, the different local IS diagrams are joined based on these root interactions. Hence, this root interaction becomes the global root interaction of the global IS diagram and carries all the children from the original root interactions. Furthermore, the different roles of each root interaction are added to the global root interaction. Formally, a global root interaction is created that is labelled with the common name corresponding with the different root interactions.
2 The Global Construction Algorithm described in this section is slightly modified compared with the
16
Moreover, the root interactions’ children with all descending interactions are added to the global root interaction.
Although the root interaction is the same in each local IS diagram, its routing type can be different across these diagrams. Depending on the routing type of the different root interactions the routing type of the global root interaction is determined. The routing type of the global root interaction is set according the following logic:
If all the different routing types are the same (i.e. all SEQ, all PAR, or all XOR), that routing type is set as the routing type of the global root interaction.
If all three types routing types are present, if only PAR and XOR, or if only PAR and SEQ are present among the local root interactions, the routing type of the global root interaction becomes PARd. This is the weakest routing type that covers all present routings. It supports both true concurrency and unordered sequences. Moreover, the decision rule is used to enforce selective routing (XOR).
If only SEQ and XOR (with or without decision rules) are present among the local root interactions, the routing type of the global root interaction becomes SEQd since the decision rule covers selective routing (XOR).
If one of the routing types carries a decision rule, this decision rule is added to the routing type of the global root interaction and the routing type is complemented with a “d” which visualize a decision rule.
17
18 T re a tm e n t D e n ta l A s s is ta n t P a tie n t S E Q d D e n ta l A s s is ta n t X -R a y R e m o v e T a rta r D e n ta l A s s is ta n t P a tie n t P a tie n t S e tu p D e n ta l A s s is ta n t S E Q D e n ta l A s s is ta n t C le a n T re a tm e n t R o o m P la c e D e n ta l In s tr u m e n ts D e n ta l A s s is ta n t T re a tm e n t R o o m T rea tm e n t R o o m T re a tm e n t R o o m T re a tm e n t D e n ta l A s s is ta n t P a tie n t S E Q d C h e c k -u p T re a tm e n t D e n tis t P a tie n t D e n tis t P a tie n t S E Q C a v ity T re a tm e n t D e n tis t P a tie n t P A R P a tie n t C a v ity D ril lin g D e n tis t C a v ity F illi n g P a tie n t D e n tis t A p p o in tm e n t D e n tis t P a tie n t S E Q R e fe rr a l A p p o in tm e n t D e n tis t P a tie n t A g e n d a A g e n d a P a tie n t A p p o in tm e n t S e c re ta ry A g e n d a X O R S e c re a tr y F o llo w -u p A p p o in tm e n t P a tie n t A g e n d a P a tie n t P e rio d ic a l A p p o in tm e n t S e c re ta ry A g e n d a D e n ta l V is it S e c re ta ry P a tie n t D e n ta l A s s is ta n t A g e n d a D e n tis t T rea tm e n t R o o m
19 3.2.2 Integration stage
At this point, all the local IS diagrams are joined into one global IS diagram. Following, the integration stage of the GCA is executed. The goal of the integration stage is to integrate overlapping views and retain complementary views in the global IS diagram. The GCA searches for commonalities and/or differences between labels and routing types of two interactions (i.e. iA and iB) in the tree of the global IS diagram. The algorithm works according to a level-order traversal sequence or breadth-first traversal. It starts at level 1, because level 0 only contains the global root interaction. Each interaction in the set of level 1 is compared with all its successors. This is repeated for all the descending levels in the tree of the global IS diagram.
In the joined global IS diagram of the illustrative example (see figure 7) level 1 consists of the interactions “Setup”, “Treatment”, “Check-up”, “Treatment”, “Appointment”, and “Appointment”. Table 2 shows all the comparisons of the interactions on level 13
. Comparison Interaction iA Routing Type iA Interaction iB Routing Type iB
1 Setup SEQ Treatment SEQd
2 Setup SEQ Check-up none
3 Setup SEQ Treatment SEQ
4 Setup SEQ Appointment SEQ
5 Setup SEQ Appointment XOR
6 Treatment SEQd Check-up none
7 Treatment SEQd Treatment SEQ
8 Treatment SEQd Appointment SEQ
9 Treatment SEQd Appointment XOR
10 Check-up none Treatment SEQ
3
20
11 Check-up none Appointment SEQ
12 Check-up none Appointment XOR
13 Treatment SEQ Appointment SEQ
14 Treatment SEQ Appointment XOR
15 Appointment SEQ Appointment XOR
Table 2, comparison of all interactions on level 1
During the comparison, the two interactions under consideration are checked for commonalities and/or differences between interaction labels and routing types. This is done according to the logic illustrated in the decision tree of figure 8. The full lined circles are the conditions of the algorithm and the dotted circles are consequential actions.
Labels iA and iB are equal No action Routing Types iA and iB are equal False True Merge Dummy True False
Figure 8, decision tree of global construction algorithm. Based on: Stuit and Meyer (2009)
21 3.2.3 No action
As mentioned before, when interaction labels are unequal no action takes place. The reason that no action takes place is that these interactions are different interactions that should both be represented. For the illustrative example this is the case for the comparisons 1, 2, 3, 4, 5, 6, 8 ,9, 10, 11, 12, 13, and 14 (see table 2).
3.2.4 Merge
When the interaction labels and routing types of two interactions are equal, that means that the interactions under consideration are overlapping views on the same interaction, the interactions are merged. In that case, a new interaction is created. This new interaction is constructed with the label, routing type, roles, and local source4 of the interactions under consideration. Roles are constructed uniquely, that is, if the same role exists in both interactions the role is added once5. Moreover, all children of the interactions with its descendant interactions are added to the new interaction. Finally, the newly constructed interaction is added to the set at the position of the first interaction under consideration.
In the illustrative example the interaction labels and routing types are equal for comparison 7 (see table 2). Both interactions are labelled “Treatment” and both interactions have the same routing type “SEQ”6. Therefore, a new interaction is constructed with the label “Treatment”, routing type “SEQd”, roles “”Dentist”, “Dental Assistant”, and “Patient”. Furthermore, the children interactions “X-Ray”, “Remove Tartar”, and “Cavity Treatment” with its descendant interactions “Cavity Drilling” and “Cavity Filling” are added to the newly created interaction. Finally, the newly constructed interaction is added to the set at the position of the first interaction
4 Local source is a newly introduced interaction attribute. This attribute contains the name of the local IS
diagram from where the interaction originates. The purpose of local source is to retain the ability to trace interactions back to local IS diagrams.
5 A role is unique when the role’s label and initiator state is unique. So, if two roles have the same labels
but one is an initiator, both roles are unique.
6 During the comparison of the routing types of two interactions the decision rules are neglected. However,
22
“Treatment”. The formal steps and activities of merging two interactions are depicted in table 3.
Input interactions iA and interaction iB
a. Create new interaction iNew
b. Set label interaction iNew as common label interaction iA and interaction iB c. Set routing type interaction iNew to common routing type interaction iA and
interaction iB
d. Assign children interaction iA and interaction iB as children to interaction iNew e. Add roles interaction iA and interaction iB to interaction iNew
f. Add local source interaction iA and interaction iB to interaction iNew g. If interaction iA or interaction iB has a constraint7
a. Set constraint to interaction iNew
h. If interaction iA or interaction iB has a decision rule a. Set decision rule to interaction iNew
i. Add interaction iNew to the set at position iA
Table 3, formal steps and activities of merging interactions
3.2.5 Dummy
In cases when the labels of two interactions are equal but their routing types are different, the interactions are considered alternative views of the same interaction. Hence, merging these interactions would result in the loss of local information and context. Therefore, in this situation, a dummy interaction is introduced to act as the parent of identically labelled interactions. In this way the alternative views are preserved.
A dummy interaction is constructed with the common label name of the interactions under consideration. The dummy’s routing type is set to selective OR (i.e. XOR).
23
Because, the use of a different routing type would imply that the interaction is executed more than once. Furthermore, the interactions under consideration and all the descendant interactions are added to the dummy’s interaction that serves as their parent interaction. Next, the roles of the interactions under consideration are added uniquely to the dummy interaction. Finally, the dummy interaction is added to the set at the position of the first interaction under consideration.
During comparison 15 (see table 2) the interaction labels match (i.e. “Appointment” and “Appointment”) and the routing types are unequal (i.e. “SEQ” and “XOR”). These interactions are alternative views of the same interaction. The consequential action is the construction of a dummy interaction “Appointment” which serves as the parent of the interactions under consideration. The roles “Dentist”, “Patient” “Secretary”, and “Agenda” are added to the dummy interaction. Finally, the dummy interaction is added to the set at the position of the first interaction “Appointment”. Table 4 shows the formal steps and activities of the creation of a dummy interaction.
Input interaction iA and interaction iB
a. Create new interaction iDum
b. Set label interaction iDum to common label interaction iA and interaction iB c. Set routing type interaction iDum to routing type XOR
d. Assign interaction iA and interaction iB as children to interaction iDum e. Add roles interaction iA and interaction iB to interaction iDum
f. Add interaction iDum to set at position iA
Table 4, formal steps and activities of creation dummy interactions
3.2.6 Applying the global construction algorithm
24
of local IS diagrams. Following, overlapping views has been integrated (i.e. merge and dummy) and complementary views has persist (i.e. no action).
Figure 9 shows the output of the algorithm, that is, the global IS diagram8. The common shared goal of the HCP is a dental visit. Therefore, the interaction “Dental Visit” appears as the global root interaction in the global IS diagram. Furthermore, figure 9 shows that the two initial interactions “Treatment” are merged into one interaction and a new dummy interaction is present which act as the parent interaction for the two alternative views on the interaction “Appointment”.
8 The root interaction of a global IS diagram does not carry an initiator role (see figure 9). The reason is that
25 T re a tm e n t D e n tis t P a tie n t S E Q d D e n ta l A s s is ta n t X -R a y R e m o v e T a rta r D e n ta l A s s is ta n t P a tie n t P a tie n t S e tu p D e n ta l A s s is ta n t S E Q D e n ta l A s s is ta n t C le a n T re a tm e n t R o o m P la c e D e n ta l In s tr u m e n ts D e n ta l A s s is ta n t T re a tm e n t R o o m T re a tm e n t R o o m T re a tm e n t R o o m T re a tm e n t D e n ta l A s s is ta n t P a tie n t S E Q d C h e c k -u p A p p o in tm e n t D e n tis t P a tie n t S e c re ta ry D e n tis t X O R C a v ity T re a tm e n t D e n tis t P a tie n t P A R P a tie n t C a v ity D ril lin g D e n tis t C a v ity F illin g P a tie n t D e n tis t A p p o in tm e n t D e n tis t P a tie n t S E Q R e fe rr a l A p p o in tm e n t D e n tis t P a tie n t A g e n d a A g e n d a P a tie n t A p p o in tm e n t S e c re ta ry A g e n d a X O R S e c re a tr y F o llo w -u p A p p o in tm e n t P a tie n t A g e n d a P a tie n t P e rio d ic a l A p p o in tm e n t S e c re ta ry A g e n d a D e n ta l V is it S e c re ta ry P a tie n t D e n ta l A s s is ta n t A g e n d a D e n tis t T re a tm e n t R o o m P a tie n t P a tie n t
26
A specific challenge when the algorithm is applied to the multiple local IS diagrams is that interactions in different local IS diagrams can have dependency relations to each other. For instance, the interaction ”Check-up” should be completed before the interaction “Treatment”. This dependency relationship should be explicitly represented in the output global IS diagram in order to have a correct order of interactions. Without a way to provide information about inter-dependencies between local IS diagrams, the order of interactions in the output global IS diagram can be incorrect because it depends solely on the processing order of the local IS diagrams by the algorithm. To address this challenge, the concept of constraints is introduced which is subject of the following section.
3.3 Constraint algorithm
As mentioned above, a specific challenge when the algorithm is applied to the multiple local IS diagrams is that interactions in different local IS diagrams can have dependency relations to each other. The sequence of interactions of the global IS diagram depends on the order of the input set of local IS diagrams. This dependency relationship should be explicitly represented in the output global IS diagram in order to have a correct order of interactions. Without a way to provide information about inter-dependencies between local IS diagrams, the order of interactions in the output global IS diagram can be incorrect because it depends solely on the processing order of the local IS diagrams by the algorithm. To overcome this limitation the concept of constraints is introduced. This concept is the subject of this section.
3.3.1 Constraints
27
gathered before the multi-view method is executed. The task of the modeller is to translate this information into constraint specifications and insert the specifications into the local IS diagram.
Thus, a constraint gives information about the order of interactions in the global IS diagram. It has two objectives. First, to determine the placement of the interaction with constraint in respect to the constraint interaction. Second, to determine how the interaction under constraint has to be executed in the global IS diagrams with respect to its siblings9. TALL is extended with an extra attribute named constraint. This attribute consists of a constraint symbol and a constraint interaction divided by a pipe symbol (i.e. “|”)10
.
[constraint symbol]|[constraint interaction]
Different constraint symbols are introduced to meet both constraint objectives. Table 5 shows the different constraint symbols.
Symbols Routing Type Constraint Type
<<< and >>> Sequential Hard constraint <<<= and >>>= Parallel Hard constraint
<< and >> Sequential Medium constrain
<<= and >>= Parallel Medium constraint
< and > Sequential Soft constraint
<=, =, and >= Parallel Soft constraint
Table 5, constraint symbols
9 Siblings are interactions that share the same parent interaction. 10
28
First, the constraint specification can contain the inequality sign (i.e. “<” or “>”). This is used to specify sequential routing. When the interaction with the constraint needs to be sequentially placed before the constraint interaction, a single left strict inequality sign (i.e. “<”) is used. Similarly, a single right strict inequality sing (i.e. “>”) is used when the interaction with the constraint needs to be placed sequentially after the constraint interaction. Both are soft constraints. When an interaction needs to be placed sequentially immediately after or before an interaction, a double inequality sign is used (i.e. “<<” or “>>”). These are medium constraints. When an interaction needs to be the first of the last sibling of the constraint interaction, a triple inequality sign is used (i.e. “<<<” or “>>>”). These are hard constraints. Thus, the amount of inequality signs determines the gravity of the sequential position.
Second, the constraint specification can contain the strict inequality sign (i.e. “<=” or “=>”) or a strict equality sign (i.e. “=”). This is used to specify parallel routing. Similarly to sequential routing also here the signs can be repeated to specify either soft, medium, or hard parallel constraints. A hard constraint (i.e. “<<<=” or “>>>=”) ensures that the interaction with constraint is placed in parallel as the first or last sibling of the constraint interaction. In case of a medium constraint (i.e. “<<=” or “>>=”), the interaction with constraint is placed in parallel directly before or after the constraint interaction. Finally, with a soft constraint (i.e. “<=” or “>=”) the interaction with a constraint is placed in parallel somewhere before or somewhere after the constraint interaction. Abstract examples are illustrated in the next subsection.
29
diagrams. Moreover, the use of the constraint attribute allows the gravity of the constraint to be specified.
3.3.2 Abstract examples
Figure 10 illustrates two abstract local views (i.e. Local IS X and Local IS Y) and the result after the GCA integrates these two views (i.e. Global IS). Depending on the order of the two views in the GCA the sequence of the global IS is determined.
A SEQ B D A SEQ C A SEQ B D C
Local IS X Local IS Y Global IS
Figure 10, example global IS diagram
The left side of figure 11 illustrates a global IS where interaction “C” has a soft constraint “<|D”. This means that interaction “C” has to be placed somewhere before interaction “D”. This is depicted in the right side of figure 11. So, interaction “C” can be placed before interaction “D” or before interaction “B”.
A SEQ B C D C A SEQ B D C
Global IS Constraint Executed
<|D
Figure 11, example soft constraint “<|D”
30 A SEQ B D C Global IS A SEQ B C D Constraint Executed <<|D
Figure 12, example medium constraint “<<|D”
Next, figure 13 shows an example where interaction “C” has a hard constraint “<<<|D”. With this constraint interaction “C” becomes the first sibling in the segment containing interaction “D”. A SEQ B D C Global IS A SEQ C B D Constraint Executed <<<|D
Figure 13, example hard constraint “<<<|D”
31 A SEQ B D C Global IS A SEQ B [PAR] Constraint Executed PAR B D <<=|D
Figure 14, example conflicting situation “<<=|D”
In the above example, interaction “C” and interaction “D” have to be executed in parallel as imposed by the constraint. According to their parent (i.e. interaction “A”) they have to be executed sequentially. Therefore, an artificial interaction named “[PAR]” is added which serves as parent for interaction “C” and interaction “D” in the output diagram. In situations where the constraint imposes sequential routing and the parent interaction another routing type (i.e. XOR, or PAR) the artificial interaction is named “[SEQ]”.
A SEQ B D C Global IS SEQ E F A SEQ B D Constraint Executed PAR C F <|E E
Figure 15, example soft constraint “<|E” different level
32
situations the constraint interaction is moved according the constraint and thereby removed from its original position11.
3.3.3 Algorithm
The construction of the global diagram is done in two steps. First, the GCA builds the global diagram without considering the constraints. Secondly, a constraint algorithm then loops through the tree structures to check and enforce the constraints. The constraint algorithm is executed in three loops: the soft constraints are processed first, the medium constraints are processed second, and the hard constraints are processed third (see figure 16). The reason for this sequence is that in this way all constraints can be satisfied. For instance, if a medium constraint is processed before a soft constraint the execution of the soft constraint can override the medium constraint.
Soft Constraint GCA Medium Constraint Hard Constraint
Figure 16, Constraint algorithm
When processing the soft constraints, the constraint algorithm loops through the global IS diagram searching for interactions with soft constraint specifications. If a specification is found, the algorithm searches for the constraint interaction in the specification.
11 Because the interaction is moved it is not clear if the roles are present in the parent interactions. To
33
Depending on the routing type imposed by the constraint the interaction is placed on its new position. This is iterated until no further soft constraints are found. The constraint algorithm then repeats this process for the medium constraints and the hard constraints. Figure 17 shows the decision tree of the CA. Formally, iA is the interaction with the constraint and iB is the constraint interaction. The first condition is if the constraint specification matches the routing type of interaction iB’s parent. If this condition is true, that means that there is no conflicting situation, iA can be moved according to the constraint symbol. If routing type constraint specification iA and parent iB are equal Routing Type iA False Create Artificial “[SEQ]” & Move Interaction Create Artificial “[PAR]” & Move Interaction SEQ PAR Move Interaction True
Figure 17, decision tree constraint algorithm
Otherwise, depending on the constraint specification of iA an artificial interaction (i.e. iArt) named “[SEQ]” or “[PAR]” is created. Table 6 shows the formal activities for the creation of an artificial interaction.
Input interaction iA and interaction iB
a. Create new interaction iArt
b. If constraint specification interaction iA is “SEQ” and routing type parent interaction iB is “PAR”
a. Set label interaction iArt to “[SEQ]”
34 a. Set label interaction iArt to “[PAR]” d. Set constraint interaction iA to interaction iArt
e. Assign interaction iA and interaction iB to interaction iArt f. Move interaction iArt
Table 6, formal steps and activities of creation artificial interaction
In either case, the interaction with constraint has to be moved depending on the constraint specification symbol. Table 7 illustrates the formal steps and activities of moving a constraint according to its constraint specification symbol. Depending on whether or not an artificial interaction is created the input interaction iA is the artificial interaction iArt. Input interaction iA and interaction iB
a. If constraint symbol interaction iA is “<”, “<<”, “<=”, or “<<=” then a. Insert interaction iA before interaction iB in segment
b. If constraint symbol interaction iA is “>”, “=”, “>>”, “>=”, or “>>=” then a. Insert interaction iA after interaction iB in segment
c. If constraint symbol interaction iA is “<<<” or “<<<=” a. Insert interaction iA as first in segment
d. If constraint symbol interaction iA is “>>>” or “>>>=” a. Insert interaction iA as last in segment
Table 7, formal steps and activities of moving interaction with constraint
3.3.4 Applying the constraint algorithm
35
assistant indicated that the interaction “Remove Tartar” is the last interaction of its siblings. Based on this information the interviewer specified two constraints which are shown in table 8. These constraint specifications are not intended to reflect reality but to illustrate the constraint algorithm.
Viewpoint Interaction Constraint
Dentist Check-up <<|Treatment
Dental Assistant Remove Tartar >>>|X-Ray
Table 8, constraint specifications illustrative example
36 T re a tm e n t D e n tis t P a tie n t S E Q d D e n tis t X -R a y C a v ity T re a tm e n t D e n ta l A s s is ta n t P a tie n t P a tie n t S e tu p D e n ta l A s s is ta n t S E Q D e n ta l A s s is ta n t C le a n T re a tm e n t R o o m P la c e D e n ta l In s tr u m e n ts D e n ta l A s s is ta n t T re a tm e n t R o o m T re a tm e n t R o o m T re a tm e n t R o o m T re a tm e n t D e n ta l A s s is ta n t P a tie n t S E Q d C h e c k -u p A p p o in tm e n t D e n tis t P a tie n t S e c re ta ry D e n tis t X O R R e m o v e T a rta r D e n tis t D e n ta l A s s is ta n t P A R P a tie n t C a v ity D ril lin g D e n tis t C a v ity F illin g P a tie n t D e n tis t A p p o in tm e n t D e n tis t P a tie n t S E Q R e fe rr a l A p p o in tm e n t D e n tis t P a tie n t A g e n d a A g e n d a P a tie n t A p p o in tm e n t S e c re ta ry A g e n d a X O R S e c re a tr y F o llo w -u p A p p o in tm e n t P a tie n t A g e n d a P a tie n t P e rio d ic a l A p p o in tm e n t S e c re ta ry A g e n d a D e n ta l V is it S e c re ta ry P a tie n t D e n ta l A s s is ta n t A g e n d a D e n tis t T re a tm e n t R o o m P a tie n t P a tie n t
37 3.4 Pruning algorithm
This section describes the pruning algorithm (PA) which is executed after the global construction algorithm and constraint algorithm (see figure 19).
Pruning Algorithm
Global IS diagram GCA/CA
Figure 19, pruning algorithm
The goal of the pruning algorithm is to reduce the size of the global IS diagram by removing interactions from the tree that are redundant or create overhead. The pruning algorithm works according to a depth-first traversal and checks each sub tree12 and interaction. The algorithm checks two situations (i.e. redundancy and overhead) which are described in the following subsections.
3.4.1 Redundancy
An interaction can occur multiple times on different levels in the global output diagram. If such interactions occur in the same sub tree, they are assumed to be the same interaction. In other words, they are considered redundant interactions and provide no additional information. The design decision is to keep only the lowest-level interaction since this one reflects the most information. Attributes from the removed interactions are added to the lowest interaction. However, the redundant interactions are only removed if they have no children because otherwise information will be lost.
12
38
The left side of figure 20 shows a situation where interaction “B” occurs two times in the same sub tree. Because, the upper interaction “B” carries no children this interaction is removed. A PAR C Pruning Executed SEQ A D A PAR B C GCA/CA Executed SEQ A D
Figure 20, example redundancy in sub tree
Furthermore, the attributes (i.e. roles and local source) of the removed interaction are added to the lowest interaction (i.e. interaction “B”). Roles are added according the bottom up approach. The right side of figure 20 shows the new situation after the pruning algorithm is executed.
The algorithm searches for redundant interactions in each sub tree. When redundancy occur, the highest redundant interaction (i.e. iHigh) is checked for children. Next, if the highest redundant interaction has no children, attributes are added to the lowest redundant interaction (i.e. iLow) and the highest redundant interaction is removed. The formal steps and activities are depicted in table 9.
Input interaction iHigh and interaction iLow
a. If interaction iHigh has no children then
a. Add roles interaction iHigh to interaction iLow
b. Add local source interaction iHigh to interaction iLow c. Remove interaction iHigh from sub tree
39 3.4.2 Overhead
Next to redundant interactions, it is also possible that some interactions or a combination of interactions does not provide additional or functional information that is necessary to reach the models goal. In other words, these interactions cause overhead. Overhead situations occur after the execution of the CA. Because, when interactions are moved based on constraint specifications new situations occur in the tree.
First, an overhead situation can appear when an artificial interaction has no siblings. Originally, an artificial interaction is created because a conflict situation occurred when the routing type imposed by the constraint specification differs from the routing type of the parent interaction of the constraint interaction. When all the sibling interactions of an interaction are moved this conflict situation disappears. To remove the overhead the artificial interaction is removed from the global output diagram and the artificial interaction’s routing type is set to its parent.
A Pruning Executed SEQ B C GCA/CA Executed A PAR [SEQ] SEQ B C
Figure 21, example overhead (artificial interaction “[SEQ]” without siblings)
Figure 21 shows an example where an artificial interaction “[SEQ]” has no siblings. The PA removes the artificial interaction and the parent’s routing type is set to SEQ.
40
serves no purpose. Therefore, the dummy and child without children are removed out the global output diagram.
A PAR A A GCA/CA Executed PAR D E SEQ B C Pruning Executed A SEQ B C
Figure 22, example removed children through constraints
Figure 22 illustrates this overhead situation. Here, one alternative view is lost because two interactions (i.e. interactions “D” and interaction “E”) are removed. Consequently, this interaction together with its parent dummy interaction is removed from the tree as shown on the right side of figure 22. The formal steps and activities of the two overhead situations are described in table 10.
Input interaction i
a. If interaction i is an artificial interaction and has no siblings
a. Set routing type parent interaction i to routing type interaction i b. Add children interaction i to parent interaction i
c. Remove interaction i
b. If interaction i is dummy interaction and one of two children has no children a. Add child interaction i with children as child parent dummy interaction i b. Remove child interaction i without children and dummy interaction i
from tree
Table 10, formal steps and activities remove overhead
41 3.5 Tool support
A software tool named Local IS Integrator (LISI) has been developed as part of this thesis project (see figure 23)13. LISI supports the three described algorithms (global construction algorithm, the constraint algorithm, and the pruning algorithm). The tool is capable of integrating a set of local IS diagrams into one global IS diagram.
Figure 23, Local IS Integrator
Local IS diagrams are created in the TALL Visual Editor and saved in a database format as one model. LISI operates on this database. After loading LISI, first, the available local IS diagrams (see figure 24) are presented and a selection can be made for integration.
Figure 24, select locals IS
By selecting or deselecting the “Constraints” and “Pruning” checkbox (see figure 23) a choice can be made whether or not to execute the constraint algorithm and the pruning algorithm. Next, LISI integrates all selected local IS diagrams into one global IS diagram
13
42
that is saved in the same database. In this process, LISI also computes the basic layout and proper positioning for the global IS diagram. The global IS diagram can be inspected through a list view in LISI by double clicking the interaction structure (see figure 25). Next, the user can load the database in the TALL Visual Editor in order to visualize the global IS diagram.
43
4 Case study
This section introduces the case study at the University Medical Center Groningen (UMCG). The case study is used as a test case to validate the multi-view modelling method based on its application to the HCP of the UMCG. The scope of the HCP is the care trajectory of the workgroup head and neck oncology. Section 4.1 starts with a description of the department. Next, section 4.2 details data collection. Finally, the multi-view modelling method is applied in section 4.3.
4.1 Workgroup head and neck oncology
Each year in the Netherlands more than 2650 times the diagnosis head-neck cancer is made. The most occurring causes of cancer in the head and neck area are smoking, alcohol, heredity, and some viruses. Not every ear, nose, and throat (ENT) specialist or dental surgeon has experience with the treatment of cancer in the head and neck area. Therefore, the care of patients with head neck-cancer in the Netherlands is concentrated around eight centers (Hoofd-halskankerzorg in het UMCG, 2010). One of these centers is the workgroup head and neck oncology at the UMCG.
The workgroup head and neck oncology is a multi-disciplinary healthcare team that threats patients with cancer in the head and neck area. The care for people with head-neck cancer is very complex (Offerman & Pruyn, 2009). Throughout the patient’s care trajectory, a HCP occurs between the team members that originate from over 40 different (para)medical disciplines.
The team interaction process within the care trajectory is a typical example of a HCP, and consists of several knowledge workers each with their focus areas and local process views. The HCP consists globally of three stages. These stages are: diagnostic research, treatment, and follow-up care (Offerman & Pruyn (2009).
44
where the results of the tests are discussed. The discussion includes the surgeon oncologist, ENT specialist oncologist, radiologist, and in some cases other disciplines. Often, additional research (e.g. PET-scan, MRI, or CT-scan) is necessary. When the tests are positive, a preliminary treatment plan is determined. After the discussion, the patient is informed about the diagnosis.
Depending on the results from the pathologist a final treatment plan is determined. There are three possible oncological treatments: surgical treatment, chemotherapy, and radiotherapy. Depending on the nature and development of the cancer one or more treatments are necessary. The surgical treatment consists of removing cancer tissue or tumours. Consequently, physical problems can arise like problems with breathing, eating, drinking, or damage of the physical appearance. To overcome these problems additional treatment may be necessary. For instance, a plastic surgeon may reconstruct the physical appearance or dental prosthetics have to be developed to resolve eating and drinking problems.
When the patient has been treated successfully he or she is dismissed from the hospital and the final phase is started (i.e. follow-up care). The patient is checked on a regular basis for a period of 5 years. In case of recurrent cancer the care trajectory is restarted. Also emotional, psychosocial, and relational effects for the patient and/or one’s fellow can arise. To cope with this, the department of psychiatry can be consulted.
4.2 Data Collection
45
modelled. Furthermore, information about constraints were transformed into 128 constraint specifications.
A problem occurs when diagrams are modelled from different agents’ viewpoints, because, each agent has its own distinct vocabulary and therefore interaction labels, role labels, and constraint specification may not match. This problem is called ontology conflict. To overcome this problem, ontology’s have to be matched (Euzenat & Shvaiko, 2007). In the local IS diagrams some ontology conflicts occurred in either interaction labels, role labels, or constraint specifications. These ontology conflicts were discussed with the key informant from the UMCG and then solved. The end result of this manual process is a set of local IS diagrams based on a common shared ontology. These local is diagrams were imported in the TALL Visual Editor.
4.3 Application
The 43 local IS diagrams served as input for LISI. The root interactions of these diagrams are based on the same root interaction “Head & Neck Oncology”. First, the 43 constructed local IS diagrams were opened from the TALL Visual Editor’s database. Second, LISI integrated the local IS diagram using the GCA into one global output diagram. Following, the CA enforced all the specified constraints and the PA removed redundant interactions and interactions that created overhead. Finally, the global IS diagram was saved into the database. The global IS diagram, which can be consulted with the TALL Visual Editor, captures the interactions, the involved roles for each interaction, and the relationship between interactions of the UMCG’s HCP. This IS diagram consists of 410 unique interactions and 157 unique roles. Furthermore, three artificial interactions were created with the label “[SEQ]” and no artificial interactions with the label “[PAR]”. Appendix B shows a part of the global IS diagram14.
The application of the method also validated the developed software tool LISI. Of course, LISI has been properly tested, but only on a small scale. The 43 local IS diagrams served
14 The integrated global IS diagram of the HCP of the neck and head oncology is too large to demonstrate
46
