T o w ards a Clinical Process Mapping Methodology (CPM M...

Towards a Clinical ProcessMapping Methodology (CPMM)To Support InformationSystems (IS) Innovation In AHealthcare Context

UCD School of Business

2

Towards a CPMM To Support IS Innovation in a Healthcare Context

Towards a Clinical Process Mapping Methodology (CPMM)To SupportInformation Systems (IS) Innovation In A Healthcare Context

Report on Initial Design Stage

Jan vom Brocke1

Christian Buddendick1

Peadar Ó Scolaí2

Séamas Kelly2

Centre for Innovation, Technology & Organisation (CITO)2

School of BusinessUniversity College DublinIreland

European Research Centre in Information Systems (ERCIS)1

University of MünsterGermany

Published by the Centre for Innovation, Technology & Organisation (CITO). All rights reserved.This document may not be copied or altered in whole or in part without the written permission ofthe publisher.

© University College Dublin, University of Münster, DATHs ICT Convergence Strategy Project.

3


Executive Summary

This report describes an initial attempt to explore the development of a Clinical Process MappingMethodology (CPMM) to support information systems (ISs) innovation in acute hospital settings.The project was commissioned by the Dublin Academic Teaching Hospitals (DATHs) Informationand Communication Technology (ICT) Strategy Project, with a view to tackling the problemsassociated with the specification and development of an integrated DATHs Electronic PatientRecord (EPR) system.

The key rationale underpinning the initiative was that any attempt to develop ISs to support (and,perhaps, transform/ enhance) clinical work, must be based on a sophisticated, holistic andgranular understanding of existing practices. It was envisaged that an appropriate CPMM mightprovide a helpful conceptual and representational approach to facilitating the development andarticulation of such an understanding.

The aim of this Initial Design Phase, then, was to specify and pilot an appropriate methodology,which could be subsequently tested and refined over an extended period.

Ethnographic methods were employed to study work practices in two separate departments(Neurology and Elderly Medicine), in two different DATHs hospitals over the course of about fourweeks. Drawing on the insights gleaned through this observational study, the initial CPMM wasdeveloped by adapting elements from existing modelling languages to suit the specifics of theclinical context in question.

The resultant CPMM, and the rationale upon which its design was based, is described in thisreport. Although the timescales involved did not permit extensive testing, the methodology waspresented to clinicians at both research sites. In both cases those involved found themethodology intuitive and the resultant maps acted as a focal point for constructive discussionand reflection.

Our observations highlight the complex, collaborative and contingent nature of clinical practice,and the important mediating role played by technical and non-technical artefacts. Thiscomplexity would caution against viewing modelling as a panacea, which can be used to mapthe world in an objective or unproblematic manner. While modelling can be very helpful forfacilitating the development of new perspectives on work, and for facilitating productive collectivesensemaking processes, it should be borne in mind that all models are purposeful, andnecessarily partial, representations of the 'real' world. This underlines the importance of usingany such modelling approach in a discriminating and reflective way.

Notwithstanding the time constraints within which this study was conducted, and its limited scope(i.e. the fact that it was confined to specific functions within two clinical departments), theresearch team is encouraged by the feedback received to date from clinicians, and is optimisticabout the potential benefits of such an approach. We recommend that this initial CPMM befurther developed, tested and verified through a pilot process within the DATHs.

4


Contents

Executive Summary 3List of Tables and Figures 5Acknowledgements 6

1 Introduction 7

2 Methodological Considerations 9

3 Process Modelling 113.1 Process Modelling Requirements in Clinical Settings 113.2 Conclusion 14

4 Designing a Clinical Process Mapping Methodology (CPMM) 154.1 Managing the Application & Refinement of the CPMM 154.2 Modelling Language 184.2.1 Process Chain 204.2.2 Process Glossary 284.2.3 Process Description 284.3 DATHs-Specific Elements of the CPMM 30

5 Conclusions, Scope and Recommendations 31

Appendix 34

References 35

5


List of Tables and Figures

TABLE ONE: Methodological Requirements 12

TABLE TWO: Basic Elements of the EPC 21-22

FIGURE ONE: Stages of the Approach 15

FIGURE TWO: Constitutive Elements of the Approach 19

FIGURE THREE: Process Signposts and Abstract Activity 23

FIGURE FOUR: Relevant Resource for Clinical Processes 24

FIGURE FIVE: Symbols for the EPC 24

FIGURE SIX: Process Model Outpatient Clinic - Part 1 25

FIGURE SEVEN: Process Model Outpatient Clinic - Part 2 26

FIGURE EIGHT: Process Model Outpatient Clinic - Part 3 27

FIGURE NINE: Example of a Process Glossary 28

FIGURE TEN: Example of a Process Description 29

6


Acknowledgements

The research team would like to express their gratitude to the staff in the ICT departments at theBeaumont and Mater hospitals, in particular to Mr Tony Kenny, Ms Rosaleen Murnane, MsJennifer O Leary and to Mr Gerard Hurl and the DATHs ICT Strategy Project team. We wouldalso like to thank the administrative staff in both Beaumont and the Mater who assisted in thisproject and the medical record staff at the Mater hospital (in particular, Ms Mary O Connor)

This research would not have been possible without the full support of a number of consultants,especially Dr Timothy Lynch, Dr Ciaran Donegan, Dr Alan Moore and Dr Dermott Phelan. Uponentering the clinical environment we were struck by the generous assistance and support offeredby a range of individual doctors and nurses. These include Dr Andrew McKeon, Dr Orla Dunne,Dr Fiona Kearney, Dr Desiree Fernandez, Dr Crochan O'Sullivan, Ms Noddy Dempsey (CNS) MsJacqueline Scott (CNS), Ms Geraldine Jackson (RGN) and, in particular, Mr Brian Magennis(CNS).

Finally the team would like to acknowledge the helpful advice and comments of colleagues inUCD and the University of Münster, especially Professor Stefan Klein and Professor AndrewDeegan.

7


1. Introduction

This report outlines the results of a recent study of clinical processes and practices conductedby the Centre for Innovation, Technology & Organisation (CITO) at the University College Dublin(UCD) School of Business and the University of Münster’s European Research Centre forInformation Systems (ERCIS) (see Appendix 1). The research was conducted within two DublinAcademic Teaching Hospitals (DATHs). The objective of this 'Initial Design Phase' was todevelop an understanding of clinical practices, at an appropriate level of granularity to facilitatethe initial design of a Clinical Process Mapping Methodology (CPMM)1 .

A review of DATHs ICT services in 2003 recommended the establishment of an organisationbased on an Integrated Service Delivery Model to incorporate the existing individual DATHs ICTfunctions. This new organisation is to provide for the convergence and standardisation ofsystems and technologies, more effective utilisation of resources (to include human, financialand technological), and to explore the improvements in service development and delivery acrossthe DATHs.

A key element of this Integrated Service Delivery Model is the development of an agreedspecification for an acute sector Electronic Patient Record (EPR) system. Consequently, theDATHs is currently exploring the possibility that the development of a CPMM would assist themin the design of an agreed specification for a standardised EPR system to support clinical workpractices. While there is currently significant interest, both nationally and internationally, in thedevelopment of integrated EPRs, the DATHs were sensitive to the need for any such system tobe aligned with clinical practices. Consequently, a more organic and collaborative approach todesigning systems to support clinical practice was considered necessary.

In approaching this problem, we were cognisant of the fact that any common system specifiedwould almost certainly have to cope with important variations in practice within and acrosshospitals, and would consequently be predicated on the successful renegotiation andreconfiguration of a mosaic of existing, and interconnecting, work practices. Moreover, whilegeneric administrative processes might be readily identified and mapped, more nuanced clinicalknowledge work practices were likely to present a much more significant challenge.

Another challenge was the need to strike a balance between formal process mapping languagesand natural language. A core element of our remit was to develop a language that could beutilised by clinicians and administrators. It is envisaged that the role of these stakeholders will bevital in the application of any such methodology/approach to the development of an appropriateprocessual understanding of the organisation of clinical work and, consequently, anymethodology developed would have to be based on a language that could be readily understoodby all users.

The overarching objective of this initial design phase, therefore, was to specify (based on directobservation of clinical practices) an initial CPMM for piloting within the DATHs. This CPMM, andthe manner in which it was developed, are described in this report.

The document is structured as follows. In Section Two, we explain our approach to examining1 The term ‘clinical process’ incorporates administrative processes within a clinical setting.

8


clinical processes and practices and (Section Three) to utilising this methodology in the contextof process modelling. This is followed, in Section Four, by a detailed description of our firstattempt at designing a CPMM; which is illustrated by a number of clinical mapping examples.The report concludes, in Section Five, with some reflections on the scope of the study and amore general discussion of conclusions and recommendations.

9


2. Methodological Considerations

In attempting to gain a detailed understanding of clinical work it was necessary to shadowclinicians during their daily activities. Ethnographic methods were used to explore the detail ofmicro-level clinical practices, and on the basis of this observational activity, an attempt was madeto specify broader and more generic chains of work processes. This type of observationalresearch presents a number of difficulties, not least, its resource intensive nature. In whatfollows, we explain and justify our choice of methodological approach.

The success, or otherwise, of any given technology depends on how it is appropriated by usersand becomes embedded in the social and organisational context in question. Consequently, anymature attempt to understand the likely implications of a specific information system (IS)implementation must be based on a sophisticated understanding of the context in question, andthe institutionalised work practices and social relations that constitute it. Our approach, then,embraces a user-orientated socio-technical philosophy. This emphasises the importance ofdeveloping a thorough understanding of the practices within which IT applications will beembedded as the starting point for design and implementation activities (Kling and Scacchi 1982;Berg 1999).

This philosophy points to the shortcomings of using more detached quantitative survey methodsfor the development of such an understanding (Berg 1999; Anderson and Aydin 2005),emphasising instead the need for intensive, ongoing engagement with the research context. Forone thing, while questions associated with 'what a clinician does at a particular point' may yielduseful data for analysis, they will seldom be able to achieve a grounded answer to the questionof 'why'.

A further difficulty with the use of these more detached research methods is the problem ofdiscriminating between what people 'say' they do and what they 'actually' do. Hence, ourapproach was particularly sensitive to observing the enacted world of work, which helpeduncover work practices that clinicians 'forgot' to describe and also verified 'general claims' madeabout system use and the practices surrounding their use.

This study utilised ethnographic methods for data collection and analysis. Ethnography refers tothe qualitative description of human social phenomena, based on extensive engagement withthe field. Ethnographic methods have recently become widely recognised and employed by ISresearchers in the field of Medical Informatics (Berg 1999; Hanseth and Lundberg 2001;Ellingsen and Monteiro 2003; Timmermans and Berg 2003; Boonstra and Boddy et. al. 2004).

The study was conducted at two large acute teaching hospitals. In Hospital A we focused onNeurology. In Hospital B we focused on Elderly Medicine. The sites were pre-selected bymanagement partly because the clinicians in question were very interested in developing waysto improve the collection, use and integration of information, and partly because both areas wereviewed as complex disciplines.

In each hospital we shadowed the clinical team as they performed their day-patient, out-patientand ward-round associated activities. In Elderly Medicine the ward-round patients were located

10


on the same ward but this was not the case for the Neurology patients. Consequently, theNeurology ward-round covered a number of different wards and resulted in us spending asignificant amount of time in the Intensive Care Unit (ICU) of Hospital A.

We examined the clinical practices of both doctors and nurses (particularly specialist nurses).Our sources of data included secondary document analysis, primary interviews (semi-structuredand unstructured), informal discussions and observation. This approach allowed us to cross-validate, triangulate and formulate questions for further investigation.

The main observations were conducted over a four week period, and involved about 120 hoursof clinician observation. Some observation work also took place prior to, and subsequent to, thisperiod. Semi-structured interviews were conducted with seven senior managers, twoadministrators and 12 clinicians. Interviews ranged from half an hour to three hours, with anumber of informants interviewed more than once. In all cases we took hand-written notes,some of which were supplemented by the use of an audio recording device. The projectconsumed approximately 650 hours of effort.

Overall, then, the selected research approach facilitated the development of a very granularunderstanding of clinical practice in the specialities studied, which informed the design of aninitial CPMM. The following section introduces the notion of process modelling, while the initialCPMM design is described in Section Four.

11


3. Process Modelling

Process Modelling is a specific kind of conceptual modelling. While conceptual models havebeen one of the key research topics in the IS field since the early 1970s (Wand 2002), interestin the area has increased recently as Service Oriented Architectures (SOA) and Model DrivenArchitectures (MDA) (Klepp, Warmer et al. 2003; Thomas 2004) have risen to prominence.

Conceptual models, as representations of a specific domain (Batani, Ceri et al. 1992), play animportant role in the IS design process. The method of conceptual modelling can serve a largevariety of different purposes (Wand 2002) and involves the application of the principle ofabstraction (Frank 1999). Specific purposes include facilitating communication between usersand software developers, supporting software developers' understanding of a certain domain,and documenting requirements for further design processes (Kung and Solvberg 1986).

In process modelling, conceptual models are developed in an attempt to describe an interrelatedset of processes within a specific organisational context. According to Becker and Kahn, aprocess is defined as “a completely closed, timely and logical sequence of activities which arerequired to work on a process-oriented business object” (2003 p.4). Typical business objects inthe context of hospitals would include patient records, prescriptions or patient appointments.

Process modelling can be used for a variety of purposes involving organisational design andapplication system design. Based on the specific purposes at hand, different perspectives (e.g.the perspective of a software engineer or a change manager) are incorporated (Rosemann,2003, p. 42). In the DATHs setting, an integration of a variety of perspectives is necessaryreflecting the professional/functional diversity of such workplaces.

In applying models in IS development processes, it is vital that the specific domain and itsmodelling requirements are accounted for (Weber 2003; Goldstein and Storey 1990; Prietula andMarch 1991; Batra and Marakas 1995; Hitchman 1995; Maier 1996). In what follows, specificrequirements for hospital-specific process modelling are discussed.

3.1 PROCESS MODELLING REQUIREMENTS IN CLINICAL SETTINGS

On the basis of the objectives of the Initial Design Phase and our understanding of the clinicalmodelling context, we identified a number of specific requirements that the modelling approachshould satisfy. These requirements are displayed in the following table and are subsequentlyoutlined in more detail.

12


NO. REQUIREMENT

Modelling Approach Requirements

I Involvement of all relevant stakeholders inthe development of the modelling process.

IIProcess models should identify andaccommodate variations across workpractices.

IIIProcess models should document the 'as-is'state and enable a discussion on a possiblefuture 'to-be' state.

IV The approach to designing process modelsshould be inclusive.

V Process models must reflect diversity.

VI Information needs should be modelled.

VII Process models have to reflect complexity.

VIII Process models should be extensible.

IX Process models must enable a commonunderstanding of processes.

TABLE ONE: Methodological Requirements

I. Involvement of all relevant stakeholders in the development of the modelling process.

The purpose of the models is to facilitate an understanding of clinical work practice as a meansof developing an initial specification for an IS. If, for instance, EPR systems are designedprimarily from a technical point of view, and do not reflect the needs of clinician stakeholders,then failure is likely. Therefore, an approach for modelling clinical processes has to integrate allrelevant stakeholders. A range of different stakeholders, as well as their particular role in theprocess, must be carefully considered. Any resultant models must be agreed upon by thestakeholders involved.

II. Process models should identify and accommodate variations across work practices.

Identifying and reflecting upon variations across work practices is crucial for the acceptance ofthe process models. The stronger each stakeholder group identifies with the model, the easierit is to use this model as a basis for discussion and the identification of process improvements.Common and divergent practices must be clearly identified within this approach.

III. Process models should document the 'as-is' state and enable a discussion on apossible future 'to-be' state.

The approach should not only facilitate the documentation of a certain state of a process but also

13


enable a discussion about this state as a means of developing to-be models.

IV. The approach to designing process models should be inclusive.

This approach is concerned with mapping the processes and practices of clinicians providingservices to patients. While much clinical activity is captured while a patient is in a hospital, it isalso vital to include the activities that take place before the patient arrives at and, after the patientleaves, the hospital. Examples of these activities include updating patient records, schedulingappointments and analysing tests.

V. Process models must reflect diversity.

In order to manage the diversity of stakeholders, needs and practices within a hospital context,multiple perspectives should be incorporated in the models. Thus, all stakeholders should beable to identify their contribution to the process within the models. For example, the role ofnurses on ward rounds differs substantially from that of junior doctors and consultants, and thisdiversity must be reflected in the models.

VI. Information needs should be modelled.

A focus on the information needs of clinicians calls for specific symbols to indicate informationneeds, and to link these needs to work practices, and to the material form which informationtakes in a given context (e.g. paper based documents, phone, and beeper).

VII. Process models have to reflect complexity.

The modelling language should identify processes and their interconnections, and facilitateabstraction as a means of managing complexity. Different levels of abstraction should beincorporated in the methodology to enable a more detailed analysis of certain activities.

VIII. Process models should be extensible.

The primary purpose of the models is to facilitate a discussion on processes. In the future,however, it is likely that new tasks might arise that can be supported by process models. forexample, a new billing or roistering system Therefore, process models should be designed (asfar as possible) in a way that ensures they are extensible and can be used for future purposes.

IX. Process models must enable a common understanding of processes.

A common understanding of clinical processes in hospitals is necessary in order to facilitate adiscussion about work practices, as well as identifying potential requirements for an IS system.The methodology should support the development of such a common understanding. A commonunderstanding in this context does not imply that all stakeholders have to accept oneperspective; this methodology should accommodate heterogeneous views.

14


3.2. CONCLUSION

In conclusion, a methodology for modelling clinical processes should meet all of therequirements described above. Based on our observations and experience in modellingprocesses, a specific CPMM was developed.

This CPMM is described in detail in the following section.

15


4.Designing a Clinical Process Mapping Methodology (CPMM)

A key success factor for the development and application of process models in a hospital contextis the integration of all relevant stakeholders in every stage of the modelling process. Here webegin by describing our approach to managing the development and application of the CPMM,which emphasises the importance of incorporating a plurality of perspectives. This is followedby an overview of the three distinctive elements, which constitute the CPMM. They are: 1)Process Chain, 2) Process Glossary and 3) Process Description.

