Dear Coroner, Re: Regulation 28 Report to Prevent Future Deaths – William Richard Stockil who died on 6 September 2022

Thank you for your Report to Prevent Future Deaths (hereafter “Report”) dated 29 April 2024 concerning the death of William Richard Stockil on 6 September 2022. In advance of responding to the specific concerns raised in your Report, I would like to express my deep condolences to William’s family and loved ones. NHS England are keen to assure the family and the coroner that the concerns raised about William’s care have been listened to and reflected upon. 

I am grateful for the further time granted to response to your Report, and I apologise for any anguish this delay may have caused to William’s family or friends. I realise that responses to Coroner Reports can form part of the important process of family and friends coming to terms with what has happened to their loved ones and appreciate this will have been an incredibly difficult time for them.

Your Report raised concerns over the electronic prescription system (EPS) provided by Oracle Corporation UK Limited (formerly Cerner Limited), and raised that there was a risk that the set-up of the alerting system now used by the Royal Surrey NHS Foundation Trust (RSFT) (following the circumstances of William’s death) will not operate to draw attention to the need for a prescription review before the medication ceases if no prescribing clinician accesses a patient’s record.

Health IT System Suppliers, such as Oracle Corporation UK Limited, should ensure that their system defaults are configured accurately and appropriately to meet the needs of their users in most clinical situations. The circumstances of your report relate to the local configuration of clinical decision support / alert functionality within the EPS.

NHS England will be engaging with Oracle Corporation UK Limited on the issues raised. I note that you have also addressed your Report to Oracle Corporation UK Limited, and we have been sighted on their response to you dated 27 June 2024. We note that they state they have not found any defect or fault with their software, and that they are open to exploring with RSFT whether any configuration changes, alterations to working practices and additional training may assist to further mitigate any clinical risks. Any identified learnings could be facilitated through their dedicated User Groups and/or general guidance could also be provided on how to best design National Medical Director NHS England Wellington House 133-155 Waterloo Road London SE1 8UG

8 July 2024

and implement prescribing clinical decision support for clinical systems. NHS England will also ensure that the concerns raised in your Report are shared with systems by our Regulation 28 Working Group regional representatives.

The NHS Digital Medicines Programme commissions a system called the e- Prescribing Risk and Safety Evaluation (ePRaSE), which is a tool that supports NHS Trusts in configuring their Electronic Prescribing and Medicines Administration (ePMA) systems, to mitigate prescribing risks and improve safety. There could be scope to incorporate a test script to explore this issue in future iterations of ePRaSE, and this will be considered by the team.

NHS England has also engaged with the Royal Surrey NHS Foundation Trust on the concerns raised in your Report and note that there has also been escalation of the issues raised in your Report across regional and national digital teams. We would refer you to the Trust for further information on their system configurations and agreed processes.

I would also like to provide further assurances on the national NHS England work taking place around the Reports to Prevent Future Deaths. All reports received are discussed by the Regulation 28 Working Group, comprising Regional Medical Directors and other clinical and quality colleagues from across the regions. This ensures that key learnings and insights around events, such as the sad death of William, are shared across the NHS at both a national and regional level and helps us to pay close attention to any emerging trends that may require further review and action.

Thank you for bringing these important patient safety issues to my attention and please do not hesitate to contact me should you need any further information.

Dear Madam,

Re: Response to Regulation 28 Report to Prevent Future Deaths dated 29 April 2024

1. This is Oracle Corporation UK Limited’s (formerly Cerner Limited) (“Oracle Health”) response (the “Response”) to the Regulation 28 Report to Prevent Future Deaths originally dated 29 April 2024 and as amended on 18 June 2024 (the “Report”). The Report was issued by Area Coroner Mrs. Joanne Andrews (the “Area Coroner”) following an Inquest opened on 23 September 2022 into the death of the Deceased on 6 September 2022 (the “Inquest”). Oracle Health was not invited to participate in the Inquest or given an opportunity to make representations and was not aware of it until receiving the Report.

A. EXECUTIVE SUMMARY

