Clinical Decision Support Software: FDA Regulation and Exemptions

Clinical Decision Support Software: FDA Regulation and Exemptions

Key Takeaways

The Regulatory Problem CDS Addresses

Clinical decision support software occupies a regulatory gray zone within the broader SaMD regulatory landscape. Many CDS applications provide information to healthcare professionals that could influence clinical decisions, but the software does not directly diagnose or treat patients. Before the 21st Century Cures Act, the regulatory status of CDS software was uncertain, creating compliance challenges for both developers and healthcare institutions.

The challenge: if all software that provides clinical information is regulated as a medical device, the regulatory burden would extend to electronic health record (EHR) systems, clinical guidelines databases, drug interaction checkers, and many other widely used health IT tools. Conversely, if no CDS is regulated, high-risk autonomous diagnostic software could avoid regulatory oversight.

The Cures Act attempted to draw a line between CDS that should be regulated (because it replaces or supplants clinical judgment) and CDS that should be exempt (because it supports clinical judgment while maintaining the healthcare professional's independent role).

The 21st Century Cures Act, Section 3060

Section 3060 of the 21st Century Cures Act (Public Law 114-255, December 13, 2016) amended Section 520(o) of the FD&C Act to exclude certain software functions from the definition of a medical device. The CDS exclusion is one of several software function exclusions created by the Cures Act.

The Four Criteria

For CDS software to qualify for the Cures Act exclusion, it must meet ALL FOUR of the following criteria:

Criterion 1: The software function is NOT intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system.

Criterion 2: The software function IS intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as clinical evidence, clinical guidelines, or patient-specific information from a patient's health record).

Criterion 3: The software function IS intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition.

Criterion 4: The software function IS intended for the purpose of enabling such healthcare professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such healthcare professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient without independently reviewing the basis for such recommendations.

Critical Interpretation Points

All four criteria are conjunctive. The software must satisfy every criterion. Failing any single criterion means the software does not qualify for the CDS exclusion and may be regulated as a medical device.

Criterion 1 is a negative requirement. The software must NOT process medical images or IVD signals. This criterion excludes all radiological AI, pathology AI, and IVD data interpretation software from the CDS exemption, regardless of whether the other three criteria are met.

Criterion 4 is the "transparency" requirement. The software must enable the healthcare professional to understand why the recommendation was made, so the professional can exercise independent clinical judgment. Software that provides a recommendation without explaining the underlying logic or data does not meet this criterion.

FDA Guidance on CDS

The January 2026 Final Guidance

FDA issued the final guidance "Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff" in January 2026. That document describes FDA's current interpretation of the statutory CDS criteria and includes examples of software functions that may fall inside or outside the section 520(o)(1)(E) exclusion.

Criterion 1: Not Acquiring, Processing, or Analyzing Images or Signals

FDA interprets "acquire, process, or analyze" broadly:

Acquiring: Capturing or receiving a medical image or signal directly from a device or imaging system. Software that receives raw DICOM data from a CT scanner is acquiring a medical image.

Processing: Performing any computational operation on a medical image or signal, including filtering, enhancement, compression, segmentation, or registration. Software that applies a noise reduction filter to an ultrasound image is processing a medical image.

Analyzing: Interpreting or extracting clinical information from a medical image or signal. Software that identifies regions of interest in a pathology slide is analyzing a medical image.

What counts as a "medical image": FDA interprets "medical image" broadly to include radiological images (X-ray, CT, MRI, ultrasound, PET), pathology images (histology, cytology), dermatological images (clinical photographs used for diagnosis), ophthalmologic images (fundus photos, OCT), and any other visual representation of anatomical or physiological data acquired for clinical purposes.

What counts as a "signal from an IVD device": Output data from in vitro diagnostic devices, including quantitative test results, waveforms, and raw analytical signals.

What counts as a "signal from a signal acquisition system": Physiological signals such as ECG, EEG, EMG, pulse oximetry, and other electronic monitoring data.

Consequence: Any software that processes images or signals fails Criterion 1, regardless of the software's other characteristics. This single criterion excludes all AI/ML-based image analysis, all signal interpretation software, and all IVD data analysis software from the CDS exemption.

Criterion 2: Displaying, Analyzing, or Printing Medical Information

This criterion requires that the software work with "medical information," which FDA interprets to include:

• Patient-specific clinical data from health records
• Clinical evidence (published literature, meta-analyses)
• Clinical practice guidelines
• Drug formulary information
• Laboratory reference ranges
• Population health data and epidemiological information

The software must actively display, analyze, or present this information, not simply store or transmit it (storage and transmission are covered by a separate Cures Act exclusion).

Criterion 3: Supporting or Providing Recommendations to Healthcare Professionals

This criterion requires that:

1. The software provides recommendations (not just data)
2. The recommendations are directed to healthcare professionals (not patients or non-clinical users)
3. The recommendations relate to prevention, diagnosis, or treatment

Healthcare professional limitation: CDS software directed at patients or non-clinical users does not meet Criterion 3, even if the information provided is identical to what would be provided to a healthcare professional. Software intended for patient self-diagnosis is not CDS-exempt.

Recommendation vs. directive: The software must provide recommendations that the healthcare professional considers, not directives that automate clinical decisions. Software that automatically adjusts a drug dose without clinician review is not "supporting or providing recommendations."

Criterion 4: Enabling Independent Review of the Basis

This is the most complex and nuanced criterion. FDA's guidance identifies several key elements:

"Independently review the basis": The healthcare professional must be able to understand WHY the software made the recommendation. The software must provide enough information for the professional to evaluate the recommendation's validity using their own clinical judgment and knowledge.

What constitutes sufficient basis:

"Not the intent that such healthcare professional rely primarily on": The software must not be designed so that the healthcare professional is expected to follow the recommendation without independent evaluation. Features that suggest primary reliance include:

• Automatic execution of recommendations without confirmation
• User interface designs that make it difficult to override recommendations
• Workflow integration that assumes acceptance of recommendations
• Marketing claims suggesting the software replaces clinical judgment

Time-Critical CDS

FDA's guidance addresses time-critical CDS specifically. Some CDS operates in time-critical clinical situations where delaying action to review the basis for a recommendation could harm the patient (e.g., sepsis alerts, critical lab value notifications, drug allergy alerts).

FDA's position: time-critical CDS is not automatically excluded from the Cures Act exemption, but the practical reality of time pressure may make it difficult to satisfy Criterion 4. If the clinical situation does not allow time for independent review, the software is designed for primary reliance rather than supported decision-making.

FDA has indicated that some time-critical CDS can still meet Criterion 4 if the basis for the recommendation is presented concurrently and can be rapidly assessed (e.g., a drug allergy alert that displays the specific allergy from the patient record alongside the recommendation to change the medication).

Examples: Exempt vs Non-Exempt CDS

Exempt CDS (Meets All Four Criteria)

Non-Exempt CDS (Fails One or More Criteria)

Borderline Cases

Implications for Software Developers

Self-Assessment Framework

Developers should systematically evaluate each criterion:

Step 1 (Criterion 1): Does the software receive, process, or analyze any medical image, IVD signal, or physiological signal?

• If yes: STOP. The software is not CDS-exempt. Proceed with device regulatory pathway.
• If no: Continue to Step 2.

Step 2 (Criterion 2): Does the software display, analyze, or print medical information about a patient or other medical information?

• If yes: Continue to Step 3.
• If no: The software may qualify for a different Cures Act exclusion (data display, EHR, etc.) but does not qualify as CDS-exempt.

Step 3 (Criterion 3): Does the software support or provide recommendations to a healthcare professional about prevention, diagnosis, or treatment?

• If yes: Continue to Step 4.
• If no: Not CDS. May be a general health information tool (potentially exempt under a different exclusion) or may be a device.

Step 4 (Criterion 4): Does the software enable the healthcare professional to independently review the basis for the recommendation?

• If yes, and the software is not designed for primary reliance: CDS-exempt.
• If no, or if the software is designed for primary reliance: Not CDS-exempt. May be regulated as a device.

Documentation Requirements

Even though CDS-exempt software is not regulated as a medical device, developers should maintain documentation of their CDS exemption analysis:

When CDS-Exempt Status Changes

Software that initially qualifies as CDS-exempt can lose that status through modifications:

FDA's Evolving Position on CDS

Areas of Ongoing Discussion

FDA has acknowledged that the Cures Act CDS criteria create interpretive challenges. Areas where FDA's position continues to evolve include:

Machine learning-based CDS: Software that uses ML algorithms to generate recommendations may struggle with Criterion 4 if the ML model is not inherently interpretable. FDA has indicated that for ML-based CDS, the basis for the recommendation must be presented in a way the healthcare professional can evaluate, even if the underlying algorithm is complex.

Population health analytics: Software that analyzes population-level data to recommend resource allocation or care management strategies may or may not meet the CDS criteria, depending on whether it provides patient-specific recommendations to healthcare professionals.

Genomic decision support: Software that interprets genetic variants and recommends treatments occupies a complex space. If the software processes raw sequencing data, it may fail Criterion 1. If it receives pre-processed variant calls and provides guideline-based treatment recommendations with cited evidence, it may qualify as CDS-exempt.

Congressional and Stakeholder Interest

There is ongoing debate about whether the Cures Act criteria appropriately balance innovation and safety. Some stakeholders argue that Criterion 1 is too restrictive (excluding beneficial image-based CDS from exemption), while others argue that Criterion 4 is too permissive (allowing complex algorithms that healthcare professionals cannot meaningfully evaluate).

FDA has noted that it continues to monitor the CDS landscape and may update its guidance as technology evolves and real-world experience accumulates.

Relationship to Other Cures Act Exclusions

The CDS exclusion is one of several software function exclusions under Section 520(o). Other relevant exclusions include:

Software that does not qualify for the CDS exclusion may still qualify for one of the other exclusions. The exclusions are independent and should each be evaluated separately.

Key Regulatory References

References