Your Intended Use Statement Is a Risk Control: ISO 14971 Risk Analysis, Part 1

# Your Intended Use Statement Is a Risk Control: ISO 14971 Risk Analysis, Part 1

In December 2014, a woman named Dana Lewis went to sleep wearing an insulin pump that was quietly making its own decisions about how much insulin to give her. Not because the manufacturer built it that way. She and a collaborator had reverse-engineered the pump, written their own software, and wired it to a glucose sensor, so that for the first time the system could adjust her insulin automatically through the night.

She wasn't waiting for industry to build it. That became the rallying cry: We Are Not Waiting. Lewis and Scott Leibrand open-sourced the project in early 2015 and called it OpenAPS, the open artificial pancreas system. People with Type 1 diabetes around the world started building their own. By mid-2016 there were around 100 people running these home-built systems. By 2020, more than 1,700. Today it's thousands, all trusting their overnight insulin to software no company sold them and no regulator approved.

To understand why they did it, you have to understand what they were escaping. Managing Type 1 diabetes by hand means being the algorithm: checking glucose, dosing, correcting, all day and, worse, all night, waking at 2 and 4 a.m. to keep blood sugar from drifting somewhere dangerous. What these people built themselves was a full night's sleep.

But every one of those systems ran on commercial pumps built for a patient in the loop, pressing the buttons. Handing dosing to an outside algorithm was completely outside the intended use the manufacturers had written down. The patients weren't breaking the pumps. They were using them in a way nobody who made them ever put on the label.

The FDA had to reckon with it. Its 2019 warning called the systems unauthorized and unreviewed, capable of the wrong insulin dose and real harm. The warning was reasonable, and it changed almost nothing. The systems worked well for the people using them, and commercial closed-loop pumps were still years behind.

I'm not telling this story to take a side on DIY looping. I'm telling it because it's the clearest example I know of a simple, uncomfortable truth: the real-world use of your device will not stay inside the intended use statement you wrote. People will use it in ways that are predictable, even if they aren't approved. If your risk analysis only considered the device used exactly as intended, your analysis has a hole in it the size of the looping community.

The three questions everyone skips

Before you can identify a single hazard, you have to answer three questions, precisely. What is this device actually for, and for whom? How will people predictably use it that you didn't intend? And what is it about the physical nature of the device, the energy in it, the materials, the way it touches a person, that could ever cause harm? Get those three wrong, and every hazard you find afterward is aimed at the wrong device. That's ISO 14971, Clause 5.

Most people skip all three. They're told to start the risk analysis, they open a failure-modes spreadsheet, and they start listing things that could go wrong. It feels productive, because the rows are filling up. But a failure mode of what, exactly? Used how, by whom, where? If you can't answer that, you're not analyzing your device. You're analyzing a vague idea of it, and the gaps in that idea become the hazards nobody catches.

Almost every course on medical device risk teaches exactly the opposite order. FMEA tutorials and risk-matrix explainers are everywhere; all of them assume the device and its use are already nailed down. They almost never are. The scoping step, the part that decides what you're even analyzing, gets treated as something you scribble in a header box and move past.

I'm Dave Saunders. I've spent more than 30 years commercializing technology, almost 20 of them in medical devices and regulatory affairs, including several surgical robots, a good part of it in audit rooms. The most expensive findings I've seen, the ones that send a company back to redo months of work, rarely come from a math error. They come from a hazard never identified, because the device's use and characteristics were never written down precisely enough to surface it.

Intended use is a risk control, not a description

Here's the claim people find hardest to believe: your intended use statement, that dry paragraph at the front of your documentation, is a risk control. Not a minor one. It's the cheapest and most powerful risk control you'll ever have, and you get to write it before you've spent a dollar on engineering.

Intended use, or intended purpose in European regulation, is the objective intent of the manufacturer about what the device is for, as shown in your specifications, instructions, labeling, and even your marketing. Your advertising is part of your intended use. Imply the device does something in a sales page, and you've just expanded your intended use, and with it, everything you're now responsible for analyzing.