2. Oracle Health deeply regrets and was saddened to learn of the various medical omissions at the Royal Surrey County Hospital (“Royal Surrey”) (albeit not causative or contributory to the Deceased’s death) and extends its condolences to the family of the Deceased and others bereaved. Oracle Health assures the Deceased’s family that Oracle Health takes the contents of the Report extremely seriously and that in response to it, Oracle Health conducted a thorough and in-depth review of the Millennium software deployed and in operation at Royal Surrey.

3. While there is no suggestion that the software at issue was in anyway at fault or contributed to the Deceased’s death, Oracle Health conducted a review as described more fully in this Response and concludes as follows (key findings are highlighted in bold throughout):

3.1. Oracle Health has not identified any evidence of any defect in its software. The Millennium software was working as designed and configured in conjunction with the Royal Surrey NHS Foundation Trust (“RSFT”) and another NHS Trust on the software domain, including subsequent modifications made independently of Oracle Health.1

3.2. Electronic alert notifications are most appropriately accessed within an individual’s electronic patient record (“EPR”) as opposed to, for example, at the point of a prescribing clinician logging into Millennium. Otherwise, there is a risk of clinicians being deluged with

1 A software domain is an administrative structure for organising, accessing and delivering software services and enables multiple customers to share the same computing resources. In the present instance, RSFT and another NHS Trust shared a common software domain.

2

alert notifications from multiple patients, including those for whom they are no longer medically responsible. Sending notifications externally (e.g., by e-mail) is subject to the same concerns and both removes the ability to monitor the acknowledgement of alert notifications and risks patient sensitive information being incorrectly disseminated or exposed to cyberattacks.

3.3. RSFT chose to override the default configuration and limit the recipients of Anti-Infective Alert Notifications (as defined below) to prescribers only, thereby preventing other users from acting as a failsafe.

3.4. The alert notification system is not intended to serve as a substitute in place of the clinical protocol to access individual patient EPRs daily and it would be improper for it to do so. To the extent that there is concern about prescribers not accessing the EPR, this is a clinical workflow issue. Ultimately, no amount of alert notifications can address the shortcomings of a prescriber failing to follow a clinical workflow or not observing underlying standards of care.

3.5. Oracle Health has no record of RSFT raising any clinical safety or other issues relating to Anti-Infective Alert Notifications during the Millennium training process or post go live. RSFT raised no service or test issues regarding such alert notifications as part of the deployment testing process or subsequent to the systems going live in May 2022.

3.6. Oracle Health does not consider that any enhancement to the alert notifications can address a clinical workflow issue but is open to exploring with RSFT whether any configuration changes, alterations to working practices, or additional training may assist to further mitigate any clinical risks.

B. ORACLE HEALTH AND MILLENNIUM

4. Oracle Health’s Millennium software has been successfully deployed globally, first in the United States in 1984 and since 1986 internationally. Oracle Health has licensed its solution at 28,000 facilities around the world, and has adapted Millennium to various types of facilities, including 3,000 hospitals, 3,500 physician practices, 200 home health facilities and 200 employer sites. Oracle Health’s clients include over 39 NHS Trusts.

5. Oracle Health designed Millennium as an electronic patient record solution. The solution creates an electronic medical record through which physicians can access near real time data. By organising the data around the patient, rather than the patient encounter, Millennium eliminates duplication and places data only once in a central repository. Millennium enables information from disparate clinical domains and multiple facilities to be seamlessly integrated.

6. The Millennium solution currently comprises nine solution and service sets with sub-modules. The relevant sub-module for the purposes of the Response is Medications Management, which covers prescription workflows, including documenting medication history, medication reconciliation and verification, the prescribing process and discharge and outpatient medicines.

3

C. CONFIGURATION AND DEPLOYMENT OF MEDICATIONS MANAGEMENT AT RSFT

7. In December 2019, RSFT and another Trust client signed an agreement to implement Oracle Health’s Millennium solution. Millennium went live at Royal Surrey in May 2022.

8. The initial steps in the deployment of the Millennium solution involves an assessment of a client’s existing systems, an evaluation of their objectives and a demonstration of the relevant solutions in default configuration. Following the initial consultation process, Oracle Health hosted a series of design and configuration workshops (“D&C Workshops”) for RSFT between around August 2020 and the beginning of January 2021. Workshops covering Medications Management were hosted by Oracle Health’s Medication Process team and were attended by subject matter experts empowered to make design decisions on behalf of RSFT. It is critical to the success of deployments that appropriate decision-makers attend these sessions and they are required to have a solid understanding of the workflow processes within their areas of expertise.

9. There are no specific Government or NHS regulations, or guidance, governing how alert notifications for anti-infective prescriptions are generated in electronic healthcare systems. However, as an experienced industry leader in electronic healthcare, Oracle Health has developed content, workflows and decision support to help meet the potential needs of its client base. As part of the D&C Workshops, RSFT representatives were given the opportunity to tailor certain aspects of Medications Management functionality to the specific needs and workflows of RSFT. Post go-live, RSFT had the option to implement additional configuration changes through Oracle Health’s ‘Apps Services’ team. However, RSFT decided to make certain configuration changes to Millennium and Medications Management on its own, independently of Oracle Health and without the benefit of its institutional knowledge and guidance as to best practice. Oracle Health is necessarily unable to comment on such configuration changes where it has no awareness of them.

10. Oracle Health understands that the Area Coroner did not have the benefit of a written, or visual, description of alert notifications in respect of anti-infectives. In default configuration:

10.1. Anti-infectives are prescribed using the ‘order’ tab in a patient’s EPR. After selecting the relevant medicine, prescribers must complete a mandatory form and sign the order to complete the prescription. Prescribers are shown alert notifications during the prescribing process if: (a) a patient’s weight and allergies have not been documented in the preceding 28 days; or (b) a prescriber has selected a duration of doses rather than days of medication.

10.2. Following the prescription of an anti-infective: (a) certain ‘alert notifications’ are displayed within a patient’s EPR; and (b) Millennium will display a ‘task’ within the ‘Doctors Worklist’.

10.3. Alert notifications arise through configurable rules contained within a module called ‘Discern Expert’ (“Rules”). To assist standard workflows for anti-infectives, customers in the UK are offered certain default Rules which they can review and configure during the design process (“Default Rules”).

(a) Configuration of Anti-Infective Alert Notifications

11. In relation to anti-infective prescriptions, the Default Rules generate three sets of alert notifications within a patient’s EPR in default configuration (“Anti-Infective Alert Notifications”). The Default Rules generate Anti-Infective Alert Notifications to all users when they access a patient’s EPR save for certain administrative staff:

4

11.1. 72-Hour Alert Notification: Generated 72 hours after the anti-infective is prescribed. The purpose of the alert notification is to prompt users to review the prescription, given the risks of anti-infective resistance. On viewing the alert notification, a user is directed to complete a review form and can either: (a) state that they are not medically responsible for the patient; or (b) acknowledge that the patient’s clinical condition, diagnosis and investigations have been reviewed and select a relevant action e.g., to stop or continue the anti-infective. The Default Rules will continue to generate the 72-Hour Alert Notification each time the patient’s EPR is accessed until the end of the prescription period unless a user conducts the necessary review. Screenshots 1 and 2 in Appendix 1 show the 72-Hour Alert Notification and accompanying review form in default configuration.

11.2. 24-Hour Pre-Expiry Alert Notification: Generated 24 hours before the prescription is due to expire. On viewing the alert notification, the user is able either to: (a) dismiss the alert notification; or (b) document that the alert notification has been acknowledged. If the alert notification is dismissed, the Default Rules will continue to generate the 24-Hour Pre-Expiry Alert Notification for the duration of the 24-hour period each time the patient’s EPR is accessed unless a user selects ‘acknowledge’ and completes the accompanying form. Screenshots 3 and 4 in Appendix 1 show the 24-Hour Pre-Expiry Alert Notification and acknowledgment form in default configuration.

11.3. 24-Hour Post-Expiry Alert Notification: An additional alert notification is generated for 24 hours after the prescription has expired each time the patient’s EPR is accessed unless it is acknowledged. Screenshots 5 and 6 in Appendix 1 show the 24-Hour Post-Expiry Alert Notification and the accompanying acknowledgment form in default configuration.

