TECHNISCHE UNIVERSITEIT EINDHOVEN

Thesis proposal Process model transformations in health care 

 

E.L.M. van den Broek BSc 

7/4/2010  

 

 

 Deriving a way to translate actual (low‐level) process models from the health care field into High‐Level process models that are understandable to specialists in the Health Care field, in order to increase their usability. 

1  

1. Delineation of the thesis project

1.1. What precisely is being researched, and why?

1.1.1. State the goal of the thesis

Deriving a way to translate actual (low‐level) process models from the health care field  into High‐Level process models that are understandable to specialists in the Health Care field, in order to increase their usability. These specialists are involved in reorganizations in the information systems field (for example: selecting  a  new  hospital  information  system),  but  do  not  have  a  background  in  either  modeling, information systems or computer technology. Models involved need to be abstracted, but must keep a certain level of detail to be of use. 

1.1.2. State the benefit of the research

By aiming to increase the understandability of process models, the goal will be to increase the usability of  process models. By  being more  understandable,  the  usage  of  process models  in  the HC  field  can increase,  allowing  for  quality  improvements  of  decisions  in  the  HC  field.  It  will  provide  software developers with a way of presenting their products in a detailed, structured and yet understandable way to HC professionals. Using a  single  language will also help HC professionals with  comparing offers by different software providers,  to see which product matches  the current processes  in  the organization best. 

1.1.3. State the known knowledge in this area

Research  shows  that  usage  of  process  models  in  HC  is  low.  Literature  suggests  that  both  from  a consumer perspective [1] and from a provider perspective, these models seem to be lacking. This does not necessarily mean they do not exist, but they are not provided to other parties. Meanwhile, research confirms  the  importance  of  process  models,  since  it  is  stated  that  knowledge  about  the  business processes is needed in order to decide which information systems an organization needs to evolve in a better  organization  [2].  Lacking  knowledge  about  business  processes  leads  to  the  acquisition  of suboptimal products. Even  if these products fit current processes and  improve efficiency, the business process  does  not  evolve  with  it  [2].  Both  from  the  consumer  perspective  and  from  the  provider perspective, literature describes why the presence and usage of process models is desirable. 

When process models are available  (mostly  the case  for  the provider side),  these models  tend  to use different modeling languages. This makes comparison between models difficult and also the integration with the consumers’ own models [3]. While reducing the number of modeling languages would be one solution, a more practical solution lies in model transformations. Research on this has mainly focused on transforming a model from a specified language into another specified language [3][4][5][6][7]. In many cases, the ‘transform to’  language  is considered to be an  industry standard [6][7]. A potential problem with (automatic) transformations is the subtle violation of a language’s standard that input models may pose [5].  

Research by Mendling et al. [8] was conducted on understandability of models. 

2  

A  company  in  this  field  is  iCON  health  care  in  the  Netherlands.  The  company  is  active  in  advising hospitals  (and  other  companies)  about  different  software  solutions,  where  simulation  is  used  for demonstrating how such a solution  is being (or could be) used at a certain hospital. These simulations use high‐level models that are created by iCON, of which iCON claims that they are understandable for HC professionals. 

 

1.2. What are the conclusions and what is the value of the conclusions?

This  research  should  lead  to  conclusions  that  provide  clarity  about  how  understandable,  high‐level process models  should  look  like. More  important will  be,  how  such models  can  be  constructed  by transforming  existing  low(er)  level models,  using  existing  tools.  This  concerns  both  the  abstraction process, as well as the visual/graphical language to use to present these process models. Based on these concerns,  strengths  and  weaknesses  of  existing  tools  will  be  discussed.  This  in  result  will  lead  to suggestions for improvements for one or multiple existing tools. The focus will be on their usage in the HC field; results should be generalized across the health care field for information systems.  

1.3. What should be done as a result of the conclusion?

Based on  the results,  it should be possible  to build a  tool  to automatically  translate  low  level process models into the high level process models that will be defined in the research. The actual programming of such a tool lies outside the scope of the research, but the research should provide a programmer with all necessary information concerning the transformation between models, to develop such a tool. 

3  

2. Research design

2.1. Methodology

2.1.1. Are you reusing some existing solution or developing something from scratch?

