EXIN BiSL Foundation study materials
EXIN BiSL Foundation study resources

The missing SMS alert at St. Aldric's Hospital

EXIN BiSL Foundation · Put your knowledge to work in context.

All case studies

The missing SMS alert at St. Aldric's Hospital

At a 600-bed hospital, the operating theatre scheduling system has a function that flags urgent cases and should send an SMS to the duty anaesthetist. For the past two weeks the SMS has not been sent. Staff have worked around it by phoning the anaesthetist, adding roughly 25 minutes of overtime per shift and creating a patient-safety risk. Forty complaints have been logged. The application is supplied and maintained by an external party under a contract that distinguishes 'defects' (fixed at no charge within the agreed specification) from 'changes' (quoted and scheduled). The supplier says the SMS behaviour was never in the original specification, calls it a change, and quotes €18,000 and eight weeks. The functionality manager has found an old requirements document that mentions 'notification of urgent cases' but does not name SMS. The hospital's business information manager must decide what to do next.

1. How should the functionality manager classify and handle the SMS issue, and what evidence should be gathered?

Read the worked answer

Classification follows the contract's definitions, not the supplier's convenience. The functionality manager should gather the original specification, the requirements document, acceptance records, user manuals, training material and any correspondence in which SMS notification was discussed. If the agreed specification required 'notification of urgent cases' and the system was accepted and used with SMS for months, there is a strong argument that SMS is part of the agreed behaviour, making this a defect. If the specification genuinely never mentioned it, the supplier's change classification may be correct, even if users assumed otherwise.

In either case, patient safety comes first: implement an interim measure, such as a manual check or an alternative alert, while the dispute is resolved. The functionality manager should document the facts and the impact, classify the issue provisionally, and route it through change management so that priority and ownership are recorded. The classification should not delay mitigation. A short joint fact-finding session with the supplier is better than exchanging letters.

2. What roles do change management and connect management play, and how should the supplier be approached?

Read the worked answer

Change management owns the procedure: it records the issue, assesses impact on patients and operations, sets priority against other changes, and ensures the eventual solution is specified, tested and accepted. Connect management owns the relationship and the contract: it checks the service agreement, raises the dispute through the agreed escalation path, and prevents the functionality manager from negotiating alone.

The supplier should be approached in a structured service review, with the evidence shared in advance and two questions on the table: is this within the agreed specification, and what interim measure can be delivered immediately? Avoid opening with penalty threats, because the supplier's cooperation on the interim fix matters more than winning the argument. At the same time, do not accept the €18,000 quote as a precondition for discussion. If the evidence is ambiguous, propose a split: the supplier fixes the safety-critical alert at cost while the wider behaviour is specified as a change. Record the outcome and the reasoning in writing, so the same argument does not return.

3. What should the hospital change to prevent a recurrence?

Read the worked answer

Three weaknesses produced this situation: an ambiguous specification, a contract that relies on that ambiguity, and no routine check that promised behaviour still works.

  • Functionality management should require testable acceptance criteria for every requirement, including operational behaviour such as who receives which alert and when.
  • The service catalogue and user documentation should state what the system does, so users do not build expectations from training slides.
  • Connect management should clarify in the contract how defects are proven, what evidence counts, and how safety-related issues are escalated out of hours.
  • Change management should include a post-implementation review that checks the actual effect on work, not just that the change was delivered.

Finally, set up a light user feedback channel so that forty complaints are not needed before a safety risk becomes visible. These measures cost little; the overtime and clinical risk already exceed any reasonable prevention budget.