5. 1 Current Investigation Approach
FEATURES
- maximising learning
- causal inference
- basically ‘patient centered’ (ie. the chronology of events)
PROS
- relatively ‘loose’ algorithm (ie. RCA) enables maximal use of relevant past professional experience
- relatively few suboptimal/not-quite-right notation constraints
(eg. the difficulties faced in the classification stage in incident reporting)
- relatively few predetermined bias for the investigation
- thus better enabling serendipitous discovery of useful findings
CONS
- highly variable investigative outcomes (eg. SUI data, the 2 reports used today)
- lack of a common perspective of the system to support learning ACROSS multiple incidents
- hard to be sure about the effectiveness of the particular causal tree used for analysis (ie. WYSIWYF)
- and as a consequence hard to be sure about the effectiveness of the recommended changes to the system
6. 2 Proposed Investigation Approach
FEATURES
- NOT INTENDED TO REPLACE existing approaches,
but to provide additional systematic support for a particular kind of investigation
- simple and readily extendable
- ongoing work.. comments and suggestion very welcome
INSPIRATIONS
- Distributed cognition (Hutchins)
- Forcing functions (Norman)
- Recent joint work with Paolo (NASA short paper)
7. 2 Proposed Investigation Approach - Scope
Intended to support reasoning about incidents that are clearly
due to some kind of information mismatch having occurred
Aims to provide much greater clarity about information trajectories
within a system and the system features affecting these trajectories
Discrepancies between model (ie. investigator beliefs about the system) and reality may be
leveraged to generate specific further potential relevant causes to
investigate (via the cause/system-feature correspondence)
8. 2 Proposed Investigation Approach - Our interpretation of a forcing function
‘Door’ example
1 door with handle 1 door without handle
door_pushed(x) P(x)
P(x)
¬ door_pushed(x)
0 0
x x
9. 2 Proposed Investigation Approach - Main concepts
human/non-human
elements
correctness and consistency
(abstracted into +ve and -ve for now)
‘system features’
10. 2 Proposed Investigation Approach - Benefits
- provides a detailed framework in which useful properties about the entire
socio-technical system may be systematically formulated and checked
- suggests in detail where missing relevant system elements and system
features may/ought to exist
- potentially allows rational and precise comparison and contrast
across incidents
- system models may be built up incrementally and
used even in a partial state
11. Vincristine Incident
( admin route information trajectories)
Syringe glass
marking
Pharmacy
technician
Syringe drug
colour
Pharmacy
database Dr Musuka
Unknown
Syringe Vincristine Prescription
packaging label syringe label chart
Nurse Vallance
Dr Mulhem
Dr Morton
THE PATIENT
EXAMPLES..
12. Fluorouracil Incident
( rate information trajectories)
Pharmacy
technician
CPOE
Another nurse
Pharmacy
information system
Prescriber
Handwritten
MAR
Pharmacy
label
Unknown
RN #2
RN #1
Infusion pump
THE PATIENT
EXAMPLES..
13. Vincristine Incident - the effects of a positive ‘system feature’
( admin route )
Pharmacy
technician
Pharmacy
SF1: Pharmacy database database Dr Musuka
‘intrathecal constraint’
Unknown
Syringe Vincristine Prescription
packaging label syringe label chart
Nurse Vallance
Dr Mulhem
Dr Morton
THE PATIENT
EXAMPLES..
14. Vincristine Incident - the effects of a negative ‘system feature’
( admin route )
Pharmacy
technician
SF2: Providing intravenous
Pharmacy
and intrathecal drugs together
database Dr Musuka
on demand
Unknown
Syringe Vincristine Prescription
packaging label syringe label chart
Nurse Vallance
Dr Mulhem
Dr Morton
THE PATIENT
EXAMPLES..
15. Fluorouracil Incident - more widespread effects..
( rate )
SF3: Variability of human Pharmacy
information interpretation technician
CPOE
Another nurse
Pharmacy
information system
Prescriber
Handwritten
MAR
Pharmacy
label
Unknown
RN #2
RN #1
Infusion pump
THE PATIENT
EXAMPLES..
16. Vincristine Incident - ‘unconstrained’ interactions (before AND after applying SF3)
( admin route )
Pharmacy
technician
Pharmacy
database Dr Musuka
Unknown
Syringe Vincristine Prescription
packaging label syringe label chart
Nurse Vallance
Dr Mulhem
Dr Morton
THE PATIENT
EXAMPLES..
- Showing whether utility for information-mismatching cases for Dcog.. (turn assumptions into open questions/explorations)
Not truly independent double check, thus RN #2 links to RN #1. We know that RN #1 was the sole programmer of the pump in this case.* the MAR and the Pharmacy-info-system may have multiple copies signify usage of the system-element at substantially different times (thus values may or may not have potentially have changed…) ..ensures that ‘identities’ are explicitly considered and acknowledged. (merged in this case)
Not forced to access at the same time..Should concentrate on just 1 example..DCog framework -> info. Trajs. -> how forcing functions can combine with this to give clear insight into ways in which the system may be further improved.
- In generally assuming 1 ‘feature’ for another scenario.
