| Recurring |
one_organization |
(a) The software failure incident having happened again at one_organization:
The software failure incident at Addenbrooke's hospital with the eHospital system is a recurring issue within the same organization. The incident occurred on the evening of Saturday 1 November when the Epic system became unstable, leading to a read-only version of the software being activated until it was restored at 2.27 am [56256].
(b) The software failure incident having happened again at multiple_organization:
There is no specific mention in the provided article about the software failure incident happening again at other organizations or with their products and services. |
| Phase (Design/Operation) |
design, operation |
(a) The software failure incident related to the design phase is evident in the article when discussing the implementation of the new patient record system, eHospital, at Addenbrooke's hospital. The system was described as causing constant glitches, with staff unable to do anything until they had logged on, indicating issues with the system's design and functionality [56256].
(b) The software failure incident related to the operation phase is highlighted in the article when it mentions that on the evening of Saturday, November 1, the Epic system became unstable, leading to a decision to switch to a read-only version of the software. This operational failure resulted in a major incident being declared, with ambulances being rerouted to different hospitals for a five-hour period, showcasing the impact of operational issues on the system [56256]. |
| Boundary (Internal/External) |
within_system |
(a) The software failure incident at Addenbrooke's hospital, related to the implementation of the eHospital patient record system, was primarily within the system. The incident involved the Epic system becoming unstable, leading to a decision to switch to a read-only version of the software and eventually declaring a 'major incident' across the system [56256]. The issues mentioned in the article, such as staff struggling with constant glitches, difficulties in logging on, and concerns about the system's functionality, all point to internal system issues contributing to the failure. |
| Nature (Human/Non-human) |
non-human_actions, human_actions |
(a) The software failure incident at Addenbrooke's hospital was related to non-human actions. The Epic system became unstable on the evening of Saturday 1 November, leading to a decision to switch to a read-only version of the software. The system was eventually restored after expert technical advice and action from suppliers, with business continuity plans being deployed. A 'major incident' was declared, and all agencies came together to support the hospital during the night, including rerouting ambulances to different hospitals for a five-hour period [56256].
(b) The software failure incident at Addenbrooke's hospital also had elements related to human actions. Staff and patients were reported to be struggling with the new patient record system, eHospital, which was causing constant glitches and difficulties in operation. Staff members were unable to do their tasks efficiently, leading to a dehumanizing experience for patients. There were concerns raised about the lack of consultation with staff and patients regarding the new system, with reports of a change in culture that was deeply upsetting to the staff. The dissatisfaction with the system and its implementation could be attributed to human actions such as inadequate training, lack of consultation, and a rushed rollout [56256]. |
| Dimension (Hardware/Software) |
hardware, software |
(a) The software failure incident at Addenbrooke's hospital was related to hardware issues. The incident occurred when the Epic system became unstable, leading to a decision to switch to a read-only version of the software. This decision was taken after the system experienced instability on the evening of Saturday, 1 November. Business continuity plans were deployed, and a 'major incident' was declared across the system, resulting in all agencies coming together to support CUHFT. Ambulances were rerouted to different hospitals for a five-hour period [56256].
(b) The software failure incident at Addenbrooke's hospital was also related to software issues. The new patient record system, eHospital, experienced constant glitches and staff were unable to perform their tasks smoothly due to issues with the software. The staff and patients were struggling with the new system, which was described as dehumanizing. The system's instability and glitches caused significant disruptions, leading to concerns about the system itself and its impact on patient care and staff morale [56256]. |
| Objective (Malicious/Non-malicious) |
non-malicious |
(a) The software failure incident described in the articles does not seem to be malicious. It appears to be a non-malicious failure caused by various contributing factors such as system instability, glitches, lack of proper consultation with staff and patients, and a change in culture affecting the user experience [56256]. |
| Intent (Poor/Accidental Decisions) |
poor_decisions, accidental_decisions |
(a) The intent of the software failure incident related to poor decisions can be inferred from the article. The incident at Addenbrooke's hospital with the eHospital system, provided by Epic Systems, resulted in significant disruptions and challenges for both patients and staff. The decision to switch to the new patient record system was met with difficulties, as staff encountered constant glitches and struggled to adapt to the new system. The official report by Jessica Bawden highlighted that the Epic system became unstable, leading to a read-only version being implemented and a 'major incident' being declared. This instability and subsequent disruptions point towards poor decisions in the implementation and readiness of the new software system, causing chaos and distress at the hospital [56256].
(b) The software failure incident at Addenbrooke's hospital can also be attributed to accidental decisions or unintended consequences. The introduction of the eHospital system was meant to improve patient care and streamline access to patient information for clinical staff. However, the implementation of the new system led to unforeseen challenges and disruptions. Staff and patients faced difficulties as the system became unstable, requiring a switch to a read-only version and rerouting ambulances to different hospitals for a period of time. The unintended consequences of the software failure incident, such as dehumanizing interactions and staff dissatisfaction with the change in culture, suggest that the decision to implement the new system may have had unintended negative impacts on the hospital's operations and patient care [56256]. |
| Capability (Incompetence/Accidental) |
development_incompetence, accidental |
(a) The software failure incident at Addenbrooke's hospital, related to the implementation of the eHospital patient record system, can be attributed to development incompetence. The article mentions that the new system caused significant disruptions and difficulties for both patients and staff. Staff members were struggling with constant glitches, and there were concerns about the system's functionality and impact on patient care. The director of corporate affairs reported that the system became unstable, leading to a major incident and the need to switch to a read-only version of the software [56256]. These issues indicate that the failure was partly due to problems introduced during the development and implementation of the software, possibly stemming from a lack of professional competence in handling such a complex system.
(b) The software failure incident at Addenbrooke's hospital can also be categorized as an accidental failure. The implementation of the eHospital patient record system led to unintended consequences, such as staff being unable to perform their duties efficiently, patients experiencing a dehumanizing environment, and disruptions in hospital operations. The incident was described as a major disruption, requiring the deployment of business continuity plans and rerouting ambulances to different hospitals for a five-hour period [56256]. These unplanned consequences and disruptions point to the failure being accidental in nature, resulting from unforeseen issues arising from the introduction of the new software system. |
| Duration |
temporary |
The software failure incident described in the articles was temporary. The incident occurred on the evening of Saturday 1 November when the Epic system became unstable, leading to a decision to switch to a read-only version of the software at approximately 11.15pm. The system was restored at 2.27am after expert technical advice and action from suppliers. During this time, business continuity plans were deployed, and a 'major incident' across the system was declared, with all agencies coming together to support CUHFT [56256]. |
| Behaviour |
crash, other |
(a) crash: The software failure incident described in the articles can be categorized as a crash. The incident involved the Epic system becoming unstable, leading to a decision to switch to a read-only version of the software, a major incident being declared, and ambulances being rerouted to different hospitals for a five-hour period due to the system failure [56256].
(b) omission: The software failure incident did not specifically mention any instances of the system omitting to perform its intended functions at a particular instance.
(c) timing: The software failure incident did not involve the system performing its intended functions too late or too early.
(d) value: The software failure incident did not mention the system performing its intended functions incorrectly.
(e) byzantine: The software failure incident did not describe the system behaving erroneously with inconsistent responses and interactions.
(f) other: The behavior of the software failure incident can be described as causing chaos and distress due to the system failure, impacting both patients and staff at the hospital [56256]. |