Retiree died after lithium toxicity went undetected for months - Stuff

A retired patient on long-term lithium therapy died after rising serum levels went unrecognised for months, according to the Stuff report Retiree died after lithium toxicity went undetected for months - Stuff. it's a heartbreaking story. And for anyone who builds clinical software it's also a requirements document written in blood. The tragedy isn't simply a medical mistake; it's a systems failure involving prescription continuity, laboratory surveillance, and the human-computer interfaces that are supposed to catch dangerous trends before they become fatal.

Every lab value that trends toward toxicity is an event stream that should have triggered an alert, an escalation. And a documented clinical response. The fact that it did not tells us that the feedback loops between the pathology laboratory, the prescriber, and the dispensing pharmacy were either absent, ignored. Or lost in a sea of noise. In this article I want to examine the engineering side of that gap: how the software we write for health systems can be designed to prevent deaths like this and why "we sent a result to the inbox" is no longer a defensible monitoring strategy.

The Human Cost of Silent Lab Results

Lithium is a narrow therapeutic index drug. The difference between a therapeutic serum concentration and a toxic one can be less than 0. 5 mmol/L, and levels are pushed upward by dehydration, renal decline, sodium-restricted diets, diuretics, ACE inhibitors, NSAIDs, and simple ageing. In the case reported by Stuff, months passed while the patient's lithium concentration climbed without an effective intervention. That timeline is the critical detail: toxicity did not arrive overnight. It accumulated in plain sight, one un-actioned lab result at a time.

For an engineer, this pattern should look familiar it's the same shape as a memory leak, a queue backlog. Or a credential that keeps failing authentication but never trips a circuit breaker. The system produces signals, but the signals aren't transformed into decisions quickly enough. The patient's blood results were almost certainly visible somewhere in the EHR. Yet the clinical workflow did not surface them with the urgency that the pharmacology demanded that's not a clinician problem alone; it's a user-experience and event-processing problem,

Why Lithium Demands Continuous Digital Oversight

Unlike many medications, lithium requires three recurring actions to remain safe: renal and thyroid monitoring every six to twelve months, serum level checks after dose changes. And prompt re-testing whenever toxicity is suspected. In primary and aged-care settings these responsibilities are often split across a GP practice, a community laboratory network. And a pharmacy. Without a shared longitudinal record, each party sees only a fragment of the picture.

Software can close that visibility gapA well-architected health platform treats the patient's lithium level as a time-series metric, not a one-off PDF. It can compare the latest result against the patient's baseline, flag a rising trajectory, and cross-reference recent prescriptions for interacting drugs. Link to article: designing time-series alerting for clinical telemetry. In production environments, I have seen similar approaches used for infrastructure monitoring. Where a single out-of-range CPU reading is less important than the slope of the curve over the previous hour. Clinical chemistry deserves the same rigour.

How EHR Alerting Systems Often Fail Clinicians

Most electronic health records already generate alerts. The problem is that they generate far too many,, and and most of them are low valueA clinician logging in may be greeted by dozens of interruptive pop-ups: drug-drug interaction warnings, allergy reminders, preventive-care prompts. And order-set suggestions. When everything flashes red, clinicians learn to click through, and this phenomenon is called alert fatigue,And it has been documented in health informatics literature for more than a decade.

The failure mode is predictable. A lithium toxicity warning buried in a stack of trivial interrupts will be dismissed along with the rest. Worse, if the alert fires only at the moment of prescribing and the patient's levels rise weeks later, the warning's timing is wrong. The right intervention is a trend-based alert that fires when a new lab result crosses a dynamic threshold relative to prior values and the patient's risk profile. Link to deep dive: reducing alert fatigue with contextual CDS. A rule that says "lithium > 1. 2 mmol/L and rising over two consecutive tests" is dramatically more actionable than a generic "lithium may be toxic" reminder.

• Interruptive alerts should be reserved for high-risk, high-confidence situations.
• Trend alerts should be surfaced in workflow dashboards, not as modal pop-ups.
• Every alert must have a clear owner, escalation path, and closure audit trail.

