
Understanding the FDA's 2026 Clinical Decision Support Software Guidance: What Medical Device Companies NTK
Table of Contents
In February 2026, the FDA quietly redrew the map for Clinical Decision Support (CDS) software. The core framework didn't change. The four criteria from the 21st Century Cures Act still stand. But the agency's updated guidance introduced enforcement discretion for single clinically appropriate recommendations, explicit automation bias language, and prescriptive transparency requirements that didn't exist before.
For teams that built CDS products under the 2022 guidance, this necessitates evaluating if the classification rationale still holds.
Many organizations built CDS tools assuming they fell outside FDA oversight. Some were right. Others are about to discover that the 2026 guidance's expanded examples and sharper definitions have moved their product from "probably non-device" into regulated territory. The cost of getting this wrong isn't theoretical: it's a redesign, a delayed launch, or an unplanned conversation with the FDA.
As software becomes deeply embedded in clinical workflows, CDS systems are rapidly shaping how healthcare decisions are made. From risk calculators and diagnostic algorithms to AI-powered recommendations, CDS tools are now central to modern healthcare delivery.
However, with increased influence comes increased regulatory scrutiny. Many organizations build CDS tools assuming they are not regulated medical devices, only to later discover they fall under FDA oversight. Understanding the FDA's CDS guidance is now essential for developers, quality teams, regulatory professionals, and digital health leaders.
This blog provides a complete introduction to CDS for beginners, explains the key differences between the FDA's 2022 and 2026 CDS guidance, and breaks down how to build a classification strategy that holds up under the new guidance.
What Is Clinical Decision Support (CDS)?
Clinical Decision Support (CDS) refers to software that provides information, recommendations, or insights to support clinical decision-making.
CDS systems are designed to assist healthcare professionals in making informed decisions about diagnosis, treatment, disease prevention, care management, and patient monitoring.
Examples of CDS tools include:
- Drug - drug interaction alerts
- Algorithms that analyze radiology images
- Software that suggests treatment options based on patient history
- Risk stratification dashboards for chronic disease management
Not all CDS is regulated. The regulatory status depends on how the software functions and how users rely on it.
Why FDA Regulates CDS?
CDS software can directly influence clinical decisions. When software meaningfully impacts diagnosis or treatment, patient safety risks increase.
To address this, the U.S. Congress included provisions for CDS in the 21st Century Cures Act (2016). This law created a category of CDS that could be excluded from regulation as a medical device, but only if specific criteria are met.
FDA's CDS guidance documents explain:
- Which CDS functions may be exempt from regulation
- Which CDS functions are considered medical devices
- How manufacturers should interpret and apply the law
As technology evolved, particularly with the rise of AI/ML, the FDA updated its interpretation, resulting in ido themportant clarifications between the 2022 and 2026 guidance.
The Four Legal Criteria for Non-Device CDS
CDS vs SaMD
CDS and SaMD often overlap but are not identical.
Non-device CDS: Software that meets all four criteria and is not regulated as a medical device.
Device CDS (regulated SaMD): CDS that fails one or more criteria and therefore qualifies as Software as a Medical Device (SaMD), subject to FDA regulation.
For example, a rule-based checklist that references clinical guidelines and clearly shows its logic may qualify as non-device CDS, an AI model that outputs a diagnosis without enabling clinicians to understand the reasoning likely qualifies as regulated SaMD.
Overview of the 2022 FDA CDS Guidance
The 2022 guidance represented the FDA's comprehensive interpretation of how CDS should be regulated under the Cures Act framework. It established:
- Clear examples of regulated vs non-regulated CDS
- The requirement for meaningful transparency and independent reviewability
- Recognition that CDS risk depends on how it is used in clinical practice
- Acknowledgement of emerging technologies such as AI/ML
- The principle that proprietary algorithms still need to provide adequate background information
The 2022 guidance provided a solid foundation, but as the FDA gained more experience reviewing digital health and AI-enabled submissions, it identified opportunities for enhanced clarity.
Why was the FDA issue updated CDS Guidance in 2026?
Between 2022 and 2026, the FDA observed:
- Growing complexity in AI/ML implementations
- Need for more specific examples to guide the industry
- Questions about single clinically appropriate recommendations
- Need for clearer distinction between patterns and discrete measurements
- Importance of addressing time-critical decision-making explicitly
- Evolving landscape of genomic and precision medicine applications
The 2026 guidance builds on the 2022 framework with enhanced clarity, expanded examples, and important new policies.
Key Differences Between the 2022 and 2026 CDS Guidance
1. Introduction of Enforcement Discretion for Single Clinically Appropriate Recommendations
2022 Guidance: Criterion 3 required software to provide recommendations that support rather than replace clinical judgment. The guidance suggested that software providing a single specific output or directive would typically fail this criterion.
2026 Guidance: Introduces a significant new policy:
"If only one option is clinically appropriate and the software function otherwise meets all criteria under section 520(o)(1)(E), FDA intends to exercise enforcement discretion for such functions."
Examples where enforcement discretion may apply:
- Software recommending a specific FDA-approved antibiotic based on patient symptoms and antibiotic history
- A tool that classifies patients with chronic low back pain into a single appropriate clinical care pathway
- Software providing one diagnostic recommendation when alternative diagnoses are highly improbable
Important limitations:
- Does not apply to time-critical decisions
- Does not apply when using unvalidated or experimental data sources
- Does not apply to acute or emergent conditions requiring immediate intervention
2. Expanded Examples
2022 Guidance: Provided approximately 12-15 examples across different categories.
2026 Guidance: Includes 32 detailed device software function examples in Section V.C alone, plus numerous additional examples throughout the document illustrating non-device CDS.
Why this matters: The expanded examples provide unprecedented specificity, helping developers understand exactly where regulatory lines are drawn. For instance:
- Pattern vs. discrete measurement: Five sequential RR interval measurements from Holter data = pattern (device) vs. single blood pressure reading = medical information (potentially non-device)
- Time sensitivity: Predicting 90-day post-transplant mortality (non-device CDS eligible) vs. predicting intraoperative mortality (device due to time-critical nature)
- Data source type: Using radiologist's clinical findings report (medical information) vs. analyzing the actual medical images (device)
3. More Explicit Guidance on "Patterns" vs. Discrete Measurements
2022 Guidance: Mentioned patterns under Criterion 1, but without extensive detail about the distinction from discrete measurements.
2026 Guidance: Provides a clear definition:
"Discrete, episodic, or intermittent point-in-time physiological measurements generally do not, by themselves, constitute a pattern."
Specific clarifications:
- ECG QRS complexes = pattern (device)
- Genetic sequences from NGS = pattern (device)
- Repeated glucose measurements from CGM = pattern (device)
- Single blood glucose lab result = medical information (potentially non-device)
- Five sequential RR intervals = pattern (device)
- Hourly pulse oximetry measurements = pattern (device)
4. Enhanced and More Prescriptive Criterion 4 Requirements
2022 Guidance: Established that software must enable independent review of the basis for recommendations, and that proprietary algorithms still need adequate transparency.
2026 Guidance: Provides substantially more prescriptive recommendations for what "independently review the basis" actually means:
a) Purpose and Intended Use Clarity:
- Must clearly identify the intended HCP user and patient population
- Must state if use is time-critical (which would disqualify it from non-device CDS)
b) Input Data Requirements:
- Plain language instructions on how inputs should be obtained
- Explanation of the relevance of each input
- Data quality requirements
c) Algorithm Transparency: Must include a plain language description of:
- General approach (meta-analysis, expert panel, statistical modeling, AI/ML techniques)
- Data representativeness for the target population
- Clinical validation study results showing performance and limitations
d) Output Contextualization:
- Relevant patient-specific information
- Identification of missing, corrupted, or unexpected data
- Known limitations or uncertainties
New addition: "In some cases, developers may need to perform usability testing to evaluate if their implementation meets Criterion 4."
5. Significantly Enhanced Genomic and Precision Medicine Guidance
2022 Guidance: Mentioned genomic applications, but with limited specific examples.
2026 Guidance: Provides detailed clarification:
- VCF (variant call format) files from NGS analyzers are considered patterns → software analyzing these fails Criterion 1
- Software that analyzes genetic sequences or their clinical implications fails Criterion 1
- However, software using results from FDA-authorized IVD tests (when used consistently with FDA labeling) as medical information may meet Criterion 2
Examples:
- Software enabling HCPs to input specific EGFR mutation results from an FDA-authorized test and identifying FDA-approved treatments = potentially non-device CDS
- Software analyzing variant genomic data without established clinical relevance = device
- Software using VCF files to provide treatment recommendations = device
6. Consistent Treatment of Patient-Facing CDS
Important clarification: Both the 2022 and 2026 guidance state clearly that software providing recommendations to patients or caregivers (not HCPs) meets the definition of a device. This has not changed.
Both versions state:
"Software functions that support or provide recommendations to patients or caregivers, not HCPs, meet the definition of a device."
However, both versions also note: FDA intends to be consistent with existing policies.
7. More Granular Risk-Based Examples and Contextual Analysis
2026 Guidance additions:
- Sub-examples showing when a base scenario would or would not qualify for enforcement discretion
- Explicit discussion of data quality and source validation requirements
- Clear distinction between analyzing clinical findings vs. analyzing raw data (images, signals, patterns)
Example format in 2026: Main scenario, followed by "However, a software function with the same functionality, but [specific variation] would not fall under this example."
This format helps developers understand the boundaries and edge cases more precisely.
What Hasn't Changed
It's equally important to understand what has remained consistent:
- The four-criteria framework is unchanged
- The requirement for transparency, regardless of algorithm complexity was present in both versions
- Patient-facing CDS as devices was already clear in 2022
- Focus on actual functionality over labeling alone has been the FDA's approach throughout
- Risk-based evaluation principles remain consistent
The 2026 guidance builds upon and clarifies the 2022 framework rather than replacing it with a fundamentally different approach.
Challenges in CDS Development and Compliance
Explainability and Transparency
Designing systems that are both powerful and interpretable remains challenging, especially for complex AI/ML models. Both guidance versions require meaningful transparency; the 2026 version simply provides more specific expectations.
Regulatory Classification Uncertainty
Misclassifying CDS can lead to enforcement risk, delayed approvals, or product redesign.
Human Factors and Usability
The 2026 guidance repositioned the automation bias analysis from Criterion 3 to Criterion 4, underscoring the importance of designing interfaces that enable, rather than replace, clinical judgment
Lifecycle Management
As CDS systems evolve, particularly adaptive AI/ML systems, maintaining compliance through updates becomes increasingly complex.
Time-Critical vs. Non-Time-Critical Design
Developers must carefully consider whether their software will be used in time-pressured situations where independent review is impractical.
The CDS Development Lifecycle for regulated products
For CDS that qualifies as SaMD, organizations must implement robust lifecycle controls, including:
- Requirements Definition
- Defining intended use and regulatory classification
- Establishing design controls and requirements traceability
- Risk Management
- Risk management aligned with ISO 14971
- Specific consideration of automation bias and time-critical use
- Design and Development
- Software lifecycle controls (IEC 62304)
- Algorithm development with appropriate transparency mechanisms
- Documentation of data sources, validation approaches, and limitations
- Verification and Validation
- Verification that implementation matches specifications
- Clinical validation of algorithm performance
- Validation across relevant sub-populations
- Human Factors Engineering
- Usability testing (IEC 62366)
- Evaluation of whether Criterion 4 is met in practice
- Assessment of automation bias risks
- Post-Market Activities
- Post-market surveillance
- Change management for algorithm updates
- Monitoring of real-world performance
How Ketryx Can Help Companies Building CDS Software
For teams building CDS that qualifies as SaMD, the 2026 guidance clarifies the rules and raises the standard for what is sufficient as "compliant". Criterion 4's new prescriptive requirements turn algorithm transparency from a best practice into a documentation obligation, and the expanded examples mean fewer products can claim ambiguity as a defense. Thus, the challenge is building systems that keep up with FDA expectations as product evolves, algorithms update, and clinical evidence grows.
Because of the 2026 guidance's enhanced Criterion 4 requirements, organizations need systems that can:
Maintain comprehensive traceability:
- Link requirements to risks, design decisions, code, validation tests, and labeling
- Document algorithm development approaches and data sources
- Track validation study results and performance across sub-populations
Generate required documentation:
- Algorithm development and validation summaries
- Plain language explanations of how inputs relate to outputs
- Data representativeness and quality documentation
- Clinical validation study reports
Support lifecycle management:
- Change control for algorithm updates
- Version control with full audit trails
- Integration with development tools (Jira, GitHub, CI/CD pipelines)
- Support for IEC 62304, ISO 14971, and FDA design control expectations
Enable efficient compliance:
- Automated documentation generation for audits and submissions
- Real-time synchronization across development and quality systems
- Streamlined change management for evolving algorithms
Ketryx helps organizations developing CDS by embedding compliance directly into development workflows, allowing teams to move faster while maintaining confidence in regulatory readiness.
Practical Guidance for CDS Developers
Step 1: Determine Your Classification
Step 2: Document Your Rationale
Regardless of your conclusion, document:
- How your software maps to each criterion
- Your interpretation of edge cases
- Why you believe you do or don't meet each criterion
Step 3: Engage with FDA Early (If Uncertain)
If your classification is unclear:
- Consider a Pre-Submission (Q-Submission)
- FDA feedback can provide valuable clarity
- Early engagement reduces downstream risk
Step 4: Build Appropriate Quality Systems
If regulated as a device:
- Implement design controls
- Establish risk management processes
- Develop verification and validation protocols
- Plan for human factors evaluation
- Establish post-market surveillance
If non-device CDS:
- Still implement appropriate software development practices
- Maintain documentation supporting Criterion 4 compliance
- Consider that FDA's interpretation may evolve
Common Misconceptions About CDS Regulation
Misconception 1: "AI/ML CDS can't be non-device CDS." Reality: AI/ML CDS can qualify as non-device CDS if it meets all four criteria, including providing sufficient transparency for independent review. It's harder but not impossible.
Misconception 2: "The 2026 guidance fundamentally changed the rules." Reality: The 2026 guidance clarified, expanded, and enhanced the 2022 framework. The core principles remained consistent.
Misconception 3: "If our labeling says it's for HCP support only, we're exempt." Reality: FDA evaluates actual functionality and likely use, not just labeling claims.
Misconception 4: "Non-device CDS doesn't need quality systems." Reality: While not subject to medical device regulations, good software development practices are still essential for safety and effectiveness.
Final Thoughts
If you're new to CDS regulation, the most important takeaway is this:
The 2022 guidance established a comprehensive framework. The 2026 guidance enhanced it with greater clarity, expanded examples, and important new policies.
The FDA evaluates CDS based on what data it uses, how it's intended to be used, whether clinicians can meaningfully review its recommendations, whether the use is time-critical, and actual functionality, not just labeling. The enforcement discretion policy is the biggest practical shift: a pragmatic recognition that sometimes only one option is clinically appropriate.
Understanding this guidance is no longer optional. It's foundational to building safe, scalable, and compliant healthcare technology. The most significant new development in 2026 is the enforcement discretion policy for single clinically appropriate recommendations a pragmatic recognition of clinical reality that provides clearer pathways for certain CDS tools.
The 2026 updates mean the bar for traceability, documentation, and transparency is higher than it's ever been.
Ketryx helps teams meet that bar. It overlays your existing tools, Jira, GitHub, TestRail, to generate audit-ready documentation as an artifact of development, not a separate workstream. For CDS teams, that means algorithm transparency records, data representativeness documentation, and clinical validation summaries linked automatically, exactly what the 2026 guidance demands under Criterion 4.
Building new CDS? Map your product against the four criteria using the 2026 guidance's expanded examples before you write code. Document your classification rationale early.
Existing products classified under 2022? Pressure-test your Criterion 4 documentation against the new prescriptive requirements and check the patterns vs. discrete measurements clarification.
Uncertain? The 32 detailed examples in Section V.C are the most specific mapping FDA has ever published. Start there. If your use case doesn't clearly match, engage FDA early. A Pre-Submission costs a fraction of a late reclassification.
The regulatory landscape will keep evolving, but the principles hold: transparency, safety, and keeping clinical judgment central to patient care.

Yashaswini Maregowda is a Client Operations Associate Intern in Quality and Regulatory at Ketryx. With a background in regulatory affairs, biomedical engineering and hands-on experience in QMS compliance for AI/ML enabled SaMD and GxP products, she has supported gap analyses and regulatory documentation aligned with ISO 13485, ISO 14971, IEC 62304 and FDA QMSR. Passionate about bridging regulatory strategy with product development, she thrives on collaborating with cross-functional teams to enhance compliance, quality, and patient safety across medical device lifecycles.


