Guest Published Article
Mitra Soltani, an electrical engineer in MedTech, has spent the last fifteen years of her career designing complex devices, surgical systems, and robotic carts. In this article, she dives into what an assumption register is, when it becomes a risk, and why they are so important. She also details the seven best field-tested reliability practices.
The Biggest Reliability Failures in Development
I’ve spent over fifteen years in MedTech—designing complex surgical systems, phaco machines, robotic carts, and high-voltage platforms that have to perform under sterile, high-stakes conditions. A few years into my career, I fortunate enough to notice a trend that seemingly plagued new engineers and startup teams alike.
The biggest reliability failures I witnessed weren’t electrical or mechanical—they were assumptions.
One early project I was part of involved a robotic surgical cart. Smart team, strong hardware, tons of bench testing. But in the field, we started getting strange failures—random shutdowns, inconsistent charging, startup delays. After weeks of testing, we traced it to something embarrassingly simple: We had assumed the cart would always be plugged in overnight.
But in real-world ORs, it wasn’t. That single unchecked assumption caused an entire cascade of failures.
This experience changed my design philosophy forever—and introduced a tool I now use on every high-stakes product: the Assumption Register.
What Is an Assumption Register?
An Assumption Register is exactly what it sounds like: a living document where your team logs everything you're assuming is true—but haven't proven yet.
Some examples I’ve seen in real MedTech projects: - “The nurse will always press the power button before attaching handpiece” - “The wall outlet will always be grounded” - “The robot arm won’t move during self-test” - “The sterilization process won’t degrade the sensor housing”
These aren’t formal requirements. They’re unspoken truths we operate on, often subconsciously—until one of them fails and causes an FDA report.
When Does an Assumption Become a Risk?
Here’s the magic moment: When the consequence of an assumption being wrong becomes non-trivial, it needs to graduate to the Risk Register.
Let’s say you're building a robotic arm for positioning during surgery. One assumption might be: "The calibration will hold for at least 10 procedures without drift."
If that turns out to be false, and misalignment affects clinical accuracy—that’s not just a technical miss. That’s a patient safety risk.
That’s when you take that assumption, link it to a use-case or user story, and formally assess it through your risk management process (DFMEA, fault tree, ISO 14971, etc.).
Why MedTech Robotics Need This More Than Ever
Modern MedTech products are increasingly robotic platforms on wheels:
- Robotic arms that assist surgeons
- Smart carts with sensors, pumps, and embedded PCs
- Mobile diagnostic units with power, logic, and mechanical motion
These aren’t single-point devices anymore. They’re multi-system, semi-autonomous platforms that behave differently depending on power state, user interaction, connectivity, and timing.
The complexity is nonlinear—and assumptions multiply fast.
A robotic surgical system might rely on:
- Clean hospital flooring for movement
- Wi-Fi to sync pre-op data
- A firmware check before enabling motion
- Battery calibration staying accurate for a full shift
Miss just one of those assumptions, and you’re suddenly stuck debugging a field issue that looks random—but was entirely predictable if it had been written down.
7 Field-Tested Reliability Practices
-
Track Your Assumptions Like They're Bugs
Start an Assumption Register by Day 1 of design. Revisit it at every design review. Add a column for "Consequence if False." That’s your early signal for risk. This keeps invisible beliefs visible—and turns engineering hunches into traceable risk actions. -
Your First Failures Will Be Human, Not Technical
Design for behavior, not specs. I’ve seen carts fail not because the wheel broke—but because a rushed tech wheeled it backwards over a power cord. Most field failures are due to misuse, misunderstanding, or user shortcuts—not design flaws. -
Design for the Tech, Not Just the Surgeon
The OR may be pristine, but the break room, storage closet, and ambulance aren’t. Most robotic MedTech products live 80% of their lives outside the use-case designers think about. Plan for impact, spills, misplacement, and rough handling. -
Reliability ≠ Redundancy
Redundancy without understanding is just expensive guessing. One reliable battery > Two under-tested ones. You don’t need two sensors—you need the right diagnostics and failure signals to know when something’s off. -
Log Everything. Even When It’s Working
Logs aren’t just for debugging—they’re for understanding behavior over time. If you can’t see what the system did 10 hours ago, you can’t explain why it failed now. Include logs for battery health, sensor drift, power cycles, and reboot cause. -
Test Recovery, Not Just Operation
Most teams only test the “happy path.” But real reliability shows up in *recovery*. What happens after a failed update? Can the system return to safe state? Does it reboot cleanly? Practice failure. It’s where your product earns trust. -
Document Assumptions Early = Minimize Surprises Later
It’s cheap to write something down. It’s expensive to fix it in the field. An Assumption Register keeps your team humble, aligned, and one step ahead of the inevitable. Write it early. Revisit it monthly. Promote assumptions to risks the moment they become consequential.
Final Thoughts
In MedTech, What You Didn’t Write Down Can Still Harm the Patient. If you’re building a robotic medical product—and especially if you're moving fast or starting lean—do yourself a favor: Start your next product not with a requirement, but with this question: “What are we assuming to be true, that could possibly be false?” And write it down. That’s not bureaucracy. That’s engineering maturity.
