On this page
- Which FDA rules apply to software development?
- Does your healthcare software need FDA review?
- How does the FDA classify medical device software?
- Which FDA premarket pathway applies to your software?
- What software documentation does the FDA expect?
- How do you build FDA-compliant software from the start?
- What extra rules apply to AI-enabled software?
- What common mistakes should developers avoid?
- How can a development partner help?
- Summing up
- FAQ
Which FDA rules apply to software development?
FDA guidelines for software development combine a few laws, one quality regulation, and several guidance documents. Which ones apply depends on what your software is intended to do and how risky it would be if it failed.
| Rule or standard | What it covers | When it applies |
|---|---|---|
| FD&C Act section 201(h) | The legal definition of a medical device | Every product with a medical intended use |
| FD&C Act section 520(o) | Software functions excluded from the device definition | Admin, wellness and some clinical decision support software |
| 21 CFR Part 820 (QMSR) | Quality management, design controls, records | Device makers, from February 2, 2026 |
| 21 CFR Part 11 | Electronic records and signatures | Records the FDA requires you to keep |
| Content of Premarket Submissions for Device Software Functions (2023) | Software documentation for FDA review | 510(k), De Novo and PMA submissions |
| Section 524B and FDA cybersecurity guidance (2025) | SBOM, vulnerability management, secure design | Cyber devices that connect to networks |
| IEC 62304 and ISO 14971 | Software life cycle and risk management | Recognized standards most teams follow |
For broader context on regulated healthcare builds, the healthcare software development guide covers architecture, interoperability and compliance together.
Does your healthcare software need FDA review?
Your software needs FDA review only if it is a medical device and is not exempt. The deciding factor is intended use: what the software is meant to do, as shown by your labeling, marketing, and product claims.
Software that is likely a medical device:
- Analyzes medical images or physiological signals, such as ECG traces, to detect a condition.
- Calculates drug doses or recommends treatment for a specific patient.
- Raises alarms that drive time-critical clinical action.
- Diagnoses or screens for a disease.
Software that is usually not regulated as a device:
- General wellness apps, such as step counters and sleep or fitness trackers with no disease claims.
- Scheduling, billing, appointment reminders, and practice management tools.
- Electronic health records and general health education content.
- Clinical decision support that meets all four section 520(o) criteria.
What changed for wellness and clinical decision support software in 2026?
The FDA updated its General Wellness and Clinical Decision Support (CDS) guidance on January 6, 2026, and both now cover more software as non-device or low-priority.
- General wellness: noninvasive wearables that estimate metrics such as heart rate can count as wellness products if they make no disease or diagnostic claims and pose minimal risk.
- Clinical decision support: the FDA now intends to use enforcement discretion when CDS software gives a single clinically appropriate recommendation and meets the other criteria.
CDS software is excluded from the device definition only if it meets all four statutory criteria:
- It does not analyze medical images, in vitro diagnostic signals or physiological signal patterns.
- It displays or analyzes medical information about a patient or other medical information.
- It supports a healthcare professional’s recommendations about prevention, diagnosis or treatment.
- It lets the professional independently review the basis for its recommendations.
How does the FDA classify medical device software?
The FDA classifies medical device software into Class I, II, or III based on risk to patients. The class decides how much evidence you need and which premarket pathway applies.
| Class | Risk level | Typical pathway | Controls |
|---|---|---|---|
| Class I | Low | Often exempt from premarket review | General controls |
| Class II | Moderate | 510(k) clearance or De Novo | General and special controls |
| Class III | High | Premarket approval (PMA) | General controls plus PMA |
Classification follows the device type, not how complex the code is. A simple algorithm that detects a life-threatening condition can be Class III, while complex scheduling software is not a device at all. Check the FDA product classification database for similar devices before you design your submission plan.
Which FDA premarket pathway applies to your software?
Most regulated software reaches the US market through 510(k) clearance or the De Novo pathway. Premarket approval is reserved for high-risk Class III devices.
- 510(k) clearance: you show the software is substantially equivalent to a legally marketed predicate device. Best for: Class II software with a clear predicate.
- De Novo classification: a risk-based request for new low-to-moderate risk devices with no predicate. A granted De Novo can become a predicate for future 510(k)s. Best for: novel software functions.
- Premarket approval (PMA): the most demanding pathway, usually with clinical evidence. Best for: Class III software where failure could cause serious harm.
- Q-Submission (Pre-Sub): an optional meeting request to get FDA feedback before you submit. Best for: any team unsure of its classification, testing plan, or predicate.
FDA review goals under the current user fee agreement (MDUFA) are measured in “FDA days”, which exclude time spent waiting on the sponsor: roughly 90 FDA days for a 510(k), 150 for De Novo and 180 for PMA. Total calendar time is usually longer.
Use the right words: a 510(k) is cleared, a De Novo is granted, and only a PMA is approved. Saying “FDA approved” for a cleared product is a labeling mistake.
What software documentation does the FDA expect?
The FDA expects documentation scaled to risk, using two levels: Basic and Enhanced. The FDA’s Content of Premarket Submissions for Device Software Functions guidance, finalized in June 2023, replaced the 2005 “level of concern” approach.
Enhanced documentation applies when a failure or flaw could present a hazardous situation with a probable risk of death or serious injury. Everything else uses Basic documentation. Typical Basic documentation includes:
- Documentation level evaluation
- Software description
- Risk management file
- Software requirements specification
- System and software architecture diagram
- Software development, configuration management and maintenance practices, or an IEC 62304 declaration of conformity
- Software testing as part of verification and validation
- Software version history
- Unresolved software anomalies
Enhanced documentation adds more detail, such as a software design specification and fuller testing records, including unit and integration testing.
How do you build FDA-compliant software from the start?
You build FDA-compliant software by designing compliance into every stage of development, not adding it at the end. These 10 steps follow the FDA’s current expectations.
1. Define intended use and user needs
Intended use is the statement of what the software does, for whom, and in what setting. It drives your classification, risk analysis, and testing, so write it before you write code.
- Document the users, the clinical setting, and the medical purpose.
- Keep marketing claims inside the documented intended use.
2. Set up a quality management system under QMSR
The Quality Management System Regulation is the FDA’s quality rule for device makers. Since February 2, 2026, 21 CFR Part 820 incorporates ISO 13485:2016 by reference, so your QMS should be built around that standard.
- Cover design controls, document control, supplier control, and corrective actions.
- Expect FDA inspections to follow the new QMSR inspection approach.
3. Follow a documented software life cycle
A documented software life cycle shows how you plan, build, test, release, and maintain the software. Most teams follow IEC 62304, the international standard for medical device software life cycle processes.
- Agile works, as long as each sprint produces the required records.
- Keep a traceability matrix linking requirements, risks, code, and tests.
4. Apply design controls
Design controls are the planned checks that prove the software meets user needs. They cover design inputs, outputs, reviews, verification, validation, and changes.
- Use strict version control and change management.
- Keep your design and development records in the QMS. Under QMSR, the ISO 13485 design and development file takes the place of the old design history file.
5. Manage risk from day one
Risk management means finding what could go wrong, judging how bad it would be, and reducing it. ISO 14971:2019, the standard for applying risk management to medical devices, is the method the FDA recognizes.
- Include software failure, misuse and cybersecurity threats.
- Update the risk file every time the software changes.
6. Verify and validate the software
Verification checks that you built the software right, and validation checks that you built the right software. Both need written protocols and results.
- Verification: unit, integration and system tests against requirements.
- Validation: user or clinical testing that the software meets user needs in real conditions.
7. Build in cybersecurity
Cybersecurity is a required part of the FDA’s safety review for connected devices. Section 524B, explained in the FDA’s 2025 premarket cybersecurity guidance, requires cyber devices to include a software bill of materials (SBOM) and a plan to monitor and fix vulnerabilities.
- Use threat modeling, encryption, access controls, and secure updates.
- Plan for coordinated vulnerability disclosure after launch.
8. Control electronic records and signatures
Electronic records that the FDA requires you to keep must be trustworthy and auditable. 21 CFR Part 11 on electronic records and signatures sets the rules for audit trails, access controls, and e-signatures.
- Patient privacy is a separate issue, covered by HIPAA. Plan for HIPAA compliance testing alongside FDA work.
9. Talk to the FDA early
The Q-Submission program lets you ask the FDA about classification, testing, and predicates before you submit. Early feedback is free to request and reduces the risk of a rejected or delayed submission.
- Prepare specific questions, not a general product pitch.
- Bring your intended use, risk analysis, and test plan.
10. Plan for post-market updates
Approval or clearance is not the end of compliance. You must track complaints, report adverse events, manage vulnerabilities and assess whether each software change needs a new submission.
- Document every change and its risk impact.
- For AI models, plan updates in advance with a predetermined change control plan.
What extra rules apply to AI-enabled software?
AI-enabled device software follows the same rules, plus guidance on how models can change after clearance. The key tool is the predetermined change control plan (PCCP), which describes planned model updates and how you will validate them.
The FDA finalized its PCCP guidance for AI-enabled device software functions in December 2024. With an authorized PCCP, you can make the described changes without a new 510(k) or De Novo. For deeper detail, see our breakdown of the FDA’s AI and ML guidelines and the steps in AI medical device software development.
What common mistakes should developers avoid?
The most common mistake is assuming the product is “just an app” and discovering late that it is a regulated device. Most other mistakes come from missing records rather than bad code.
- Making medical claims in marketing that the intended use and testing do not support.
- Picking the wrong class or pathway because no one checked predicate devices.
- Writing documentation after development instead of during it.
- Treating risk management as a one-time task.
- Leaving out cybersecurity, which can lead to a refused submission for cyber devices.
- Calling a cleared product “FDA approved.”
- Shipping software updates without assessing whether they need a new submission.
How can a development partner help?
A development partner with healthcare experience can set up compliant processes, documentation, and testing from the first sprint. That leaves your regulatory lead free to focus on strategy and FDA communication.
Look for a team that has built regulated healthcare software, works inside a documented QMS, and can produce traceability and test evidence on request. Ailoitte is one option as a healthcare app development company for teams that need engineering support alongside their regulatory advisors.
If you are building a new product, the guide on how to build a healthcare app covers the wider build process, and our walkthrough on launching an FDA-cleared app covers the launch steps.
Summing up
FDA guidelines for software development apply when your software’s intended use makes it a medical device. In 2026, that means building under the new QMSR, documenting at the Basic or Enhanced level, planning cybersecurity for connected devices, and choosing the right pathway, usually 510(k) or De Novo. Teams that define intended use early and document as they build avoid the costliest delays.
Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 5× faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering.
About Ailoitte