The CPMM described in this report is designed for the purpose of providing a basis for adiscussion on the structure of processes in the DATHs context. It particularly aims at fulfillingthe requirements identified in section 3.1 of this report. Thus, it should be considered that furtherapplications might require changes to the methodology. Moreover, on each occasion where themethodology is used a statement of purpose must be constructed and agreed upon. Processmodels are always developed with a specific purpose in mind and attempts to over extend theirapplication should be treated with caution.

4.1 Managing the Application & Refinement of the CPMM

The following figure displays the main stages to be considered. It should be noted that this is nota strictly sequential process and much iteration between these stages will take place. Withineach stage certain tasks are performed, which are based on the process modelling requirementsoutlined earlier (Section 3.1). In what follows, each of the main stages within this managementprocess is described.

FIGURE ONE: Stages of the ApproachModelling support

16


Stage 1: Information gathering

This stage is the basis for all following stages. It is here that we gather relevant informationbased on the ethnographic methods described in Section Two.

Prior to the identification of processes, the aim and scope of the overall modelling project has tobe clearly defined. Based on the project specification, the boundaries and limitations of theproject need to be agreed.

The activities and work practices associated with each process are fundamental. Activitiesdefine what has to be done at a specific stage of a process, while practices indicate how theactivity is performed within a specific context. Apart from these two elements, further informationis needed on:

o the organisational unit (e.g. consultant, nurse etc.) performing a certain activityo the dedicated input and output of each observed activityo individual work practices as variants of certain activitieso the interconnection between the activities and their sequential and logical ordero parallel or alternative orders of activities and the reason for alternative orderso events in the processes that trigger certain activities as well as dedicated follow up

events or activitieso the connections to other processeso the IT artefacts in use to support certain activities ando individual information needs associated with specific activities

A single, on-off, observation is rarely sufficient to gather this information. If possible, more thanone observation of each process should be conducted and observations should besupplemented by semi-structured interviews with the relevant stakeholders. A key issue at thisstage is to identify variants of processes, in order to facilitate a richer appreciation of the diversityof practice.

A natural language description of the process should be developed for each process observed.This provides a good basis for further stages in the development and application of the processmodels (further details on process descriptions can be found in Section 4.2).

Stage 2: Design of as-is process model

Based on the observations and interviews documented in the process descriptions, processchains2 for each process identified are modelled. The design of the chains is achieved byabstraction. All similar processes that have been observed are analysed, and common activitiesand events are extracted and ordered within the process model. Within these models, indicators

2 Process chains are specific process maps focussing on the logical and sequential order of processes. For further details see the modelling language section (4.2.1) of this report.

17


for information needs, as well as individual work practices, are displayed.

