Time Integrity: Can You Prove That 14:37 Means 14:37?

What Does 11:47 Actually Prove?

In the previous Article, we examined Audit Trails and asked a deceptively simple question: “What does the System actually prove?” 

Now let us take one apparently unremarkable piece of information contained within a Digital Record and ask the same question of it. 

The time. 

Imagine that a hospital is required to establish that Instrument Set A1746 completed a compliant decontamination cycle on 16 March 2023. 

The Track & Trace Record says: “Instrument Set A1746 — Decontamination Cycle Complete — 14:37 — PASS.” 

There is something reassuringly precise about 14:37 isn’t there? It does not say that the cycle finished sometime during the afternoon. It gives us an hour and a minute. That apparent precision gives the Record authority. 

But now let us replace the Instrument with a Patient. 

NHS England’s specification for Automatic Identification and Data Capture recognises that Radio-Frequency Identification (RFID) may be used to track people, including Patients and caregivers, moving through healthcare facilities. 

NHS Trusts including East London, Medway and Barnsley have used digitally enabled Patient wristbands for identification, location or care-coordination purposes. 

Suppose years later (and you’ll recall it always takes serious Personal Injury Cases a long time to get into Court), a Court is examining the treatment of a Patient whose condition was deteriorating seriously while she was awaiting an operation. 

The Digital Record says: “Patient left Ward A — 11:47.“

But what actually happened at 11:47?  

Did the Patient physically leave the Ward? Was an electronic wristband detected? Did a member of staff change her status? Was a wristband deposited in a dropbox? Or did another System merely receive Data generated by an earlier Event? 

Suppose other Evidence suggests that the Patient actually left at 11:32 and then spent fifteen minutes waiting elsewhere while her condition deteriorated. Perhaps that fifteen-minute delay was pivotal in the case of a seriously deteriorating condition. 

Suddenly the difference between 11:32 and 11:47 matters very much indeed. 

The question is no longer whether the computer contains the Data “11:47”. Plainly it does. The question is whether the organisation can prove what happened to the Patient at 11:47. 

And behind that question lies another: 

Which clock produced 11:47? On which Clock’s “Evidence” is the Court to rely upon? 

In addition, when we speak of a computer’s “clock”, we should not imagine one master clock hanging somewhere in the Hospital to which every Digital Record automatically refers. 

There may be many clocks. 

A medical device may maintain its own internal clock. A workstation or tablet may have another. A Patient-tracking device or local controller may generate a time of its own. An application server may add a Timestamp when it receives or processes the Data, while a database server may add another when the Record is written to the Database. 

CCTV equipment may have its own clock again.  

Some of those clocks may be synchronised automatically to a common network time source; others may depend upon their own configuration, hardware or administrative settings. 

Data can therefore travel through several pieces of equipment, each capable of associating its own time with the Same Underlying Event. 

So when a Digital Record says “11:47”, the first technical question raised in Court may be surprisingly basic: from where, physically and electronically, did that 11:47 come? 

In other words, several clocks may exist within the same Digital environment and, unless Time Integrity has been properly maintained, they need not all agree about what time it is. 

So was the Clock that ‘thought’ it was 11:47 correct? Or was another Clock involved in capturing the Data?  

Was it accurate? Was it synchronised? Could it be altered? (our old friend “immutability”) What Event caused the Timestamp to be generated? And can anybody demonstrate, perhaps several years later, that the time recorded by the System reliably corresponds with the Event which the Record is now being used to prove? 

That is the problem of Time Integrity.  

A Timestamp is not a witness to Time. It is Data upon which the Court is invited to rely to distinguish professional negligence from an ‘unhappy event’. 

And, like every other piece of Data upon which an evidential proposition depends, its reliability may one day have to be proved.

What Event Does the Time Actually Record?

Consider Barnsley Hospital NHS Foundation Trust. Its digital wristband is linked to the Hospital System and can assist porters in locating a Patient for an appointment, investigation or transfer. When the Patient leaves Hospital, removal of the wristband and its placement in a dropbox can automatically discharge the Patient from the System. 

Now consider the evidential implications. 

Suppose the Digital Record subsequently “says”: “Patient discharged — 11:47.”

What happened at 11:47? 

Did the Patient leave the Ward? Did she leave the Hospital? Was the wristband removed? Was it placed in the dropbox? Or was 11:47 simply the moment at which an Event generated somewhere within that process was recorded by the Hospital System? 

Those are not necessarily the same Event. 

Return to Instrument Set A1746. Does 14:37 mean the physical decontamination cycle finished then? That the equipment generated the Event then? That another System received it then? Or that the Record was written to a Database then? 

Those moments may be separated by seconds or minutes. In some Systems, perhaps longer. 

The Digital Record need not be false. The Timestamp need not be inaccurate. The computer may have recorded 11:47 perfectly. 

The evidential problem is that 11:47 may accurately record the Wrong Event for the proposition which somebody is subsequently trying to prove. 

Before asking whether a Timestamp is accurate, let us ask what Event it actually timestamps.

Record Time is not necessarily Event Time

There is a further problem. 

Suppose every clock is correct. The Ward System, Patient-tracking System, Electronic Health Record and Theatre System are perfectly synchronised. 

Have we proved when the Event occurred? 

Not necessarily. 

At 11:47:03 the Patient physically leaves Ward A. At 11:47:05 her wristband is detected. At 11:47:08 the Patient-tracking System processes that Event. At 11:47:11 another Hospital System receives the information. At 11:47:14 a Record is written to a Database. 

