The Risk File Doesn't Close When You Ship (ISO 14971 Clause 10)

# The Risk File Doesn't Close When You Ship (ISO 14971 Clause 10)

Your pump launched four months ago. Sales are good, nobody is panicking, the first big safety report is still months away. Then the monthly complaint count lands on someone's desk. Twelve occlusion reports. Not across the life of the product. In a single month.

So here is the question that whole month now turns on. Is that a problem? Your pre-market file said occlusion was rare, and acceptable. Your notified body agreed. But twelve in thirty days is a number your file never saw. You have a signal. What you do not have yet is a verdict.

The distance between those two words is where this whole module lives. A signal is just a number that looks wrong. A verdict is what you get after you have found the denominator, chased the root cause, and asked honestly whether the risk you accepted before launch is still the risk you actually have. The dangerous gap is the time between the signal arriving and someone connecting it to the risk file. That gap is where devices hurt people, and closing it is the entire job of the last clause in the standard.

This is Module 12 of The Operator's Guide to ISO 14971, the finale. I'm Dave Saunders. I've spent more than 30 years commercializing technology, almost 20 of them in medical devices and regulatory work, including several surgical robots. Across this series we've built the WearPump risk file from an empty page: eleven hazardous situations, each identified, estimated, controlled, and closed. We judged the whole device acceptable against injection therapy, wrote the report, got it signed, and shipped. By every pre-market measure, the risk work is done. And that is exactly the moment the standard says you are most at risk of stopping too early, because the device just met its first real patients, and they are about to teach you things no analysis ever could.

What Clause 10 actually asks for

Clause 10 is titled production and post-production activities, and you could read that title and assume it is about manufacturing quality. It is not, or not only. The core of it is three verbs. You establish a system to collect information generated after the device is released, about your device and about similar ones. You review that information against your risk estimates. And when it changes the picture, you feed it back into the risk process. Collect, review, feed back. The clause wants all three.

I want to be blunt about the failure here, because it is everywhere. You cannot satisfy Clause 10 by saying you have a complaint system. A complaint system that collects reports and files them is one third of the requirement, and it is the easy third. You also need a review step that measures those reports against the numbers in your risk file, and a feedback path that actually changes the file when the numbers move. Collect without review is a filing cabinet. Review without feedback is a report nobody acts on. The clause requires the whole loop, closed.

Surveillance is the input, not the judgment

Post-market surveillance is not the same thing as risk management. Surveillance is the stream of real-world information coming in the door. Risk management is what you do with it: the analysis, the judgment, the decision to act.

That distinction clears up a lot of confusion. Your surveillance system feeds your risk process. Teams that treat the two as one thing, or worse, hand surveillance to a quality group that never talks to the risk team, end up with a pile of data and a risk file that never learns from it.

One piece of the incoming stream is a legal line, not a judgment call. Some of what comes in the door is not just risk data, it is a reportable event: a death, a serious injury, a malfunction that could cause one if it recurred. When one of those lands, a clock starts, and the regulator has to be told on a defined timeline whether or not you have finished investigating. In the United States that duty lives in the medical device reporting rule. In Europe it is the vigilance system. Your surveillance has to catch those the instant they arrive and route them two ways at once, to the regulator and into the risk file.

The five sources, and why the mix is the point

So what do you collect for a device like the WearPump? Five sources, and each one sees something the others miss.

1. 1. Complaints and adverse-event reports. Every complaint that arrives, by phone, email, or through the app support channel, gets captured in a controlled system, and some events trigger mandatory reporting by law. The shift in thinking is this: a complaint about occlusion is not a customer-service ticket. It is a data point about the probability of a hazardous situation you already estimated on paper, before launch. It is the real world checking your math.
2. 2. The companion app. The WearPump talks to a phone, and that phone is a surveillance instrument. Every logged connection failure, unexpected alarm, or dosing exception is data, and with the right consent and privacy controls, it gives you a population-level signal far earlier than complaints can. A patient with a Bluetooth dropout usually does not file anything. But the app knows it happened, and if it is happening to thousands of patients, the app can tell you before anyone picks up the phone.
3. 3. Field service and returns. When a unit comes back, why did it come back, and when a technician opens it, what do they actually find? Returned devices are physical evidence, and root-cause work on them can confirm or flatly contradict what the complaint descriptions say. A patient tells you the device failed; the returned unit tells you whether it failed the way they thought or a different way entirely.
4. 4. Published literature and similar devices. Competitors' incident databases, adverse events reported against pumps like yours, peer-reviewed papers on wearable insulin delivery. The technical report that accompanies the standard is explicit that similar devices are in scope. If another wearable pump is seeing unexpected occlusion rates, that is relevant to your file, because your patients live in the same physical world theirs do.
5. 5. Structured user feedback. Surveys, calls logged by your clinical support team, reports from the doctors and nurses who prescribe the device. This is where usability problems surface first: the application technique that is harder than you thought, the training gap, the placement mistake people keep making. Those show up in feedback long before they escalate into complaints or harm.

The point of five sources is not five separate reports gathering dust. It is triangulation. A complaint says the device failed. The returned unit tells you how. The app telemetry tells you how often, across the whole population. The literature tells you whether the rest of the field is seeing the same thing. The user feedback tells you whether it is really a training gap wearing a hardware costume. No single source is trustworthy on its own. It is where they agree, and disagree, that the real signal lives.

Cadence, and the trigger

A surveillance system without a rhythm is a pile of data with good intentions. So you give it one. Weekly, someone runs a simple count of complaints by category, and those categories map straight to the hazards in your file: occlusion, adhesion failure, connection loss. That is your early-warning read, no analysis, just the count. Monthly, you move from raw counts to rates, complaints per use, because a count with no denominator is meaningless. Quarterly, you run a full review across all five sources. Once a year, you write the formal safety summary.

And then the one thing that turns all that watching into action: a trigger, defined as a number, not a feeling. Not "if the rate seems high." Not "if the team feels concerned." A specific number, written down before you ever need it. For the WearPump, say it plainly: if the observed rate for any hazard exceeds twice its pre-market estimate for two consecutive monitoring periods, escalation is mandatory. The instant that condition is met, you stop the routine monthly trending and convene a real risk review. The reason it has to be a number on paper is simple. When someone new is watching the dashboard at the end of a long week, the trigger cannot live in one experienced person's gut. It has to be on the wall.

The signal: twelve occlusions

Come back to those twelve occlusions, because we now have exactly that situation, and we are going to work it all the way through.

First question the team asks, before anyone panics: what is the denominator? Twelve complaints out of how much use? You pull the distribution data. Say there are around five hundred WearPumps active in the field. Each patient runs a fresh wear cycle every three days, so in a thirty-day month that is roughly ten uses per patient, and five hundred patients gives you about five thousand uses that month. Twelve events against five thousand uses is a rate of about one in four hundred, call it two to three events per thousand uses.

The denominator is where teams quietly go wrong, because it is harder than the count. How many devices are actually on patients right now, not sitting in a warehouse? How many wear cycles did each of them really run this month? Someone who started three weeks ago has fewer uses than someone who started at launch. Get the denominator too small, and a manageable rate looks like a crisis. Get it too big, and a real crisis hides in the noise. The number twelve is the easy part. The five thousand underneath it is the part that takes real work to trust.

Now compare that to what your file predicted. Before launch, you estimated the occlusion pathway, the same one you first mapped in the fault tree back in Module 5, as remote. On your scale, remote meant fewer than one harmful event in ten thousand uses. Your observed rate is roughly one in four hundred. That is more than twenty times higher than you estimated, and it is not the first month either. Month three was already running elevated. Two consecutive periods above the line. The trigger is not close. It is blown.

Before the review starts, the team sorts the twelve by what actually happened to the patient. Most caught it, saw their glucose climbing, changed the site, and corrected before it got dangerous. A few swapped the device out with no real harm. But one patient ended up hospitalized with diabetic ketoacidosis, a serious adverse event, and that one is already moving through mandatory reporting. So the picture is twelve events, one serious injury, a rate more than twenty times the estimate, two months running. That one hospitalization also starts a second clock. Telling the regulator, on their timeline, that a serious injury happened is a compliance duty. Figuring out whether your risk estimate was wrong is a risk-management duty. The same twelve complaints trigger both, and a mature system runs them side by side instead of letting the investigation hold up the report.

The afternoon the pattern fell out

Twelve tells you the frequency. It does not tell you the mechanism, and you cannot fix a mechanism you have not found. So your quality engineer pulls all twelve records and builds a simple matrix: wear duration at the time of the event, cannula lot number, whether the patient had in-person training. Within an afternoon, a pattern falls out. Every one of the twelve happened after forty-eight hours of wear. Nine of the twelve share a single cannula lot, one where the tubing wall sat on the thin end of the tolerance. And several of the patients had no hands-on training, just the written instructions in the box.

Pull that cannula thread, because it is instructive. The suspect lot was not out of specification. The tubing wall was inside the tolerance you set, just sitting at the thin end of it. Which means the problem is not a broken part. It is a specification drawn a little too loose for how the device is actually used, late in a wear cycle, under real body movement. That is a harder finding, and a more honest one, because it sends you back not just to the supplier but to your own drawing, to ask whether the tolerance itself was wrong.

Now map that to the risk file, and notice what it is and what it is not. This is not a new hazard. You are not discovering something you never imagined. It is the occlusion pathway you already had, the one that fed the fault tree, now telling you that your pre-market probability estimate was optimistic. The real world runs occlusions more often than your bench analysis assumed, especially late in the wear cycle, with a marginal cannula lot, in the hands of an untrained user. The hazard was right. The number was wrong.

The updated estimate, and the acceptance you reopen

The observed rate pushes the occlusion probability up a full band, from remote to occasional. Severity does not move: the harm is still under-delivery driving blood sugar up, serious, dangerous if it runs to ketoacidosis, exactly as you scored it. So the risk moves, driven by probability, and you write it down properly. Old estimate, new estimate, the real-world data that drove the change, the date, and a signature. You do not quietly edit a number. You record a change.

And you do not treat one month as the whole story. You plot the rate across months. Month three ran a little hot. Month four crossed the line. That climbing trend is more convincing than any single data point, because it rules out a one-off bad week. When you take this to a regulator, or to your own management, the story is not twelve complaints in isolation. It is a rate that was already rising, that you caught on the second period and acted on before it climbed a third. That is a system working, and it is a very different story to tell than one alarming number.

That new number does two things immediately. First, the acceptance you granted this risk before launch was based on the old probability, so that acceptance is no longer valid, and its rationale has to be reopened and re-examined. You cannot lean on a judgment built from a number you now know was wrong. Second, you have to ask whether more risk reduction is now reasonably practicable. And the root cause has already answered that: a cannula lot problem, a wear-time pattern, a training gap. Those are not theoretical. They are things you can act on this month.

The decision, and the time-bound call

Three options land on the table. One, hold the suspect cannula lot and open a formal investigation with the supplier. Two, make hands-on training mandatory before any patient gets a device, in person or a verified remote session, no exceptions. Three, cut the labeled wear time from seventy-two hours down to forty-eight, since every single event happened past the forty-eight-hour mark. The first two are cheap, fast, and clearly worth doing, so you commit to both inside sixty days.

The third one is harder, and you do not decide it today. Dropping to forty-eight hours would directly address the timing, but it also takes something real from the patient. That extra day of convenience is part of why the pump beats injections in the first place. So you make a time-bound call instead: implement the lot hold and the training now, watch the occlusion rate over the next ninety days, and if fixing the lot and the training brings it back down, you may not need the labeling change at all.

That is benefit-risk analysis in the post-market world, and it is the whole course coming back around. You weighed a residual risk, the occlusions, against a benefit to the patient, that extra day of wear, and made a call you could defend, with a date to revisit it. It is the exact logic from Module 9, except now the numbers are real, measured in the field, instead of estimated at a desk. The process does not change when the device ships. The evidence just gets better, and the stakes get more concrete.

Closing the loop, the step teams skip

Here is where teams lose the thread: documenting the loop closure. The analysis means nothing if it does not land back in the file. So the occlusion entry gets its revised estimate, dated, referencing the surveillance report that drove it. The two new controls get their own records, the lot hold and the training requirement, each with an owner and a verification method. The surveillance review itself gets filed as a dated, signed record. The corrective action in your quality system gets cross-linked to the risk file, and the risk file gets cross-linked back. And a ninety-day date goes on the calendar to check whether any of it worked.

That cross-link is not bureaucratic decoration. Picture the auditor a year from now, opening the occlusion entry. If they see the old estimate, the original acceptance, and nothing else, they ask the obvious question: you had a serious adverse event and a complaint spike, where is that in the risk file? If your answer is "it is over in the corrective-action system," the follow-up is "and the two are supposed to be linked, so where is the link?" The link is what proves you did not just handle the complaint, you let it change your understanding of the device. Miss it, and a good response looks like a cover-up.

