Princess of Wales Hospital blood glucometer case REED
Version v3

Harold Thimbleby

26 January 2025

Example automatically-generated evidence narrative file revisiting the 2014 Princess of Wales Hospital blood glucometer case. For an overview of the background to the case, with a full description of the meaning of the diagram and further details of its associated narrative, go to the REED site home page.


REED v3 diagram.

Quick overview — combined versions: v2; v3

REED fileDigital signature
lib/pow-reed6bebf5fe791f276b0dbd8b5728d151a8

If a REED file has been changed since this report was made, then its digital signature will now be different. You can run the REED tool with flag ‘-s’ on any file to confirm its signature.

24nodes—24with notes(19 highlighted)
25arrows—7with notes

There are 2 weakly connected components (i.e., there are 2 independent REED diagrams not connected to each other with any arrows, regardless of the directions of the arrows).

19 highlighted nodes

⚑blue used 10 timesVersion 3 uses blue to highlight the impact of critical new evidence introduced by the Abbott engineer. Only one node was explicitly highlighted blue, but the REED tool is used to automatically cascade the blue highlight to all affected evidence.
⚑red used 2 timesSpecific, relevant computer problems as already admitted in evidence. Use of non-forensic tools like Excel (which, for instance, allows rows of data to be deleted without leaving any record of changing the data) used to process the evidence. In short, any evidence highlighted in red is unreliable.
⚐white used 4 timesNo information available (yet). This may or may not be considered a problem after relevant evidence is provided.
⚑yellow used 3 timesProblems that have not yet been resolved. Concerns need to be addressed in cross-examination.

⚑v3-0.0, “Unsupervised Abbott engineer”— Cascaded node
⚑v2-4.2, “Abbott PrecisionWeb database”
⚑v2-4.3, “Ward PCs”— was ⚐ before cascade
⚑v2-5.1, “Police forensic database system”— was ⚑ before cascade
⚑v2-5.2, “No known backups that could have provided evidence”— was ⚐ before cascade
⚑v2-5.3, “Frequent crashes documented”— was ⚑ before cascade
⚑v2-5.4, “Lots of unknown complex middleware”— was ⚑ before cascade
⚑v2-6.1, “Main Police evidence”— was ⚑ before cascade
⚑v2-6.2, “Main hospital databases”— was ⚑ before cascade
⚑v2-8.1, “Nurse-written paper records (never disclosed)”— was ⚐ before cascade
⚑v2-1.1, “Wrong XceedPros seized by Police”
⚑v2-3.1, “Police summary of wrong XceedPro evidence”
⚐v2-1.3, “Patients”
⚐v2-1.4, “Hospital computer operators”
⚐v2-2.2, “XceedPros on Ward 2”
⚐v2-3.3, “XceedPro dock on ward”
⚑v2-3.4, “No evidence of any testing ever performed”
⚑v2-4.4, “No evidence of error logs or audits”
⚑v2-4.5, “No evidence to support reliability of forensic methods”

Node narrative evidence for component 1

⚑ Node v3-3.0 Unsupervised Abbott engineer

 Nick Reece, a PrecisionWeb support Specialist employed by Abbott Diabetes Care, had been asked by the hospital to help when the Princess of Wales PrecisionWeb database faced problems in 2013. Mr. Reece then worked unsupervised on the PrecisionWeb database, apparently taking no notes and certainly not following any forensic process.

Reece gave evidence that he had failed to take notes on exactly what he did when editing, deleting, and modifying data in the PrecisionWeb database. He admitted he had deleted critical data, which would have created the impression that nurses had been negligent not performing blood glucose tests.

This deletion of computer evidence explains the discrereed pancy in patient records that the prosecution claims had been wholly and entirely caused by the nurses’ criminal negligence.

   
→ ⚑ v2-4.2, “Abbott PrecisionWeb database”

Node v2-1.2 Defendant nurses on Ward 2

 The defendants were named, and provided witness statements.
   
→ ⚑ v2-4.3, “Ward PCs”
→ ⚐ v2-2.2, “XceedPros on Ward 2”
→ ⚑ v2-8.1, “Nurse-written paper records (never disclosed)”

⚐ Node v2-1.3 Patients

 The patients on Ward 2 had limited capacity.
   
→ ⚐ v2-2.2, “XceedPros on Ward 2”

⚐ Node v2-1.4 Hospital computer operators

 We have no idea what the hospital computer system operators did, how they were managed, or what their security protocols (if any) were.

Note how (using Statechart conventions for diagrams) a single arrow from node v2-1.4, “Hospital computer operators”) to the group v2-7.1, “Hospital IT Systems” is sufficient to show that computer operators affect all nodes inside the box.

— Statecharts, invented by David Harel, are well-known diagrams widely used in computer science.
   
