Case Study and Worked Example

• Members fail to sufficiently discuss how to overcome bureaucratic blocks and other forms of institutional inertia.

This knowledge can be applied to the method in which we govern tool support, specifically, how we utilise technology in our decision making process. We need to support and adopt technologies that combat Groupthink and actively aid the group decision making process [39], [76].

Other examples of BPMN extension include Herbert & Sharpe [114], where the formalism was applied to multiple decision criteria such as cost and technical quality. Their work developed a limited formalised variant of BPMN that extended support towards simple probabilistic branching and rewards. Planning Support Systems (PSS) have also witnessed a similar approach in Campagna et al [49] where the authors claim that it is simple to adapt the BPMN formalism to aid with designing PSS. Bahrani et al [25] similarly adopt BPMN in their work focusing on short-term operational decision making in healthcare, reporting that the model aids the maker with more accurate and timely decisions.

7.3 Case Study and Worked Example

The following four activities provide real-life decision making scenarios that help to exem-plify the benefits of our notation changes. The principle example in this work is the treatment of thrombolytic stroke patients as this process involves high-risk, multi-person decision making which highlights effectively the applicability of our contributions.

Three other smaller-scale examples are also documented utilising some of the proposed notations.

Thrombolytic Stroke Treatment

In a clinical environment, shared decision making is increasingly considered good practice. In this context we define shared decision making as the interaction between medical practitioner and patient (the sharing of medical information and even particular faiths, beliefs or practices related to treatment). In essence, the medical staff will provide the medical knowledge for the process, and the patient will give their preferences. This new approach to care replaces the traditional more paternalistic role of the clinician and patient where many of the decisions were solely conducted without the patient’s input [88].

The following scenario is taken verbatim from Nesbitt & Turland [69]:

‘John (67 years old) was admitted to hospital with a suspected stroke. His wife, Sheila attended with him. During the initial assessment phase, the A+E consultant asked Sheila the

approximate time at which John began to exhibit the signs of a stroke. John was asked if had taken either Clopodogrel or Aspirin recently and if he was receiving any hypertensive treatment. Following these questions, the consultant looks at the patient’s medical records for indications of a previous cerebravascular event or a history of diabetes. At this stage, the consultant can ascertain whether the patient is a candidate for thrombolysis. In the meantime, an A+E nurse has recorded John’s systolic blood pressure, his blood glucose value, approximate weight and has performed a National Institutes of Health Stroke Scale (NIHSS) assessment on him. Finally, John has a CT scan to look for evidence of infarctions in his brain. At this point, John’s indicators meet the licensing criteria for thrombolysis. Since his stroke is moderate, the treatment has the greatest net benefit compared to non-treatment.

With this in mind, the consultant asks Sheila for consent for treatment, explaining what her husband has and discussing thrombolytic treatment. The consultant states that out of 100 patients like John, approximately 33 extra patients would make a successful recovery with thrombolysis than without it. However, there is a small risk of a brain haemorrhage that could result in death or serious injury. After some discussion, Sheila asks what the consultant would recommend; the consultant recommends treatment. Sheila signs the consent form and the drug is administered’.

With this scenario the BPMN formalism can aid considerably in modelling the problem space and mapping the decision points. For example, whether or not to proceed with further decision making if the patient does not fit within the licensing criteria. With any tool, however, design is critical (see HCI in chapter 2.4, 4).

Security Policy

Security policies are often governed by fixed budgeting and resource allocation. Relating specifically to a university environment and the transferral of data (see chapter 3), our notations enable a better understanding of these finite variables through graphical and programmatical representation. The impact of this is to suggest new tools and technologies that may or may not be available at a given instance related to a particular resource (for example, with cost - less expensive options are available once a certain budget constraint is exceeded, with time - more efficient processes are highlighted for optimisation purposes).

Security Policy - with Tools

The use of tools in this scenario would allow for automatic allocation of node traversal based on set criteria and bounds within the model.

7.3 Case Study and Worked Example 159

Cardiovascular Disease Risk Reduction

‘A GP is using their practice’s EMIS (Egton Medical Information Systems) computer system (a database that stores a practice’s patient records) to check patient records. In this scenario, EMIS will flag patients who are at high risk of cardiovascular disease (such as stroke or heart attack). The GP will invite each patient flagged at risk for a discussion on reducing their risk.

This is achieved using a tool called CVdecide that displays risk presentations in the form of a Pictograph, showing risk of disease based on such factors as the patient’s weight and smoking status. Based on these factors, both GP and Patient will discuss a plan for reducing the patient’s cardiovascular risk’ [69].

With the above scenario, a consent point could be added to the BPMN model indicating the goals that have been agreed by both parties.

The following table (7.1) summaries these scenarios and relates specifically to the application of the new notations detailing their salient features.

Feature CVD MBA Security Stroke Comparable BPMN construct

Cost^† * none

Time * * * Time start event only

Multi-person * * * * Swimlanes

Confidentiality * * * none

High risk * * none

Information capture * * * * Data object

Private * * * * none

Defined goals * * * * none

Output information * * * * Data object

Share documents * * none

Workflow data * * * * none

Scope data * * * * none

†In the context of the scenarios, cost is defined as a scalar values that is given to a financial, effort or other quantifiable variable.

Table 7.1 Summary of salient decision making activities in each of the examples [69]

The table documents important similarities between the applications, notably that all scenarios generate their own data (risk presentation, policy document etc.) and can defined on an aggregate level by the existing data object constructs. In addition, the actors from each scenario conform to the swim-lane constructs already defined within the BPMN specification along with information flows denoted by arrows.

Workflow data is defined as ‘data that is accessible to the entire group’ [69]. Scope data can be considered as ‘any kind of data that is private to an individual or a subset of individuals’ [69]. The existing BPMN formalism includes document elements that can be adapted to encapsulate these details.

The remaining contributions have no similar definitions within the existing BPMN formalism. The next section details their features and implementation.