How Medical Software Manages Risk: ISO 14971 and IEC 62304 in Plain Terms

The short answer

Medical software is made safe less by any single clever test and more by a disciplined process that anticipates harm before it happens. Two international standards carry most of that weight. ISO 14971 is the standard for risk management: a structured way to ask what could go wrong, how badly, and how likely, and then to reduce those risks and check that the reduction worked. IEC 62304 is the standard for the software lifecycle: it sorts software by how much harm a failure could cause and then requires a matching level of engineering rigor. This is an educational explainer of how the two fit together, drawn from my work in medical device regulation. It is not legal or regulatory advice, and any real project should confirm the current requirements against the standards themselves.

Two standards that do two different jobs

People often blur these together, which makes both harder to understand. They answer separate questions.

ISO 14971 is about thinking clearly about harm to patients, users, and bystanders, across the whole life of a device. It does not care whether the device is a scalpel, an infusion pump, or a piece of software. IEC 62304 is narrower and deeper. It governs how the software itself is planned, built, tested, and maintained. The two interlock: IEC 62304 hands its safety-related decisions to the risk-management process defined by ISO 14971, and the risk process feeds requirements back into the software work. One asks what could hurt someone; the other asks how to build the code so it does not.

ISO 14971: thinking clearly about harm

What a risk actually is

The standard defines risk as the combination of the probability that a harm occurs and the severity of that harm. That pairing matters. A rare event with catastrophic consequences and a frequent event with trivial consequences can demand very different responses, and collapsing them into a single word hides the difference. Naming the two parts separately is what lets a team reason instead of guess.

The loop, step by step

Risk management under ISO 14971 runs as a loop, not a one-time gate. It begins with risk analysis: listing the hazards, tracing the chains of events that could turn a hazard into a hazardous situation, and estimating the resulting risk. Next comes risk evaluation, deciding which risks need to be reduced. Then risk control, where the team designs in protections, in a clear order of preference: make the design inherently safe first, add protective measures second, and rely on warnings or instructions only as a last resort. After each control, the team verifies that it was implemented and that it actually works.

What remains after all of that is residual risk, and the standard insists you look at it honestly, both risk by risk and as a whole. A device can pass every individual check and still carry too much combined risk, so the overall residual risk gets its own judgment. Where a meaningful risk remains, it is weighed against the clinical benefit the device provides. The reasoning is written down in a risk management file, and the work does not stop at release. Information from production and from real use flows back in, and the loop runs again when something changes.

IEC 62304: building the software with discipline

Safety classes set the bar

IEC 62304 begins by asking a blunt question: if this software failed in the worst plausible way, how badly could a person be hurt? The answer sets a safety class. Class A covers software where no injury is possible. Class B covers software where non-serious injury is possible. Class C covers software where death or serious injury is possible. The higher the class, the more the standard expects in documentation, design detail, and testing. A tool that only displays reference text sits far from a tool that helps titrate a therapy, and the standard treats them differently on purpose.

The lifecycle

For the work itself, IEC 62304 lays out a lifecycle: plan the development, define software requirements, design the architecture and then the detailed design, implement and verify the units, integrate and test, and run system testing before release. Around that spine sit processes that are easy to underrate. Configuration management keeps track of exactly which versions of which parts make up a release. Problem resolution gives defects a controlled path from report to fix. Maintenance applies the same rigor to changes after launch, because a small patch to safety-critical software is still a change to safety-critical software.

The parts you did not write

Most real software includes components the team did not build, from libraries to legacy modules. The standard calls these SOUP, software of unknown provenance, and it refuses to let them be a blind spot. A team has to understand what a SOUP component does, what could go wrong with it, and how that feeds the risk picture. Borrowed code is not exempt from the duty of care.

Why process, not just testing

Testing is necessary and it is not sufficient. A famous observation in software is that testing can reveal the presence of faults but never prove their absence. Disciplined process is how a team compensates. When a hazard is traced to a specific requirement, and that requirement is traced to a specific design element and a specific test, a reviewer can follow the whole chain and see that the risk was actually addressed rather than assumed away. That traceability, unglamorous as it sounds, is much of what separates software a clinician can rely on from software that merely demoed well.

How this connects to the rest of the rulebook

These standards are the quiet backbone under the more visible frameworks. Medical device rules in Europe and the review expectations in the United States lean on risk management and a controlled software lifecycle. Newer rules for artificial intelligence echo the same idea, asking for continuous risk management across a system's life rather than a single approval moment. Learn ISO 14971 and IEC 62304 well and much of the rest of the regulatory landscape reads as variations on a theme you already understand: name the harm, reduce it by design, prove you did, and keep watching after launch.