(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.

https://www.hse.gov.uk/pubns/books/hsg245.html