Every clock is right. Every Timestamp is right. 

But there are now five different times associated with what somebody may subsequently describe simply as: “Patient left Ward — 11:47.” 

Which one is the Event Time? 

The distinction becomes still clearer where human intervention is involved. 

Let us suppose medication is administered at 10:15 but entered into the Electronic Health Record at 10:23.  

The NHS Data Model and Dictionary itself distinguishes a “MEDICATION ADMINISTRATION RECORDED TIMESTAMP”: the time at which administration was recorded in the Electronic Health Record. 

10:23 may therefore be an entirely accurate Record Time. 

It is not necessarily the Event Time. 

A System designed to record when Data was entered, received or processed may later be asked to prove when the underlying physical or Clinical Event occurred. Those propositions must not simply be assumed to be the same. 

Because a perfectly accurate clock can produce a perfectly accurate Timestamp for an Event which is not the Event now in dispute. 

When the Clock Changes the Evidence

So far, our examples have been hypothetical. So let us now leave the hypothetical world behind. 

Wrong times have appeared in real Digital Evidence. Investigators have discovered that apparently precise Digital Records did not correspond with real time. Courts have had to decide whether incorrect computer clocks actually mattered. 

Consider the important case of  R v Slade, Pearman and Baxter [2015] EWCA Crim 71. 

The case concerned convictions for conspiracy to murder.  

An important part of the prosecution case depended upon chronology: CCTV, mobile telephone and cell-site Evidence were used to establish where particular people and vehicles were at particular times. 

Following conviction and on Appeal, further analysis revealed that a relevant CCTV clock was 22 minutes slow! 

That mattered because the CCTV was being considered alongside mobile telephone and cell-site Evidence.  

Once the timing was corrected and the different sources examined together, the apparent chronology changed. The Court of Appeal considered the corrected timing with other important fresh Evidence and concluded that the convictions were unsafe. They were quashed. 

Let’s be clear – this was no academic dispute about the accuracy of a computer clock. Men had been convicted of conspiracy to murder, and the chronology upon which those convictions rested was now being re-examined in a manner the Lower Court did not. 

But we must be precise about what Slade proves.  

The defective CCTV clock did not, by itself, overturn the convictions. But the case demonstrates the danger:  if a Timestamp is used to place somebody at a particular location at a particular moment, an incorrect time may distort the chronology upon which the evidential case depends. 

Nor is the problem confined to the Courtroom. 

In an investigation into a death at HMP Wandsworth, the Prisons and Probation Ombudsman found that CCTV used to reconstruct Events was not showing real time. Interruptions to the electricity supply had caused the CCTV clock to stop and lose time. 

The investigator established the discrepancy by looking outside the CCTV System and comparing it with the independently recorded time of the emergency call to the ambulance service. The CCTV clock was approximately eight minutes slow. 

More troublingly, the investigator recorded that it was not possible to verify the CCTV timings against real time on other occasions. 

The CCTV System could tell the investigator what time its own clock said it was. It required Evidence from another System to establish that the time was wrong. 

But a wrong clock does not automatically make Digital Evidence unreliable. 

That distinction reached the House of Lords (now called the Supreme Court) in DPP v McKeown; DPP v Jones [1997] 1 WLR 295; [1997] 1 All ER 737. 

The cases concerned Intoximeter breath-testing machines whose internal clocks were incorrect. The error did not invalidate the Evidence because it had not affected the machines’ measurement of alcohol concentration. The evidential proposition was the alcohol reading; the defective clock did not render that measurement unreliable. 

The question is therefore more precise: What is the Digital Record being used to prove? 

If the proposition is “This machine accurately measured this concentration of alcohol”, an erroneous clock may be irrelevant. 

But if the proposition is “This Patient left this Ward at 11:47”, or “This person was at this location at 22:14”, Time is part of the proposition which the Evidence is being used to prove. 

The question is not simply: “Was the clock wrong?” 

It is: “If the clock was wrong, what else have we got wrong?” 

Precision is not Time Integrity

Digital Systems are extraordinarily good at producing precise times. 

11:47:03 looks authoritative – doesn’t it? 

But precision is not Time Integrity. 

Before relying upon a Timestamp as Evidence, we may need to know what Event generated it, which clock produced it, whether that clock was accurate and synchronised, whether it could be altered, and whether those matters can still be proved years later. 

Sometimes an incorrect clock will make no difference at all. 

But sometimes a few minutes may change the chronology upon which an entire evidential proposition depends. 

The question is therefore not simply: “What time does the Record say?” 

It is: “What Event does that time represent, and can you prove that the time is right?” 

It is all well and good that a computer system can record 14:37 with absolute precision. 

But that does not, by itself, prove that the Event in question actually happened at 14:37. 

And as was made out above – that can make the difference between imprisonment or freedom. Or the difference between Professional Negligence and an unfortunate event which was no one’s fault.

Missed the earlier parts of the series?

Read the first four articles by Dr. Brian Bandey:

When Compliance Data Enters the Courtroom – and Fails

Why Most Compliance Systems Cannot Prove Data Integrity in Court

The Forgotten Purpose of Evidential Friction

Track & Trace Systems – Good at Recording, Not Necessarily Good at Proving?

Disclaimer. The views and opinions expressed in this article are solely those of the author and do not necessarily reflect the official policy or position of Test Labs Limited. The content provided is for informational purposes only and is not intended to constitute legal or professional advice. Test Labs assumes no responsibility for any errors or omissions in the content of this article, nor for any actions taken in reliance thereon.