All identified processes are then ordered within a framework indicating the role of a processwithin an organisation. This framework is an overall map that helps the user to navigate throughthe various process models throughout the DATHs. The framework should include all relevantbusiness objects and processes. When applying a case tool, the underlying clinical process canbe hyperlinked to the corresponding areas of the framework.

To enable a common understanding of the process, a process glossary is developed. Within thisglossary, all central terms and expressions that are specific for a certain stakeholder groupshould be explained (for more details see section on modelling language in Section 4.2.2).

The development of the as-is process model should be overseen by the process modellingteam. The main challenge at this stage is to make judgments about the appropriate level ofabstraction and to define the boundaries of processes and their interconnections. In order toallow more than one level of abstraction, the concept of 'abstract activities' is employed.Interconnections between processes can be visualised by the modelling frameworks andprocess signposts (see Section 4.2.1). Workshops on process modelling can facilitate thedevelopment of specific skills needed to design as-is process models. These as-is processmodels build the basis for important collective discussions on the as-is state of a process.

Stage 3: Discussion on as-is process model

This discussion should be initiated by the modelling team. All relevant stakeholders associatedwith the process in question should be invited. Relevant stakeholders would have beenidentified during the information gathering stage. A dedicated meeting or workshop with allrelevant documents, especially the glossary and the process chains should be organised tofacilitate a common understanding. The discussion should be open and all necessaryadjustments to the process models should be agreed. As a result, all stakeholders should agreethat the process models provide a helpful representation of the as-is state of the process.

In addition to reviewing the as-is model, this meeting should also explore suggestions onpotential to-be states of the process, giving each stakeholder group the opportunity to makecomments on process improvements. These process improvements are not limited toimprovements in the sequential and logical order of activities. Even more important may beimprovements in the mediation of activities by IT artefacts and in the provision of informationresource to support clinical practice. All comments on process improvements should becollected and documented for the development of a to-be process model.

18


Stage 4: Development of to-be model

Based on the stakeholders' suggestions, the practical feasibility of ideas must be examined.This includes consistency checks; it needs to be established what effects a change in oneprocess might evoke in other processes. The change in process chains can only beimplemented in the to-be model. This stage requires discussion between the modelling teamand relevant stakeholders. The development of to-be models may require several iterations.

Stage 5: Application of process models for further purposes

After all process models are reviewed and evaluated by the stakeholders, further applications ofthe models can be planned. It is worth reiterating that extreme case should be taken whenmaking judgements about the applicability of any model beyond the purposes for which it wasinitially conceived. The aim of this specific process modelling project is to develop a specificationfor an EPR system which addresses the information needs of clinicians.

The modelling approach needs to be supported by an adequate modelling language and tools.In the following section, components of the CPMM, which has been modified to incorporate thespecific requirements of clinical practice, are presented.

4.2 Modelling Language

Based on the requirements of this project, an event-driven modelling language was adapted forthe acute hospital context. This language provides a graphical view of processes through thedesign of process chains. In order to document the specific underlying work-practices, theprocess chains are supported by the process glossary and the process descriptions. Thefollowing section describes, in more detail, each element of the modelling language.

The method developed for this Initial Design Phase utilised a combination of descriptionsdistinguished by three distinct levels:

Process Chain: As an abstract description of a process, a process chain is included in theprocess model. This process chain is independent of any specific observed process in practice;it is a general abstraction of similar processes that have been observed. For example, a processchain for the outpatient clinics was constructed which may be applied to a variety of outpatientclinics independent of speciality (the extent of its applicability, of course, requires validation).

Process Glossary: The second aspect to be included in the process model is a processglossary, where central terms and abbreviations are explained. These glossaries are specific forcertain institutions and may cover more than one process instance.

19


Process Chains

FIGURE TWO: Constitutive elements of a process model in the DATHs context

Process Description: On the lowest level of abstraction, detailed process descriptions aredeveloped, which are specific for each observed process and organisational unit. Thesedescriptions include observed individual work practices.

The three constitutive elements of a process model for hospitals are displayed in Figure Two.

20


4.2.1 Process Chain

Process chains can be modelled in the semi-formal language of Event-Driven Process Chains(EPC) (Scheer 1998). This language aims to facilitates the development of a commonunderstanding and collective discussion about processes. EPCs are especially suitable for thedesign of an information system because they deliver an integrated view of processes (activities,events, and their interconnections), organisational units, and the IT and non-IT resourcesemployed in a process. In contrast to other modelling approaches, this integrated view ofprocesses enables the identification of interdependencies, technologies, tasks, andresponsibilities. Moreover, EPCs facilitate the direct linking of events and activities. Thisenables us to signify the interconnection between the fulfilment of a certain task, itspreconditions, and its outcome.

EPCs are directed graphs which use three basic elements for modelling the control flow.

Events depict flow-relevant states of the process. In contrast to activities, events consumeneither time nor cost. Within EPCs they are displayed as hexagons and do not have thecapability to make decisions. They potentially fulfil two tasks. One task is the initialisation ofactivities; the other task is the documentation of a state that has been reached after one or moreactivities have been executed. The example of a CT can be used for illustrative purposes. Asa starting event, a patient with an order form for a CT arrives in the CT department. This startingevent indicates that a CT activity should be conducted. The CT picture is a resource producedby this activity. The availability of this new resource for further activities is modelled by thefollowing event. This event can trigger further activities, for example printing the picture.

Activities are active nodes and transfer input and output data/ information. They are executedby resources and can indicate further process flows. In the DATHs context, typical activities areexecuted by consultants, SHOs, nurses or other professional units. Examples of activities arethe scheduling of a clinic on a certain day or performing a memory test or a full blood count(FBC). Activities are triggered by events. The outcome of an activity is one or more events. Forexample, the ordered FBC will trigger the conducting of an FBC, the result (as an event) is theavailable FBC result, which can be processed in another activity (e.g. a consultant setting up atest). In the graphs, they are identified by rectangles with soft rounded corners.

Logical Connectors are used to model splitting (outbound connectors), or joining (inboundconnectors), points in process models. Three different connectors are available in the EPC:

o Conjunction (AND-connector)o Disjunction (XOR-connector)o Adjunction (OR-connector)

AND-connectors indicate that certain process strings are processed in parallel, whereas XOR-connectors indicate that only one of the following strings can be processed as a follow up.Therefore, the XOR-connector is applied to indicate process variants. An example for a processvariant in the DATHs is a follow up investigation where the patient may be seen by a consultant,a junior doctor/ SHO, or a specialist nurse. The last possible connector is the OR-connector.

Events depict flow relevant states of theprocess. In contrast to activities, eventsconsume neither time nor cost. They do nothave the capability to make decisions. Theypotentially fulfil two tasks. One task is theinitialisation of activities; the other task is thedocumentation of a state that has beenreached after one or more activities have beenexecuted.

Activities are active nodes which transferinput and output data/ information. Theyrepresent certain tasks that have to be fulfilledin order to achieve a new state in the process.They are executed by human and non-humanelements and can influence the process flow.

Outbound Connectors They indicate thatafter a certain activity or event a process issplit up into different parts. The ANDOutbound connector indicates that thefollowing activities and events are parallel.XOR Outbound-connectors indicate that thefollowing activities and events are exclusive.OR indicates that (a) either one of thefollowing strings will be executed exclusivelyor, (b) more than one of the following stringswill be executed simultaneously. OR and XORoutbound-connectors can only be appliedfollowing an activity. AND outbound-connectors can also be applied after events.

This connector is applied to indicate that (a) either one of the following strings will be executedexclusively or, (b) more than one of the following strings will be executed simultaneously. In theDATHs context, this connector can be applied to indicate that, for example, the resultingdiagnosis for a specific patient may have different follow-up process variants, or a mixture ofmore than one variant is required. For instance, some patients only require an FBC as a followup, whereas other patients need an additional CT scan.

The basic elements of an EPC are displayed in the following table.

21


22


Inbound Connectors are used to reconnectdifferent strings of processes. The sameinbound connector should be used toreconnect the strings in order to facilitatenavigation within one process chain.

Control Flow: These are applied to representthe sequential and logical order of activities,events and connectors.

TABLE TWO: Basic Elements of EPC

These basic elements can be used for modelling processes. When applying these elements,some basic rules have to be considered:

o Every process chain starts and terminates with an event.o Events and activities follow each other.o Connectors can follow each other.o Neither an OR nor a XOR outbound connector can follow an event. This is not applicable

for inbound connectors.o Resources can be allocated to activities.

Due to the specific requirements of the hospital domain, and the intended application purpose ofthe models, the basic EPCs need to be customised for modelling clinical processes. Tospecifically deal with the complexity and diversity of this domain two more elements can beintroduced: process signposts and abstract activities.

Process Signposts indicate an interface between different processes in a hospital. Forexample, this concept can be applied in the outpatient clinic process to indicate that when ablood test is ordered, the process “blood test” is triggered.

Abstract Activities (which are represented in the EPC by an activity with a black point in theupper right corner of the rectangle) allow the integration of different levels of abstraction inprocess chains. This allows certain common sub-processes to be triggered within a large varietyof processes thus facilitating the reuse of model artefacts.

Both symbols are displayed in Figure Three.

23


Abstract Activities are applied for thedesignation of further processes/ practices at alower level of abstraction. They can be usedto identify more detailed process maps in orderto increase efficiency.

Process Signposts indicate that at a certainstage in the process another process istriggered. They can also represent a startingpoint of another process and, therefore, shouldhave the same name. Process Signposts willfacilitate navigation across the process maps.

In addition, many of the resources attached to activities are specific to the DATHs. Based onour preliminary work, many of the following resources would appear to be relevant: humanresources (specified and unspecified), data and application systems, paper based documentsand other resources. These resources can be attached to activities by a directional allocationedge. Figure Four describes the meaning of the symbols we specified to model theseresources.

FIGURE THREE: Process signposts and abstract activities

Allocation edge. Used to link resources toactivities, could be inbound, outbound or non-directional.

Specified Human resource (function) whichperforms an activity.

Unspecified Human resource (function) whichperforms an activity.

24


Application System to be used for supportingan activity.

Paper based document.

Data/ Information to be processed by anapplication system.

Other IT artefacts that are used as tools in orderto facilitate the information exchange (e.g.telephone, beeper).

FIGURE FOUR: Relevant resources for clinical processes

Based on the specific process modelling in the DATHs, symbols for annotations have to beprovided. This is particularly important for modelling individual information needs. Theseannotations are used in order to indicate a specific individual information need (triangle), anunderlying work-practice (circle), or other specific comments on elements of the EPC(rectangle). Annotations for information needs can be attached to resources, whereasannotations for underlying work practices can only be attached to activities. Annotations forspecific comments can be attached to every element of the EPC. All annotations should benumbered sequentially, linked to a process description, and explained in detail. The annotationsymbols are displayed in Figure Five.

Symbols for further natural language basedexplanations e.g. certain specific workpractices.

Symbols for an information need,corresponding to a certain resource.

General symbols for specific comments.

1

FIGURE FIVE: Symbols for EPCs

Figures Six, Seven and Eight provide examples of initial process chains constructed during theDesign Phase.

25


FIGURE SIX: Process Model “Outpatient Clinic” Part One

26


FIGURE SEVEN: Process Model “Outpatient Clinic” Part Two

27


FIGURE EIGHT: Process Model “Outpatient Clinic” Part Three

28


There are a large amount of case tools available for process modelling. We used a packagewhich supports the definition of extensions to EPCs as well as the definition of standardisedshapes that can be reused for modelling the different constructs. In this initial design phase,customised shapes were developed. The software we used has the ability to hyperlink certainconstructs with other elements of the modelling language; for example, a direct hyperlink to anelement of the process glossary. Furthermore, the process chains can be modified by means ofcut-and-paste operations. This facilitates the development of to-be models in Stage Four of ourapproach.

4.2.2. Process Glossary

The process glossary specifies all terms and abbreviations associated with a specific process.It is essential in terms of facilitating a discussion amongst all stakeholders about a certainprocess. Based on the process description and the process chains, all relevant terms andabbreviations that need to be explained are extracted and integrated in the glossary. Theglossary is formatted within a table, as illustrated in the following figure.

Apart from the abbreviations shown above, key terms can also be explained in the glossary (e.g.a “Parkinson test”). The glossary can be implemented as a Microsoft Word document. Thisoffers the potential of hyper-linking to other documents (e.g. to a scan of the Parkinson testdocument), or to process descriptions and process chains.

4.2.3. Process Description

The process description is a basic part of the modelling language and consists of two elements:1) basic information in the form of a table, and 2) a natural language description of the observedprocess. For each observed process a specific process description is provided. The processdescription builds the basis for the elaboration of activities and events, as well as processvariants and underlying work practices. Process descriptions are standardised documents.Figure Ten provides an illustrative example of a part of a process description.

TERM EXPLANATION

FBC Full Blood Count

GP General Practitioner

OT Occupational Therapist

PT Physiotherapist

CT Computed Tomography

Patient Centre Patient Centre is a specific applicationsystem

FIGURE NINE: Example of a process glossary

29


NAME OF THE PROCESS NEUROLOGY CLINIC

Date of observation 04.04.2006

Hospital Hospital X

Name and role of stakeholders that havebeen observed

Dr. A, consultantB, SHOC, Specialist registrarD, Secretary

Name of observation team members Ó Scolaí, PeadarBuddendick, Christian

Basic information:

Natural language description of observed process:

The neurology clinic process is a core process… .

FIGURE 10: Example of process description

Within the process description the following fields and sections should be filled out:

1. Name of the process.

2. Date of observation.

3. Name of observation team members.

4. Name and role of stakeholders that have been observed.

5. Description of observed process (timely and logical ordered).

6. Identified information needs and corresponding activities. The information needs should belinked to the annotations in the process chain by reference to the number of the annotation. Ifapplicable, specific resources and their communicative limitations should be indicated.

7. Identified work practices. In this section the corresponding activities should be mentioned.To link the work practices to the process chains the number of the annotation displayed in thechain should be quoted.

8. Related processes (name of processes that trigger the described specific process, as well asname of processes that are triggered; table; hyperlinks).

To summarise, then, individual work practices and the corresponding information needs of all

30


stakeholders are documented in a natural language process description which constitutes thefirst layer of a CPMM. Each observed discipline has its own specific process description. In thesecond layer these descriptions form the basis for the development of process glossaries, wherekey context specific terms are explained in a table. The process glossary can be eitherclinic/process specific or organisation specific. Process specific glossaries facilitate a commonunderstanding across different hospitals, whereas hospital specific glossaries facilitate acommon understanding across different hospital specialisms. The third layer consists of processchains.

4.3 DATHs-Specific Elements of the CPMM

This proposed methodology is based on, and adapted from, well established process modellingmethods. Having regard to the uniqueness of the acute hospital sector we decided to employan event driven modelling approach. An exclusive focus on events in mapping clinicalinformation needs, however, is insufficient. Both events and activities must be identified anddescribed. Activities, in particular, offer the potential to learn about clinical information needs. Inthis regard, the individual work practices of various stakeholder activities must be represented.

