One of the most common questions from healthcare technology teams building AI-powered tools is whether their product will be regulated as a medical device by the FDA. The answer is nuanced, but the FDA's Clinical Decision Support (CDS) guidance provides a clear framework for understanding where the regulatory boundary lies.
The 21st Century Cures Act, signed in 2016 and further clarified by FDA guidance in September 2022, excludes certain types of CDS software from the definition of a medical device. If your software meets all four criteria in the exclusion, it is not subject to FDA medical device regulation. If it fails any one of the four, it may be regulated.
The Four Criteria for CDS Exemption
To qualify as non-device CDS under the Cures Act, your software must meet all four of these criteria:
Criterion 1: Not intended to acquire, process, or analyze a medical image or signal
If your software processes imaging data (X-rays, MRIs, CT scans, pathology slides) or physiological signals (EKG waveforms, continuous glucose monitoring), it does not qualify for the CDS exemption. Period. This criterion is binary and has no gray area.
For formulary management and drug information systems, this criterion is straightforward to meet. These systems work with drug data, pricing information, clinical guidelines, and utilization data, none of which constitute medical images or signals.
Criterion 2: Intended for the purpose of displaying, analyzing, or printing medical information
The software must support one or more of these functions: displaying, analyzing, or printing medical information about a patient or other medical conditions. Most clinical and healthcare technology software meets this criterion easily.
Criterion 3: Intended for use by a healthcare professional
The software must be intended for use by healthcare professionals (HCPs), not patients or general consumers. A formulary management tool used by pharmacists and formulary analysts qualifies. A patient-facing medication management app may not, depending on its functionality.
The FDA's guidance makes an important distinction here. The intended user does not have to be a physician. Pharmacists, nurses, pharmacy technicians, and other licensed healthcare professionals qualify. The key is that the user has the training and context to independently evaluate the software's recommendations.
Criterion 4: Intended to enable the HCP to independently review the basis for the recommendation
This is the criterion that trips up most AI-powered systems. The software must present its recommendations in a way that enables the healthcare professional to independently evaluate and verify the basis for the recommendation. The system cannot be a "black box" that simply says "do this" without showing its work.
For AI systems, this means:
- The system must show the data sources it used to generate a recommendation
- The reasoning chain must be transparent (why this recommendation and not another)
- The HCP must be able to reach their own conclusion based on the information provided
- The system should present recommendations as suggestions, not directives
What This Means for Healthcare AI
The practical implication is that most formulary management, drug information, and clinical decision support tools can be built without FDA device regulation, as long as they are designed correctly. The design requirements are:
- Show your sources. When the system recommends a formulary placement or flags a drug interaction, cite the specific data sources (FDA label, clinical guideline, utilization data) that informed the recommendation.
- Show your reasoning. Do not just surface the conclusion. Show the intermediate steps. "Drug X is recommended for Tier 2 because: similar efficacy to Tier 1 alternative Y (PMID: 12345678), 35% cost advantage, and no additional safety signals in FAERS data."
- Keep the human in the loop. The system recommends. The HCP decides. Never auto-execute clinical decisions without professional review.
- Target HCP users. Design the interface and documentation for healthcare professional users. If you also want a patient-facing version, that may need separate regulatory analysis.
Examples: In and Out of Scope
Systems that typically qualify for the CDS exemption:
- Formulary analysis tools that recommend tier placements with supporting evidence
- Drug interaction checkers that flag potential interactions with clinical citations
- Prior authorization support tools that present relevant clinical guidelines
- Utilization review dashboards that highlight outlier prescribing patterns
Systems that likely do NOT qualify:
- AI that autonomously adjusts medication dosing based on lab values (no independent review)
- Systems that process medical images to recommend diagnoses
- Patient-facing apps that recommend treatments without HCP intermediation
- Any system marketed as providing autonomous clinical decisions
Documentation and Risk Management
Even if your system qualifies for the CDS exemption, good practice dictates maintaining documentation of your regulatory analysis. Document why you believe each of the four criteria is met, and maintain this analysis as the product evolves. Feature changes that seem minor from an engineering perspective (like adding a patient-facing view or removing the evidence citations for "cleaner UX") can change your regulatory classification.
The CDS exemption is a powerful enabler for healthcare technology innovation. It allows teams to build sophisticated AI-powered tools that support clinical decisions without the cost and timeline of FDA clearance. The key is designing the system correctly from the start, with transparency and professional review as architectural requirements rather than afterthoughts.