The Decimal Point Nobody Checked: What ISO 14971 Requires and Why It Exists

In 2018, a patient in a hospital outside Chicago received a fatal insulin overdose. The pump was FDA-cleared. The hospital had protocols and trained staff. The device had been on the market for years without incident.

The investigation found that the dose-confirmation interface was ambiguous under certain lighting conditions. A decimal point was hard to read. A nurse confirmed a dose that was ten times the intended amount. The patient died.

Nobody set out to harm that patient. Every person in that chain was doing their job. The failure was upstream, at a design table, probably years earlier, where someone made a decision about interface contrast without asking the right question. Not because they didn't care. Because no process forced the question.

ISO 14971:2019 is the international standard that creates that process. It's the framework regulators expect you to have worked before your device reaches a patient. This is Module 1 of a 12-module course that builds a complete risk management file from scratch on a single running device: WearPump, a wearable subcutaneous insulin pump for Type 1 diabetes.

What ISO 14971 actually is

Most companies describe ISO 14971 as a compliance requirement. That framing is accurate, but it's also the reason risk management files end up as the most expensive PDFs in the building. They get written to pass an audit, not to catch a decimal point.

ISO 14971:2019 is the international standard for applying risk management principles to medical devices, published by the International Organization for Standardization. It's been mandatory-by-reference in the EU Medical Device Regulation and formally expected by the FDA since its first edition in 2000. In the United States, FDA expects manufacturers to have a risk management process consistent with ISO 14971 as a condition of market clearance or approval. In the EU, compliance is required under the MDR, not just encouraged.

The companies that get this right treat it as a design tool, not a compliance artifact. It forces a specific set of questions early, when design decisions are still cheap to change. Companies that work the process properly finish audits faster, catch problems earlier, and submit regulatory packages that hold up under scrutiny. Companies that treat it as paperwork tend to find out why that approach fails at the worst possible time.

How the standard is structured

ISO 14971:2019 has 10 clauses and three normative annexes.

Clause 1 defines scope. Everything counts: the physical device, the software, the accessories, the drug-device interface, the packaging. If it can contribute to a patient outcome, it's in scope.

Clause 3 is terms and definitions. This is where the standard becomes precise and where most people, having learned the words informally, discover they've been using them wrong.

Clause 4 sets up the risk management system: your policies, your responsibilities, your verification criteria.

Clauses 5 through 9 are the operational core: hazard identification, risk estimation, risk evaluation, risk control, and the review of overall residual risk.

Clause 10 adds production and post-production activities: vigilance, complaint handling, post-market surveillance. Risk management doesn't end at market clearance.

Everything you generate through this process, the analyses, the decisions, the evidence, goes into one document: the risk management file. That file is what an auditor reviews. It's also what you review when a patient complaint comes in and you need to know whether you anticipated that scenario.

The four definitions your auditor will test you on

Before Clause 4, before the file, before any analysis at all: four words. Get these wrong and every risk analysis that follows is built on a cracked foundation.

A hazard is a potential source of harm, not the harm itself. A sharp edge on a device enclosure is a hazard. The bacteria that can grow in a catheter hub is a hazard. Electrical energy in a powered device is a hazard.

A hazardous situation is the set of circumstances in which a person is exposed to a hazard. Not the hazard in the abstract, but the specific context where exposure becomes possible: a patient using the device in a bathroom while showering, a clinician who misidentifies a connector under low light, a child who accesses the device's cartridge compartment.

Harm is the actual physical injury or damage to health that results. Overdose. Infection. Electrocution. These are harms. They are outcomes, not scenarios.

Risk is the combination of the probability that a harm will occur and the severity of that harm if it does. ISO 14971 doesn't ask you to eliminate risk. It asks you to estimate it, control it, and evaluate what's left against a defined acceptability threshold.

These four words are not synonyms. An auditor will ask you to define them in that order, and to demonstrate that your risk analysis uses them in that order. The insulin pump case at the start of this piece shows what happens when they blur together: the hazard (ambiguous interface) was present; the hazardous situation (a nurse confirming a dose in a clinical setting) was predictable; the harm (fatal overdose) was documented in human-factors literature for similar devices. The question was never asked.

The regulator's view

Regulators work with incomplete information. They can't test your device in every use scenario, and they can't audit every design decision you made. What they can evaluate is your process.

Did you have a systematic method for identifying what could go wrong? Did you document your reasoning? Did you apply controls proportional to the risks you found? Did you revisit all of it when something changed?

When you can answer yes to those questions with evidence, submissions move faster. When a post-market complaint lands, your response is grounded in documented prior analysis rather than reconstructed memory. The companies that invest in this process don't do it only because regulators require it. They do it because it's the only systematic way to make design decisions before a patient does the testing for you.

What "in scope" means for your device

Clause 1 defines scope. The implication most teams miss: you can't scope out the parts of your device that are inconvenient to analyze.

