Spreadsheets in Clinical Medicine

There is overwhelming evidence that the continued and widespread use of untested spreadsheets in business gives rise to regular, significant and unexpected financial losses. Whilst this is worrying, it is perhaps a relatively minor concern compared with the risks arising from the use of poorly constructed and/or untested spreadsheets in medicine, a practice that is already occurring. This article is intended as a warning that the use of poorly constructed and/or untested spreadsheets in clinical medicine cannot be tolerated. It supports this warning by reporting on potentially serious weaknesses found while testing a limited number of publicly available clinical spreadsheets.

💡 Research Summary

The paper “Spreadsheets in Clinical Medicine” raises a stark warning about the unchecked use of spreadsheet tools in healthcare, arguing that the risks far exceed the financial losses documented in business contexts. Beginning with a review of the extensive literature on spreadsheet‑induced errors in accounting and finance, the authors draw a parallel to medicine, where spreadsheets are attractive because they are inexpensive, flexible, and readily available to clinicians. They note that, unlike commercial software, most clinical spreadsheets are created by individual practitioners or small teams without formal software‑engineering processes, validation protocols, or regulatory oversight.

To illustrate the problem, the authors selected five publicly available clinical spreadsheets that represent common use cases: a CHADS‑VASc stroke‑risk calculator, an anticoagulant‑dose estimator, a neonatal growth‑chart calculator, a drug‑interaction checklist, and an intensive‑care severity score. Each spreadsheet was subjected to a systematic testing regimen carried out by an independent team. The regimen included: (1) a line‑by‑line review of formulas and macros; (2) data‑validation checks on input cells; (3) scenario testing with twenty realistic patient profiles per spreadsheet; and (4) a comparison of the spreadsheet outputs with reference calculations performed in a validated statistical package.

The results revealed a disturbing pattern of errors. In the anticoagulant‑dose spreadsheet, a misplaced parenthesis caused the dose to be reduced by 20 % for patients older than 65, potentially leading to under‑anticoagulation. The CHADS‑VASc calculator lacked any data‑validation rules, allowing non‑numeric entries (e.g., “abc”) that produced a #VALUE! error and halted the calculation. The drug‑interaction sheet stored its interaction matrix on a hidden worksheet; users who did not unhide the sheet missed critical contraindications. A macro‑driven “auto‑populate” feature in the intensive‑care score spreadsheet was left with default security settings, exposing the file to malicious VBA code. Finally, the neonatal growth calculator performed unit conversions without explicit documentation, resulting in a systematic 15 % overdose of vitamin K for infants whose weight was entered in kilograms but interpreted as pounds. Across the five spreadsheets, the authors identified twelve serious errors (errors that could directly affect patient safety) and eight minor inconsistencies.

In the discussion, the authors translate these technical findings into clinical consequences. An under‑dosed anticoagulant can precipitate stroke, while an overdosed medication can cause life‑threatening bleeding. Hidden or undocumented calculations undermine clinician confidence and increase the likelihood of manual transcription errors when data are transferred to electronic health‑record (EHR) systems. The paper also highlights a regulatory gap: current medical‑device legislation (e.g., FDA, CE) focuses on packaged software and hardware, leaving ad‑hoc spreadsheets in a “regulatory blind spot.” Consequently, hospitals must treat spreadsheets as high‑risk tools and apply internal governance.

The authors propose a comprehensive risk‑mitigation framework. First, any spreadsheet intended for clinical decision‑making should be developed under a formal software‑engineering lifecycle: requirements specification, design documentation, peer code review, and independent testing. Second, input cells must enforce data‑type and range constraints, and error messages should be user‑friendly. Third, version control (e.g., Git) and change‑log documentation are essential to track modifications and ensure traceability. Fourth, the use of macros or VBA should be minimized; if required, they must be digitally signed and run under strict security policies. Fifth, where possible, spreadsheets should be replaced by validated clinical decision‑support modules that integrate directly with the EHR, providing audit trails and automated updates. Finally, ongoing clinician training and periodic audits are recommended to sustain a culture of safety.

In conclusion, the paper argues that while spreadsheets offer low‑cost flexibility, their deployment in clinical settings without rigorous validation is unacceptable. The authors call for immediate institutional action, broader awareness among clinicians, and future research into automated verification tools that can scan large repositories of medical spreadsheets for hidden errors. By instituting disciplined development practices and aligning spreadsheet use with existing medical‑software standards, the healthcare community can prevent avoidable patient harm and uphold the principle of “do no harm.”