Clinical Risk Management in Medical Software: Applying IEC 62304 & ISO 14971

The Intersection of Software Bugs and Clinical Harm

In non-medical software, a bug causes an annoying crash, a visual glitch, or a delayed transaction. In clinical software, a software failure or ergonomic design flaw translates directly into biological harm:

• A drop-down menu that auto-selects '10 mg' instead of '1 mg' can precipitate a fatal paediatric overdose.
• A latency spike during chart switching can result in clinical notes or pathology requests being saved to the wrong patient's electronic health record.
• Poor default timezone handling can cause insulin administration schedules to misalign across daylight savings transitions.

Managing these hazards requires formal Clinical Risk Management throughout the entire software lifecycle.

ISO 14971: The Risk Management Lifecycle

ISO 14971 mandates an iterative, document-driven risk management framework consisting of five structured phases:

1. Hazard Identification: Identifying every plausible biological, operational, or technical hazard (e.g. drug-drug interaction missed, incorrect weight-based dosage calculated, server timeout during emergency consultation).
2. Risk Estimation: Assessing both the Severity of Harm (from Negligible to Catastrophic) and the Probability of Occurrence to determine baseline risk levels.
3. Risk Control Measures (Inherent Safety First): Mitigating risks following the strict statutory hierarchy:
   • Level 1: Inherent Safety by Design: Eliminating the hazard completely in software architecture (e.g. hard mathematical bounds preventing doses outside biological viability).
   • Level 2: Protective Measures: Automated safeguards (e.g. required second confirmation for high-risk Schedule 8 medications).
   • Level 3: Information for Safety: Warnings, tooltips, and user manual documentation (the weakest form of control).
4. Evaluation of Residual Risk: Proving that after risk controls are applied, all residual risks are reduced to As Low As Reasonably Practicable (ALARP) and that overall benefits outweigh remaining risks.
5. Post-Production Monitoring: Continuous clinical surveillance of real-world operational logs and incident reports.

IEC 62304 Software Safety Classification

IEC 62304 categorises medical software systems into three distinct safety classes based on their potential to cause injury:

• Class A: No injury or damage to health is possible (minimal formal verification documentation required).
• Class B: Non-serious injury is possible (comprehensive architectural design, unit testing, and integration verification required).
• Class C: Death or serious injury is possible (exhaustive code review, complete unit test isolation, and rigorous static code analysis required).

Eliminating Alert Fatigue: The Danger of Crying Wolf

One of the most insidious hazards in modern clinical software is alert fatigue. When an electronic medical record displays intrusive modal pop-up warnings for dozens of clinically trivial or theoretical drug interactions during routine prescribing, clinicians rapidly develop cognitive habituation.

Studies show that clinicians dismiss up to 90–95% of clinical alerts without reading them when alert thresholds are poorly calibrated. When a genuinely life-threatening anaphylactic allergy warning pops up, it is reflexively clicked through and ignored alongside the trivial ones.

Modern clinical risk management prioritises high-specificity, tiered alert architectures: reserving hard-stop modal interruptions strictly for life-critical contraindications, while presenting minor clinical guidance through subtle, non-disruptive inline visual affordances.