"FDA compliant" gets used as a catch-all in healthcare software pitches, and it hides the question that actually determines your launch date: is your software regulated as a medical device at all, and if so, which class?
That single classification decision — made early, sometimes before a line of code is written — sets your entire build timeline. It determines whether you're looking at a few months of documentation work or a multi-year premarket submission process. Vendors who talk about "FDA software compliance" without ever mentioning SaMD classification are skipping the step that actually shapes your project plan, your budget, and your go-live date.
This post walks through what Software as a Medical Device actually means, how FDA classification works, and why getting this right at the start saves months later.
What "Software as a Medical Device" Actually Means
Software as a Medical Device (SaMD) is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. The International Medical Device Regulators Forum (IMDRF) — a group FDA participates in — defined this category to separate standalone medical software from software that's just embedded in a physical device, like the firmware running an infusion pump.
The distinction matters because plenty of healthcare software isn't SaMD at all. A scheduling tool, a billing system, or a general EMR record-keeping module typically isn't regulated as a medical device. But software that analyzes patient data to inform a diagnosis, calculates a treatment dose, or flags a clinical risk score often is — even if it's a feature bolted onto a broader platform.
The test FDA applies isn't "does this touch patient data." It's whether the software's output is used to diagnose, treat, prevent, cure, or mitigate a disease or condition, and how much clinical judgment stands between that output and a decision affecting patient care.
How FDA Classification Actually Works
Once software qualifies as SaMD, FDA places it into one of three device classes, and the class is what drives everything downstream.
Class I covers low-risk software — general wellness tools or software with minimal potential for harm if it malfunctions. Most Class I devices are exempt from premarket submission requirements, though general controls and quality system obligations still apply.
Class II covers moderate-risk software — most clinical decision support tools, diagnostic aids, and monitoring software fall here. Class II devices typically require a 510(k) premarket submission, showing the software is substantially equivalent to an already-cleared device.
Class III covers high-risk software — tools that support life-sustaining decisions or carry significant risk if they fail. Class III devices require Premarket Approval (PMA), the most rigorous and lengthy FDA pathway, involving full clinical evidence review.
Classification isn't based on how sophisticated the software is. It's based on the risk associated with an incorrect output and how much a clinician's independent judgment can catch that error before it affects the patient. Two products with similar tech stacks can land in different classes because one presents its output as decision support a clinician reviews, and the other presents it as a direct diagnostic conclusion.
Why Classification Drives Your Build Timeline
Classification isn't a compliance detail you handle at the end. It determines the shape of the entire project.
Class I builds move fast. With general controls and no premarket submission required in most cases, a Class I product can often follow a build timeline close to standard software development — weeks to a few months of added documentation work, not years.
Class II builds require a 510(k) pathway. Budget for predicate device research, a formal submission, and FDA review time that commonly runs several months after submission — on top of the months needed to prepare the submission itself. Development has to build in verification and validation documentation from day one, not bolt it on afterward.
Class III builds are a different scale of project entirely. PMA submissions require clinical evidence, often clinical trials, and FDA review that can run well over a year. If your product might land in Class III, that needs to be flagged during the initial scoping conversation, not discovered mid-build.
Quality system requirements apply earlier than most teams expect. As of February 2026, FDA's Quality Management System Regulation (QMSR) formally incorporates ISO 13485:2016 into 21 CFR Part 820, replacing the older QSR. That means design controls, risk management, and documented development processes are now expected in a form aligned with the international ISO standard from the start of development — not retrofitted before submission. Teams that build without a quality management system in place from day one typically have to redo significant documentation later, which adds months.
The practical implication: the classification conversation has to happen before the technical architecture is locked in, because the class you land in determines what documentation, testing, and controls your build process needs to produce as it goes.
Common Timeline Mistakes in SaMD Projects
Most SaMD delays trace back to a handful of avoidable planning errors.
- Treating classification as a legal afterthought. Teams start building first and ask "are we regulated?" only once they're preparing for launch, which means retrofitting design controls and documentation into an already-built product.
- Underestimating Class II submission timelines. Founders often budget for the 510(k) review window but not the months of predicate research and submission preparation that come before FDA even starts the clock.
- Assuming AI/ML features don't change the classification. Adding a predictive or AI-driven feature to an existing tool can shift its intended use and risk profile enough to change its class — and teams frequently miss this when scoping incremental features.
- Building without design controls from the start. Under QMSR, design history files, risk management documentation, and traceability need to exist from early development, not get created retroactively to satisfy a submission checklist.
- Not distinguishing regulated features from unregulated ones. A platform with both a Class II clinical feature and unregulated administrative features often needs to scope, document, and test those two halves differently, which teams frequently miss until late in the build.
What a Well-Planned SaMD Build Process Looks Like
A development process built around SaMD requirements, rather than general software best practices alone, typically includes:
- Classification assessment before architecture decisions. Determining likely device class early so the technical build accounts for the right documentation and testing burden from day one.
- Design controls integrated into the development workflow. Requirements, risk analysis, verification, and validation tracked as the software is built, not reconstructed afterward.
- A quality management system aligned with QMSR/ISO 13485. Documentation practices that satisfy FDA's current framework without needing a parallel compliance effort bolted on later.
- Predicate device research built into product planning. For Class II products, identifying viable predicates early shapes both the technical build and the eventual 510(k) narrative.
- Change management that flags reclassification risk. A process for evaluating whether a new feature shifts intended use or risk profile enough to affect classification before it ships.
This is the same principle that applies to well-built prior authorization or claims systems: catching the structural issue early costs far less than fixing it after the fact.
Why Generic Software Vendors Miss This
Most software development shops are good at building software. Fewer have actually taken a product through FDA classification and a 510(k) or PMA submission — and that gap shows up as timeline surprises six months into a build, not at kickoff.
A generic dev partner will build what you ask for. A partner experienced with regulated healthcare software will ask what class your product is likely to fall into before writing the first requirement, because that answer changes the technical approach, the documentation burden, and the realistic launch date. This is the difference healthcare software development companies in USA bring when they specialize in medical device software development rather than general healthcare IT — and it's also why HIPAA-compliant healthcare software and SaMD-compliant healthcare software are related but not the same bar to clear. HIPAA governs data privacy; SaMD classification governs the safety and efficacy claims your software is legally allowed to make.
Frequently Asked Questions
What determines whether software is classified as SaMD? FDA looks at whether the software's intended use is to diagnose, treat, prevent, cure, or mitigate a disease or condition, and how directly its output drives a clinical decision. Software that simply manages records, schedules, or billing typically isn't SaMD, even if it touches patient data. Software that generates a diagnostic score, risk flag, or treatment recommendation usually is.
How long does FDA classification and clearance typically add to a build timeline? It depends entirely on the class. Class I software adds relatively little — mostly documentation. Class II software adds months for predicate research, submission preparation, and FDA review time after submission. Class III software adds well over a year in most cases, given the clinical evidence and trial requirements involved.
Can a software update change a product's FDA classification? Yes. Adding a new clinical feature, an AI-driven prediction, or expanding the software's intended use can shift its risk profile enough to require reclassification or a new submission. This is one of the most commonly missed risks in ongoing SaMD development, especially with incremental AI features.
Do all healthcare software products need FDA clearance? No. A large share of healthcare software — scheduling, billing, general record-keeping, workflow automation — falls outside SaMD entirely and isn't subject to FDA premarket requirements. The determination has to be made based on the specific feature's intended use, not the product category as a whole.
Plan the Regulatory Path Before You Plan the Build
SaMD classification isn't a form you fill out before submission. It's a decision that should shape your architecture, your documentation process, and your timeline from the first planning conversation. Teams that treat it as an afterthought end up rebuilding documentation, and sometimes rebuilding features, months after they thought they were close to launch.
If you're planning a clinical software feature and aren't sure where it lands on FDA's risk classification, that's worth sorting out before development starts, not after. Contact Us and Aryabh Consulting will help you map your product's likely classification and what that means for a realistic build timeline.
Sign in to leave a comment.