→ ⚑ v2-7.1, “Hospital IT Systems”
→ ⚑ v2-3.4, “No evidence of any testing ever performed”

⚐ Node v2-2.2 XceedPros on Ward 2 — (Group: Hospital IT Systems)

The nurse takes an XceedPro to a patient, and they must then tap the XceedPro with their ID card, then scan the patient’s ID card. Then the patient is pricked to obtain a small blood sample, which is inserted into the XceedPro. The XceedPro records the IDs, the date and time, and the blood glucose level. Nurses may share ID cards, or they may “double tap” and use their ID card twice instead of using the patient’s ID card.

See node v2-2.1, “Abbott labs”: Manufacturer evidence says XceedPros have numerous bugs; however none of the documented bugs lose patient data.

← ⚐ v2-1.3, “Patients”
←    v2-1.2, “Defendant nurses on Ward 2”
    
→ ⚐ v2-3.3, “XceedPro dock on ward”

Node v2-3.2 PrecisionWeb operators manual

 The operators manual for PrecisionWeb says it should not be used for clinical purposes. All the evidence for this case assumed the clinical records in PrecisionWeb were reliable.
   
→ ⚑ v2-4.2, “Abbott PrecisionWeb database”

⚐ Node v2-3.3 XceedPro dock on ward — (Group: Hospital IT Systems)

No evidence of the reliability of the XceedPro dock (for example, hospital test results, or manufacturer claims of reliability, or even daily checks of integrity) has been offered. Its reliable use depends on hospital network reliability, and no evidence of the reliability of the hospital network has been offered. The network may have had outages during the relevant period.
← ⚐ v2-2.2, “XceedPros on Ward 2”
    
→ ⚑ v2-4.2, “Abbott PrecisionWeb database”

⚑ Node v2-3.4 No evidence of any testing ever performed

 The hospital presented no evidence that it knew that any of its systems were reliable. However, the hospital did present evidence that PrecisionWeb regularly crashes (node v2-5.3, “Frequent crashes documented”).
←    v2-7.1, “Hospital IT Systems”
← ⚐ v2-1.4, “Hospital computer operators”
    
→ ⚑ v2-4.4, “No evidence of error logs or audits”

⚑ Node v2-4.2 Abbott PrecisionWeb database — (Group: Hospital IT Systems)

PrecisionWeb is a proprietary database designed to monitor XceedPros, such as their battery health.

PrecisionWeb manual warns that it is not designed for clinical use, but the Princess of Wales hospital used it clinically — the blood glucose readings (amongst other data) are copied, via middleware (node v2-5.4, “Lots of unknown complex middleware”) to the main hospital database. It is therefore not clear that PrecisionWeb is reliable enough to present patient data as evidence.

← ⚑ v3-0.0, “Unsupervised Abbott engineer”
←    v2-3.2, “PrecisionWeb operators manual”
← ⚐ v2-3.3, “XceedPro dock on ward”
    
→ ⚑ v2-5.2, “No known backups that could have provided evidence”
→ ⚑ v2-5.4, “Lots of unknown complex middleware”
→ ⚑ v2-5.1, “Police forensic database system”
→ ⚑ v2-5.3, “Frequent crashes documented”

⚑ Node v2-4.3 Ward PCs — (Group: Hospital IT Systems)

The ward has PCs where nurses can review patient information.

It is not clear whether nurses can edit data, for instance in case two patients were mixed up with the XceedPros (e.g., by putting the wrong test strip in or using one with a second patient) — and if so, whether edits must be done by the nurse (or person with the same ID) who originally took the readings.

We do not know who had access to the Ward PCs (whether nurses or hospital operators).

←    v2-1.2, “Defendant nurses on Ward 2”
    
→ ⚑ v2-5.4, “Lots of unknown complex middleware”

⚑ Node v2-4.4 No evidence of error logs or audits

 It is astonishing there is no evidence that the hospital ever checked whether their computer systems were functioning normally.

It is also astonishing the Police recorded data from hospital systems without confirming the reliability of the data, and did so without hospital supervision.

← ⚑ v2-3.4, “No evidence of any testing ever performed”

⚑ Node v2-4.5 No evidence to support reliability of forensic methods

 The Police visited the hospital and exported CSV data from the hospital’s PrecisionWeb database to an unencrypted USB stick, a process that is insecure.

Although there were opportunities for the Police to collect incorrect or incomplete evidence, or to corrupt the evidence that they had collected, there is no nothing to suggest that the Police checked their final computer evidence against the original hospital sources. The police process took no precautions to detect or mitigate the effect of possible cyberattack (or other database problems, such as hardware faults, system crashes — which were known to occur — or operator error), such as comparing their collected data with backups.

