Introduction to Workflow in Healthcare

This article introduces Workflow Management Systems and their role in healthcare.

Workflow has its genesis in the imaging industry, from where it moved into mainstream production environments, such as manufacturing. Workflow aims to monitor and coordinate the activities associated with well defined business processes. It does this by having a Workflow Engine direct the flow of activities, under instructions from a Process Definition that ties together the component activities or tasks , including decision- making, notification, synchronisation etc. Tasks can either be launched automatically by computer, or placed on worklists to be initiated manually.

Workflow Systems, rather than concentrate on the detail of tasks, provide an environment to automate and assist the management of tasks and the flow of workitems from one task to the next. They encompass authorisation, authentication, scheduling, monitoring, event processing, queues, prioritisation, escalation, load balancing, task termination, auditing.We could say that workflow focuses on the “who” and the “how” of actions.

In the past few years, there has been a growing belief that workflow technologies could benefit many areas of healthcare and as such, just like the Electronic Health Record (EHR), should form a foundation stone for the next generation of health information systems.

Collaborative workflows are focused on achieving a common goal and often require that the participants have access to a common set of documents or information and hence are often connected to document-management systems. In healthcare, this repository-based system is minimally, a Patient Identification System and ideally, a comprehensive Electronic Health Record System.

In workflow systems, we normally expect to have defined a given process and at run time, we invoke “instances” of the process. In healthcare, we refer to each instance as a “case”. The “case” is treated as an object which changes state as it flows through the process. The process is composed of distinct “activities”, which at run time, become “activity instances” or “tasks”. These tasks might be performed automatically by a computer, or the may be placed in a queue for a human, or group of humans to undertake. Such a queue is termed a “worklist”, and each item on the worklist is referred to as a “workitem”. Thus, a “workitem” describes a task to be undertaken by a specific person or role.

Workflow systems have been utilised in a number of domains for many years.

Productivity and quality gains have encouraged their adoption in more industries. However, before workflow functionality becomes an integral component of health information management systems, there are some domain specific hurdles that need to be cleared, including, but not limited to the following:-

1. Distributed - Traditional production workflow systems were confined to one organisation. In many healthcare situations, a number of care providers may be involved. Each of these separate actors have their own work practices and systems, and so, many workflow systems need to be distributed and interinstitutional. This implies a requirement for introspection i.e. The ability to interrogate a system at runtime for information about itself.

2. instance-adaptive - workflow instances ( ie. Individual patient in care process ) need to adapt or even transfer to a different workflow schema. Example: someone is admitted for appendectomy. “Appendectomy Workflow” is instantiated. Patient undergoes surgery and contracts Haemolytic Streptococcal infection, which is diagnosed as malaria. Patient is placed under “Malaria treatment workflow”. Finally diagnosis is changed to correct initial misdiagnosis and “Haemolytic Strep. Treatment Workflow” is invoked.
The above three could be treated as separate workflows, but it is likely that some form of messaging will be required between the three instances. In the above example, the workflows are invoked sequentially. Sometimes the workflows are invoked concurrently, due to uncertainty in diagnosis. Another consequence of ad-hoc change, is the requirement for new actors to come on board.

3. non-deterministic. i.e. States are not necessarily related to activities or events. This means that traditional object life-cycle models are inadequate. Traditional (Petri-net based) models of object life-cycles assume that a state results from a transition. In healthcare, we are not dealing with causal systems ( at least not in the macro observable level). It may be true for some activities, but not necessarily for others. E.g. Activities which are measurements are deterministic: transition.take_Xray ==> place.Xray_taken, but activities that invoke actions often are not: transition.lower_BP may not result in place.BP_lowered. A second example is the frequent occurrence of state changes without any modelled event.

4. based on expectations. i.e. Care plans are about intent rather than result.

 5. complex - in terms of:-

• the number of activities.

• the number of attributes.

• uncertainty of attributes.

• events are often analog and long-lasting.

• the patient ( or some part thereof ) is an object.

• roles - ad hoc ( see 6. )

 6. properties and behaviour of actors are not defined a priori . Actors (clinicians etc.) should probably be modelled as objects, whereas traditional workflow  systems tend to ignore the properties and behaviour of participants and roles in the workflow process. Healthcare actors possess attributes and behaviour, such as current role, expertise, availability, ability to prescribe etc.

Some other concepts are often integrated with, related to, or mistaken for workflow, including:-

• Coordinated Care

• Managed Care

• Clinical Guidelines

• Care Plans

• Decision Support Systems.

Unfortunately, like Workflow, each of these terms carries a deal of historical and political baggage,that might predispose the reader to align with or be antagonistic towards.

Author: Eric Browne

Further information: