The Hierarchy of Controls You Know Is the Wrong One for a Medical Device

# The Hierarchy of Controls You Know Is the Wrong One for a Medical Device

If you've ever seen a hierarchy of controls, there's a good chance you saw the wrong one. The version almost everybody knows, elimination, substitution, engineering controls, on down to protective equipment, was built to protect workers on a factory floor. It wasn't built for a medical device. And if you carry it over to your device, it quietly points you at the weakest control there is.

Here's the difference that matters. A workplace hierarchy is about protecting a person from a dangerous environment around them. You take the hazard out of the room, or you put the worker in a respirator. A medical device isn't the room. It's the thing touching the patient. So ISO 14971, the standard that governs it, hands you a different hierarchy, with three tiers, in a specific order you're not allowed to shuffle.

Those three tiers are inherently safe design, then protective measures, then information for safety. That last one, information for safety, is the polite name for a warning: a label, a line in the manual, a training class. It's the weakest thing on the list. Yet under a deadline, it's almost always the first thing a team reaches for, because it's the cheapest and the fastest. Hold onto that, because it turns out to be the whole game.

This is Module 8 of The Operator's Guide to ISO 14971. In the last module, every one of WearPump's eleven hazards got scored, plotted on the matrix, and given a verdict. The connectivity hazard came back red, unacceptable, blocked from shipping. The motor driver fault landed in the elevated band, because it can over-deliver insulin. A cluster of yellows each owed a real reduction effort. That list is a work order. Here, we work it.

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.

Why the order is fixed

Why three tiers, and why in an order you can't rearrange? Because the tiers aren't equally reliable, and the standard knows it. Read from the top down, the order is a ranking of how much you're trusting a human being to do the right thing. At the top, you trust no one. At the bottom, you're trusting a tired clinician at two in the morning to remember one line from a manual she read once.

I learned this on the other side of the medical world, in security. On connected devices and surgical robots, I watched team after team treat security as something you bolt on right before you ship. It never held. Security you design in at the architecture stage is cheap and solid; security you staple on after the design freezes is expensive, and it leaks. Safety works the same way. The protection you build into the design is the protection that holds.

Tier 1: inherently safe design

Inherently safe design means you remove the hazard, or shrink the risk, by changing the design itself. Not by warning about it. Not by alarming on it. By making the dangerous thing unable to happen, or unable to happen as badly. The risk that isn't there is the only one you never have to manage or explain to an auditor again. The standard calls this tier inherently safe design and manufacture, so it also covers how the thing is built, not just how it's drawn.

A control at this tier doesn't depend on anyone noticing anything, reading anything, or reacting in time. It just holds, silently, every second. There's no human in the loop to get tired, distracted, or overruled by a busy shift.

On WearPump, the worst hazard is the motor pushing too much insulin into the patient. The Tier 1 move isn't a warning that says watch for over-delivery. It's a hard limit, written into the firmware, that physically cannot command more than a set dose in a set window of time. The software can be told to hurt someone, and it refuses.

There's an even purer version. The reservoir holds 3 mL and not a drop more, because the housing geometry won't accept more. Even in a total runaway, the most the device can deliver is what fits in that chamber. You didn't write a procedure against overdose; you made a large overdose mechanically impossible. The tubing connectors are keyed too, so a half-asleep user can't cross-connect them: the parts refuse to mate the wrong way. Same principle every time. Take the human decision out, and pour the safety into the shape of the thing.

Tier 1 is also the hardest and most expensive to reach, especially late. Three weeks from a launch you've already announced, "change the design" is a brutal sentence to hear, which is exactly why teams talk themselves out of it and drift toward the cheap stuff. The standard is built to stop that drift. So the first question on every hazard is the same: can I design this out?

Tier 2: protective measures

When you genuinely can't design the hazard away, you add something that actively guards against it. The word that matters is active. A protective measure does something. It detects, blocks, stops, or forces an extra step. It isn't a note hoping you'll behave. It's a mechanism that intervenes whether you're paying attention or not.

On WearPump, the cleanest example is the occlusion alarm. If the line blocks and pressure climbs, the device doesn't just beep and hope. It sounds, and it stops the pump automatically. The alarm informs the human, but the automatic stop is the real protection, because it acts even when there's no human to hear it. That pairing, detect and then act, is what makes it Tier 2 and not Tier 3. Others are layered through the device: an air-in-line detector that catches a bubble before it reaches the patient, a two-step confirmation before any large bolus so one accidental tap can't dump a dose.

