A Closer Look at the Common Prereview Medical Device Compliance Pitfalls an FDA Panel Cited at MedCon
How to avoid compliance issues around software change documentation, design creep, and marketing beyond intended use
A new report from RAPS recaps a MedCon 2025 panel where FDA officials spotlighted recurring compliance issues that frequently trigger enforcement—many of which we also uncover in our own audit and inspection readiness work with medical device firms.
From undocumented software changes and unchecked design drift to off-label marketing on social media, these pitfalls continue to appear in 483 observations and warning letters, despite being well-known risks.
To take this one step further, we’re breaking down what the FDA said and sharing a bit about what we observe in the field, with specific, actionable steps that teams can take to strengthen their systems and stay inspection-ready in each of these areas.
Let’s take each of them one by one.
Pitfall #1: Insufficient documentation for software changes
"If you’re not submitting the premarket authorization, the only thing I can recommend is justify, document, really concrete that decision, so whenever we come in, you can explain why,” said FDA’s Katelyn Staub-Zamperini, medical device senior operations officer in the Office of Medical Device and Radiological Health Inspectorate (OMDRHI) and Office of Inspections and Investigations (OII). “If a design change impacts a medical device’s use, safety, or effectiveness, it warrants at least a review of the device.”
We often advise device firms to document explicit reasons for categorizing changes as non-significant. For instance, if a software update addresses a user interface issue, explicitly state why this does not affect safety, effectiveness, or intended use.
During one device audit last year, for example, we discovered a medtech firm failed to document why a software change labeled a "minor bug fix" that adjusted device alert thresholds did not require a 510(k). Implementing an explicit "decision rationale" template in their change control procedures resolved this issue and prevented recurrence.
Also, if you haven’t already, create standardized templates for documenting software changes, clearly capturing rationale, risk assessment, validation procedures, and approvals.
Today’s eQMS tools often have built-in alerting capabilities to prompt regulatory reviews based on predefined criteria—use them!
Pitfall #2: Design creep resulting in unrecognized product changes
FDA’s Staub-Zamperini highlighted cases where "over time, they've made small little adjustments," resulting in a product "nowhere near what was originally cleared."
From the RAPS report:
Changes that impact the functionality and user interface of a device should be a “careful consideration,” Staub-Zamperini explained. The “biggest issue stemming from this,” she said, comes when software engineers do not have a trigger in their change system to alert the regulatory team in a company when a change would warrant a review. For instance, changes to software requiring a review can sometimes be labeled as an upgrade, update, improvement, or a bug fix.
“I’ve seen at firms, their software engineers, they’re focused on fixing that bug, and once the bug is fixed, their goal has been accomplished,” Staub-Zamperini said. “I’ve seen that lack of a trigger, with the regulatory staff coming in to see if that’s the software bug, and [the] change that it made happen would have required a review.”
Another major issue surrounding premarket authorizations is a design brief that resembles the original submitted device, but not the current device on the market.
“I've seen cases recently where a design, their premarket authorization is over 15 years old,” Staub-Zamperini said. “Over time, they've made small little adjustments, and then looking now, 15 years later, their product is nowhere near what was originally cleared because of all these little changes.”
When we encounter this problem during audits, we often suggest that firms create and maintain a dynamic "change log" that specifically highlights incremental adjustments. Regularly evaluate this log against your initial submission.