Dear Georgina Nolan,

INQUEST INTO THE DEATH OF MR SHIYA COLLINS

RegulaƟon 28. Report to prevent future deaths.

I am wriƟng to you as Technical Director of Cleric Computer Services Ltd and in response to the RegulaƟon 28 report for the prevenƟon of future deaths dated 31st October 2023 as issued by you following the inquest into the tragic death of Mr. Shiya Collins. The Coroner’s Concerns raised the following MATTERS OF CONCERN “(1) Seven calls were made to the North East Ambulance Service (following the iniƟal call) indicaƟng that Shiya Collins’ condiƟon was deterioraƟng. Call handlers recognized the need for clinical input in order to facilitate a possible upgrade of the ambulance response to category 1. However, the locking facility on the Cleric computer system used in the control room precluded any clinician from accessing/upgrading the call because the system was locked and unable to be accessed whilst live calls relaƟng to the case were ongoing.”

MY RESPONSE I address the point you have raised below: - Your concern relates to the Record Locking funcƟon with the Cleric computer system used by the North East Ambulance Service NHS FoundaƟon Trust (NEAS). I am extremely disappointed with the findings of the inquest and the subsequent regulaƟon 28 report directed towards Cleric. It appears that full explanaƟon of the system’s behavior along with the faciliƟes built in to miƟgate the situaƟon outlined in the RegulaƟon 28 report have either not been fully disclosed, or they have not been set out clearly and in a comprehensible way. Record locking is a fundamental part of a mulƟuser system; the funcƟon serves to protect the integrity and consistency of data, without record locking there would be the risk of mulƟple users overwriƟng each other’s input. To overcome the effect of record locking the Cleric system has robust built-in miƟgaƟons, in the system operated by the North East Ambulance Service NHS FoundaƟon Trust the system had (at all material Ɵmes) the following faciliƟes in place:

All informaƟon relaƟng to a call is visible/accessible even when a record (call) is locked. It is indicated as being in a ‘read only state’. Any user viewing a record (call) in a locked state would automaƟcally have an up-to-date view of the call as the record is refreshed when data is added/removed/updated. CriƟcal informaƟon relaƟng to the dispatch of an ambulance response can be updated while a record (call) is locked. This informaƟon is clearly presented to the dispatch team. This informaƟon may relate to and highlight the urgency/criƟcality of a response. The priority of the call can be upgraded while the record (call) is locked. This is restricted by role-based access and would normally be undertaken by a clinician. This updated informaƟon is clearly presented to the dispatch team. CriƟcal informaƟon relaƟng to the call can be entered and automaƟcally sent to the responding crew(s) while the record (call) is locked. AddiƟonal notes can be entered while a record (call) is locked. There is a mechanism available to create a note on the record (call) and send an alert to the user(s) responsible for that call (dispatch team etc), this is available while the record (call) is locked. A user who is ‘locked out’ and in the ‘read only’ view can request the ‘locking’ user to unlock the call via a system mail funcƟon in order that they can take control of the record (call). Record (call) locks can be forcibly removed by users of the system who have the appropriate role-based access. This would then allow another user to ‘take control’ of the record (call) in an unlocked state. The clinician could have created a new record (call) in isolaƟon to the original locked record (call) and triaged it appropriately.

The lock feature is important to protect the integrity of the call and to stop data conflicts, the record (call) is only locked to an operator while they are acƟve in the call. While it is technically correct that a clinician is not able to re-triage a call whilst it is in a locked state, I hope that the informaƟon I have provided adequately addresses the concern that ‘the computer system precluded any clinician from accessing/upgrading the call because the system was locked” Within the capabiliƟes and provision of the Cleric system there are several means through which the ‘locking’ issue was able to have been overcome.(described above). I am concerned that the extent of the system miƟgaƟons in relaƟon to the locking process were not fully conveyed during the hearing of the inquest.

‘Cleric’ systems handle millions of calls safely and effecƟvely annually across the UK. We are constantly working in partnership with our customers (Ambulance Trusts) to ensure that the system evolves to meet the ever-changing demands placed on those customers.

PROPOSED ACTION We have consulted with our customers (Ambulance Trusts) to explore potenƟal improvements and we have agreed that minor changes will be implemented within the system:

A record will open to a user in a ‘read only’ state. The user will then be required to request a lock on the record rather than the lock being applied automaƟcally. The mechanism to request a release of a lock from one user to another user will be streamlined. It is important to note that the above changes will not eliminate locks as they remain a fundamental mechanism within these types of system, they are minor amendments to streamline exisƟng funcƟonality. System users also have robust operaƟonal processes/procedures in place to handle such circumstances. This is a truly tragic case, and our thoughts are with Mr Collins’ family & friends. I hope that this addresses the maters of concern which you have highlighted. If we can be of further assistance to you then please do not hesitate to contact me.