Although the Police used Excel to manage the evidence (which can delete data, columns and rows, etc, without leaving any record of changes) there is no record to show that they checked their final evidence against the original data.

The final evidence was presented to the court on both encrypted CDs and USB sticks and was explicitly claimed to be forensic quality evidence.

   
→ ⚑ v2-5.1, “Police forensic database system”

⚑ Node v2-5.1 Police forensic database system

 The Police used PrecisionWeb unsupervised, exported data to CSV format.
— Hospital policy has since been revised.

The Police certainly examined the PrecisionWeb data in Excel, as their written evidence says their first attempts crashed Excel (presumably because of the size of the Excel spreadsheet). I do not understand why the Police did not use SQL (or any other decent database), as they could simply have copied the SQL PrecisionWeb database rather than relying on PrecisionWeb to convert it to CSV.

CSV is a very unsuitable data format to choose for evidence, as there is no way to detect edited, deleted, or inserted data.

Whatever CSV data they selected, they copied to a USB stick. This stick was then taken by car to a Police forensic environment, and copied to an encrypted secure disk drive. Subsequently, unencrypted CDs were burned from the files on the secure disc.

The Police evidence claimed their process was forensic — but it was only forensic after copying CSV data to the secure disk drive, and provided that no Police staff with password access modified the data.

← ⚑ v2-4.5, “No evidence to support reliability of forensic methods”
← ⚑ v2-4.2, “Abbott PrecisionWeb database”
    
→ ⚑ v2-6.1, “Main Police evidence”

⚑ Node v2-5.2 No known backups that could have provided evidence

 If backups had been taken (we do not know) then it would have been natural to check if the alleged missing nurse data had ever been stored on the main PrecisionWeb database.

Backups would have shown whether failures happened in PrecisionWeb, or earlier for instance over arrows A (as the prosecution argued), B, C or D.

← ⚑ v2-4.2, “Abbott PrecisionWeb database”
    
→ ⚑ v2-6.2, “Main hospital databases”

⚑ Node v2-5.3 Frequent crashes documented

 Evidence revealed in court was that the PrecisionWeb database (or the server it ran on) frequently crashed. The evidence said nothing about the impact of crashes on the integrity of the database; presumably at least the transactions pending when crashes happened would be lost.
← ⚑ v2-4.2, “Abbott PrecisionWeb database”

⚑ Node v2-5.4 Lots of unknown complex middleware — (Group: Hospital IT Systems)

PrecisionWeb (node v2-4.2, “Abbott PrecisionWeb database”) is not interoperable with other hospital systems, so middleware Conworx is used to interface PrecisionWeb to the main patient databases.

No evidence of the reliability of Conworx and other middleware (for example, hospital test results, or manufacturer claims of reliability) has been mentioned in evidence.

The hospital refused access to technicians, which meant we have no idea of or the extent of the middleware or how it is supposed to work.

Such complex multi-manufacturer systems will have bugs, so it is very surprising not to have error logs (etc) presented in routine statements.

← ⚑ v2-4.2, “Abbott PrecisionWeb database”
← ⚑ v2-4.3, “Ward PCs”
    
→ ⚑ v2-6.2, “Main hospital databases”

⚑ Node v2-6.1 Main Police evidence

 A joint prosecution/defence expert witness report (“Experts’ Joint Statement on Matters Agreed and/or Disagreed in regard to Part 35 12 (3) CPR”) lists many problems, including that the CDs CH/15 the Police provided to the prosecution and defence experts were different, raising serious questions of Police forensic process \cite{POW-resources}.

Refer to node v2-5.1, “Police forensic database system”.

← ⚑ v2-5.1, “Police forensic database system”

⚑ Node v2-6.2 Main hospital databases — (Group: Hospital IT Systems)

The hospital databases are managed by hospital technicians. None provided evidence statements, and none were called to give evidence.

Such complex systems will have bugs, so it is very surprising not to have error logs (etc) presented in routine statements.

It is curious that the discrepancies were originally discovered from the main hospital databases, not from PrecisionWeb. The Police never took evidence from the main hospital databases.

← ⚑ v2-5.2, “No known backups that could have provided evidence”
← ⚑ v2-5.4, “Lots of unknown complex middleware”
    
→ ⚑ v2-8.1, “Nurse-written paper records (never disclosed)”

Node v2-7.1 Hospital IT Systems

 We know nothing about the management of the hospital systems and any impact on the evidence. In a hospital (or any other critical environment) one would expect at least daily checks of reliable performance or error logs. The REED diagram shows there were no such checks.
← ⚐ v2-1.4, “Hospital computer operators”
    
→ ⚑ v2-3.4, “No evidence of any testing ever performed”

