Health informatics

Lecture 4: Understanding clinical processes

Research on computer interpretable clinical guidelines and clinical decision support systems discussed in the previous lecture has largely focused on individual points of care rather than processes of care. Whether we consider simple aids like clinical alerts and reminders or more sophisticated systems for interpreting data and giving advice on diagnosis and treatment, application developers tend to focus on specific tasks rather than clinical processes which are extended in time. Yet the delivery of patient care always involves some kind of process, whether carried out by people or by a mixture of people and computers, particularly in the treatment of chronic and other long-term conditions. Patients frequently have personal care plans and complex processes are often organized around standard care pathways. The schematic figure below is an example of a care pathway for women with suspected and/or proven breast cancer. This has a number of phases (covering the detection of possible disease, work-up/diagnosis; treatment and long-term follow-up) within which each box represents a collection of specialist services which have to be properly coordinated and for which reliable and timely communication needs to be maintained between everyone involved; the arrows show some of the many lines of communication channels which may be used during the care of a single patient with suspected breast cancer.

Key challenges in providing informatics support for complex care pathways such as this include: 1. Supporting communication between all the members of the care team and the patient (and computer systems) to ensure all are properly informed, and their work is coordinated in a reliable and safe manner. 2. Workflow support, including support for clinical and administrative tasks over extended periods of time. Clinical tasks include accurate recording of clinical information, making decisions appropriately and acting on them in a timely way, and managing complex treatment plans (e.g. chemotherapy usually involves a number of courses of treatment, each consisting of several cycles, in which each cycle may require the administration of several drugs to the patient in a complex schedule.

Communication and coordination

Most health care processes involve exchanging information. Four different types of communication can be distinguished based on the physical distance that the information has to travel. These are listed in decreasing order of information volume yet in increasing order of use of information technology. 1. Within the workgroup, to record and manage the care of individual patients 2. Between specialised diagnostic and treatment departments, to request services and to report results 3. Across organisation boundaries between hospital doctors GPs and community staff, to ensure continuity of care 4. From the care provider to payers and regulatory agencies, for revenue and accountability. Just as people are only able to communicate with each other if they have a common language, computer applications can only share information if they communicate with a common protocol, covering: Functional interoperability: functions to physically communicate, e.g. send and receive documents and data files, share data and information. Semantic interoperability: common vocabulary and concepts that allows them to understand complex medical conditions and processes (lecture 2).

HL7 standard for functional interoperability

Health Level 7 is a standards organization that was created to develop and maintain open protocols for communication between healthcare systems. The HL7 interoperability protocol is an internationally accepted and accredited standard for inter-system and inter-organisation messaging, clinical text document mark-up, and user interface integration as well as a health data model and a message development methodology. The main areas covered by the standard are shown below.

HL7 version 2 (copyright T Benson)

HL7 Version 2 is the most widely used healthcare interoperability standard in the World. It is used in over 90% of all hospitals in the USA and is increasingly supported by healthcare IT suppliers worldwide. The initial focus of HL7 in 1987 was on exchanging information about patient admissions, discharges and transfers within hospitals. HL7 V2.0 (1988) included a major extension to add in messages for exchanging orders and reports for tests and treatment. An HL7 message is a way to transmit data between disparate systems. HL7 V2 messages are sent in response to trigger events. An HL7 trigger event is a real-world event that initiates communication and the sending of a message, and is shown as part of the message type. The trigger event

indicates what happened to cause a message to be generated; it defines the purpose for the message being sent and is present in every HL7 message. The key concepts underlying the HL7 messaging standard are shown in the following figure.

HL7 key concepts (copyright T Benson)

Message types are identified by a three-character code, and are used in conjunction with a trigger event. Very commonly used message types include ACK General acknowledgement ADT Admit/discharge transfer MDM Medical document management MFN Master files notification ORM Order (Pharmacy/treatment)

ORU Observation result QRY Query RAS Pharmacy/treatment administration RDE Pharmacy/treatment order RGV Pharmacy/treatment given SIU Scheduling information

As in the example below message consists of a group of segments in a defined sequence, with these segments (or groups of segments) being optional or mandatory, and/or repeatable.

The name of each segment in the message is specified by the first field of the segment, which is always three characters long. For example: MSH (Message Header) contains information about the message itself, including sender and receiver of the message, the type of message, and the date and time it was sent. PID (Patient Information) contains demographic information about the patient, such as name, patient ID and address. NK1 (Next of Kin) contains contact information for the patient's next of kin. PV1 (Patient Visit) contains information about the patient's hospital stay, such as the assigned location and the referring doctor. Over 120 different segments are available for use in HL7 messages.

HL7 Reference Information Model (RIM)

HL7 is a language, and every language has a grammar. The HL7 Reference Information Model or RIM specifies the grammar of HL7 messages and, specifically, the basic building blocks of the language and their permitted relationships. The RIM is not a model of healthcare, although it is healthcare specific, nor is it a model of any message, although it is used in messages. The RIM backbone has five core classes and a number of permitted relationships between them. In HL7 V3, every happening is an Act, which is analogous to a verb in

English. Each Act may have any number of Participations, in Roles, played by Entities. These are analogous to nouns. Each Act may also be related to other Acts, via Act Relationships. Act, Role and Entity classes also have a number of specialisations. For example, Entity has a specialisation called Living Subject, which itself has a specialisation called Person. Person inherits the attributes of both Entity and Living Subject. The Version 3 RIM defines all the things of interest referenced in HL7 messages, structured documents or any future HL7 "information packages" that may be needed for advanced services like clinical decision support and care plans. The main parts of the current version of the RIM define the professional and other roles that individuals can plan in a process of care, the acts they are able to carry out and so on.

The RIM is expressed using a notation which can be graphically presented as a network of classes containing their attributes and connected by their associations (an entity-relation diagram). The diagrams below shows the RIM networks for roles and clinical acts.

Modelling and supporting clinical workflow

Efforts to develop formal and computer-based tools for modeling processes long predate the appearance of medical informatics. Critical path analysis, for example, was developed in the 1950s for scheduling a set of activities in any process with interdependent tasks (e.g. construction, software development, research project management, product development, engineering, and plant maintenance). The essential technique is to develop a model of all the activities required to complete the project, the time that each activity will take to completion, and the dependencies between the activities. Gantt charts are designed for modelling schedules in terms of the start/finish dates of the component tasks of a project aligned on a timeline, and showing the status of planned and active tasks. Some Gantt charts also show dependencies between tasks (e.g. preconditions on initiating a task which depend on the completion of another activity or delivery of an output). PERT charts were developed for managing large military projects to simplify planning and scheduling. Unlike Gantt charts the PERT method accommodates some uncertainty by making it possible to schedule a task while not knowing precisely the details and durations of all the activities.

Left PERT chart for a seven-month project with five milestones, 10 through 50m and six activities, A through F Right Gantt chart for a simple project of 2 main tasks plus component activities [source Wikipedia].

These early methods for modelling processes have limitations from the point of view of clinical process management. They were not developed for actively executing or supporting the management of a process in real time. Neither are they oriented towards dynamic modifications of plans in the light of changing situations or unexpected events, as must happen in clinical medicine. They were also designed primarily for

managing one-off projects, not for supporting routine processes like clinical diagnosis and treatment, and are typically used for analysing dependencies in a process and detect overruns or other problems.

Business process modeling

Business process modelling, and associated IT systems for enacting models and supporting business processes in real-time are increasingly used in commercial applications. The figure below illustrates the relationship between a business process and two key concepts: the idea of a process definition language that formally describes the process model, and a workflow management system, the technology platform which supports the management of that process by scheduling activities, managing data, and ensuring effective communication between interrelated or dependent activities and synchronization of related activities. Execution of a particular instance of a business process, such as the management of an order for a product or service, is initiated and controlled by the workflow management system under the control of the process definition for that kind of order.

Source http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf

A number of workflow languages have been developed and proposals for standards are now emerging. They have been developed primarily with the business community in mind for modelling and supporting business organisations and processes rather than medical organisations and processes, though adaptation for use clinical settings is now being actively pursued. The figure below shows a number of workflows that typically occur in the detection and diagnosis of possible breast cancer. Business process

modelling languages are intended to allow designers to formalise a process definition such as a workflow, in which the notation shows visually who does what, where and in what order activities are carried out. The example is presented in one business process notation, BPMN, in which a woman with suspected breast cancer is referred to a specialist breast clinic by a general practitioner (GP). The GP and the clinic are collaborating businesses in BPMN terminology. The clinic also collaborates with laboratories for specialist services that provide specialist investigations such as imaging (mammography) and fine needle aspiration biopsy (FNA).

The BPMN notation can be translated into a standard XML-based interchange format (XPDL) and an executable process definition such as the Business Process Execution Language (BPEL) developed by the Workflow Management Coalition. BPMN draws on familiar conventions such as those used in flow diagrams (though the term is avoided in BPM circles) but it also visualises trigger events, organisations and messages which do not normally appear in flow diagrams, as well as the structure of a business process at internal and external levels. BPMN supports four main kinds of construct: flow objects; connecting objects; swim-lanes and artifacts. Flow objects An activity is any kind of work that the business performs. An activity can be atomic (a task) or non-atomic (a sub-process). Gateways are used to control branching and merging of flows and can be the points at which decisions are taken. An event is anything that can happen during the course of a business process which is not under the control of that process. Events usually have a cause (trigger) and/or an effect (result) and can affect the flow of the process.

In the above example the start event for the clinical process is that a patient attends a GP clinic, shown as a circle on the boundary of the GP Community box; rounded rectangles are internal activities of collaborating organisations, and the diamond is a gateway following completion of diagnosis, when the patient is given a positive diagnosis or the all clear. Connecting objects Flow objects are connected together to model the activity sequences in a business process. Three Connecting Objects are supported in BPMN:

Sequence Flow defines the order in which activities are to be performed. Message Flow is concerned with the flow of information between collaborating businesses or individuals. Associations are typically used to represent the inputs and outputs of activities in a process.

The black-headed arrows in the figure represent sequence flow (the activity at the tail of the arrow must be completed before the activity at the head of the arrow can be started). The dotted arrows with white heads are messages and flows of information to and from the specialist laboratories and between the GP and the clinic. Swim-lanes Many process modelling tools use swim-lanes to show independent actors e.g. businesses or services. BPMN supports two main constructs: pools and lanes. Pools are used to represent separate business entities and are physically separated in a business process diagram. In Figure 4 there are three pools, one representing the GP, one the breast clinic and the third the specialist labs. The activities within pools are considered to be self-contained processes so that sequence flow may not cross the boundary of a pool. Message flow is used to model the communication between participants so it must connect between two pools (or the objects within the pools). Lanes are sub-partitions within a pool and are used to organize and categorize activities. In figure 4 there are two lanes within the laboratories pool, one representing a mammography process and the other a cytology service. Lanes are often used to separate the activities associated with a specific company function or role. Artifacts Various application-specific artifacts can be added to a model including data objects, documentation and annotations. Many concepts that are important in clinical medicine, such as patient records, decision processes, treatment plans, would be regarded as artifacts in business process modeling and are not part of the formal process model.

Task Network Languages

During the last decade in which workflow languages have been achieving prominence the medical informatics community has also been developing ways of modelling clinical processes such as clinical guidelines and care plans. Although they share concerns with the workflow community the health informatics community has taken a distinctive approach because some important activities in clinical practice are viewed only as artifacts in business process modeling so they are not explicitly supported within this framework. This divergence has been partly because of the original focus of clinical informatics on decision-making (e.g. how to interpret situations and events or the best choice of clinical investigation or the most effective and safest treatment. Furthermore the guidelines community has been concerned process definitions formalise processes in a way that reflects clinical tasks and constraints as clinicians perceive these. Task Network Languages have emerged as a way of achieving these objectives. The motivation for developing task network languages for CIGs is summarised by Peleg et al (2003) as: A key component of guidelinebased decision-support tools is a machine interpretable guideline model that unfolds over time. To model such guidelines, many groups have adopted an approach involving hierarchical decomposition of a guideline plan into a network of component tasks. The plan components provide design primitives that are custom-tailored to clinical guidelines. Relationships among plan components, such as ordering constraints, can be described, and tools for the visual representation of plans and the organization of tasks within them are typically provided. TNLs differ in their emphases and in their approaches to addressing particular modeling challenges. A subset of them (ASBRU, GLIF3 and PROforma) have put a major emphasis on defining process definition languages which makes them more directly comparable with business process modelling and workflow languages. Peleg et al reviewed six task network modeling systems which had been developed to capture clinical guidelines and evidence-based practice in a computer-executable form (Asbru, EON, GLIF, GUIDE, PRODIGY, and PROforma, see www.openclinical.org) in order to compare similarities and differences and establish a consensus on a set of common components. A unifying feature of the task network schemes is that they represent clinical guidelines as plans. The plans components represent decisions, actions, or hierarchically decomposed sub-plans of the guideline and their inter-relationships. An example of a plan for diagnosis of women with possible breast cancer is shown as a PROforma task network in the figure below.

A task network language is typically organized around a standard ontology (lecture 2) of tasks. PROforma supports the definition of clinical processes, pathways and care plans in terms of plans, decisions, actions and enquiries. All tasks may have attributes representing the goal of the task, triggering events, pre-conditions which must be satisfied if the task is to be enacted, and post-conditions which will be true if the task is completed successfully. All tasks have distinguishing attributes as well. Plans (rounded rectangle in the above figure) have a characteristic structure in terms of nested components (tasks and sub-plans) and have special trigger conditions which define when they should be terminated or aborted. consist of sets of tasks to be carried out for some purpose. In task network languages plans are viewed as the building blocks of the process model, and may contain any number of tasks. Plans may impose a sequential ordering on their component tasks or may permit them to be executed concurrently. Decisions (circles) are tasks which involve choices of some kind, such as a choice between alternative investigations, diagnoses or treatments. The PROforma specification of a decision task defines the decision options, relevant information, a set of argument rules which evaluate the pros and cons of each option in a particular setting, an aggregation function which weighs the argument in order to establish a preferred ordering on the options, and a commitment rules which determines which of the options should be selected and when. Actions are procedures (such as the administration of an injection) which need to be carried out externally to the PROforma process, typically by a clinician. Enquiries (diamonds) are actions returning required information from the user, electronic health record, devices or other external data sources.

Petri nets
Petri nets provide a formal representation of a process as a directed graph with annotations, which can be interpreted dynamically to simulate or enact that process. Petri nets can be used for describing systems that may be concurrent, asynchronous, distributed, parallel, nondeterministic and/or stochastic. Petri nets are a very general model which can capture Gantt and PERT charts as well as finite state machines, dataflow networks and in theory any process that can be represented as a graph. They are increasingly used to formalize business process modeling languages and some researchers are looking at them for medical task network modeling (Mulyar et al, 2007). There are two kinds of nodes in a Petri net: places and transitions. Places represent conditions and transitions represent events. A transition node has a certain number of input and output places representing the preconditions and post-conditions of the event. Petri net model P is a finite set of places T is a finite set of transitions (P T = ) F (P X T) (T X P) is a flow relation Common extensions to basic PN model Time (to model durations and delays) Colour (e.g. resources, goods, humans which participate in the process) Hierarchy (subnets)

The basic abstraction (input places - transitions - output places) subsumes many different forms, including (input data computation output data); (resources needed task or job resources released); (preconditions event post-conditions) and other concrete interpretations of a graph.

References
Mulyar N, van der Aalst W, Peleg M "A Pattern-based Analysis of Clinical ComputerInterpretable Guideline Modeling Languages" Journal of the American Medical Informatics Association 2007;14(6):781-787

Peleg M, Tu S, Bury J, Ciccarese P, Fox J, Greenes RA, Hall R, Johnson PD, Jones N, Kumar A, Miksch S, Quaglini S, Seyfang A, Shortliffe EH, Stefanelli M. Comparing computer-interpretable guideline models: a case-study approach Journal of the American Medical Informatics Association. 2003 Jan-Feb; 10(1):52-68.