The following points summarise the main DATHs-specific elements of the methodology that weredesigned as part of this adaptation on the basis of our ethnographic engagement with the initialresearch sites.

o The methodology allows one to explicitly note the material form of clinical information artefacts.

o The methodology is not limited to a set of symbols for mapping. It also incorporates an approach to facilitate the development and discussion of the models.

o Processes are not solely described by process chains. In addition, work practices and information needs are mapped by means of process descriptions. Furthermore, a process glossary is constructed in order to facilitate a common understanding among allstakeholders.

o Based on observations, DATHs-specific symbols for clinical process modelling were specified. Moreover, in addition to the standardised elements of an EPC, we developed two DATHs-specific elements: Process Signposts and Abstract Activities. The section on resources is also DATHs-specific. For example, a symbol for modelling certain paper-based documents is incorporated in the language.

o DATHs-specific annotations were designed to model information needs and work practices. These annotations identify possible limitations within the process maps, and they enable a cooperative discussion on how far different work practices should be supported by an EPR specification.

31


5. Conclusions, Scope and Recommendations

This is a first attempt at developing a CPMM that can be used to identify and represent clinicalpractice at varying levels of granularity. If used appropriately, this kind of approach offers ameans of facilitating the process of specifying an EPR system for acute hospitals in a mannerthat recognises and supports the complexity of clinical work practices.

At the very least, process models emphasise the interactive and unfolding nature of healthcarework (Berg and Toussaint 2003). In particular, it allows us to model a broad range of workprocesses without preconceptions as to which of these may be supported (or, indeed, partiallyor completely automated) by electronic information systems. Indeed, a striking feature of ourobservations of hospital life was the diversity of different (non-electronic) technologies thatappear to play a central role in co-ordinating clinical work (e.g. paper charts, telephones,bleepers etc.). Decisions can then be subsequently made about which (if any) clinicalprocesses/practices need to be supported by different kinds of technology, and the extent towhich these can and should be integrated. In principle, the CPMM described in this documentfacilitates such an approach (Robinson, Frosdick et al. 2001).

Moreover, this initial design phase highlighted a number of potential benefits of using a CPMM.For instance, the models/maps provided a useful way of revealing the complexity of a clinicalenvironment and its constituent practices. In both research sites the clinicians appeared to findthe maps useful and the language intuitive. The maps provided a way of reflecting on theprocesses and sparked a useful on-site discussion which proved fruitful in addressing variousmisconceptions.

Notwithstanding those positive indications, the time constraints within which this study wasconducted, and its limited scope (i.e. the fact that it was confined to specific functions within twoclinical departments), are two important issues that should be borne in mind. In particular, theamount of time required to develop a sophisticated understanding of complex clinical workpractices, and the extent of the possible divergence in practices across departments andlocations, should not be underestimated. Furthermore, while mapping descriptions are useful, itshould not be forgotten that they are necessarily underspecified and … “[a]ny concrete workactivity only unfolds 'in the doing', in constant interaction with the contingent circumstances thatmake up the situation in which it is located” (p.92 Berg 1999). All models are limited in that theyprovide a purposeful, and necessarily partial, perspective on a complex social/organisational‘reality’. Consequently, it is imperative not to mistake the model for the ‘reality’ that it purports torepresent. One of the key benefits of process modelling is likely to be the understanding gainedthrough participation in the process as opposed to the model produced.

To further develop this methodology it is necessary to engage in a comprehensive process of

32


refinement and negotiation across other hospitals and other medical specialities. Researchquestions in this area should focus on the following issues:

o Validation of the approach: Does this methodology and associated models support a useful discussion on EPR specification and design? It is important to note that, while initial feedback from clinicians was encouraging, the methodology has not yet been tested 'in anger'. Consequently, the modelling approach should be used and developed further in the context of the two clinical departments involved in the initial design phase. Issues of particular interest include the extent and quality of clinician engagement thatthe method facilitates, and the ease with which good quality initial specifications for ICTsupport might be developed.

o Broader roll-out across the DATHs: Is the method appropriate in other application areas?

o Operational issues: How easy will it be for the IS team to appropriate the method and apply it in a mature manner within their everyday work practices?

In conclusion, we see a value in the production of process maps and descriptions which facilitatean understanding of clinical processes and practices at a level of granularity that is currentlyabsent in the DATHs setting. We believe this initial CPMM presents a basis from which toexamine clinical processes and identify a range of clinical information needs, and we areencouraged by the initial support and feedback from clinicians. In our view, the emphasis shouldbe on the collective sense-making processes that such modelling activities facilitate. It is this'methodology-in-use' that is crucial to the facilitation of meaningful forms or communication andcollaboration across a broad range of clinical areas. Consequently, the skill, judgement andexperience of those using the methodology will be crucial to its successful deployment.

As a first step, the CPMM should be piloted in a number of sites. In developing appropriatecompetencies in the use of this methodology, the DATHs may wish to consider focusing on twolevels.

o Process Level: A team of modelling experts to evaluate and further develop the methodology in tandem with the implementation team. This team could also help to coordinate its application by means of an ongoing coaching process.

o Project Level: In order to safeguard the quality of the overall project approach and to ensure that clinical practices are identified, another research team (not directly involved in modelling) could monitor the project and play a supervisory role in observing the data collection.

33


This CPMM offers a promising approach to overcoming some of the reported difficultiesassociated with system specification, design and implementation within clinical settings. It hasthe potential to create an environment of mutual understanding and shared responsibility forsystem design and implementation. Used appropriately, the CPMM can facilitate helpful formsof individual and collective reflection, and provide a focus for meaningful and actionable dialoguebetween clinicians and IS professionals.

Moreover, this CPMM represents an innovative approach to the development of an initialElectronic Patient Record specification that will be sensitive to the complexity and diversity ofclinical practice.

34


Appendix 1

The Centre for Innovation, Technology & Organisation (CITO), at the UCD School of Business,is home to a multi-disciplinary research community that is broadly concerned with understandingthe role played by information, knowledge, and information and communication technologies(ICT) in the constitution and transformation of organisational life.