⚑ Node v2-8.1 Nurse-written paper records (never disclosed)

 Contemporaneously with treating patients, nurses should review the XceedPro they have used and copy its data to paper notes. The Police never provided the nurse-written records.

The XceedPro can record up to 2,500 patient records and then it will start overwriting records. As I never had access to the relevant XceedPros, I do not know whether this bug was relevant: had an XceedPro recorded about 2,500 records it could have given the impression the nurse had not performed tests the nurse had documented on paper notes.

← ⚑ v2-6.2, “Main hospital databases”
←    v2-1.2, “Defendant nurses on Ward 2”

Node narrative evidence for component 2

⚑ Node v2-1.1 Wrong XceedPros seized by Police — (Group: XceedPro evidence)

The PrecisionWeb data records XceedPro serial numbers, and shows that XceedPros routinely move around the hospital.

The PrecisionWeb data confirms that the Police seized all three XceedPros that happened to be on Ward 2 on the date when they visited it. However, the seizure did not include any XceedPros that had been used by the defendants.

Seizing the wrong XceedPros will give the false impression that the XceedPro data confirms the Prosecution’s contention that the nurses’s fabricated meter readings. The seized XceedPros were checked as reliable by Abbott (node v2-2.1, “Abbott labs”) — that is, Abbott unsurprisingly confirms their XceedPros work as they expect, not that they checked the right XceedPros.

The REED paper explains how the Police came to seize the wrong XceedPros.

   
→ ⚑ v2-2.1, “Abbott labs”
→ ⚑ v2-3.1, “Police summary of wrong XceedPro evidence”

Node v2-2.1 Abbott labs — (Group: XceedPro evidence)

The US company Abbott manufactured the XceedPros and the PrecisionWeb database, both critical components of this case.

The Police sent the wrong 3 XceedPros to Abbott to determine if they worked correctly. The Abbott labs found no relevant problems with the XceedPros, but they did confirm that all XceedPros had bugs.

However, none of the bugs Abbott described would affect or cause loss of data, unless the XceedPros had been used to try to record over 2,500 tests, which is considerably higher than any XceedPro at the Princess of Wales had ever recorded (at least as established by the Police’s PrecisionWeb evidence).

← ⚑ v2-1.1, “Wrong XceedPros seized by Police”
    
→ ⚑ v2-3.1, “Police summary of wrong XceedPro evidence”

⚑ Node v2-3.1 Police summary of wrong XceedPro evidence — (Group: XceedPro evidence)

Because of the problems noted under node v2-1.1, “Wrong XceedPros seized by Police”, this evidence was excluded.
←    v2-2.1, “Abbott labs”
← ⚑ v2-1.1, “Wrong XceedPros seized by Police”

Node v2-4.1 XceedPro evidence

 The Police examined the wrong XceedPros. The evidence presented on XceedPros is not relevant to the case.

Arrow narrative evidence

Arrow ?

v2-4.2, “Abbott PrecisionWeb database”
→v2-5.4, “Lots of unknown complex middleware”

Arrows marked “\textbf{?}” indicate evidence flows that we should know about, but no relevant information has been made available, despite requests. We think the evidence probably does not exist because (we surmise that) the IT operators probably did not do the appropriate work, such as testing (see v2-3.4, “No evidence of any testing ever performed”).

Arrow A

v2-1.2, “Defendant nurses on Ward 2”
→v2-2.2, “XceedPros on Ward 2”

A nurse uses an XceedPro to take a sample from a specific patient, and the XceedPro records the nurse’s and the patient’s IDs.

Arrow B

v2-1.3, “Patients”
→v2-2.2, “XceedPros on Ward 2”

A blood sample from a patient enters an XceedPro.

Arrow C

v2-2.2, “XceedPros on Ward 2”
→v2-3.3, “XceedPro dock on ward”

The XceedPros provide date, time, XceedPro ID, nurse ID, patient ID, blood glucose level, etc.

Arrow D

v2-3.3, “XceedPro dock on ward”
→v2-4.2, “Abbott PrecisionWeb database”

Should be identical to the XceedPro data from v2-2.2, “XceedPros on Ward 2” via arrow C plus a timestamp of upload.

Arrow E

v2-4.2, “Abbott PrecisionWeb database”
→v2-5.1, “Police forensic database system”

The Police exported a CSV file from the PrecisionWeb database of every record derived from all XceedPros in the hospital (see arrow D) over the relevant period of time. CSV is a non-forensic and very unreliable data format.

Arrow F

v2-5.1, “Police forensic database system”
→v2-6.1, “Main Police evidence”

Should be a collection of all data starting at v2-2.2, “XceedPros on Ward 2” (it wasn’t; see figure 7 in the REED paper for the reasons) but crucially the Police evidence was incomplete since it provided no way to check consistency with the data from v2-2.2, “XceedPros on Ward 2”.