Here's how a sentence becomes a safety device. The intended use statement draws a boundary around the hazard space you're responsible for. Everything inside it, every use you intend, you must analyze and control. Make that boundary narrow and specific, and you have a tractable problem. Make it broad and vague, and you've told an auditor, and a court, that you're responsible for analyzing everything inside that enormous boundary.

This is where people get it exactly backwards. They write the statement broad on purpose, to keep options open, to not limit the market. What that actually does is enroll them in analyzing, controlling, and defending every use their words now cover.

Two versions of the same claim make the difference concrete. Version one: "for the management of glucose-related conditions." Version two: "for the subcutaneous delivery of rapid-acting insulin for Type 1 diabetes, in patients six years and older." The first sounds bigger, and it's a trap: it puts Type 2 diabetes, gestational diabetes, and hospital glucose control all inside the fence. The second is smaller, sharper, and it's freedom, because everything it leaves out is a hazard analysis you don't have to do and a claim you don't have to defend.

I've sat in a review where a company's intended use statement said their device was for use "in the home and in clinical environments." Sounds harmless. But "clinical environments" meant they now had to consider operating rooms, with their electrosurgery and specific electrical safety requirements, and intensive care, with its tangle of other devices. They didn't mean to claim any of that. One vague phrase added months of analysis they never intended to take on.

One more consequence catches people off guard: intended use helps determine your device's regulatory classification, and with it, how hard your road to market is. Claim a use that puts you in a higher-risk class, and you've signed up for more clinical evidence, more scrutiny, more time. The statement isn't only a risk control. It's a business decision.

What goes into a real statement