The  focus will be on  the  evaluation of existing  tools  for model  transformations. Using  available  low‐levels from within the field, these existing model transformation tools will be evaluated. A framework should  be  used  for  evaluating  the  tools.  Rad  et  al.  [3]  have  already  developed  a  framework  for evaluating modeling  languages  in  the HC  field. The  framework  can help  in deciding what a desirable language is for higher‐level models. Since it focuses on HC‐specific issues, this framework will also be a good  starting  point  for  developing  a  framework  for  evaluating  transformation  tools.  If  possible,  the research will include the actual adjustment/extension of an evaluated tool. 

The models used will originate from the HC field. Either   hand‐crafted models can be used, or models might be generated from logs, by using a tool such as ProM. The reason for using either method, will be discussed below. 

Hand‐crafted models 

These models are constructed mainly by software developers and are constructed for internal usage (for workflow enactment, for process simulation, or for demonstration purposes). They can be readily used, if developers are willing to supply these models. Workflow enactment models could be made available by  IT  organizations  such  as  ChipSoft  or  Siemens  (in  the  context  of  the  EZIS  and  SOARIAN  suites respectively.)  Models can also be developed by third parties such as iCON, who model the processes at a hospital (for simulation and demonstration purposes).  

The  quality  of  and  the  language  used  for  these  models  is  likely  to  vary  among  developers  and organizations  [3]. This makes  it hard  to develop a universal  solution  that  is applicable  to all  low‐level models  available  from  software  developers  and  organizations.  The  main  advantage  of  using  pre‐developed low‐level models by software developers and organizations is that these models focus solely on either the software product offered or on the hospital process. There is no ‘interference’ of the other processes (i.e. the influence of an information system on the process of a hospital), thereby providing a much better basis for comparing the own hospital process with the process of the offered product(s). 

Generating models from logs (ProM tool) 

ProM is a very versatile tool for applying process mining on log files of a wide variety of types. The result is typically a low‐level model of the process. The acceptance of different types of log files makes ProM usable  in many  situations,  and  thus provides  similar  source models  for different hospitals.  The main disadvantage of basing the model on log files is the required implementation of an information system, in order to provide  logs that ProM can handle. Though other  (non‐electronic)  log files can be used for manual construction of process models, this procedure is too time consuming in order to be considered for this research. Requiring an information system will naturally exclude scenario’s in which hospitals are about to purchase an information system. From a systems perspective, the acquiring of an information 

4  

system has a very  large  impact on the hospital, thus eliminating this scenario from the research would be a limitation. 

The problem with pre‐developed models is a quality aspect, while the problem with models generated from  log  files  is  based  on  a  time  aspect,  since  the  duration  of  the  thesis  project  is  predefined  and therefore limited. Valuing the quality aspect, the usage of models that are generated using ProM is more desired  in  this situation. As a result of  this,  the research will  focus on post‐HIS situations  in hospitals, however  it should be possible to replicate the research for pre‐HIS situations by using process models from pre‐HIS situations. The option to use pre‐developed models will be kept as a “fallback”, in the case that process mining  fails on  log  traces.  Since  these models  are  already  available, no delay would be caused by switching to these hand‐crafted models. 

 

Figure 1 ‐ schematic overview of the goal 

Figure 1 shows more clearly how the generated models will be used, and how iCON can contribute. The upper  process  shows  the  way  of  working  at  iCON,  as  told  by  the  employees:  at  a  health  care organization, there will be a certain process. The professionals at iCON try to understand this process by interviewing  those  involved  in  the  process.  The  result  is  an  abstract  of  the  actual  (highly  detailed) process, which  is very useful  for  supporting decision making  in  software  implementations. The  lower process shows process mining. Log traces from the actual process are used to  ‘mine’ the process. The result  is a highly detailed model, that corresponds very accurately to the actual process. However,  it  is far to detailed to be used by HC professionals. Thus the aim of the research will be to transform these highly detailed process models,  to more abstract process models  that are  similar  to  those offered by iCON. 

2.1.2. How will you get your ideas for your solution development?

Using the tools on the available  low‐level models will  lead to problems, since research has shown that development on  these  tools  is not  finished. Due  to  the differences between  tools,  it  is assumed  that problems caused by one tool, may not be present  in other tools. The development of the solution will focus on these differences. While comparing advantages and disadvantages of different tools, the goal is to remove disadvantages  from  tools by  incorporating advantages  from other  tools.  It  is also expected 

5  

that  iCON  can  contribute  to  the  solution  development,  since  this  company  has  experience with  the development of understandable models, aimed at the HC field. 