CITO's approach is guided by the assumption that a sophisticated understanding of ICT, andtheir role in mediating social and organisational life, should be based on an appreciation of howsuch artefacts come to be embedded within broader institutional (organisational, cultural,economic, political) contexts.

Since 2003, CITO has been developing a research agenda focusing on the development anduse of ICTs for organisational innovation within the Irish Health Service.

Through its relationship with key healthcare players in the Irish context, and its access tonetworks of international research teams, CITO hope to facilitate a discussion on the role oftechnology in healthcare and to provide specialist resources and advice when possible.

In keeping with its modus operandi as a network organisation, CITO invited the EuropeanResearch Centre for Information Systems (ERCIS) (based at the University of MünsterGermany) to partner in this project. ERCIS has extensive experience in process engineering,which proved invaluable.

The research team consisted of:

Dr Séamas Kelly (UCD) Director of CITO and Principal Investigator.

Dr Jan vom Brocke (University of Münster) Principal Process Researcher.

Mr Peadar Ó Scolaí (UCD) Investigator and Project Manager.

Mr Christian Buddendick (University of Münster) Investigator.

Professor Stefan Klein and Professor Andrew Deegan acted in an advisory capacity.

35


References

Anderson, J. and C. Aydin (2005). “Evaluating Organizational Impact of Healthcare InformationSystems.” New York, Springer Science and Business Media, Inc.

Batani, C., Ceri, S., and Navathe, J.B. “Conceptual Database Design: An Entity-RelationshipApproach”. Benjamin/Cummings, Reedwood City, Ca, 1992.

Batra, D., and Marakas, G.M. “Conceptual data modeling in theory and practice,” EuropeanJournal of Information Systems (4) 1995, pp 185-193.

Becker, J., and Kahn, D. “The Process in Focus,” in: Process Management - A Guide for theDesign of Business Processes, J. Becker, M. Kugler and M. Rosemann (eds.), Springer, Berlinet al., 2003, pp. 1-12.

Berg, M. (1999). “Patient care information systems and health care work: a sociotechnicalapproach.” International Journal of Health Informatics (55): 87-101.

Berg, M. and P. Toussaint (2003). “The mantra of modeling and the forgotten powers of paper: asociotechnical view on the development of process-oriented ICT in health care.” InternationalJournal of Medical Informatics(69): 223-234.

Boonstra, A., D. Boddy, M., Fischibacher. (2004). “The limited acceptance of an electronicprescription system by general practitioners: reasons and practical implications.” NewTechnology, Work and Employment 19(2): 128-144.

Brocke, J. v. and C. Buddendick (2006). “Knowledge Evolution on the Basis of Reference Mod-els, Towards a Theoretical Foundation.” 5th IADIS International Conference WWW/Internet2006, Murcia, Spain.

Ellingsen, G. and E. Monteiro (2003). “A Patchwork Planet: Integration and Cooperation in Hos-pitals.” Computer Supported Cooperative Work(12): 71-95.

Frank, U. (1999). “Conceptual Modelling as the Core of the Information Systems Discipline -Perspectives and Epistemological Challenges.” Fifth Americas Conference on Information Sys-tems (AMCIS 1999), Milwaukee, Wisconsin 1999.

Goldstein, R. C. and V. Storey (1990). “Some findings on the intuitiveness of entity-relationshipconstructs.” Entity-Relationship Approach to Database Design. F. H. Lochovsky. Amsterdam,Netherlands, Elsevier Science Publishers, B. V.: 9-23.

Hanseth, O. and N. Lundberg (2001). “Designing Work Oriented Infrastructures.” ComputerSupported Cooperative Work 10: 347-372.

Hitchman, S. (1995). “Practitioner perceptions of the use of some semantic concepts in the en-tity-relationship model.” European Journal of Information Systems 4: 31-40.

36


Klepp, A., J. Warmer, et al. (2003). “MDA Explained: The Model Driven Architecture - Practiceand Promise.” New York, Addison-Wesley.

Kling, R. and W. Scacchi (1982). “The Web of Computing: Computer Technology as Social Or-ganization.” Advances in Computing 21: 2-85.

Kung, C. H. and A. Solvberg (1986). “Activity modeling and behaviour modeling.” InformationSystems Design Methodologies: Improving the Practice. T. W. Olle, Sol, H.G., and Verijen-Stuart,A.A. Amsterdam, Netherlands, Elsevier Science Publishers, B. V.: 145-171.

Maier, R. (1996). “Benefits and quality of data modeling-Results of an empirical analysis.” 15thInternet. Conf. Entity-Relationship Approach, Cottbus, Germany.

Prietula, M. J. and S. T. March (1991). “Form and substance in physical database design: Anempirical study.” Information Systems Research 2: 287-314.

Robinson, D., P. Frosdick, Brisco, Els. (2001). “HL7 Version 3: An Impact Assessment.” N. H. S.U. Kingdom, NHS Information Authority 35.

Rosemann, M. (2003). “Preparation of Modeling. Process Management - A Guide for the Designof Business Processes.” J. Becker, M. Kugler and M. Rosemann. Berlin et al., Springer: 41-78.

Scheer, A.-W. (1998). “ARIS - Business Process Modelling.” Berlin et al., Springer.

Thomas, D. (2004). “MDA: Revenge of the Modelers or UML Utopia?” IEEE Software May/June2004: 22-24.

Timmermans S and Berg M (2003). “The practice of medical technology.” Sociology of Health &Illness 25: 97-114.

Wand, Y., and Weber, R. (2002). “Research Commentary: Information Systems and ConceptualModeling - A Research Agenda.” Information Systems Research 13(4): 363-376.

Weber, R. (2003). “Editor´s comments: Still Desperately Seeking the IT Artifact.” MIS Quarterly27(2): iii-xi.

37


For further information contact:

Dr Séamas Kelly [email protected] Ó Scolaí [email protected]

Scoil Ghnó Uí Chuinn UCDAn Coláiste Ollscoile, Baile Átha CliathBelfield, Baile Átha Cliath 4, Éire.


UCD School of Business

T o w ards a Clinical Process Mapping Methodology (CPM M...

Documents

Transcript of T o w ards a Clinical Process Mapping Methodology (CPM M...