“For purposes of this guidance, FDA refers to a software function that meets the definition of a device as a ‘device software function.’” (FDA Jan 7, 2025 draft). In practice, DSF covers both stand-alone software (SaMD) and software in a device (SiMD). If a software function has a medical intended use under FD&C §201(h), it’s a DSF and falls under FDA oversight.
Why This Term Matters for AI Teams?
SaMD has been the headline for years, but the AI draft guidance shifts focus to the function-level unit FDA regulates.
Knowing whether each function in your app is a DSF:
- determines if you need a 510(k), De Novo, or PMA,
- dictates whether you must submit a Predetermined Change Control Plan (PCCP), and
- shapes your evidence package (validation, cybersecurity, data lineage).
The Legal Definition Behind The Term
FD&C Act § 201(h)
A device is “any product… intended for use in diagnosis… cure, mitigation, treatment, or prevention of disease… which does not achieve its primary intended purposes through chemical action or being metabolized.”
Draft guidance (2025) clarification
FDA simply applies that device definition to software functions: intent-driven, not platform-driven. Your hosting environment (phone, cloud, on-prem) is irrelevant; the intended use is everything.
Real-world AI DSF examples
Still unsure? Let’s look at a few real-world examples.
Imaging Classifier
An AI tool that flags potential tumors in MRI scans.
✅ Intended for diagnosis
✅ Used by clinicians
✅ Device software function
Insulin-Dosing Algorithm
Software that calculates recommended insulin doses using patient data.
✅ Directly affects treatment
✅ Regulated as a Class II or III DSF
Clinical Decision Support Flag
An app that highlights abnormal EKG patterns.
☑️ May qualify as DSF if it interprets or guides care—not just displays data
3-Question Litmus Test: Is Your Code a DSF?
Before worrying about submissions, start here.
- What is the intended use?If it diagnoses, treats, monitors, or predicts health conditions—watch out. FDA cares about intent, not disclaimers.
- Who is the end user?If it informs decisions by clinicians or patients, you’re probably in DSF territory.
- Is it standalone or embedded?Standalone software is a prime DSF candidate. If it’s embedded in a device’s firmware, it might fall under that device’s classification instead.
Why This Matters for Submissions
So your software qualifies as a DSF—now what?
PCCP Requirements
If your algorithm changes over time (think retraining, updating thresholds), the FDA now expects a Predetermined Change Control Plan. That means documenting:
- What you’ll change in the future
- How you’ll validate those changes
- How risks will be mitigated
Other Supporting Documents
You’ll also need:
- DSF description
- Intended use statement
- Model architecture diagram & training data lineage
- Input/output data types
- Performance claims and validation methods
- Cybersecurity & SBOM per 2024 guidance
Skipping this will lead to delays—or worse, rejection.
The Fastest Path to Market
No more guesswork. Move from research to a defendable FDA strategy, faster. Backed by FDA sources. Teams report 12 hours saved weekly.
FAQs
Q: Is firmware considered a Device Software Function?
Not typically. Firmware is usually considered part of the hardware device itself. DSFs are usually standalone or app-based.
Q: Do wellness algorithms count as DSFs?
Only if they make medical claims. If it just tracks steps or sleep, you’re probably safe. But once it says “reduce anxiety” or “improve glucose,” you may cross the line.
Q: How does PCCP tie into DSFs?
If your DSF includes AI/ML that evolves over time, the FDA expects a PCCP showing how you’ll manage those changes safely.