2.1.3. What criteria (test, etc.) shall be used to test the validity of the answer?

In order to assess the validity of the answer, the solution should be used on actual low‐level models. The transformed models should then be reviewed by HC professionals for understandability. Since iCON has experience with developing models  for  the health  care  industry,  they  should be able  to perform  this review. However, in order not to exclude actual HC professionals, the understandability of the high‐level models should also be verified by HC professionals. iCON is interested in what HC professionals think of the models that they develop themselves, thus reviewing the models developed for this research should be  done  by  both HC  professionals  and  iCON.  This way  validity  is  increased  and  iCON  benefits  from feedback from the HC field. 

2.1.4. Why was the chosen method selected?

The method described above was selected for a number of reasons: 

‐There has been a vast amount of research on model transformations so far. This research has focused on multiple  tools and multiple  languages, which has  resulted  in different  functionality. By  comparing multiple tools and multiple languages, indirectly this research is used. Building a new tool from scratch would ignore all this previous research. Part of the research on tools has been goal‐driven, where tools have been tested to perform a specific task (e.i. refactoring, translation). With the fourth iteration of the International workshop on Graph‐Based tools (GraBaTs) in 2008, this workshop is converted to a contest (now  known  as  Transformation  Tool  Contest)  where  different  modeling  tools  are  put  to  the  test, performing different kind of tasks [9].  Results of this contest may aid in the selection of tools to review.  

‐Since the HC field proves to be different from mainstream business in many aspects, it is important to make sure that the solution is applicable to the HC field. The best way to achieve this, is by basing the research on models that are found in the HC field. Meanwhile, since iCON puts effort in this research, it is important that the research has also practical relevance. By using their models for input and by having them review the developed models, this relevance can be achieved. 

2.1.5. Can you identify some intermediate steps in your solution development?

The research can largely be broken into two parts.  The first part will focus on the selection of a suitable modeling language for presenting higher‐level models to HC professionals. The second part will focus on the  evaluation  of  transformation  tools  and  the  subsequent  improvement  of  (a)  tool(s).  Some intermediate steps that can be identified, as shown in Figure 2. A more detailed overview can be found further below. 

6  

 

Part IV: Transformation

‐Derive transformation rules‐Test/review rules

Part III: Evaluation of transformation tools‐investigate different transformation tools

‐development of evaluation framework

‐evaluation of transformation tools (using actual low‐level models from the HC field)

‐improvement of transformation tool(s) [optional]

Part II: Modeling languageSelect model language to use by:

‐Investigating different modeling languages (possibly with suggestions by iCON)

‐Use of framework by Rad et al. (6)

Part I: Models

generate low‐level models from log traces 

(using ProM)

Investigate desired format of high‐level models 

(based on iCON models)

Figure 2 ‐ Intermediate steps 

2.1.6. To what extent will the findings be capable of generalization?

Findings  should be  capable of being  generalized  across  the entire HC  field of   process management.  Within  the  HC  field,  process management  is  often  better  known  as  ``care  path  documentation’’  or ``procedure, policy and guideline development’’.     Within  the HC  field,  the  results may be  specific  to large  organizations  or  clusters  (hospitals,  rehabilitation  centra,  collaborations  between  general practitioners and insurers, …) It may be possible that the results are generalizable towards any process‐oriented  large  organization  or  cluster  (also  from  other  industry  segments,  such  as  the  automotive industry,  the  logistics  industry, …)   However,  this would be an unexpected positive development, but this is not part of the scope of this research. 

2.1.7. How great can the reliability of the results be expected to be? And the validity?

Due to the reliance on existing tools  (which are constructed, based on earlier research),  it  is expected that the reliability of the results will be high. Applying the results to field‐models, further increases the validity. The use of process mining will also have a positive effect on the validity, since the risk of using models  that do not  fully correspond  to  the real situation  is much  lower. Attributing  to  this  is  the  fact that  there  is  no  reliance  on  developers  concerning  the  release  of  their models  and  the  quality  and 

7  

8  

language  of  these models.  Comparing with  reliability,  it  is  expected  that  validity  is much  harder  to achieve. Using multiple models  from as many different aspects within  the HC  field helps  in  improving validity. 

2.1.8. What is the main field of research where you plan on searching for relevant

sources?

