Risk Management in Medical Software

Testing cannot prove that medical software is safe under every condition. The inputs are too varied, the state space too large, and the surrounding clinical system too changeable. Risk management uses a different strategy: identify how software could contribute to harm, reduce those pathways by design, verify the controls, validate the finished use, and keep monitoring after release.

ISO 14971:2019 supplies the device-wide risk-management process. IEC 62304 supplies a framework for medical-device software development and maintenance. They overlap, but neither replaces the other. Regulatory requirements, usability engineering, and clinical evaluation still apply. So do security, privacy, and quality-system obligations.

First decide what the software is meant to do#

Risk begins with intended use. A calculator that displays a clinician-entered value, a model that prioritizes emergency images, and an infusion controller may all contain software, but their possible harms differ. Identify the medical purpose, target condition, and patient population. Identify the intended user, environment, and hardware. Identify the interfaces and level of human review.

This step also affects whether a function meets a jurisdiction's device definition and how it is regulated. ISO 14971 and IEC 62304 do not themselves decide market classification. IMDRF's Software as a Medical Device framework instead considers the significance of the information to a healthcare decision and the seriousness of the healthcare situation, but national rules translate that concept differently.

Write foreseeable misuse as well as intended operation. Users may enter the wrong unit, act on a stale result, miss a warning, reuse a recommendation for another patient, or continue after a network failure. “User error” is not a stopping point. Design asks why the system permitted or failed to detect the error.

Build the chain from hazard to harm#

A hazard is a potential source of harm. A hazardous situation is a circumstance in which a person is subjected to that hazard. Harm is the resulting injury or damage to health.

For a dosing function, incorrect calculation is a software failure, not yet the full risk statement. One possible sequence is: an input unit is misinterpreted, the displayed dose is too high, the user does not recognize the mismatch, the dose is administered, and the patient experiences toxicity. You can put a control on any link in that chain.

A useful analysis records:

1. the hazard and foreseeable sequence of events;
2. the hazardous situation and affected person;
3. the possible harm and its severity;
4. the estimated risk under defined assumptions;
5. the acceptability decision;
6. each control and where it acts;
7. verification that the control was implemented;
8. validation or other evidence that it reduces risk in use;
9. residual risk and benefit-risk reasoning where needed.

Software failures are often systematic. The same latent defect can recur whenever a triggering state appears, and a reassuringly low observed defect rate does not entitle you to assume a near-zero probability while the triggering conditions are poorly understood.

Control risk by design before relying on warnings#

The usual hierarchy favors inherent safety, then protective measures, then information for safety. In software, inherent safety might constrain an input range, prevent an impossible state, remove an unnecessary function, or choose an architecture that isolates a critical component. Protective measures can include plausibility checks, alarms, and redundancy. They can include watchdogs, safe states, and required confirmation.

Labeling and training matter, but they are weaker when a design can prevent the failure. A warning that appears too often becomes background. A message displayed after an irreversible action is not an effective control. Human-factors testing should examine whether intended users notice, understand, and act correctly under realistic workload.

Each control becomes a requirement. Traceability should connect the hazard analysis to the requirement, design element, implementation, verification result, and residual-risk assessment, though a matrix is useful only for as long as you maintain its links through every change.

What IEC 62304 contributes#

IEC 62304 defines a common set of software life-cycle processes for medical-device software, whether software is the device or part of a larger device. The current IEC listing is the 2006 standard with Amendment 1:2015 incorporated, with a stability date through 2028.

The framework covers development planning, requirements, and architecture. It covers detailed design where applicable, implementation, and unit verification. It covers integration and integration testing, system testing, and release. It also covers maintenance, configuration management, and problem resolution.

IEC 62304 assigns software safety classes according to the possible injury if the software contributes to a hazardous situation: class A where no injury or damage to health is possible, class B where nonserious injury is possible, and class C where death or serious injury is possible. The applicable activities become more demanding as safety significance rises. That software class is not the same as FDA device class, EU MDR class, or IMDRF SaMD category, so name the scheme every time: “class B software” on its own does not tell your reader which of the four you mean.

