How Medical Device Startups Are Navigating FDA’s Digital Health Framework
The FDA has spent the last four years constructing a regulatory framework for AI and software-based medical devices that is more coherent than most startups realize—and more demanding than most engineering teams are prepared for. The result is a growing gap between companies that treat regulatory readiness as a documentation sprint before submission and those that have built it into their engineering process from the beginning. The second group is winning.
This is not a compliance article. It’s an analysis of how the engineering strategy choices made in early development either compound into regulatory advantage or compound into rework, rejection, and delay. The FDA’s current framework gives you more room to innovate than the previous one—but only if you understand the mechanisms and design for them.
The Current Regulatory Landscape for AI/ML-Based Devices
FDA’s 2021 action plan for AI/ML-based Software as a Medical Device, followed by the 2024 guidance on Predetermined Change Control Plans, represents a deliberate shift in how the agency thinks about AI in clinical contexts. The old model—lock a device down, get it cleared, never change it—was never realistic for software and is actively hostile to AI systems that need to adapt based on real-world performance data.
The current framework acknowledges this. FDA now distinguishes between:
Software as a Medical Device (SaMD): Software intended to perform a medical purpose without being part of a hardware medical device. This covers everything from diagnostic imaging AI to clinical decision support tools that cross the threshold from informational to actionable.
Predetermined Change Control Plans (PCCP): A submission-time commitment that specifies what types of changes a company expects to make to an AI/ML device, how those changes will be evaluated, and what performance benchmarks must be maintained. An approved PCCP means the company can implement those pre-specified changes without filing a new 510(k) or PMA supplement.
Software Functions in Devices (SiMD): AI/ML embedded in traditional hardware devices—imaging systems, infusion pumps, diagnostic equipment. These have different regulatory pathways depending on the device class and the role of the software.
The distinction matters operationally. A startup building a standalone diagnostic AI has different submission levers available than one embedding AI into a Class II device with an existing predicate.
The PCCP: Engineering Asset, Not Just Regulatory Document
Startups that encounter the Predetermined Change Control Plan late in development tend to treat it as a document to write. Startups that encounter it early tend to recognize it for what it is: a forcing function for rigorous product thinking.
A well-constructed PCCP requires you to specify, in advance:
- The types of modifications you anticipate making (retraining on expanded datasets, algorithmic updates, output recalibration)
- The impact assessment methodology you’ll use to evaluate whether a change triggers re-submission
- The performance monitoring plan that generates the real-world data feeding that assessment
- The test procedures and acceptance criteria that will validate each change category
This is not a bureaucratic wish list. Writing it forces engineering and regulatory teams to answer questions they often avoid in early-stage development: What is the device actually optimizing for? What counts as performance degradation? How will we know if the model is drifting? Who decides whether a change is within scope?
Companies that work through those questions at the design stage—tying PCCP categories directly to their systems requirements and risk assessments—find that the PCCP writes itself from artifacts that already exist. Companies that write the PCCP retroactively discover they don’t have the underlying engineering rationale documented anywhere.
The practical implication: your requirements hierarchy for an AI-enabled SaMD should explicitly include performance specifications that map to PCCP thresholds. If your device is a dermatology diagnostic AI, your requirements should specify sensitivity and specificity floors for each indication, the dataset characteristics that define valid training conditions, and the statistical boundaries of acceptable model behavior. Those aren’t just test criteria—they’re the engineering foundation of your PCCP.
The De Novo Pathway: Underused and Misunderstood
Many AI-enabled medical device startups default to 510(k) because it’s familiar. The reflex is understandable and often wrong.
The 510(k) pathway requires substantial equivalence to a predicate device. For truly novel AI applications—a sepsis prediction model, a multimodal diagnostic system that integrates imaging and lab data, an AI that detects early-stage neurological conditions from speech patterns—there frequently is no predicate that captures what the device actually does. Forcing 510(k) on a device with no genuine predicate means either finding a weak predicate that invites questions about equivalence claims, or building a submission that the FDA reviewer reads as a misclassification.
The De Novo pathway, by contrast, is designed for low-to-moderate risk novel devices. It takes longer (FDA’s target review time is 150 days, reality is often longer) but it has distinct advantages for AI-enabled devices:
It creates the predicate. A De Novo clearance establishes a new device classification, which means your cleared device becomes the predicate for future 510(k)s—including your own next-generation products. A startup that successfully navigates De Novo for a novel AI diagnostic owns a regulatory position competitors have to reference.
The special controls framework can embed AI-specific requirements. De Novo decisions include special controls—conditions that must be met for devices in that classification. For AI devices, FDA has been using special controls to codify algorithmic transparency, post-market performance monitoring, and labeling requirements for algorithm-aided outputs. Those controls become part of the regulatory floor for the category, and a company that helped define them through their submission is positioned ahead of competitors who follow.
It avoids the predicate trap. A weak 510(k) predicate argument doesn’t just risk a not-substantially-equivalent determination; it structures your device’s regulatory identity around a device it doesn’t actually resemble. That creates downstream problems when you modify the device, expand indications, or face a competitor’s 510(k) that cites your device as a predicate for something you don’t endorse.
The calculus for most novel AI-enabled devices: if you can credibly argue substantial equivalence to an existing predicate on both intended use and technological characteristics, 510(k) is faster. If that argument requires significant stretching, De Novo will save time overall by avoiding cycles of additional information requests and the risk of a non-substantial-equivalence determination after months of back-and-forth.
Where 510(k) Submissions Are Actually Failing
For AI-enabled devices where 510(k) is the right pathway, the pattern of failure is instructive. FDA’s Additional Information requests and Not Substantially Equivalent determinations for AI devices disproportionately cite:
Inadequate software documentation. FDA’s guidance documents are explicit: software submissions must include a Software Description Document, a Hazard Analysis, and documentation of the software development lifecycle. Many startups produce these as standalone documents written after development is complete. Reviewers can tell. The questions that come back ask for the engineering rationale behind decisions that weren’t documented when the decisions were made.
Untraceable design decisions for AI components. For traditional software, design traceability means linking requirements to test cases. For AI components, FDA expects the traceability chain to include: the clinical need driving the algorithm design, the dataset characteristics and curation decisions, the model architecture choices and their justification, the performance evaluation methodology, and the connection between performance metrics and patient risk. Most startups have parts of this documented in different places. Some have it in no document that a regulatory reviewer would recognize.
Risk analysis that treats AI as a black box. FMEA and fault tree analysis for AI-enabled devices have to grapple with failure modes that traditional medical device risk analysis doesn’t cover: model drift, dataset shift, adversarial inputs, edge case performance, and the interaction between algorithm output and clinical workflow. Submissions that use traditional risk templates without adapting them for AI-specific failure modes signal to reviewers that the team hasn’t thought carefully about the actual risk profile.
Post-market surveillance plans that aren’t operationally grounded. FDA expects SaMD companies to monitor real-world performance continuously. Submissions that describe a monitoring plan without specifics—what metrics, what data sources, what thresholds trigger action, who reviews the data and how often—get questions that are hard to answer quickly.
Engineering for Regulatory Readiness Without Slowing Down
The engineering teams navigating this most effectively have restructured their process around a few core principles:
Requirements are the regulatory artifact. Every requirement for an AI-enabled medical device is simultaneously an engineering specification and a regulatory claim. A requirement that says “the algorithm shall detect atrial fibrillation” needs to specify: in what patient population, under what ECG recording conditions, measured against what reference standard, with what performance threshold. That specificity is what makes the requirement traceable through design, testing, and risk analysis. Vague requirements create documentation debt that surfaces at submission time.
Change control is ongoing, not episodic. One of the most common engineering pathologies in medical device startups is treating change control as a formality—something that happens when regulatory is watching. For AI devices, where model updates, dataset expansions, and algorithm tweaks are part of normal development, undocumented changes create submission-time reconstruction problems. The engineering team needs change documentation habits that capture the rationale for decisions at the time they’re made, not reconstructed from memory six months later.
Traceability has to be queryable, not just present. A requirements traceability matrix that exists as a spreadsheet or a PDF might satisfy a checkbox. It doesn’t help an engineer quickly assess the impact of a proposed change on regulatory status, or help a regulatory reviewer understand the chain from a clinical requirement to a validation test result. Connected traceability—where requirements, risks, tests, and design artifacts are linked in a system that can be queried and traversed—is what makes regulatory review faster and less expensive.
Tools matter here. The legacy requirements management systems built for aerospace and automotive—IBM DOORS and its successors—carry significant structural overhead for small medical device teams. They’re powerful and well-understood by large OEM quality systems, but their document-centric architectures and complex deployment requirements create friction for startups that need to move fast. More modern SaaS platforms offer better usability but not all of them are built for the specific traceability demands of 21 CFR Part 820 and the FDA’s Software as a Medical Device guidance.
Flow Engineering has emerged as a platform that takes the graph-based, AI-native approach that medical device teams increasingly need. Rather than treating requirements as documents, it models them as connected nodes in a live graph—so when a requirement changes, its relationships to risk controls, test cases, and design decisions are immediately visible. For teams building AI-enabled SaMD, this kind of connected traceability directly supports the PCCP impact assessment workflow: you can trace a proposed model update to the requirements it touches, the risk controls it affects, and the validation tests that need to be re-run before you can execute the change under your approved PCCP. That’s not a theoretical benefit—it’s the difference between a change assessment that takes days and one that takes weeks.
What Regulatory Readiness Actually Looks Like in Practice
The medical device startups making credible progress toward FDA submission share a few operational patterns:
They write their Device Description and Intended Use Statement before the device is built, not after. This sounds obvious and is rarely practiced. An early Intended Use Statement forces explicit decisions about patient population, use environment, user qualifications, and clinical decision context—decisions that constrain architecture and training data choices in ways that have regulatory implications.
They run a regulatory touchpoint at every significant design decision point, not just at submission. This doesn’t mean regulatory staff embedded in sprint reviews. It means engineers who understand which decisions require regulatory documentation and flag them in real time.
They treat their SOUP (Software of Unknown Provenance) and third-party model dependencies as first-class regulatory artifacts. For AI-enabled devices that use foundation models, pre-trained components, or commercial AI APIs, the regulatory question is always: what can you claim about the behavior and limitations of this component, and how do those limitations bound your device’s performance claims? Teams that haven’t mapped this can’t answer FDA’s inevitable questions about algorithm transparency.
They participate in FDA’s Pre-Submission program. A Q-Sub (Pre-Submission meeting request) costs time but almost always pays back faster than reacting to a deficiency letter. FDA reviewer feedback on novel AI applications is often substantive and specific—it tells you what evidence will actually be expected rather than leaving you to guess.
Honest Assessment
The FDA’s digital health framework for AI and SaMD is more workable than its reputation suggests. The PCCP mechanism gives adaptive AI systems a real path to iterative improvement post-clearance. The De Novo pathway gives novel devices a route to market that doesn’t require forcing weak predicate arguments. The guidance documents—FDA’s SaMD framework, the AI/ML action plan, the PCCP guidance—are genuinely useful engineering inputs, not just compliance paperwork.
The challenge is that the framework rewards engineering rigor from the start and taxes engineering shortcuts at the end. A startup that builds connected traceability, documents design decisions in real time, and structures its requirements around regulatory thresholds will find submission faster and cheaper than one that builds first and documents retroactively.
The companies that are succeeding aren’t moving slower. They’re building regulatory readiness into engineering workflow rather than treating it as a separate lane. The infrastructure investment is real. The payoff at submission time is also real.