We use cookies to display personalized content, analyze site traffic, provide recommendations, and ensure you have a great browsing experience. By continuing to use our site, you consent to our use of cookies. Privacy Policy.
Software that functions as a medical device sits at the intersection of two fast-moving worlds: digital health innovation and FDA regulation. Understanding where your software falls under FDA's SaMD framework, and what that means for your path to market, is the first step toward FDA software as a medical device compliance. Since 2007, QSS has guided device developers, digital health companies, and international software manufacturers through the FDA regulatory process with clarity and confidence.
FDA SaMD regulation applies to software that performs a medical function independently, not software that simply runs a hardware device. Determining whether your product meets that definition, and at what risk level, shapes every decision that follows: whether you need a 510(k), a De Novo request, or fall under enforcement discretion.
The landscape has shifted significantly with FDA's Digital Health Center of Excellence and evolving guidance on clinical decision support software and mobile medical applications. What applied two years ago may not apply today. Companies that move forward without current regulatory intelligence risk building a compliance strategy around outdated assumption.
For international companies entering the U.S. market, FDA SaMD requirements add another layer to an already complex market entry picture. Classification, submission, cybersecurity documentation, and post-market obligations all need to be addressed before your software reaches U.S. users.
We assess your software’s intended use, clinical function, and risk profile to determine how FDA classifies it and which regulatory pathway applies. This is the foundation of every SaMD compliance strategy, and the step most companies underestimate.
Many Class II software devices require a 510(k) premarket notification before reaching the U.S. market. We prepare the full SaMD 510(k) submission package, including software documentation, substantial equivalence arguments, and performance data structured to FDA’s current guidance for software devices.
When your software is novel and no valid predicate exists, the De Novo pathway may be the appropriate route. We evaluate De Novo eligibility and support the classification request for software devices presenting low to moderate risk.
Not all CDS software is regulated as a medical device under FDA’s current framework. We assess whether your software meets the criteria for regulated CDS and advise on documentation and labeling requirements accordingly.
FDA now expects cybersecurity documentation as part of SaMD premarket submissions. We advise on what FDA requires, help structure the cybersecurity documentation package, and ensure submissions meet current agency expectations.
FDA’s PCCP framework allows software developers to plan for future modifications without triggering a new submission for every update. We advise on whether a PCCP is appropriate for your device and help structure the plan to FDA’s requirements.
Changes to SaMD after clearance may trigger new submission obligations. We advise on when modifications require FDA action, support post-market documentation, and help clients maintain ongoing compliance as their software evolves.
SaMD is software that performs a medical function on its own, without being part of a hardware medical device. FDA defines it as software intended to be used for a medical purpose — such as diagnosing a condition, treating a patient, or monitoring a clinical parameter — that runs on a general-purpose platform like a smartphone, tablet, or cloud environment. Whether your software qualifies as SaMD determines whether FDA regulation applies and at what level.
No. FDA applies a risk-based approach and exercises enforcement discretion over certain categories of software, including some low-risk general wellness apps and certain clinical decision support tools. The key question is whether your software meets FDA’s definition of a medical device function. Determining that accurately requires a regulatory assessment of your software’s intended use and clinical claims, not a general assumption based on product category.
FDA uses a risk-based framework to classify SaMD based on the significance of the information it provides and the condition it is intended to address. Higher-risk classifications — where the software drives or informs critical clinical decisions — require more rigorous premarket review. Lower-risk software may qualify for enforcement discretion or a streamlined pathway. Classification directly determines which submission type, if any, is required.
Many Class II SaMD products require a 510(k) premarket notification before they can be marketed in the United States. The specific requirement depends on your device classification and whether a valid predicate exists. Some novel software devices may require a De Novo classification request instead. An accurate pathway assessment at the start of your project is the most reliable way to avoid investing in the wrong submission type.
FDA expects premarket submissions for SaMD to include a cybersecurity plan covering threat modeling, security controls, and a software bill of materials (SBOM). Requirements have expanded significantly under FDA’s 2023 cybersecurity guidance. The level of documentation expected scales with the risk profile of the device and the sensitivity of the data it handles.
Yes, but FDA requirements apply regardless of where the software is developed. International SaMD developers must meet the same classification, submission, and post-market obligations as U.S.-based manufacturers. A U.S. Agent may also be required depending on your establishment registration obligations. QSS works with international digital health companies navigating U.S. market entry on a regular basis.
A PCCP is a framework that allows SaMD developers to plan and implement certain future software modifications without submitting a new 510(k) for each change. FDA introduced PCCP guidance to accommodate the iterative nature of software development. Not every SaMD product requires one, but for companies planning ongoing updates to their device, a well-structured PCCP can reduce regulatory burden significantly over time.
Talk to a specialist about your SaMD compliance pathway — whether you are determining classification for the first time or preparing a submission for the U.S. market.