But protective measures sit a step below design for a reason. They can fail. An alarm needs power, a working sensor, a speaker, and a person within earshot. A confirmation step can be worn down by a user who taps through it out of habit. The protection is real, but it has moving parts and a human somewhere in the chain.

Tier 3: information for safety

Tier 3 is labels, the instructions for use, warnings, and training. It's the last resort, and the standard is blunt about that. On WearPump it looks like a line in the instructions that says don't wear the device longer than three days without a clinician check. It looks like a low-battery alert well before the battery dies, and a training session for the nurse setting it up the first time. All of it is information, handed to a person, in the hope they read it, remember it, and act on it.

That hope is exactly why it's the weakest tier. Every other tier does the work for you. Information for safety asks the human to do the work, under stress, in the moment. A warning is only ever as strong as that clinician's worst night, and you don't get to pick her night.

To be fair to Tier 3, good labeling saves people. The problem is never that warnings are useless. It's treating a warning as the fix when it's really just the floor, the thing you're left with after the real work. And this is the pull that makes it go wrong: a design change is expensive and slow, an alarm is a project of its own, but a warning label is a sentence you can write this afternoon and close before the meeting is over. So when the schedule is tight, and it's always tight, gravity drags every team to the bottom.

The rule nobody honors

You don't get to skip to a warning label if a design change was reasonably practicable.

Read it slowly, because that one sentence is the entire point. If you could have designed the hazard out, or guarded it with a real protective measure, and it was practicable to do so, then a warning is not an acceptable answer. You work top down, and you have to be able to show why you stopped where you stopped.

Two things follow, and teams get both wrong. First, the order is mandatory: Tier 1 before Tier 2 before Tier 3, on every hazard. Second, and this is the one people miss in the other direction, you're allowed to combine tiers. For a serious hazard you should. What you can't do is leapfrog up the cheap way and pretend the higher tiers weren't available.

This is what a good auditor hunts for. They'll find a warning in your file and ask one quiet, devastating question: did you consider designing this out first? Show me. A real analysis, with options weighed and rejected for documented reasons, is fine. A shrug means that warning just became the most expensive sentence in your submission. The files pulled apart in a courtroom years later are full of warnings added exactly where a design change was the honest answer, and nobody wanted to pay for it that quarter.

The line worth keeping: real risk control is a design problem before it's a labeling problem. The best control is the hazard you engineered out of existence. The worst is a warning you reached for because it was Tuesday and the release was Friday.

Working WearPump, tier by tier

Start with the ugliest hazard, the motor driver fault that can over-deliver insulin. Severity as high as it goes. So we don't pick a control, we stack everything practicable. Tier 1 first: the firmware dose ceiling and the 3 mL reservoir cap, neither of which depends on anyone noticing anything. Then Tier 2 on top: an occlusion sensor and an independent watchdog circuit that can stop the motor if the main processor misbehaves. Then, and only then, Tier 3: a clear note in the instructions on what a fault alert means. Design, then guard, then inform. We didn't choose between the tiers, we layered them, so each one catches the failure of the layer above it. That's defense in depth, and it starts at the top.

Now the red one, connectivity. The tempting fix is pure Tier 2: encrypt the link, add authentication, done. That's real, and we keep it. But stop there and you've missed the Tier 1 question: why does a safety function depend on the phone at all? Ask it honestly and the design changes. The pump has to be safe completely on its own, running its own alarms and enforcing its own limits with the phone switched off. The app becomes a convenience, not a safety control. Two teams can ship the exact same encryption. The one that also made the pump safe standalone has a defensible file; the one that leaned on encryption as the whole answer left a serious hazard resting on a wireless link, and an auditor will find it.

The yellows go faster once you see the pattern. The skin reaction at the adhesive site: switching to a silicone adhesive was a Tier 1 move, a design change, with an app reminder to rotate the site as a Tier 3 touch behind it. But one yellow hides a trap, and it's the doorway to the part everyone skips.

Every control can create a new risk

This is what separates a mature risk file from a naive one: every control you add can create a brand-new hazard of its own. A safety feature is never free. ISO 14971 has a clause for this, 7.5, and it's the one I see skipped most. Every control you introduce must be reviewed for the new hazards it brings with it. You don't get to add a control, tick the box, and walk away. You turn around and ask: what did that fix just break?

Take the silenced-alarm hazard. Your instinct is to add more alarm: louder, harder to silence, a backup alert. All reasonable. All Tier 2. And every one of them can make your device more dangerous, not less. Picture where the device actually lives, a busy ward or a home with a dozen other devices all beeping. Make your alarm more aggressive, multiply it across every device in the room, and what you get isn't safety. It's noise. And there's a name for what that noise does to people.