Most research on this topic has been carried out  in the  information systems and process management field and the cross‐over field between HC and information systems. This last field is actually more a sub‐field of the  information systems field. The HC field will provide research focusing on the way of doing business in HC.  

Below is a short list of publication outlets that have been used in preparation to the thesis. It is expected that these outlets will continue to be relevant in the thesis. This list is non‐exhaustive. 

International Journal of Medical Informatics 

Journal of Medical Systems 

Journal of Theoretical and Applied Electronic Commerce Research 

Workshops and conferences, such as the MHPW2010 workshop, contributed valuable knowledge about information technology in health care, and will continue to do so during this research. 

Since the HC field of information systems is frequently visited in publications for information technology, it  is expected that a  lot of  information will be supplied by different publication outlets. Of course, the literature study conducted earlier will be an  important source of both  information and  references  for the thesis. 

2.1.9. What are the main publication outlets that are relevant for your thesis?

Some of the consulted publications should also be interested in the current research project. The International Journal of Medical Informatics and the Journal of Medical Systems seem to share their scope with the topic of the research being conducted for this thesis project. Because this research aims at increasing usability of process models to HC professionals, outlets that are read by these professionals are also of interest. Quality Management in Healthcare and Health Business are examples of non‐academic publications that reach the target audience. 

9  

 

3. Project plan & time schedule Figure 3  (previous page) shows a detailed planning  for this thesis project. Below, this planning will be described in more detail: both risks and input from iCON will be discussed. 

Part I: Models 

Investigate process mining 

A mainly  theoretical  research  on  the  usage  of  process mining.  This  research  is  an  extension  to  the research that has been conducted for the  literature study. The focus will be on which parameters and plug‐ins to use when mining. Included in this, is a short research on the differences between heuristics mining and fuzzy mining. 

Research on process mining is strongly supported by the Information Systems department at the faculty of Industrial Engineering & Innovation Sciences (IE&IS) at the TU/e. A lot of knowledge and literature  on process mining  has  originated  at  this  department,  thus  it  should  be  no  problem  to  acquire  required information.  

Risk impact: non‐significant  

 

Generate low‐level models from log traces 

Using process mining,  log traces are translated to process models. Knowledge acquired  in the previous phase  is used for deciding on configuration for mining.  If available,  logtraces provided by  iCON will be used. Because of the direct relation between these  logtraces and models developed by  iCON, this  is a very  valuable process.  In  case  iCON  is not able  to  supply  logtraces before  the deadline,  it  should be evaluated if it would still be valuable to do this process at a later point in time. 

Availability of log traces may prove to be difficult, but some log traces are already available. If no other traces are available, this won’t cause delays but will influence the completeness of the research.  

Risk: low 

 

Investigate process models from different sources 

There  is  an  abundance  of  different  types  of  process models,  using  different  languages  and  different formats. The models will be analyzed on their strengths and weaknesses. The goal  is  to  find desirable characteristics  that  will  make  up  the  process  model  format  specified  later.  This  process  is  mainly explorative. 

10  

Risk impact: Moderate 

Due to the differences between the languages, it is hard to compare them. Some of the languages used are either new or still  in development. Development on these  languages during research may  influence the outcome of observations done earlier. 

Risk  aversion:  upon  starting  the  process,  the  current  format  of models  and  the  current  syntax  and semantics of languages will be used. Changes in models, syntax and/or semantics will not be considered unless these changes will have a large impact and these changes can be applied within time constraints. 

 

Process model format [MILESTONE] 

Finishing part I of the research should lead to a desired format for process models, that will be used in later parts as the ‘transform to’ format. 

Basing on the results of the model investigation, it should be possible to develop a preferred format. The experts at iCON will be consulted for decision support. 

Part II: Modeling language 

Part II and Part III take place in a loop: modeling languages are reviewed one at a time and subsequently matching transformation tools are reviewed. If a modeling language proves to be unsuitable after both the  language  itself  and  the  available  transformation  tools  have  been  reviewed,  a  new  modeling language is selected and both processes take place again. This approach was selected because it may be unnecessary  to evaluate all pre‐selected modeling  languages: once a  suitable modeling  language has been found, it is possible to proceed. 

Investigate different modeling languages 

This process  is a continuation of the “investigation”‐phase conducted  in part  I, but more  in‐depht. The aim  here  is  to  investigate  to which  extent  a  language  is  able  to  conform  to  the  desired  format,  as constructed at the Process model format milestone. 

This process takes place with one model at a time. Duration of the process will depend on the number of iterations needed before a suitable language is found. Therefore, the risk associated with this process is mainly time‐oriented. When more  iterations of this process are needed, this will result  in a  longer total process. 

Risk impact: high 

Risk aversion: see ‘investigate different transformation tools’ 

 

11  

Construct modeling language evaluation guidelines 

Based on the process model format constructed, guidelines will be proposed to aid in the evaluation of a modeling  language. A starting point for constructing these guidelines will be the framework developed by Rad et al. [3]. Further input for guidelines can be provided by iCON. Because the number of iterations for evaluating  a modeling  language  is unknown,  it  is  considered  to be unnecessary  to develop  a  full framework for evaluating languages. 

Due to the mainly theoretical nature of this process, the associated risk is expected to be non‐significant. 

Risk impact: non‐significant 

 

Apply guidelines 

As a part of the evaluation of the modeling language, the constructed guidelines are applied to language under research. There is no risk associated with this process. 

 

Investigate different transformation tools 

Similar to investigating different modeling tools, also different transformation tools will be investigated. This investigation will be related to the modeling language that has been investigated, as transformation tools  are  typically  able  to  only  transform  from  one  input  language  to  one  output  language.  This investigation should lead to a taxonomy that clarifies the differences and similarities between tools. 

As with the modeling language investigation process, this process might be executed multiple times: for every modeling language that is research, also transformation tools will be investigated. Added difficulty originates  from  the  sometimes  poor  documentation  and  construction  of  transformation  tools,  as encountered  in preparation for this research. Development on many tools has not finished, resulting  in the need to use Work‐in‐progress builds or beta‐versions of tools. 

Risk impact: high 

Risk  aversion: Both  the  investigation  of modeling  languages  and  transformation  tools  can potentially delay the research, since multiple iterations of both processes are possible. In order to prevent this from happening, a modeling  language and an accompanying  transformation  tool  should be  selected before the end of may. In case the modeling languages and transformation tools investigated up till that point all prove to be unable to fully achieve the goal stated for this research, the best language and tool should be selected. Shortcoming of both the language and the tool must be documented, as should the impact of these imperfections on the final result. 

The  incompleteness of both documentation and development on  transformation  tools  is unavoidable. Fortunately, most transformation tools are either developed at the TU/e or are developed with support 

12  

from researchers at TU/e. Contacting  these people may decrease a delay caused by  incompleteness of documentation and/or software. 

 

Construct transformation evaluation guidelines 

Based on the process model format constructed and the modeling language selected, guidelines will be proposed  to  aid  in  the  evaluation  of  transformation  tools.  The  taxonomy  develop  in  the  previous process, can be used as a starting point here, since it provides different characteristics of transformation tools. The constructing of guidelines focuses on deciding which behavior and which characteristics are desired. 

Due to the mainly theoretical nature of this process, the associated risk is expected to be non‐significant. 

Risk impact: non‐significant 

 

Apply guidelines 

As a part of the evaluation of the modeling language, the constructed guidelines are applied to language under research. There is no risk associated with this process. 

 

Test understandability of format 

In order to make sure that the research achieves its goal, it is important to test the understandability of the  format  proposed within  the HC  field. HC  professionals will  be  asked  about  their  opinion  on  the proposed format, using the modeling language selected in part II and the transformation tool in part III. It is assumed that iCON can arrange contact with some HC professionals. Also, iCON should review the understandability of  the proposed  language/format  for process models.  It  is best  to meet with  iCON before the HC professionals, so the feedback from iCON can already be processed, thus making it more likely that the HC professionals will find the models understandable. Based on the feedback received, it may be necessary to make changes to the previous sections. 

In  the worst  case  scenario,  the  selected modeling  language  and  transformation  tool(s)  need  to  be discarded, thereby forcing another entry in iteration loop that consists of part II and part III. Afterwards, another test for understandability should be conducted. This would result in a serious delay. 

Risk impact: very high 

Risk aversion: since the  impact of this risk cannot be changed,  it  is better to minimize the  likelihood of this  risk. By  including people  from  the HC  field  in an earlier phase,  it will be much more clear what  is expected from the HC field. 

13  

 

 

Part IV: Transformation 

Derive transformation rules & Test/review rules 

Having chosen a modeling language and a transformation tool, rules need to be defined to achieve the desired format. These rules need to be well documented, as they should provide input to a programmer who can  implement  these rules  into  (an) existing  transformation  tool(s). Another  import aspect  is  the testing of these rules, for which these rules should be applied to multiple models. The best test would be to apply these transformation rules on  logtraces from  iCON customers. This allows to compare the result of automatic transformation with the result iCON achieves by their approach. 

At  the moment,  it  is  impossible  to  state  how many  rules  are  required  for  successfully  transforming models to the desired format. As a result of this, it is hard to plan the duration of this activity. The same goes for the test/review process: the duration of this process is unknown in advance. 

Risk impact: moderate / high 

Corrective actions: since the risks described above are unavoidable, it is important to have a strategy to cope with  these  risks. The worst  case  scenario would be  that  there are no  transformation  rules  to be found. In that case it should clearly be documented why this is the case. Proposed strategies that did not result in transformation rules should be discussed and it should be analyzed why this did not work. 

Quality  of  rules  is more  important  than  quantity  of  rules.  In  other words:  it  is  better  to  have  a  few transformations rules that are unable to transform an entire model but work on different models, than having a lot of rules that can only transform one specific model correctly and fully. 

3.1. Time schedule Due to the  involvement of  iCON, not all deadlines are equally strict. Because of dependence on them, certain activities might be postponed for a week. When this is the case, it is important that resources are shifted to the next activity, in order to not delay the entire project. iCON has seen and agreed upon this planning. 

deadline  Process  Involvement iCON March 30th 2010  Investigate PM   

Generate low‐level models  Logtraces of iCON customers Investigate process models  iCON process models 

April 2nd 2010  Process model format  Discuss findings / initiate “investigate modeling language” 

April 16th 2010  [hand in ‐ milestone] process model + pre‐investigation of models 

Arrange meeting(s) with client(s) for pre‐face of ‘understandability test’ 

14  

15  

April 23rd 2010  Deadline for considering new modeling languages 

 

April 30th 2010  Investigate modeling language    Investigate transformation tool   

May 14th 2010  Test understandability  Test understandability: HC professionals & iCON 

[hand in – milestone] Modeling language   [hand in – milestone] Transformation tool   

June 25th 2010  Derive transformation rules   Test/Review rules   [hand in – milestone] Transformation rules 

Discuss results & progress 

July 30th 2010  Delays   Write report   [hand in] Final report & presentation  Final presentation 

Table 1 ‐ time planning, deliverables in bold, meetings in italic 

 

[1]  ChipSoft, ChipSoft productportfolio, 2009. [2]  G. Vassilacopoulus en E. Paraskevopoulou, “A Process Model Basis for Evolving Hospital Information 

Systems,” Journal of Medical Systems,  vol. 21, 1997, pp. 141‐153. [3]  A.A. Rad, M. Benyoucef, en C.E. Kuziemsky, “An Evolution Framework for Business Process Modeling 

Languages in Healthcare,” Journal of Theoretical and Applied Electronic Commerce Research,  vol. 4, 2009, pp. 1‐19. 

[4]  F. Gottschalk, W. van der Aalst, M. Jansen‐Vullers, en H. Verbeek, “Protos2CPN: Using colored Petri nets for configuring and testing business processes,” International Journal on Software Tools for Technology Transfer,  vol. 10, 2008, pp. 95‐109. 

[5]  O. Muliawan, P. van Gorp, en D. Janssens, “Executing a Standard Compliant Transformation Model on a Non‐standard Platform,”  Lillehammer: 2008. 

[6]  P. Jiang, Q. Mair, en J. Newman, “Using UML to Design Distributed Collaborative Workflows: from UML to XPDL,” WETICE '03: Proceedings of the Twelfth International Workshop on Enabling Technologies, 2003. 

[7]  H. Zha, Y. Yang, J. Wang, en L. Wen, “Transforming XPDL to Petri Nets,” Business Process Mangement Workshops,  Heidelberg: Springer Berlin / Heidelberg, 2008, pp. 197‐207. 

[8]  J. Mendling, H. Reijers, en J. Cardoso, “What Makes Process Models Understandable?,” Business Process Management, Springer Berlin / Heidelberg, 2007, pp. 48‐63. 

[9]  P. van Gorp, “TTC 2010: Transformation Tool Contest Website,” http://is.ieis.tue.nl/staff/pvgorp/events/TTC2010/, 2010.