A complete intended use statement answers a specific set of questions: the medical indication (what condition it diagnoses, treats, or monitors), the patient population (who it's for, including age and condition limits), the intended user (a trained clinician or a layperson at home), the environment of use, the part of the body it contacts and how, and the duration of that contact. Each element changes the hazards you have to consider. A device for trained clinicians can assume a level of competence a home-use device cannot. A device used for an hour has different risks than one worn for days.

WearPump's, written for real:

WearPump: Intended Use For the subcutaneous delivery of rapid-acting insulin, for the management of Type 1 diabetes, in patients aged six years and older, used by the patient or a trained caregiver, in home and everyday environments, applied to the skin and delivering through a subcutaneous cannula, for a wear period of up to 72 hours.

Every clause is a deliberate fence. Rapid-acting insulin, not any drug, so WearPump isn't on the hook for analyzing other infusions. Age six and older excludes the youngest children and the very different risks of dosing tiny bodies; reopening that market means reopening the analysis on purpose. Home and everyday environments means considering water and travel, but not the operating room. Each fence is a hazard chosen or explicitly left out.

Once that boundary exists, it does something else: it tells you where to look for misuse. Anything a person does outside the intended use is either reasonably foreseeable misuse, which must be analyzed, or genuinely unforeseeable misuse, documented as beyond scope. You can't sort uses into those two bins until you've drawn the line.

Misuse is predictable, not exotic

Reasonably foreseeable misuse isn't an edge case you check a box for and forget. It's the richest source of real-world hazards you have, and it's almost entirely predictable if you're honest about how people actually behave, not how you wish they would. Tired, rushed, optimistic, improvising, and occasionally building an artificial pancreas in a bedroom because they got tired of waiting.

The definition, from Clause 3.15: use of the device in a way not intended, resulting from readily predictable human behavior. The load-bearing word is reasonably. You're not required to anticipate every bizarre thing a human could conceivably do. You're required to anticipate what ordinary people, under real conditions, predictably will do, and the standard does require it.

Worth separating two things that get blurred: misuse is using the device in a way not intended; use error is trying to use it correctly and still getting a result nobody wanted, because the design let the user slip. Entering the wrong dose because the screen is confusing is a use error, not misuse. Both belong in the analysis; use errors also get dedicated treatment under the usability standard, IEC 62366.

Predictable misuse comes from a few familiar places: stretching a consumable to save hassle, skipping a step under time pressure, using a device on someone it wasn't meant for, working around an annoying limitation, or, like the looping community, extending a device past its purpose because it solves a real problem better than the approved option does. The moment a device has a wireless interface and an app, the question is unavoidable: what happens when someone connects something else to it? A third-party app, a home automation script. You may never approve it. But if it's predictable, and for a connected insulin pump it is, it belongs in the analysis.

Five foreseeable misuse scenarios for WearPump, none of them a device failure:

1. 1. A patient extends wear past 72 hours while traveling, accepting a degraded adhesive and higher infection risk.
2. 2. A caregiver gives a correction dose without checking current glucose first, stacking insulin on insulin.
3. 3. A parent lets a child swim past the splash rating.
4. 4. A patient pairs WearPump with an unofficial app or a DIY loop.
5. 5. A patient keeps using a single infusion set past its recommended life because changing it is inconvenient.

Every one is a human being behaving the way human beings predictably behave, and every one becomes an input to the hazard analysis.

The checklist almost nobody uses

The third input is the most overlooked, and the most useful: the physical and functional facts about the device that could, under some circumstance, matter for safety. Not the hazards yet, just the characteristics.

ISO 14971's companion guidance document, the technical report numbered 24971, has an annex that's essentially a checklist: roughly three dozen questions, each designed to surface a relevant characteristic. It's the closest thing the standard has to a hazard-finding machine, sitting in a document most engineers never open.

Brainstorming from memory only finds the hazards you already worry about; you'll never find the class you've never thought about, precisely because you've never thought about it. A structured list, written by people who've seen devices fail in every imaginable way, forces categories you'd have sailed right past.

The questions group into categories: energy (electrical, thermal, mechanical, radiated), materials and substances, biological and chemical, the patient, the user, the environment, data and connectivity, and end of life. Sample questions: Does the device deliver energy to the patient? Does it deliver substances? Are materials in contact with tissue? Is it susceptible to temperature, humidity, or electromagnetic fields? Is it controlled by software? Does it connect to other devices? Each yes isn't a hazard by itself. Each yes is a place to go look for one.

WearPump's inventory:

This is an inventory, not a hazard analysis. Confusing the two produces a worse version of both. The hazards come from the inventory, in the next module.

One characteristic, walked through

Take a single line: WearPump stores insulin under pressure. On its own, that's just a fact. Now ask the hazard question: under what circumstance could that stored pressure cause harm? If an occlusion builds and the pressure has nowhere to go, a sudden release could push an unintended bolus into the patient. A neutral characteristic, plus a circumstance, becomes a hazardous situation. That move repeats for every line in the table.

Why the order matters

Three inputs define the scoped problem the hazard analysis actually solves: the intended use statement (the boundary), the foreseeable misuse list (how people predictably step outside it), and the safety-characteristics table (what about the device could ever cause harm).

The order isn't arbitrary. Scope first, then identify, then estimate. The looping community is a hazard a manufacturer only catches by asking not just how the device is intended to be used, but how it will actually be used. Skip the scoping and jump to the FMEA, and the result is a rigorous analysis of a device that doesn't quite exist, while the real one gets used in ways nobody wrote down.

If there's one thing to take from this: intended use is a decision, not a description. Choose it, write it narrowly, defend every word. Then look honestly at how real people will step outside it, and inventory everything about the device that could ever matter for safety, using the checklist instead of memory. Do that, and the hazard analysis in the next module has something solid to stand on.

Module 5 runs a systematic hazard identification on this scoped foundation, using FMEA to trace forward from failures and fault tree analysis to trace backward from harms, turning these three inputs into WearPump's actual hazard table.

If this was useful, Module 5 is next. More on product strategy, roadmaps, and fractional CPO work at baserealitygroup.com, and the written version of this work goes out in a newsletter called The Build, at davesaunders.net.

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 →