Architecture should contain failure#

Architecture is a risk control when it separates critical from noncritical functions, defines interfaces, limits privilege, protects data integrity, and allows safe degradation; a safety kernel may validate commands from a more complex component. A local fallback may preserve essential operation when a cloud service is unavailable.

Segregation must be demonstrated, not asserted. Shared memory, common libraries, operating systems, networks, and update mechanisms can defeat nominal boundaries. Interface specifications should define units, ranges, and timing. They should define invalid states, authentication, and behavior when data are missing or late. Third-party or off-the-shelf software requires an inventory, version, and known-anomaly review. It requires vulnerability monitoring, license review, integration testing, and a maintenance plan. Calling a component “commercial” does not transfer accountability for the finished device.

Verification and validation answer different questions#

Verification asks whether each work product meets its specified requirements. Reviews, static analysis, and unit tests can contribute. So can integration tests, system tests, and boundary tests. So can fault injection and code coverage. The methods should match the safety class and risk.

Validation asks whether the finished device, in its intended environment and workflow, meets user needs and intended use, because a calculation can be mathematically correct yet unsafe because the display hides units, the alert arrives late, or the clinical claim lacks evidence.

Tests need expected results, versioned inputs, pass criteria, and anomaly disposition. A passing regression suite does not excuse unresolved anomalies whose clinical effect has not been assessed. Conversely, raw bug count is not a safety metric because severity and reach differ.

Cybersecurity is patient-safety risk#

The FDA's February 2026 cybersecurity guidance treats security across the total product life cycle. Authenticity, authorization, and availability can all affect safety. So can confidentiality, integrity, and secure update capability. Threat modeling should connect a security event to clinical harm rather than live in a separate spreadsheet.

Security controls include least privilege, authentication, and logging. They include secure defaults, cryptographic protection where appropriate, and vulnerability testing. They include coordinated disclosure, software-bill-of-materials processes, and timely patching. A patch also creates change risk, so it needs impact assessment, verification, controlled release, and rollback planning. Security is not limited to deliberate attack. Expired certificates, misconfigured networks, unavailable update servers, and unsupported dependencies can create the same unsafe state.

US quality-system context changed in 2026#

FDA's Quality Management System Regulation became effective on February 2, 2026. It incorporates ISO 13485:2016 by reference into 21 CFR Part 820, with additional US provisions. This change does not make ISO 14971 or IEC 62304 identical to law, nor does certification alone demonstrate compliance.

It does reinforce life-cycle quality records, design and development controls, and supplier controls. It reinforces complaints, corrective action, and management responsibility. FDA's 2023 device-software submission guidance describes documentation levels and recommended software evidence for premarket review. Submission documentation should be the output of a working process, not reconstructed after development.

Release starts the feedback loop#

Production and post-production information can reveal new hazards, changed frequency, or ineffective controls. It can reveal misuse, security vulnerabilities, or risk in a subgroup. Sources include complaints, adverse-event reports, and service records. They include support tickets, telemetry with proper governance, and literature. They include recalls and supplier notices.

Define thresholds and owners before launch. A signal can trigger investigation, corrective action, or labeling change. It can trigger user communication, software update, field action, or reassessment of benefit and risk. Verify that the response worked.

Every released version needs traceability to requirements, risk controls, and tests. It needs traceability to unresolved anomalies, build environment, third-party components, and distribution. Without version lineage, you cannot reliably reproduce a field event.

References#

1. ISO 14971:2019 official standard record
2. IEC 62304 official standard record
3. FDA device-software premarket submission guidance
4. FDA 2026 medical-device cybersecurity guidance
5. FDA Quality Management System Regulation
6. IMDRF Software as a Medical Device risk framework