It's called alarm fatigue, and it isn't a theory. The Joint Commission, which accredits hospitals across the United States, reviewed alarm-related events over a three-and-a-half-year window. There were 98 of them. 80 ended in a patient death, not from the original problem, but from the alarm that was supposed to catch it, and got tuned out. The reason is almost mathematical: on a single hospital unit, devices can throw off hundreds of alarm signals a day, and the Joint Commission estimated that 85% to 99% of them need no action at all. So people do the only rational thing they can when nearly every alarm is a false one. They stop trusting the alarms. They turn them down, silence them, and eventually stop hearing them.

So the occlusion alarm you added as a Tier 2 control, the good one, is also a contribution to that wall of noise. Push it too hard and your safety feature becomes one more alarm a clinician learns to ignore. The control didn't just have a side effect. Under the wrong conditions, the control became the hazard.

And the answer to alarm fatigue isn't another warning telling nurses to take the alarms seriously. That's Tier 3 answering a problem Tier 3 created. The real answer is to design the alarm to fire only when it truly matters, so it stays credible. That's a Tier 1 move on your Tier 2 control. You go back up the hierarchy. There's no free move here. Mature risk management isn't a hunt for controls to pile on. It's a running argument about whether each control truly makes the patient safer, all things counted.

Existence is not effectiveness

You've chosen your controls and checked them for new risks. You're not done. A control on a slide is not a control on a patient. Clause 7.2 gives you not one obligation but three, and they aren't the same: implement the control, verify you implemented it, and verify it's effective.

The first is obvious: you decided on a firmware dose ceiling, so somebody writes that firmware. The next two get skipped. Verifying implementation means confirming the control actually reached the finished device, not just the plan. I've seen a dose limit that lived proudly in the requirements document and was never written into the shipped firmware, because everyone assumed someone else had done it. On paper the hazard was controlled; on the bench the pump would happily over-deliver.

Verifying effectiveness is the one with teeth. Not a document check: a bench test, a usability study, a validation with real users, proof the control genuinely reduces the risk the way you claimed. Go back to the alarm. On the bench you can verify it fires, every time. Implementation confirmed. But is it effective? Put it in a real ward with real background noise and watch whether a real nurse notices it and acts in time. That's a different test, and plenty of alarms pass the first and fail the second.

Existence is not effectiveness. A control that's present but doesn't work isn't a safety feature. It's a comforting story you tell yourself, right up until the day it matters. All of it goes in the file: what you implemented, the evidence it reached the device, the evidence it works.

The completeness check, and what's left

One last step, and skipping it is how good teams still get hurt. Clause 7.6 is the completeness check: go back through every hazardous situation you ever identified and confirm each one has been addressed. Not most. Every one. It's a deliberately boring sweep, and it exists to catch the hazard that fell through the cracks between two busy engineers. Because the hazard that hurts someone is almost never the one you fought hardest over. It's the one nobody remembered to control.

Put WearPump back on the matrix. The motor driver fault, once elevated, now sits behind a stack of controls, and its residual risk has dropped into a band we can live with. The connectivity hazard, once red and blocking, has moved off red, not because we encrypted it, but because the pump no longer needs the phone to keep the patient safe. The adhesive reaction is softened by the silicone. But not everything landed on green. Some hazards still carry a residual risk, smaller than before, real reduction behind it, but not zero. That leftover isn't a failure. It's the true output of risk control, and pretending it away is how files become fiction.

That residual, the risk that remains after you've done everything the hierarchy asks, isn't the end of the story. It's the beginning of the next one, where you decide whether the total risk left across the whole device is acceptable given everything the device does for the patient. That's overall residual risk, and it's the next module.

The takeaway

For every hazard on that grid, the file now tells a clean, defensible story: here was the hazard, here's how we tried to design it out, here's how we guarded what we couldn't remove, here's the warning we were left with, and here's our proof it works. That story is what risk control really is. Everything else is paperwork pretending to be safety.

Hold onto the order. Design it out. Then guard it. Then, and only then, warn about it. Reach for the warning first and you haven't controlled the risk, you've just documented that you noticed it. The hierarchy isn't bureaucracy. It's the difference between a device that's safe and a device that merely has a thick binder claiming it is.

More on product strategy, roadmaps, and fractional CPO work at baserealitygroup.com. I also write more broadly for founders 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 →