The digital health landscape is undergoing a seismic shift—and January 2026 marked a major milestone. The U.S. Food and Drug Administration (FDA) released two transformative guidance documents, one focused on Clinical Decision Support (CDS) software and the other on General Wellness Products. These new policies redraw the regulatory lines for what qualifies as a “medical device,” and where the FDA is willing to exercise its enforcement discretion, opening a wide lane for health tech developers building in the CDS, wellness, longevity, and wearable tech space.
This two-part series breaks down the 2026 updates and what they mean for your business. Whether you're designing clinical software or consumer wellness tools, the implications are huge. The updated guidance doesn't just tweak definitions—it significantly expands the boundaries for innovation, allowing some technologies previously considered “devices” to now fall outside FDA oversight entirely.
Part One focused on General Wellness Products and the opportunities created by the 2026 wellness guidance revision. The FDA has clarified and, crucially, loosened restrictions around non-invasive physiological tracking, labeling practices, and low-risk devices.
In Part Two, we'll walk through the statutory definition of non-device CDS, how FDA's thinking has evolved since 2019, and what the 2026 changes mean in practice. The goal is to give founders, product managers, and regulatory teams a practical checklist: how to structure your CDS features so they qualify as non-device software under FDA law—or, if they don't, how to understand the associated regulatory risk.
Like the wellness guidance, the CDS guidance refines where the agency draws the line between regulated "medical devices" and non-device software functions. For companies building AI diagnostics, care-navigation tools, triage algorithms, or provider-facing analytics, the CDS guidance is a roadmap for how to design powerful clinical tools that stay outside FDA device regulation or, at a minimum, benefit from a far lighter enforcement posture. To take advantage of expanded opportunity in this space, you need to understand how the FDA thinks about software as a medical device (SAMD), and exactly where the 2026 CDS guidance relaxes (and tightens) prior expectations.
OK, let’s dig into what the latest FDA CDS guidance means for your B2B digital health tool.
Clinical Decision Support: The FDA Carve-Out Powering Clinical AI
To understand the framework for evaluating CDS in light of the latest guidance, it helps to zoom out first. In 2016, the 21st Century Cures Act amended the definition of “device” in the Federal Food, Drug, and Cosmetic Act (FD&C Act) to exclude certain software functions. Congress explicitly carved out, among other things, certain general wellness products, medical device data management tools, and CDS software. The FDA’s task over the last several years has been to translate those statutory carve-outs into practical rules that software developers can actually apply.
FDA’s first step in implementing the Cures Act for CDS was its April 2019 guidance, “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act,” which explained how Section 520(o) would reshape several existing software policies, including CDS. That same year, they released draft CDS guidance, and then published the revised final CDS guidance on September 28, 2022. That 2022 document narrowed what the FDA considered “non-device” CDS and led many developers to more precisely evaluate whether their tools were actually outside device regulation. The January 2026 CDS guidance replaces the 2022 version and most significantly re-opens a previously closed lane for non-device CDS.
The 2026 guidance refines and partially relaxes the 2022 framework in light of real-world implementation challenges and the rapid evolution of AI-enabled clinical software. Specifically, it includes the following updates:
- clarification that displaying multiple discrete, point-in-time physiological measurements generally do not constitute a "pattern" under Criteria 1, potentially allowing more software to qualify;
- removal of "sampling frequency" as an explicit consideration for what constitutes "medical information"; and
- most significantly, the FDA now exercises enforcement discretion for software that provides a single specific clinically appropriate recommendation, removing prior restrictions that forced companies to provide multiple options even where only one was clinically appropriate. This last change makes it substantially easier for CDS software to provide precise, actionable guidance to healthcare professionals while still qualifying for the non-device exemption.
Just as with wellness products, the 2026 CDS framework is all about how you position and architect your product: who the software is for, what data it ingests, what type of recommendations it generates, and how transparently it explains its logic to clinicians. Done right, the new guidance creates a wide lane for decision support that is meaningful, precise, and often AI-enabled—without automatically becoming a regulated device. Done poorly, small drafting choices in your marketing, UI, or technical design can convert your CDS into a medical device that triggers clearance or approval requirements.
Wait a minute, is my software even considered a medical device?
I realize I didn’t cover this in Part One, and it’s actually an important consideration—why do the non-device CDS or wellness exemption analysis if the FDA wouldn’t even consider you a device to begin with?
The FD&C Act defines what counts as a "medical device"--generally, the FDA considers a product a medical device based on two factors: (1) its physical form and (2) its intended use.
Medical devices are typically physical objects-machines, implements, implants, and similar items. This distinguishes them from drugs or biologics. Under the FD&C Act, products that meet the physical form requirement are regulated as medical devices when they're intended for:
- Diagnosing disease.
- Curing disease.
- Mitigating disease.
- Treating disease.
- Preventing disease.
- Affecting the structure or function of the body.
You may be saying...but my product is just software—not a physical object. What am I even doing here?
Not so fast…. software is actually an exception to the physical form rule. The FDA regulates software as a medical device when it's intended to diagnose, cure, mitigate, treat, or prevent disease, or to alter the structure or function of the body.
But…
The FD&C Act notes five types of software exempt from classification as a medical device:
- Administrative software
- Health and wellness software (which we covered in Part One)
- Electronic health records
- Software for medical device data management (MDDM)
- Clinical decision support software (the topic of this Part Two!)
The rest of this article focuses on Criteria 5: Clinical Decision Support Software. However, because many CDS companies use medical device data as part of their product, it’s worth briefly covering Criteria 4: Software for Medical Device Data Management.
Software that simply acts as a "middleman" for medical device data is not regulated as a medical device, as long as it doesn't interpret or analyze the data. Think of it as a pass-through: the software can move data around, store it, change its format, and display it (including lab test results), but it can't add new clinical insights or conclusions about the patient. It may also:
- Process physicians' notes and records regarding medical device data and results.
- Show general information about the results.
- Share information about the lab test or medical device that created the data.
KEY CONSIDERATION: To stay exempt, your MDDM software cannot change the medical device data itself, and it cannot control how a connected medical device works or adjust its settings.
PRO TIP: Note that the FDA analyzes software function by function, so a single product might have one function that qualifies as non-device CDS and another that doesn't qualify for any exemption. For more details on how the FDA evaluates multi-function devices, check out the 2020 FDA guidance document on this topic.
Also, it's important to note that the guidance doesn't contain explicit analysis for every use case, intended use, or product function-the FDA can't anticipate every innovation. However, the guidance is a framework for analysis, especially when supplemented with consideration of evolving federal policy trends. For thoughts on this, be sure to follow me on LinkedIn. Things are moving fast.
How do I know if my clinical decision support product qualifies as non-device CDS?
At a high level, CDS software provides recommendations or information to healthcare professionals for the prevention, diagnosis, or treatment of diseases or other health conditions in patients. The FD&C Act does not consider this software a device if it:
- Does not acquire, process, or analyze medical images or signals from medical devices.
- Allows the health professional to review the basis for its results independently so that the health professional is not intended to primarily rely on the software to determine a patient's diagnosis or treatment.
Specifically, clinical decision support software functions qualify for the “non-device CDS” exemption if they meet all of the following criteria:
- 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
- intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines)
- intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
- intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents, so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient
Below, I'll break down each of these components and note what has changed in FDA policy since the prior guidance was released in 2022:
Criteria 1: 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
A software function meets this criterion if it does not process or analyze:
- Medical images (e.g., computed tomography (CT), x-ray, ultrasound, magnetic resonance imaging (MRI))
- A “signal” from a test run outside the body on a sample like blood, saliva, urine, or tissue, to help diagnose a condition, monitor disease, or guide treatment (e.g., a lab test where a device reads a signal from a sample and software turns that signal into a result a clinician can use). If the software processes or analyzes the result of the test to generate a clinical test result, it fails this criterion.
- A “signal” or “pattern” from a medical device outside or inside the body (e.g., ECG, remote monitoring devices). Here's the difference: a signal is a single reading of something the device measures, while a pattern means the device takes multiple readings over time. This may signal (no pun intended) the FDA's intention to specifically allow software that processes or analyzes individual point-in-time physiological measurements to meet this criteria. Admittedly, this is a tricky one, with some of the FDA examples seemingly contradicting this conclusion. You’ll want to loop in trained counsel on this in particular.
Real World Example: Many digital health companies use data derived from cleared remote monitoring devices to generate patient insights in a platform or other display. One example is an SpO2 monitor. If the company acquires, processes, or analyzes the raw output (signals) from the SpO2 device and uses that for a clinical purpose, it fails this criteria. If, however, the SpO2 device provides an SpO2 measurement as part of its functionality, and the software simply displays the device's output (see Criteria 2, below), this criteria is likely met. If the software analyzes or processes patterns of individual point-in-time measurements from a SpO2 device, the software might meet this criteria.
Criteria 2: Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information
If the input of the software function is “medical information about a patient” or other medical information more generally—i.e., NOT a signal or pattern—this criteria is met.
In the 2026 guidance, the FDA clarifies the definition of “medical information about a patient”.
Information:
(1) used in, or relating to, the clinical care of the patient, including patient-specific information;
(2) that generally can be communicated between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision;
(3) the information's relevance to patient care is supported by well-understood sources*; and
(4) the information can be appropriately understood in context.
*Information from “well-understood and accepted sources” is that which “reflects knowledge and practices that are widely recognized and accepted within the medical or scientific community that are supported by scientific evidence, including peer-reviewed literature, clinical guidelines, or authoritative consensus documents.”
REAL WORLD EXAMPLE: A CDS software function identifies patients diagnosed with chronic heart failure (CHF) from within an HCP's EHR. When an HCP views the patient records, it displays the available blood pressure, ECG, and other relevant diagnostic information about that patient (obtained from a cleared device or present in the patient's medical record) and provides the HCP with suggested medications and treatment pathways for the patient. If the suggestions include best practices for treatment of CHF derived from medical literature and government guidelines (best practice: citing these sources!) that are verified and validated, this criterion is likely met.
Note: The 2026 guidance removed a reference to “sampling frequency” as an important consideration for whether something is considered “medical information”. This removes ambiguity in the guidance around whether a single measurement that is clinically meaningful can be considered medical information for the purpose of generating a clinical recommendation.
What if I display or analyze “medical information” on an ongoing basis over time?
This is a tricky one: displaying or analyzing discrete measurement results qualifies as "medical information" under Criteria 2, but continuous sampling of the same information may be a "pattern" that fails Criteria 1. The boundary between analyzing medical information and analyzing a pattern rmust be navigated carefully given the contradictory information in the guidance. Stakeholders should address this tension in comments to the FDA.
Criteria 3: Intended for the purpose of supporting or providing recommendations to an HCP about the prevention, diagnosis, or treatment of a disease or condition
If the software function provides condition-, disease-, and/or patient- specific recommendations to an HCP to enhance, inform, and/or influence a health care decision, but is not intended to replace or direct the HCP's judgment, this criterion is met.
This criteria fails if the software provides a specific preventive, diagnostic, or treatment output or directive or replaces a HCP's judgment. However, software that presents recommendations based on an analysis of patient-specific information and provides the HCP with a treatment option or diagnostic recommendation can now meet this criterion EXCEPT where the output is intended to support time-critical decision-making.
2026 EXPANSION OF CDS CRITERIA:
Under the 2022 guidance, software that provided a single specific (clinically appropriate) recommendation failed to meet Criteria 3. Specifically, the guidance stated that a software function does not meet Criteria 3 if it:
- Provides a specific preventative, diagnostic, or treatment course;
- Provides a specific follow-up directive;
- Provides a treatment plan for a specific patient's disease or condition.
This led many CDS providers to modify their outputs to include optionality for treatment recommendations, follow-up prompts, and other alerts, even where there was only one clearly clinically appropriate option. In prior guidance, the agency seemed to indicate that simply displaying generally acceptable information that was not specific to any particular patient was the limit for meeting this criterion. For this reason, some companies avoided patient-specific recommendations altogether.
The 2026 guidance marks a significant shift: FDA now explicitly states that it will exercise enforcement discretion for software that provides a single, clinically appropriate recommendation (as long as it meets all other criteria). This is transformative. Companies can now deliver precise, actionable guidance to healthcare professionals-exactly what clinicians need-without the prior requirement to artificially include multiple options or risk triggering device regulation.
Here are some examples of functions that are now permissible under Criteria 3:
- A software function that predictsthe general risk of future cardiovascular events for an HCP to consider based on a patient's weight, current and historical smoking status, blood pressure, and brain natriuretic peptide (BNP) in vitro diagnostic (IVD) test results.
- A software function that creates a recommended treatment plan, including possible medication(s), for patients diagnosed with cognitive impairment for an HCP to consider based on the patient's diagnosis related to cognitive impairment, as well as potential comorbidities, age, sex, and patient preferences, and that should be reviewed, revised, and finalized by an HCP.
- A software function that recommends a specific FDA-approved antibiotic agent for an HCP to consider based on the patient's symptoms, recent hospitalizations, and previous antibiotic exposure.
- A software function that analyzes a radiologist's clinical findings of an image to generate a proposed summary of the clinical findings for a patient's radiology or pathology report, including a specific diagnostic recommendation based on clinical guidelines that should be reviewed, revised, and finalized by an HCP.
- A software function that provides an HCP with a differential diagnosis based on a patient's symptoms, vital signs, and laboratory values, and that, depending on the clinical context, may present either multiple diagnostic considerations or a single clinically appropriate diagnostic recommendation when alternative diagnoses are highly improbable.
- A software function that classifies patients with chronic low back pain into a single recommended appropriate clinical care pathway (e.g., conservative management or referral to a surgical spine specialist) based on patient history, symptom duration, and documented clinical findings, where the recommendation is intended to be reviewed and acted upon by an HCP.
- A software function that estimates 90-day and 1-year postoperative mortality and complication risk following lung transplantation based on patient-specific clinical characteristics and published clinical evidence, where the output is intended to support pre-transplant planning and shared decision-making and is reviewed by an HCP.
Reminder: If the software is providing recommendations to patients or caregivers (and not directly to a healthcare professional), it will not meet the criteria for CDS! If you're marketing to consumers, you will want to check out Part One of this series.
Criteria 4: Intended for the purpose of enabling an HCP to independently review the basis for the recommendations that such software presents, so that it is not the intent that the HCP rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient
If the software function is intended to enable HCPs to independently review the basis for the recommendations presented by the software, this criterion is met. The purpose of this requirement is to ensure that the recommendation informs decision-making regarding clinical care, but does not replace the judgment of the HCP.
So what does that mean in practice?
This means that the software or its labeling should provide plain language information about underlying data sources and an easy-to-understand explanation of the basis of the provided recommendation. The FDA is going to focus on whether the presentation of this information actually assists in the exercise of physician judgment. If the information is too complex, hides the ball, or fails to provide a reasonable basis for understanding the decision-relevant information, the software may fail Criteria 4.
By way of example (but not as a directive), the FDA shares its recommendations for meeting Criteria 4. The software or labeling should:
- Clearly disclose the product's intended use, user, and patient population
- Identify required inputs with plain language instructions on how the inputs should be obtained, their relevance, and data quality requirements;
- Provide a plain language description of:
- The general approach relied upon to provide the recommendations (e.g., meta-analysis of clinical studies, expert panel, statistical modeling, AI/ML techniques).
- The data is relied upon so that an HCP can assess whether the data is representative of their patient population, and performance results are sufficient for the intended HCP user to understand the basis of the recommendation.
- A description of the results from clinical studies conducted to validate the algorithm/recommendations so that an HCP can assess the potential performance and limitations when applied to their patients (e.g., sub-populations with untested or highly variable algorithm performance).
- Display relevant patient-specific information, other knowns/unknowns, and data quality indicators that enable the HCP to independently review the basis for recommendations and apply their own clinical judgment.
FDA notes that companies may need to perform “usability” testing to confirm whether they meet this criterion. In addition, the guidance emphasized that an HCP’s ability to independently review is impacted by the time-sensitive nature of the use case. They note that in situations that require urgent action, automation bias increases because there is not sufficient time for the user to adequately consider other information.
Pro Tip: For companies selling to hospitals treating critically ill patients in emergent cases that require quick decision-making, this criterion will be hard to meet.
Real World Example: A software is marketed as a solution that identifies potential sepsis patients and recommends clinical treatment options based on EHR inputs—it notes it is not for time-critical use cases. It disclaims that its insights are only as complete as the data available to it in the EHR. Alongside its recommendations for a care pathway for a patient with antibiotic-resistant Staphylococcus, the software cites medical literature sources for the clinical practice guidelines and includes links for HCPs to review the underlying data sources. Further, the software notes clearly in the HCP dashboard the key data points it used to source these recommendations, where those data points came from (e.g., lab results, patient temp and blood pressure results, and which information sources it used to source these data points), and any missing or abnormal values for review by the HCP. The product labeling states that the underlying technology has undergone validation studies, and it pulls its recommendations from a curated library of best practices chosen by a board-certified internal medicine physician for sepsis patients that includes only peer-reviewed studies through the current year. The software identifies the studies that most closely match the patient-specific diagnosis and demographics, and other considerations regarding the efficacy and safety of the treatment options. This software likely meets Criteria 4.
Bringing it all together, the 2026 CDS guidance is best understood as an evolution, not a reset. The 2019 implementation of the Cures Act drew the initial lines around non-device CDS; the 2022 guidance clarified those lines; and the 2026 update responds by expanding opportunityies, including through granting targeted enforcement discretion so clinically useful, provider-facing tools do not automatically become regulated devices.
What’s Next?
For your team, the practical next steps are to (1) map each software function against the four statutory criteria, (2) confirm that any use of images, signals, or patterns is clearly outside the non-device lane—or redesigned to fit within it, (3) document your data sources, validation strategy, and explainability features to support independent review by HCPs, and (4) pressure-test time-critical use cases where automation bias and clinical urgency may undermine a non-device position.
Viewed alongside the expanded wellness safe harbors in Part One, the message from the FDA in 2026 is clear: there is meaningful room to build powerful, AI-enabled tools for both consumers and clinicians without defaulting into full device regulation—if you are deliberate about how you frame intended use, structure recommendations, and design transparency into your product from day one.
And, as with Part One, if you'd like help pressure-testing whether your CDS functions qualify as non-device under the 2026 framework—or how to re-architect them if they don't—this is where a focused regulatory strategy can unlock product velocity rather than slow it down.
Teams that understand how the FDA thinks about software will move faster, build better tools, and avoid unnecessary regulatory drag. If you want to use the new guidance to expand what your product can do, without expanding your regulatory burden, let’s talk: elevarelaw.com/contact