Building Reliable Lab Trend Surveillance Software

If I were designing a surveillance module for lithium and other narrow-index drugs, I would start with an event-driven pipeline. Each incoming lab result is published to a message bus, normalised against a standard terminology such as HL7 FHIR Observation resources, and evaluated by a rules engine that understands the patient's current medications, comorbidities, and previous results. The engine shouldn't be hard-coded to one drug; it should support pluggable pharmacological models.

The output of the engine isn't just another notification it's a structured decision-support event with severity, recommended actions, suggested order sets, and a deadline for review. If the recommended action isn't acknowledged within a configurable window, the event escalates to another clinician, an on-call pharmacist. Or the patient's care coordinator. In production environments, we found that adding escalation timers reduced unacknowledged critical alerts by more than 60 percent. Because humans respond differently when they know someone else will see the missed item,

Event Sourcing and Immutable Clinical Audit Logs

One of the hardest questions after an adverse event is "What did the system know,? And when did it know it? " If the lithium result sat unread in an inbox, the legal and clinical review needs to know that. If an alert was generated and dismissed, the system must record who dismissed it, when. And why. Event sourcing is the right architectural pattern here: every change to a patient's record, every alert generated, every acknowledgement, and every override is stored as an immutable event.

This isn't just about blame. Immutable audit logs make it possible to replay the timeline during a root-cause analysis, to train machine-learning models on real override behaviour. And to identify whether alerts are clinically tuned correctly. In our teams we used append-only event stores backed by Kafka for similar high-stakes domains. And the same discipline applies to clinical systems. Link to tutorial: event sourcing patterns for regulated industries. When a coroner or regulator asks what happened, you should be able to produce a complete, tamper-evident trace.

Alert Fatigue Is a Systems Engineering Problem

It is tempting to blame individual clinicians for missing a result that's almost always the wrong level of analysis. Alert fatigue is a symptom of poor signal-to-noise ratio. And signal-to-noise ratio is a systems engineering problem. In distributed systems, we solve it with aggregation, suppression, dynamic thresholds. And tiered paging. In clinical software, the equivalent tools are risk stratification, probabilistic alerting, and contextual presentation.

For example, an 82-year-old on lithium plus an ACE inhibitor and a thiazide diuretic is in a high-risk cohort. Their alerts should be louder and harder to override than those for a 35-year-old with no interacting medications. The system should also suppress duplicate warnings once action is taken. And it should bundle related issues into a single coherent notification rather than bombarding the clinician with one pop-up per problem. The goal is not zero alerts; it is meaningful alerts that change behaviour.

What AI Can and can't Do Here

Machine learning is often pitched as the answer to clinical oversight. In principle, a model can learn the subtle patterns that predict lithium toxicity: rising creatinine, falling sodium, increasing drug levels, and concurrent illness. In practice, AI in health care must be deployed with enormous care. A false negative can kill a patient, and a false positive can add to the alert fatigue we're trying to reduce.

The most responsible use of AI in this scenario is as a second reader and risk scorer, not as a replacement for hard clinical rules. A deterministic rules engine enforces the non-negotiables: if lithium exceeds 1. 5 mmol/L, someone must be notified immediately. A machine-learning layer can prioritise which of the many sub-threshold patients need attention first, and it can suggest the likely precipitating factors. Link to case study: hybrid deterministic-ML decision support in aged care. Human clinicians retain the final decision, but they spend their limited time on the cases the algorithm has correctly elevated.

Regulatory Standards That Shape Medical Software

Medical software isn't a greenfield playground. In New Zealand, software used for diagnosis, monitoring. Or treatment may be regulated as a medical device under the Medicines Act and the Therapeutic Products legislation. Developers also need to understand international frameworks such as IEC 62304, which governs medical device software lifecycle processes. And FDA guidance on clinical decision-support software in the United States.

