(And What Regulators Are Actually Looking For)
The Everyday Problem
A safety issue shows up during testing.
The team investigates, applies a fix, and documents the decision.
Everyone moves on.
Months later, a similar issue appears.
Sometimes it’s the exact same problem. Sometimes it looks new—but it feels familiar.
Now the question comes up: Why are we dealing with this again?
This is a common experience for medical device teams, especially startups preparing for their first submission or growing teams juggling design changes, testing, and timelines.
What People Assume (And Why It Makes Sense)
Most teams assume:
“If we fixed it once, it shouldn’t come back.”
That assumption is reasonable. Development moves fast, and teams rely on testing, documentation, and external labs to confirm that issues are resolved.
There is also trust in the process:
The test passed.
The issue was recorded.
The required steps were followed.
From the outside, it looks complete.
From the inside, it feels like progress.
What Actually Goes Wrong
In real-world device development, most teams fix the event, not the conditions that allowed the event.
Here’s how repeating problems usually happen:
A test failure leads to a retest, not a deeper question.
A complaint leads to a replacement, not a system review.
A deviation leads to retraining, not a design or process rethink.
Each action responds to what happened last time.
Very few actions reduce the chance of it happening again.
Over time, this creates predictable consequences:
Issues reappear in slightly different forms.
Testing expands without clearer answers.
Explanations become harder to defend later.
The system stays vulnerable, even though the paperwork grows.
Why This Happens So Often
Medical device development involves many moving parts:
Design decisions
Materials and suppliers
Manufacturing steps
Use conditions
Packaging and shipping
Testing assumptions
When these elements are evaluated in isolation, small gaps form between them.
Those gaps are where repeat problems live.
Most testing systems are designed to confirm expectations—not to challenge them.
Translate the Regulatory Expectation
There’s a common belief that regulators are mainly looking for completed forms and passed tests.
That’s not quite true.
What regulators actually want is much more human.
They want to see that you:
Understand how your device could fail
Recognize why a problem occurred
Made decisions that meaningfully reduce risk
Can explain your reasoning clearly and consistently
Regulators care less about whether you used the “right” template and more about whether your safety story makes sense from start to finish.
A test result without reasoning is weak.
A fix without explanation is fragile.
Why Repeating Problems Raise Red Flags
When the same type of issue keeps appearing, it signals that:
The original question may have been too narrow
The test may not reflect real-world use
A design or material assumption went unchallenged
Documentation captured actions, not thinking
This doesn’t mean the team did anything wrong.
It means the system wasn’t designed to surface the full picture early enough.
A Simple Example
Imagine a small, handheld medical device with a molded plastic housing.
During testing, a crack appears near one corner.
The team tightens inspection criteria and replaces affected units.
The test passes. The issue is closed.
Later, similar cracks appear during shipping simulation.
What changed?
A closer look shows:
The material supplier adjusted the resin formulation
The corner geometry already concentrated stress
The inspection focused on visible cracks, not early stress indicators
A prior design update increased internal pressure slightly
No single change caused the issue.
The system allowed multiple small changes to stack up without being evaluated together.
If the team had earlier asked how design, material, and use conditions interacted, the risk might have been identified before repeat testing and delays.
What Regulators Expect in These Situations
From a regulatory perspective, this is not about blame.
It’s about understanding.
Regulators expect teams to show that:
They noticed the pattern
They looked beyond the immediate symptom
They adjusted their approach to reduce future risk
They are assessing how well a team understands its own device and development system—not whether mistakes ever happen.
This applies whether you are preparing a submission or responding to questions from the U.S. Food and Drug Administration.
Where Kandih Comes In
This is where experienced, early input makes a difference.
Kandih works with medical device teams as part of the development process—not as a last-minute fix.
The focus is on helping teams:
Notice early safety signals before they turn into repeat issues
Ask better questions when a result feels unclear or incomplete
Design testing that reflects real-world use, not just requirements
Evaluate design and material changes in context
Review study plans and results for hidden assumptions
Support safety decisions that can still be explained clearly later
The goal is not more testing.
It’s better understanding.
What Good Looks Like
When safety thinking is integrated early, teams experience fewer surprises.
Problems still occur—but they don’t repeat as often.
Decisions are easier to explain because the reasoning was clear at the time.
Testing answers meaningful questions instead of creating new ones.
Design changes are evaluated for impact, not just compliance.
Most importantly, safety becomes something the team understands—not something they hope the test results will confirm.
Why This Matters Beyond Compliance
Clear safety reasoning doesn’t just satisfy regulators.
It saves time and money.
It reduces rework and delays.
It builds confidence across engineering, quality, and leadership teams.
When decisions are grounded in understanding, they hold up—even as teams grow and change.
When the same problems keep showing up, the issue is rarely effort or intent.
It’s usually a missing question.
If a safety decision can’t be explained simply, it probably isn’t finished yet.
The goal isn’t more documentation or more testing.
It’s clearer thinking, earlier.
References
FDA – Quality System Regulation Preamble (CAPA Effectiveness)
FDA explicitly states that corrective actions must address root cause and prevent recurrence—not just close issues quickly.
https://www.fda.gov/files/drugs/published/Overview-of-Quality-System-Regulation.pdf
ICH Q10 – Pharmaceutical Quality System
Requires evaluation of corrective action effectiveness and discourages superficial fixes driven by timelines.
https://database.ich.org/sites/default/files/Q10_Guideline.pdf
ISO 9001:2015 – Clause 10.2 (Corrective Action)
Mandates that organizations evaluate whether actions taken actually prevent recurrence—not just implement them quickly.
https://www.iso.org/standard/62085.html
Reason, J. (2000). Human Error: Models and Management. BMJ
Foundational paper explaining why rushed, behavior-based fixes fail when systems remain unchanged.
https://www.bmj.com/content/320/7237/768
ASQ – Root Cause Analysis: Why Quick Fixes Fail
Explains how urgency leads to symptom treatment instead of true root cause correction.
https://asq.org/quality-resources/root-cause-analysis
ISPE – Risk-Based Approach to Quality and Investigations
Discusses the danger of timeline-driven investigations and superficial corrective actions.
https://ispe.org/publications/guidance-documents
HSE (UK) – Investigating Accidents and Incidents
Demonstrates that rushed investigations lead to missed root causes and repeat failures.