Medical Device Startups and the 510(k) Requirements Trap
There is a shortcut that medical device startups take so consistently it has become an industry pattern. When preparing a 510(k) submission, requirements documentation gets written backwards — starting from the predicate device’s known characteristics and working inward toward the product being cleared, rather than starting from what the device actually does and what safety it must maintain.
The logic is understandable. The 510(k) pathway requires demonstrating substantial equivalence to a legally marketed predicate. The fastest way to demonstrate equivalence is to show that your device’s intended use and technological characteristics match or do not raise new safety questions. So teams reverse-engineer their requirements to fit that comparison. The predicate becomes the specification template.
This is a trap. The requirements that clear your device are not the same requirements that build it safely, verify it rigorously, or surveil it effectively once it is on the market. When those two requirement sets are collapsed into one document, the shortcuts show up later — in design control gaps, in V&V failures, and increasingly in FDA warning letters tied to inadequate post-market surveillance of AI-enabled features.
What Predicate-Matched Requirements Look Like
The pattern is recognizable once you know what to look for.
A startup is developing a cardiac rhythm monitoring wearable. The predicate is a cleared Holter monitor. The 510(k) requirements document will specify:
- Sampling rate at or above the predicate’s known specification
- Lead configuration equivalent to the predicate
- Signal bandwidth within the predicate’s cleared range
- Alarm thresholds that match cleared parameters
These are comparison statements dressed as requirements. They say “we are like the predicate” rather than “here is what the system must do and under what conditions it must do it safely.”
What is missing: the specific patient population conditions under which the device must perform, the failure modes that arise from novel sensor placement, the degradation behavior under signal noise, the alarm condition logic if Bluetooth transmission drops, the accuracy bounds under patient motion. None of these appear in the predicate’s 510(k) — because the predicate never had to answer for them the same way. And so they do not appear in the new submission either.
The device gets cleared. Development continues with a requirements set that does not actually specify the system.
Where the Trap Closes: Design Control
FDA’s design control regulation under 21 CFR Part 820 (and its updated alignment with ISO 13485) requires a structured design and development process in which requirements are established, outputs are verified against those requirements, and the result is validated against user needs. The regulation assumes requirements that are technically specific, measurable, and traceable to design outputs.
Predicate-matched requirements fail this structure in two ways.
First, they are often not independently verifiable. “Sampling rate equivalent to predicate” is not a test you can run. There is no pass/fail criterion. When the verification and validation phase arrives, engineers have to reconstruct the actual performance specifications the device should meet — specifications that should have been the requirements in the first place. This reconstruction work is done under schedule pressure, without regulatory review, and frequently without consistency across the engineering team.
Second, the traceability matrix becomes fictional. The requirements traceability matrix (RTM) that maps requirements to design outputs to test results gets populated by matching predicate comparison statements to tests that were actually designed to validate the real system. The links exist in the spreadsheet. The logic connecting them does not. FDA reviewers increasingly understand this distinction. So do plaintiff attorneys after an adverse event.
A 2024 analysis of FDA warning letters related to design control found that inadequate or incomplete design verification was cited in 43% of letters to device manufacturers with fewer than 500 employees. The requirement-to-verification chain was identified as deficient in the majority of those cases. Predicate-matching creates exactly the conditions that produce this deficiency at scale.
The V&V Consequence
Verification and validation failures in 510(k)-cleared devices often trace directly to this documentation gap, but they appear disguised as test planning failures or resource constraints.
The actual mechanism: when requirements are vague or comparative rather than functional and measurable, test engineers cannot derive test cases from them directly. They instead write tests that reflect their understanding of how the device works — which is accurate — but do not explicitly reference the documented requirements. The RTM is then populated after the fact, matching tests to requirements by proximity rather than by derivation.
This is the wrong direction. Test cases should be derived from requirements. When they are not, you have no systematic assurance that the test suite covers the requirement space. You have tests that happened to be written, matched retrospectively to requirements that happened to be in the document.
For traditional medical devices, this gap is serious but sometimes manageable. For AI-enabled medical devices, it is fatal to the evidentiary chain that FDA now expects.
FDA Scrutiny of AI-Enabled Devices: A Different Documentation Problem
FDA’s evolving framework for AI/ML-enabled medical devices — including the 2021 action plan, the 2023 draft guidance on predetermined change control plans (PCCPs), and the continued development of the AI/ML software function lifecycle framework — introduces a class of documentation requirements that predicate matching cannot satisfy by construction.
Here is the problem: AI-enabled devices have intended use envelopes that are defined by algorithm training conditions, input data characteristics, and performance bounds across subpopulations. None of these appear in the predicate’s cleared labeling, because the predicate either did not use AI or used a different algorithm with different boundary conditions.
A startup developing an AI-powered diabetic retinopathy screening device cannot borrow its performance requirements from a predicate that used ophthalmologist review as the comparison method. The AI system’s sensitivity and specificity requirements must be specified by intended use context — imaging equipment types, patient population demographics, ambient lighting conditions, image quality thresholds below which the algorithm output is unreliable. These specifications have to be generated from the actual system design, not extracted from a predicate comparison.
FDA’s 2024 final guidance on marketing submissions for AI/ML-enabled device software functions explicitly requires that submissions include: the reference dataset characteristics, the algorithm’s performance across clinically relevant subgroups, the conditions under which the algorithm’s output is expected to degrade, and the monitoring approach that will detect that degradation in post-market use.
None of these can be borrowed from a predicate. All of them must originate in the device’s own requirements documentation. A team that built its requirements around predicate matching now has to reconstruct the entire specification — under regulatory scrutiny, often after clearance, and sometimes after a safety signal has already appeared in post-market data.
Post-Market Surveillance: Where the Bill Comes Due
The FDA’s post-market surveillance requirements for AI-enabled devices are not hypothetical. Section 522 postmarket surveillance orders have been issued to AI-enabled device makers whose cleared submissions lacked adequate performance monitoring commitments. The order requires a surveillance study that should have been planned before clearance — designed from requirements that should have been written before development.
Retroactive post-market surveillance planning against vague requirements is expensive and scientifically weak. What outcomes are you monitoring? Against what performance floor? For which patient subpopulations? If the requirements document says “performance equivalent to predicate,” there is no baseline to monitor against that is specific to how the device actually functions in the field.
The companies that avoid this problem have a common characteristic: their requirements documentation was written to describe the system, not to describe the predicate match. Those requirements can be operationalized into surveillance protocols. They have specific metrics, defined acceptable ranges, and clear conditions under which a performance deviation triggers investigation.
What Modern Requirements Practice Looks Like
The practical alternative to predicate-matching is not more documentation. It is structuring requirements around three questions:
What must the device do, under what conditions, to what measurable standard? This produces functional and performance requirements that are independently verifiable and that can drive test case derivation without reconstruction.
What can go wrong, and what must the design do to prevent or mitigate it? This connects requirements to the risk management file (ISO 14971) at the requirement level, not as a post-hoc annotation.
What will we measure in post-market use to know the device is performing as required? This connects requirements to surveillance design before the device ships.
Tools are beginning to support this structure explicitly. Flow Engineering, built for hardware and systems engineering teams, implements a graph-based requirements model that makes the connections between functional requirements, risk controls, and verification methods explicit at the data level — not as spreadsheet links, but as typed relationships that can be queried, audited, and traversed. For medical device teams, this means the RTM is not a document assembled at submission time; it is a live artifact of the engineering process that reflects actual traceability as it is built. The ability to trace a requirement through its risk rationale to its verification test to its post-market monitoring metric in a single connected model is the structural answer to the predicate-matching trap.
This matters because FDA reviewers are increasingly asking for this level of traceability coherence — not just the RTM as a table, but evidence that the connections in the table reflect engineering logic rather than document assembly.
The Regulatory Direction Is Clear
FDA is not moving toward less scrutiny of AI-enabled medical device requirements. The agency’s Digital Health Center of Excellence, the International Medical Device Regulators Forum (IMDRF) alignment work, and the EU MDR’s technical documentation requirements are all converging on the same expectation: requirements that describe the actual system, connected to risk controls that address actual failure modes, verified by tests derived from those requirements, and monitored by surveillance protocols that can detect meaningful performance deviation.
The 510(k) predicate-matching shortcut was always a documentation risk. For AI-enabled devices in 2026, it is a product risk — one that surfaces in warning letters, 522 orders, and adverse event investigations that cost far more than the time saved during submission preparation.
The teams that will navigate FDA’s evolving AI device framework successfully are the ones that stop writing requirements for the submission and start writing requirements for the system.