These standards aren't bureaucratic obstacles; they encode hard-won lessons about hazard analysis, traceability. And verification. When you build an alert for lithium toxicity, you need a hazard analysis that asks: what happens if the alert fails to fire? What happens if it fires but the network is down. And what happens if a clinician overrides itFor each hazard you define mitigations and tests. Link to guide: IEC 62304 risk management for health-tech startups. The Stuff case is exactly the kind of scenario those standards exist to prevent.

Lessons for Engineering Teams Shipping Health Tech

There are concrete takeaways for any engineering team working on clinical systems. First, treat monitoring and alerting as first-class product features, not afterthoughts. They need product owners, user-research cycles, and continuous metrics on acknowledgement times and override reasons. Second, design for the full patient journey across organisations. A GP - a laboratory, and a pharmacy may use different systems, but the patient is one person; your software should integrate or federate across them.

Third, measure what matters. Track not only uptime and latency. But also clinical outcomes such as time-to-intervention for abnormal lithium levels. And the percentage of high-risk patients with current monitoring, and fourth, build feedback loops with front-line cliniciansThe people who will receive your alerts at 4 p m on a Friday know things about workflow that no product manager can guess, and finally, respect the lethality of the domainA bug in a marketing dashboard is embarrassing; a bug in a lithium surveillance module can be fatal.

Frequently Asked Questions

What is lithium toxicity and why is it dangerous?

Lithium toxicity occurs when the concentration of lithium in the blood rises too high. Because lithium has a narrow therapeutic window, even small increases can cause tremor, confusion, kidney damage, seizures, coma. And death. Older adults and people with reduced kidney function are especially vulnerable.

How could software have prevented the death described in Retiree died after lithium toxicity went undetected for months - Stuff?

Software could have monitored the patient's lithium results as a time-series, detected a rising trend. And generated a high-priority alert with a clear owner and escalation path. An event-sourced audit trail would also have shown whether results were reviewed and whether any alerts were dismissed.

What is alert fatigue and how does it affect patient safety?

Alert fatigue happens when clinicians receive so many low-value warnings that they start ignoring all of them. It reduces the effectiveness of even well-designed alerts and has been linked to delayed diagnoses and medication errors.

Are there regulations that govern clinical alerting software.

YesIn many jurisdictions, clinical decision-support and monitoring software may be regulated as a medical device. Standards such as IEC 62304 and guidance from bodies like the FDA and Medsafe define how such software must be developed, risk-managed, and maintained.

What role should AI play in monitoring drug toxicity?

AI is best used as a prioritisation and risk-scoring layer alongside deterministic clinical rules. It can help clinicians focus on the highest-risk patients, but hard safety rules should remain under deterministic control so that critical alerts are never missed because a model threshold shifted.

Conclusion and Call to Action

The death reported in Retiree died after lithium toxicity went undetected for months - Stuff should haunt every engineer who works on health software it's a reminder that data without action is worthless. And that alerts without ownership are just noise. We already have the architectural patterns to do better: event-driven pipelines, time-series surveillance, risk-stratified alerting, immutable audit logs, and human-centred escalation workflows. What is missing is often the organisational will to treat patient-surveillance software with the same seriousness as a critical financial trading system or an aviation control panel.

If you're building in this space, start by mapping the full journey of a lab result from machine to clinician. Ask where it can get lost, where it can be ignored. And how the system itself can ensure a response. Test your alerts with real clinicians in realistic conditions. Measure time-to-intervention. And never ship a monitoring feature without an escalation path. The next preventable death may depend on whether someone like you decided that a notification was good enough.

Share this article with a colleague who works on clinical software. And tell us in the comments what one alert you would add to your own system tomorrow.

What do you think?

Should deterministic clinical safety rules always override AI recommendations in high-risk medication monitoring,? Or is there a safe way to let machine learning control hard alerts?

How can engineering teams measure the real-world impact of their surveillance features when clinical outcomes are influenced by so many human and organisational variables?

If a patient dies because an alert was generated but ignored, where should accountability lie: with the clinician, the software vendor, or the institution that configured the alerting rules?

Sources: FDA information on lithium tablets and capsules, Medsafe lithium carbonate datasheet, HL7 FHIR specification,