12. The Report references staff receiving and “click[ing] off” alert notifications they did not consider relevant. That appears to be a reference either to: (a) the option to select ‘not medically responsible’ in the case of the 72-Hour Alert Notification; or (b) the option to ‘dismiss’ the 24-Hour Pre and Post Expiry Alert Notifications. Sending the alert notification to individuals who may not be medically responsible for the relevant care serves an important function: they operate as a failsafe to ensure that those who are responsible are made aware of the alert notifications if they have not received them, for example by raising a face-to-face query with the relevant prescriber. In certain circumstances, the Rules will generate a ‘hard stop’ alert notification which cannot be dismissed and requires a user to undertake action there and then. As a matter of clinical best practice these ‘hard stop’ alert notifications are used in very limited circumstances so as to avoid, for example, disrupting urgent tasks which may need to be completed for the patient in other workflows. It is not practical to target particular alert notifications to particular clinicians because of the frequent changeover in care and the fact that the recipients would be swiftly superseded.

13. As noted above, RSFT was given the opportunity to make certain configuration changes to the Default Rules during the D&C Workshops. The scope of changes that could be made included the content, frequency, period and recipients of the alert notifications. RSFT retained the three alert notifications referenced above with the following configuration changes:

13.1. Recipients: RSFT decided to limit recipients of the Anti-Infective Alert Notifications to doctors, pharmacists, nurses, pharmacy technicians and non-medical prescribers. The Report suggests that after the Deceased’s death, RSFT further limited the recipients of these alert notifications to prescribers only. Oracle Health was not consulted in relation to this latter change and was not aware that it had been made.

13.2. 72-Hour Alert Notification: RSFT decided to include a ‘Long Term Anti-Infective’ field which, if selected, would disable the 72-Hour Alert Notification. Oracle Health understands

5

that RSFT subsequently made an additional modification to change the 72-Hour Alert Notification to a 48-hour alert notification.

13.3. 24-Hour Pre and Post Expiry Alert Notifications: RSFT disabled the 24-Hour Post- Expiry Alert Notification if a user had acknowledged the 24-Hour Pre-Expiry Alert Notification.

13.4. Additional Alert Notifications: RSFT explored the option of including an additional review alert notification which would mirror the existing 72-Hour Alert Notification. This new alert notification would fire 5 days after the prescription had started. RSFT ultimately decided not to pursue the change prior to go-live.

14. The Report suggests that there were a “pre-agreed number of alerts” and that “alerts can be used up”. By way of clarification, there is no numerical cap on the number of Anti-Infective Alert Notifications that can be sent within the default configuration parameters, and no such cap was introduced by RSFT during the D&C Workshops process.

15. In respect of the Report’s observation that “there was a risk that the alerting system would not operate to draw attention to the need for prescription review before the medication ceases if no prescribing clinician accesses a patient’s record”:

15.1. Alert Notifications support various user workflows and are intended to operate as a failsafe against human error or oversight compared with traditional paper-based systems. However, alert notifications do not replace the need for users to follow clinical workflows or underlying duties or standards of care. This includes, for example, the general requirement (subject to certain exceptions) that “patients should be reviewed by a consultant at least ONCE EVERY 24 HOURS, seven days a week, unless it has been determined that this would not affect the patient’s care pathway”.2

15.2. Electronic alert notifications must operate within the confines of the Millennium system and having alert notifications sent externally (e.g., by e-mail) would be less effective and risks unacceptable data security breaches.

15.2.1. Displaying alert notifications when a clinician or other user logs into Millennium, as opposed to when they open a particular patient’s EPR, has historically been considered and continues to be considered by clinical subject matter experts within the ‘Meds Management Special Interest Group’ as unworkable. In particular, a substantial volume of alert notifications would be sent to a large number of users, many of whom will have no, or no ongoing involvement, in a patient’s journey. A patient can be seen, for example, by a number of different users depending on shift patterns and medical need. Such a system would be inefficient, and risk ‘alert fatigue’3 and disruption of important workflows.

15.2.2. Sending alert notifications externally (e.g., by e-mail) would be similarly unworkable, and still risks inundating inboxes with notifications of no immediate relevance to that user. E-mail notifications maintain the requirement for clinicians and other users to follow clinical workflows to take the required action, but bring attendant risk from being housed outside the Millennium system. In particular: (a) viewing alert notifications by e-mail removes the ability of Millennium to monitor acknowledgments

2 NHS Seven Day Services Clinical Standards (Version 2, 8 February 2022), Item 8. 3 Broadly defined as a high volume of alert notifications causing users, including clinicians, to become desensitised and ignoring or failing to respond appropriately to such alert notifications.

6

with a corresponding loss of visibility and accountability; (b) e-mails would delay the time taken to respond to alert notifications with users still being required to log into the system in order to action them; and (c) patient sensitive information in e-mail inboxes is subject to increased risk of erroneous dissemination or cyberattacks.

15.3. Accordingly, alert notifications must be displayed in context at an appropriate location to ensure that they are manageable and viewable by relevant users. The most logical way to organise and display alert notifications is through the individual patient’s EPR. The EPR is Millennium’s central repository for key medical information for each patient. Users with active involvement in a patient’s care should routinely access the EPR, including as a result of best practice and standards of care. If such users access the EPR, alert notifications will be displayed to the most relevant users at any given time. Ultimately, however, no alert notification can compel a user to login to Millennium or to consult the EPR.

15.4. As noted above, an important mitigant against prescribers failing to access the EPR at regular intervals is to ensure that a wide user-base receives alert notifications when checking a patient’s record. By limiting the pool of recipients to prescribers only, RSFT risks diluting an important failsafe because other users are no longer able to see and act on alert notifications. Moreover, as noted above, the number of alert notifications in each alert notification period cannot be “used up” so there is no downside to presenting them to a wide user-base, even if some portion of those users select “not medically responsible” or dismiss the alert notification.

(b) Tasks within the Doctors Worklist within Millennium

16. In addition to the above referenced alert notifications, Millennium will display in the ‘Doctors Worklist’ a ‘task’ to complete the anti-infective review 24 hours after prescription (“24-Hour Task”). The Doctors Worklist is a patient dashboard which displays an overview of each patient assigned to a particular clinician. The 24-Hour Task provides clinicians with an opportunity to complete the review before the 72-Hour Alert Notification is generated. Screenshot 7 in Appendix 1 shows the 24-Hour Task as it appears within the Doctors Worklist.

(c) Testing, Training and Ongoing Monitoring of Medications Management by RSFT

17. Oracle Health has no record of RSFT raising any clinical safety issues relating to alert notifications or tasks for anti-infective prescriptions during the Millennium training process or additional support period. Further, RSFT raised no relevant service or test issues as part of the deployment testing process or subsequent to the systems going live in May 2022.

D. POTENTIAL ENHANCEMENTS TO MEDICATIONS MANAGEMENT AS DEPLOYED AT RSFT

18. Oracle Health continuously engages in ongoing dialogue with its clients regarding potential software code and configuration enhancements to its Millennium solutions. Such enhancements can arise at the global, or national, level in response to the knowledge and experience gained by Oracle Health from working with its extensive client base. They can also arise in response to specific issues at the level of local deployments. In each case, Oracle Health will discuss with its client the appropriateness of taking a potential upgrade and its impact on existing workflows and the user interface. Ultimately, the decision on whether to take a particular code or configuration enhancement remains with the client and can involve clinical and commercial considerations.

7

19. Oracle Health considers that the anti-infective alert notification features are appropriate and functioning as designed. To the extent the Area Coroner’s concern relates to prescribers not accessing the EPR, this is respectfully an issue in the clinical workflow which cannot be addressed through further alert notifications. Nevertheless, Oracle Health will:

19.1. Explore with RSFT whether Oracle Health can assist with any configuration or other changes that could assist in facilitating adherence to the clinical workflow. In particular, RSFT may consider increasing the categories of users who receive Anti-Infective Alert Notifications to restore the failsafe built into the Default Rules.

19.2. More generally, Oracle will also discuss with RSFT the benefits of: (a) establishing an alert notifications committee as part of its healthcare information technology governance, to review existing alert notifications or identify new alert notifications for development; (b) defining, documenting and regularly reviewing how it works with alert notifications in digital solutions through a published Standard Operating Practice; and (c) working more closely with Oracle Health’s ‘Apps Services’ team for future configuration changes.

19.3. Offer supplemental training packages by Oracle Health of RSFT staff in their use and operation of Medications Management as may be considered helpful.