CITACIÓN A PARTICULARES

A number of researchers have looked explicitly at process modelling and the computerisation of workflows and clinical guidelines [192, 198, 199, 200, 193, 194, 195, 196, 197]. Examples of these researches include:

• {M}1_{Muscholl [198, 199] proposes an architectural model to support a standardised ref-}

erence model for clinical guidelines and interchange among distributed CISs. The {G} Guideline Interchange Format (GLIF) [200] and workflow reference model published by

68 7.5 Workflow Technology in Healthcare

WFMC [201] are similar projects to Muscholl, in that they aim to unify the rules among multiple systems by designing a suitable architectural model. These projects demon- strated the benefits of having an automated common reference model in this domain. However, they did not go beyond the model and discuss how practically the model could be implemented.

• {K} Knape et al. [193], focus on the need to facilitate the use of clinical guidelines. This research proposed an approach which transforms narrative clinical guidelines into a UML model, which then could be translated into an XMI (XML Metadata Interchange) rep- resentation, which can be used to build appropriate information systems. This research shows the need to have guidelines attached to clinical decision systems for adaptive sup- port. However, it does not look practically at how this approach could be implemented. Similarly, {P} Peleg and Samson [194], propose a template which could be used to trans- late narrative guidelines to produce a representation which could be used electronically to create suitable information systems.

• {Ma} Mans et al. [195], propose a framework called Proclet to model the gynaecological oncology care process. They compare the proposed framework with other modelling techniques and present how it advances this support to real-life scenarios. The research compares the modelling techniques in-terms of their granularity and concurrency support for different interactions. Again, this is a modelling approach which does not describe an implementation approach.

• {A} Alexandrou et al. [196], propose a prototype which supports real-time adoption of the healthcare processes. It comprises a process execution engine assisted by a semantic info-structure. Although this research uses similar tools to those proposed in our approach including: clinical guidelines and workflow technology, the focus is different. In our re- search we focus on supporting the communication and coordination among care team members as an important goal in the implementation of the treatment process. Alexan- drou’s prototype [196] focuses on supporting continuous change in the treatment process as its main goal.

• {H} Huser et al. [197], use an open-source WFMS to support clinical decision making based on clinical guidelines. This research uses similar tools to those suggested by us but focuses on different aspects of the treatment process. In our approach we look at the support for communication and coordination along the treatment pathway. This means we look at decision points but unlike Huser’s approach where this is the focus, in our work it is part of the process being implemented.

7.5 Workflow Technology in Healthcare 69

In order to position our work against these different approaches, we need to look at their support for: communication, coordination, ICPs, and workflows. These are the basic elements of our research and are the difference between their approaches and the approach we propose. Table 7.2 analyses the support for these different elements for the system discussed here.

Approaches Communication Coordination ICP Workflow Implementation

{M} [198, 199] _{X X X} X X {G} [200] _{X X X} X X {K} [193] _{X X X} X X {p} [194] X X X X X {Ma} [195] _{X X X} X X {A} [196] - - _{X X} X {H} [197] - - _{X X} X

Table 7.2: Analysis of Different Approaches.

Key: a ‘_{X’means facility, ‘X’means not facility and ‘- ’means not mentioned as a goal.}

7.5.2

Discussion

Projects proposed in the literature which use workflow technology in the healthcare domain, mainly support a very focused task which is a stand-alone solution. Although they promote flexibility and adaptability as key benefits, the functionality they promote are very limited and are to be used at a single department or organisation. These projects are mainly proposing administrative tools which do not consider the support for patient-centric care. These are clearly distinguished as being different from the concept proposed in this research where the system is aimed at supporting the care team’s work as the patient proceeds along an ICP.

The different projects that use workflow technology confirm the capabilities of such a tool and the benefits it provides to the processes implemented. These projects confirm its flexibility, adaptability, scaleability as well as its ability to automate processes, handle exceptions, and interact with humans and machines.

Table 7.2, shows that even projects that focus on computerisation of workflows and clinical guidelines do not actually take their approaches beyond the models or simply do not address the uses which were the focus of this research, namely the support for team communication and care coordination. A systematic survey on computerisation of workflows, guidelines, and care pathways published in 2012 [192], identified 108 different research projects in this area. It classifies the different approaches as:

70 7.5 Workflow Technology in Healthcare

• Electronic healthcare record integration,

• Clinical workflow integration and point of care, and

• System implementations: knowledge models, software, and architecture.

Our approach focuses on the second and third of these areas. We studied the clinical workflow integration and the support it could provide for decisions being made at the point of care, as well as creating an architecture coping with existing legacy systems.

In terms of Implementation, none of the projects that implements clinical guidelines into a work- flow engine focuses on support for the treatment process by supporting team communication and care coordination. while in terms of architecture, none of the projects using workflow techno- logy addressed the need for independent tools that interact with legacy systems. Moreover, none identified the resulting system as a tool that evolves these systems and enhances their function- alities. The vision of constructing a VO around the patient needs for patient-centric care is also novel.

71

Chapter 8

Workflow: Terminology and Concept

Overview

In chapter 7, workflow technology was selected as a suitable tool to support the research prob- lem specified in chapter 6. Literature review showed that there are different workflow types and therefore different types of system are available. This chapter presents the study under- taken to identify the specification of the workflow system type that gives the best support for the problem domain. Moreover, a selection process was conducted to choose a WFMS for the proof-of-concept prototype.

72 8.2 Workflow Terminology

8.1

Introduction

The following sections describe workflow technology. It explains related terminologies, work- flow types, type of flows, patterns, and WFMS types. This will be followed by an introduction to different WFMSs and a comparison between them. This concludes with a list of the char- acteristics of a WFMS’s engine that best suit the problem domain. According to the specified characteristics, a system is then selected to be used in implementing a prototype to meet the project’s aims.

8.2

Workflow Terminology

Some of the terminologies and concepts associated with workflow technology will be briefly in- troduced in the following sections and also the relationships between the different terminologies will be presented in figure 8.1.

8.2.1

Workflow

A workflow is the sequence of steps or processes from initiation to completion through which a piece of work is accomplished. The steps can be industrial or administrative or any other type of process. The WFMC defines workflow as:

“The automation of business process, in whole or part, during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules” [2].

8.2.2

WFMS

Initially, the pattern and design of a workflow was coded into applications to execute the busi- ness flow logic of an organisation. With the evolution of the computer, information and object- oriented technologies, nowadays WFMSs have been widely implemented to support distributed work units through use of a workflow engine [174, 173]. The WFMC defines a WFMS as: “A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications” [2].

8.2 Workflow Terminology 73

8.2.3

Business Process

According to [202], the activities in organisations can be: material processes where physically humans move things from one place to another to perform an action; Information processes where techniques of data processing are used in a networked environment for valuable inform- ation processing; and/or business processes, where roles and acts get involved in the process. In practice, business processes usually get implemented in information processes with some sort of data processing. Information processes are then implemented as material processes where manual processes can be involved.

Business processes generally can be described as the flow of procedures or activities that are undertaken to perform a certain task or service. There can be one or more activity(s) in a business process but they are usually restricted to a certain role in the organisation and each role is restricted to specific actions. Moreover, activities in a business process usually require an input which gets processed through a method to produce an output [2, 174, 202, 203].

8.2.4

Process Definition

A process definition is linked to pre-defined roles of the business process flow which sustain and support the execution of the workflow logic by a WFMS. It also includes accurate information about routing conditions, inputs, and outputs as well as authorised users, data to be used, and the invoked IT resources of every single activity in the workflow [2, 174, 204].

8.2.5

Activity (Process)

Activity in a workflow is the piece of work that forms a logical step to perform the business objective. It can be either a manual or automated step and can use a resource such as data, web services and/or a computer application [2].