For WearPump, scope covers three layers that interact with each other. The physical device includes the pump body, cannula, reservoir, insertion mechanism, skin adhesive, housing materials, and any component a patient or clinician touches. The software includes the dose calculation algorithm, the BLE stack connecting the device to the companion app, the app's UI logic, and the alarms and alerts. Software is a medical device under both FDA and EU MDR frameworks, and its failure modes are in scope. The drug-device interface is the third layer: WearPump delivers insulin, a high-alert medication where dosing precision is directly tied to patient outcome. The interaction between the delivery mechanism and the drug, including flow rate variability, occlusion detection, and the consequences of under- or over-delivery, is in scope.

You can't run a risk analysis only on the hardware. You can't exclude the software because it "runs on the phone." You can't hand the drug-device interaction to a different team and assume it isn't your risk to manage. Clause 1 won't let you.

Acceptable risk, not zero risk

There's a sentence in ISO 14971's introduction that most risk management training skips: the goal is not to eliminate risk. The goal is to reduce risk to an acceptable level.

No medical device is risk-free. Risk is not a failure of design; it's a property of intervening in biology. What ISO 14971 requires is that you think clearly about the trade. For every risk you identify, you weigh it against the clinical benefit the device provides.

For WearPump, the benefit case is strong. Type 1 diabetes requires continuous insulin delivery to survive, and WearPump provides more precise, more convenient delivery than multiple daily injections. The risks don't disappear because the benefit is high; they have to be estimated, controlled, and documented. But the benefit is real, and it counts.

Acceptable risk is risk that has been evaluated in the context of clinical benefit and found to be within the criteria you established before the analysis began. Not zero, not trivial, within criteria. That's the standard.

Building the risk file before you've found a single hazard

The first four entries in a risk management file have nothing to do with hazards. They exist before any hazard identification begins, because without them you have no framework for deciding what to do with the hazards when you find them.

The first entry is your intended use and intended users. For WearPump: continuous subcutaneous insulin infusion for Type 1 diabetics, ages 18 and older, self-administered. This definition determines the use scenarios you're obligated to analyze and the population whose physiological variability your device has to accommodate.

The second is your scope of risk management activities. What's in (hardware, software, drug-device interface) and what's out, explicitly stated, signed, and dated, not implied.

The third entry is the risk management team: names, roles, expertise. A team with no clinical representation can't credibly analyze clinical risks. A team with no software expertise can't analyze software failure modes. Team composition is a commitment that your analysis will actually have the coverage it claims.

The fourth entry is your risk acceptability criteria: the thresholds that define what you will accept as residual risk and what you won't. These have to be established before the hazard analysis begins. If you set them after, you've given yourself the option to move the goalposts to wherever your analysis lands. That's not risk management; it's reverse-engineering a pass.

The WearPump risk landscape

WearPump's full risk analysis will develop across all 12 modules. Three categories matter from the start.

Drug delivery risks are the highest-severity category. Overdose and underdose are the failure modes with the most direct path to patient death. The decimal point in the opening case belongs here, as do occlusion detection failures and software miscalculations around dose confirmation.

Software risks are substantial and consistently underestimated. The dose calculation algorithm, the BLE stack, the companion app: each has its own failure modes, from incorrect calculation to dropped connection to misleading UI state. Software failures in a drug delivery device show up regularly in FDA adverse event reports.

Human factors risks reflect the reality of who uses this device. WearPump users are managing a chronic condition, often tired, often under stress, often in imperfect environments. The device has to work for someone at 3am with crashing blood glucose, not an engineer in controlled test conditions. Human factors analysis is the process by which you find the decimal points before a patient does.

What's coming in Modules 2-12

Each module adds a layer to the WearPump risk file. Module 2 covers risk management planning. Module 3 covers intended use, intended users, and use scenarios. Module 4 is risk estimation: for each hazard you identify, you assign probability and severity. Module 5 covers risk evaluation against the acceptability criteria. Module 6 covers risk controls and the required hierarchy for applying them. Modules 7 and 8 cover residual risk and the overall residual risk review. Modules 9 through 12 close with production and post-production activities, the benefit-risk determination, and the complete file review.

By the end of the course, you'll have a complete risk management file built from first principles on a real device. The framework transfers to yours.

Action items for this week

Before Module 2, three specific things are worth doing now.

First, get ISO 14971:2019 and read Clause 1 and Clause 3. Not the whole standard, just those two clauses. Scope and definitions. Thirty minutes at most.

Second, draft your intended use statement for your device. One sentence: what the device does, for whom, in what context. Then ask whether your current risk analysis covers the full population and the full range of use environments that sentence implies.

Third, write down the names of five people who belong on your risk management team. Check whether the necessary roles are covered: clinical, engineering, software, regulatory, human factors. If one is missing, that's your first risk management action.

Before Module 2

Think about the device you're working on right now. What is the highest-consequence thing that could go wrong, not the most likely, but the most severe? Do you have a documented process for managing that risk? Is it in your risk file, or is it in your head?

If it's only in your head, that's what this course is for.

---

Dave Saunders works with medical device companies on regulatory strategy, risk management, and the specific decisions that determine whether a device reaches the market and performs as intended. More at baserealitygroup.com.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for hard-tech founders. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →