Your next field failure was decided upstream

You shipped the device, you celebrated, and you moved on...

And then that field problem headed your way, the one that'll show up as a complaint 6 months from now... Odds are it was already decided, long before launch, in a requirement that wasn't written quite well enough.

I sat down with Shawnnah Monterrey for the podcast recently. She's built medical device software for 25 years, and now she reads other teams' FDA submissions as an accredited Third-Party Reviewer. So the same failure patterns come across her desk over and over, which means she's basically seeing what the FDA sees.

Near the end, I asked her a simple question: where upstream does the whole loop break first?

Her answer was a single word. "Requirements."

I asked if that was really the pattern. "Every time."

That's a big deal. Understanding that consistent failure could change what happens after you ship product. Call it the SaMD (Software as a Medical Device) compliance workflow: requirement, code, test, release. It runs in both directions, and reading it backward, from a field complaint to the requirement behind it, is the direction that pays.

So let me walk you through the mechanics, instead of just quoting the slogan.

A complaint points backward

Most teams treat the post-market side like a fire queue. A complaint comes in, you put it out, you move to the next one.

Not a bad job for a Tuesday.

But Shawnnah described defects the way you'd describe a splinter. Something gets injected at some stage, in design, in the code, on the manufacturing line. The further downstream you catch it, the more it costs to pull out.

When you catch a bug while you're coding, you fix a line. Catch it in the field across your install base, and now you're running root-cause analysis on thousands of units and negotiating with regulators. You pay now or pay later, as she puts it.

She gave the example of a screw. Suppose you under-specify the torque on a single screw in R&D, hand it to manufacturing without the number, and that screw works loose out in the field. Now you've got a dead-on-arrival unit and a complaint over something that reads, on paper, as trivial. (A screw. It's always something you'd never put on a risk register.)

The software version is harder, because you can't see it. What if an obscure, high-risk bug shows up in the field?

If the code wasn't documented and there were no unit tests, you can't even reproduce it, let alone trace it. So you sit there, stuck.

And when Shawnnah traces those failures back, the gap is almost always in the same place. The requirement wasn't specific enough, so the testing that followed was inadequate.

So the problem, in real-life, is: inadequate requirements, followed by inadequate tests. Every time.

The traceback only works if the trace exists

Shawnnah worked on a ventilator years ago with a bug: when a patient breathed a certain way, the device threw a high-priority alarm and shut itself down. This ventilator that stopped ventilating and started venting to air, which is a recipe for a Class I recall.

The team tried to reproduce it the obvious way, breathing into the patient circuit, guessing at the pattern, but couldn't reproduce the problem.

It only made sense after someone went back to the design documents and found an implementation that was intentional but flawed. Once they understood the assumption baked into the code, they were able to reproduce the problem.

Her lesson pointed to the tests. Unit tests tied to the implementation would have caught it before launch, and even after, they'd have let the team reproduce it without a human in the loop.

That's the way it's supposed to work. The traceback from a field failure to the design decision that caused it only works if the trace was built in the first place. When you skip the documentation and the tests, and root-cause analysis becomes archaeology.

It gets even worse when you multiply it by the number of products in the field. She had an install base north of 80,000 units that could have been carrying the issue. That's a brutally expensive software update to a mistake that started as a single assumption upstream.

→ BONUS RESOURCE: If you want the ground rules for how medical device software is meant to be documented and tested across its lifecycle, start with IEC 62304. It's the standard sitting under everything I just described.

The other place traceability breaks down is between the people taking complaints and the people building the next version.

Shawnnah has watched complaint data get miscategorized into uselessness. Garbage in, garbage out, so actual trends never reach engineering.

She told me about a field team that wrote custom software to patch product issues for customers, and that information never made it back to R&D. The product kept shipping the same defects while the field kept papering over them.

(The scariest part about that is the fact taht everyone was doing their job!)

Her fix is boring but it works. Have an open channel and a standing review of post-market trends, and complaint data treated as a direct input into the next build.

That last part needs management to budget bug fixes alongside features, and to stop flinching every time an engineer says "refactor." Refactoring is just maintenance. If you skip it long enough you'll get a system nobody wants to touch.

There's one modern wrinkle, since it's on everyone's mind... I asked her about AI-written code. She's a skeptic, and her worry is specific: traceability.

If you regenerate code to fix a bug, you often can't cleanly differentiate the old and new versions, which turns regression analysis into a guessing game. Her takeaway was that if AI wrote your code, you'd better have very high unit-test coverage, because the requirement-to-test trace has to carry even more weight than before.

Make the traceback possible before you need it

So here's what "trace it upstream" actually asks of you.

Requirements need to be specific enough that a test can check them. Make sure you have a a design FMEA (DFMEA) that goes bottom-up through how your subsystems interact and fail, even when the FDA won't ask to see it, because Shawnnah's experience is that field failures live in those subsystem interactions.

Unit tests must betied to the implementation. And there needs to be a live path from a complaint back to the design decision that spawned it.

That last one is where your tooling either helps or hurts. If your requirements, your design records, your verification, and your complaints live in four disconnected places, the backward trace is a manual dig every single time. If they're linked, a field signal can walk itself back to the requirement it came from.

That's a separate question from where the records should live, which my colleagues have already covered.

→ BONUS RESOURCE: They make the full case for keeping compliance inside the dev tools your engineers already use in the SaMD dev-tools guide. That's the map. What I'm describing is one move on it: making sure the records those tools hold actually capture the upstream detail that lets you trace a failure home.

And if you want the specific argument for why Jira and GitHub belong inside your QMS, it's right there. This piece picks up after you've won that fight, with what those records need to contain once they're in.

Where I'd start

If there's one thing to take from Shawnnah, it's that the post-market loop is decided long before post-market. Your ability to read a field failure backward to its source is set the day you write the requirement. By the time the complaint arrives, the answer's already been written.

Keep reading

If you are building out your SaMD traceability process, these related guides go deeper on the specific components:

• IEC 62304: how medical device software is meant to be documented and tested
• Compliance inside your dev tools: the SaMD guide
• SaMD quality ops: why Jira and GitHub belong inside your QMS
• Software risk management under ISO 14971: linking software hazards to system risks
• IEC 62304 and the software DHF: design controls that don't slow engineers down
• What auditors actually look for in software documentation

So the practical move is to make that backward trace possible before you ever need it, and that takes a quality system that keeps requirements, design, testing, and complaints connected in one place. If you want to see what that looks like when it's actually linked, here's where I'd start with Greenlight Guru.

P.S. Remember that bug with your name on it, the one from 6 months ago? Go pull the requirements for whatever you're shipping next. Read them the way Shawnnah would. That's where the next one is hiding, or, if you did the upstream work, where it isn't. The problem is your requirements. Every time.