Written and maintained by CASRAI Editorial Board
Last updated
IEC/TR 80002-1 (Medical device software — Part 1: Guidance on the application of ISO 14971 to medical device software) is the international technical report jointly developed by IEC Subcommittee 62A and ISO Technical Committee 210 to help software engineers and regulatory teams apply ISO 14971 risk management principles to Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD). While IEC 62304 defines the normative software development and maintenance life cycle processes (including Clause 7 software risk management), IEC/TR 80002-1 explains how to identify software anomalies, model causal hazard chains, and implement defensive risk controls when software failures are purely systematic rather than random.
How Does IEC/TR 80002-1 Guide the Application of ISO 14971 to Medical Device Software?
IEC/TR 80002-1 mirrors the step-by-step clause structure of ISO 14971 (and complements general guidance in ISO/TR 24971) while translating hardware-oriented risk concepts into software architecture terms:
- Mapping the Causal Chain from Anomaly to Harm: Software does not directly inflict physical injury on its own; rather, a latent defect or unhandled external event causes a software anomaly (incorrect output, timing delay, or halt), which leads to a system-level hazardous situation (such as delivering an incorrect radiation dose or displaying stale patient vitals), which can then result in clinical harm.
- Annex B Generic Software Hazard Causes: To prevent teams from overlooking software-specific failure modes during hazard identification, Annex B of IEC/TR 80002-1 provides structured checklists of common software causes across data integrity, timing/concurrency, race conditions, memory/resource exhaustion, user interface confusion, and third-party Off-The-Shelf (OTS) or SOUP (Software of Unknown Provenance) failure modes.
- Hierarchy of Software Risk Controls: In alignment with ISO 14971 and IEC 62304 vs. ISO 13485 quality controls, IEC/TR 80002-1 emphasizes that when a software failure can lead to severe harm, risk control measures planted inside the same software subsystem provide lower independence than external hardware interlocks, independent watchdog processors, or partitioned architectural boundaries.
Why Does Software Failure Have No Random Statistical Failure Rate (P1 = 1) in ISO 14971 Risk Analysis?
One of the most important regulatory principles established in ISO 14971, IEC 62304, and IEC/TR 80002-1 is the distinction between physical component wear-out and software bugs:
- Decomposing Probability of Harm ($P = P_1 times P_2$): Under ISO 14971, the total probability of harm ($P$) is decomposed into $P_1$ (the probability that a hazardous situation occurs, driven by the failure mode) and $P_2$ (the probability that the hazardous situation leads to actual patient or operator harm).
- Systematic vs. Random Failures: Mechanical and electronic hardware fails randomly over time due to thermal stress, fatigue, or component degradation, allowing engineers to calculate statistical Mean Time Between Failures (MTBF) for $P_1$. Software, by contrast, does not wear out. Every software failure is a systematic failure caused by a latent specification, design, or coding defect that is already present in the executable binary. Whenever the exact triggering input state, timing sequence, and environmental condition occur, the software will fail 100% of the time.
- Setting $P_1 = 1.0$ (Worst-Case Assumption): Because there is no valid consensus method to assign a quantitative random probability to whether a latent bug will be triggered in clinical use, IEC/TR 80002-1 and IEC 62304 require risk analysts to treat the probability of a software failure occurring ($P_1$) as 1.0 (100%)—or else drive software safety classification and risk acceptability solely from the severity of harm and the clinically verifiable probability $P_2$ that the hazardous situation causes injury.
- Process Rigor vs. Risk Reduction Claims: Following rigorous coding standards, static analysis, and unit testing reduces the likelihood of introducing defects, but IEC/TR 80002-1 cautions that software process maturity alone cannot be used to claim a numerical reduction in $P_1$ on a risk matrix without specific architectural or clinical risk controls.
How Do You Perform Software FMEA (sFMEA) and Fault Tree Analysis (FTA) for SaMD and Clinical AI?
Annex C of IEC/TR 80002-1 details how to combine bottom-up and top-down hazard analysis methods across the software architecture so that neither architectural single points of failure nor external system interactions are missed:
| Analysis Dimension | Software FMEA (sFMEA) | Fault Tree Analysis (FTA) |
|---|---|---|
| Analytical Direction | Bottom-Up (Inductive): Starts with individual software items, modules, APIs, or SOUP components and asks how each could fail | Top-Down (Deductive): Starts with an undesirable top-level clinical hazard or hazardous situation and traces all logical combinations of causes |
| Primary Unit of Analysis | Software units, classes, database tables, inter-process messages, and AI/ML inference pipelines decomposed per IEC 62304 architecture | Boolean logic gates (AND, OR) linking hardware faults, user errors, network dropouts, and software module failures |
| Typical Failure Modes Examined | Corrupted variable state, division by zero, stale cache value, dropped API packet, thread deadlock, or out-of-distribution AI input | Simultaneous failure of primary control algorithm AND failure of independent watchdog monitor to trigger safe state |
| Key Strength in Medical Software | Ensures systematic coverage of every software item and SOUP library in the IEC 62304 architecture specification | Evaluates multi-factor failure chains and verifies whether defensive risk controls are truly independent (no common-cause failure) |
| Key Limitation | Poor at modeling concurrent multi-component failures or complex timing interactions across hardware and user workflows | Can miss unexpected lower-level software side effects if the top-level hazard list is incomplete |
Applying sFMEA and FTA to Modern SaMD and Clinical AI
- Partitioning and Defensive Architecture: During sFMEA, engineers evaluate each IEC 62304 software item for failure modes such as omission (no output), commission (unintended output), wrong timing (early/late response), and incorrect value. When an item’s failure can lead to high-severity harm, architects introduce segregated software partitions or external sanity checks so that high-risk safety monitors cannot be corrupted by non-critical UI or telemetry threads.
- Tracing Risk Controls to Verification: Every software risk control identified in the ISO 14971 risk management file—such as input range validation, cyclic redundancy checks (CRC), watchdogs, or out-of-distribution confidence thresholds in clinical AI—must be documented as a formal software requirement and traced to objective verification testing.
Frequently Asked Questions
How does IEC/TR 80002-1 guide the application of ISO 14971 to medical device software?
IEC/TR 80002-1 translates ISO 14971 risk management clauses into software engineering practices by mapping how latent software defects cause software anomalies, hazardous situations, and patient harm; providing Annex B checklists of generic software hazard causes; and integrating ISO 14971 risk controls directly with the IEC 62304 software life cycle.
Why does software failure have no random statistical failure rate (P1 = 1) in ISO 14971 risk analysis?
Unlike hardware components that degrade physically with quantifiable random failure rates, software failures are systematic design defects that trigger deterministically whenever specific input and state conditions align. Because the probability of encountering those conditions ($P_1$) cannot be statistically estimated in a valid manner, IEC/TR 80002-1 and IEC 62304 assume $P_1 = 1.0$ and base software risk controls on the severity of harm and the clinical probability $P_2$.
How do you perform Software FMEA (sFMEA) and Fault Tree Analysis (FTA) for SaMD and clinical AI?
Teams use top-down Fault Tree Analysis (FTA) early in system design to decompose top-level clinical hazards into combinations of software, hardware, and user faults (checking for common-cause failures across `AND`/`OR` gates), and pair it with bottom-up Software FMEA (sFMEA) across every IEC 62304 software item and SOUP component to verify that module-level failures are caught by independent risk controls.