All of this rolls up, once a year, into a single formal summary. In Europe it is called a periodic safety update report, and for a device like this one it is a requirement, not a courtesy. It gathers everything the year taught you, the complaint rates, the signals, the changes you made, like our occlusion revision, and it states in writing whether the benefit-risk balance you certified at launch still holds. It is the living file, compressed into one document a regulator reads to decide whether they still trust your device on the market.

The living file

That is really the whole idea of Clause 10: the living risk file. A file last touched on the day the device was approved is a file that stopped learning the moment the device met a patient, and that is the worst possible time to stop. So every surveillance review ends one of two ways, an update or a documented finding of no change required, and both get recorded. Even a quiet month where nothing crossed a threshold gets written down, because the absence of a signal is itself evidence that your system is running and watching.

When an update does happen, it does not erase what came before. The file is additive. The new version contains the old one, and the revision history shows every change, every date, every author, every reason. So when that auditor reads the current version, they can trace the entire path, from your pre-market estimate, to the real-world signal, to how fast you acted, to what you decided and why. That traceability is not just a requirement. It is your proof, in writing, that you were paying attention the whole time.

Think about how a regulator opens your file after something has gone badly wrong in the field. They are not asking whether the device was designed well, they already know something failed. They are asking four things. Did you know this was possible? Did you estimate it honestly? Did you control it? Did you respond when the data warned you? A living file, with a dated trail from estimate to signal to action, answers all four. A file frozen on launch day answers none of them, and that silence is its own kind of answer.

There is also a reason to do this well that has nothing to do with fear of an auditor. The team that catches its own occlusion signal in month four and acts has better real-world data by month twelve than any pre-market study could have handed them. They ship a better cannula next year, because the field told them exactly where to look. The team that waits to be told, by a regulator or a lawyer, learns the same lesson years later, at ten times the cost. Surveillance is not a tax on a finished product. It is the fastest, truest feedback you will ever get on how your device really behaves.

The complete file, and one honest admission

So here it is, one last time: the complete WearPump risk file, the thing we have been building brick by brick since Module 2. Four original hazards from the first pass. Four more from the failure-mode analysis. Three from the fault trees. Eleven in all, each estimated, each controlled through the hierarchy, each residual either accepted outright or carried on a benefit-risk argument. The whole device judged acceptable against injections. The report written and signed. And now one entry freshly reopened by twelve occlusions in the real world. That is not a finished document. It is a living one.

I want to be straight with you about something, now that the whole file is in front of us. If you have been taking careful notes across these twelve modules, you may have caught a place or two where we described a hazard a little differently from one module to the next, or sharpened a number as our thinking got clearer. That is not a slip I am hoping you missed. That is the process, running in front of you. Our understanding of the silenced-alarm situation got sharper the second time we looked at it. That is exactly what a living file does.

When you find one of those discrepancies in your own file, you make a real decision about it, and this is a genuinely useful distinction to carry. Was it just how you described the thing, a loose wording, a stale reference? Then you correct the record under document control and move on. Or was it a real gap in the analysis, a risk you underestimated, a control that was not doing what you claimed? Then it is not an edit. It is a finding, and it goes through the improvement cycle, the same corrective-action loop we just ran on the occlusion signal. Knowing which of the two you are looking at is a real skill, and now you have it.

So the honest answer to "when is a risk file done" is that it is not, not as long as the device is on the market. It closes for a design freeze and opens again for a change. It absorbs a field signal, revises, and re-closes. It is a document that breathes for the entire life of the product, and the day it stops breathing is the day you have stopped listening to the people wearing your device.

Your turn

So here is the question I want to leave you holding. If your device, the real one you are working on right now, received twelve complaints of the same failure mode in a single month, how long would it take your team to know? Not to hear about one of them, but to know that all twelve had arrived, that they shared a pattern, and that the pattern needed to reach someone who could hold it up against the estimate in the risk file. Less than a week? A few weeks? Or are you genuinely not sure? Your answer tells you exactly where your surveillance system needs the most work.

And that is the series. You have done something here that most people in this field, even experienced ones, have never actually done. You built a complete risk management file, from an empty page to a living document, on one real device, following every clause of the standard in order. You know why the process exists, how to run it, and how to keep it alive after launch. That is not a small thing to carry into your next project, and the patients on the other end of that work are the reason it matters.

---

If this series has been useful to you, I write more of this thinking in my newsletter, The Build, at davesaunders.net, and the rest of my work is at baserealitygroup.com. Subscribe there so the next series finds you when it starts. Now go keep that risk file alive.

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 →