FDA’s New 2026 Guidance: What Changed for Digital Health Platforms, Wearables and CDS (and why you may want to revisit paused features)
Yash Dave
Why this update matters
On January 6, 2026, the FDA issued updated final guidance for:
And it withdrew the 2017 guidance “Software as a Medical Device (SaMD): Clinical Evaluation” (withdrawal date shown as January 6, 2026).
Net effect: clearer “what’s in vs out” boundaries for many consumer-facing wellness features and some clinician-facing CDS patterns, while keeping the line firm for anything that starts to look like diagnosis, disease management, or time-critical clinical decision-making.
1) Wearables and “digital health” wellness features
1. What it felt like before (the practical reality)
Even under the earlier General Wellness framework (and the broader device definition), teams often hesitated to ship features that:
- output a “medical-looking” metric (especially blood pressure, glucose-adjacent insights, oxygen saturation, ECG-like interpretations), or
- could be interpreted as screening/monitoring a condition, or
- used clinical-style thresholds or language.
Because the biggest risk was not just “what the algorithm does,” but how users interpret it and how your claims, UI, and prompts frame it.
The WHOOP example made that tension obvious: the FDA said a blood pressure estimation feature was inherently tied to diagnosing hypo/hypertension, and that disclaimers did not outweigh the product’s design and intended use.
2. What it’s like now
The updated General Wellness (Jan 6, 2026) guidance keeps the core concept (FDA generally does not intend to regulate low-risk general wellness products as devices) but adds more explicit “you can do this if…” clarity, including a notable modernization:
3. A clearer lane for non-invasive sensing that outputs physiologic parameters
The FDA says it may consider certain non-invasive sensing products (example: optical sensing) that estimate/infer/output physiologic parameters such as:
- blood pressure
- oxygen saturation
- blood glucose
- heart rate variability (HRV)
…as general wellness products when those outputs are intended solely for wellness uses and specific guardrails are met.
Those guardrails include:
- non-invasive and not implanted
- no risky intervention/tech without controls
- not intended for diagnosis/cure/mitigation/prevention/treatment
- not intended to substitute for an FDA-authorized device
- no outputs that prompt or guide specific clinical action
- avoid “clinically mimicking” values unless you can validate them
4. The “still regulated” line is also clearer
The guidance is also explicit that products are not general wellness when intended for medical/clinical purposes like screening, diagnosis, monitoring, alerting, or management of a disease or condition.
And FDA communications around this theme have been consistent: “wellness” is easier to support, “medical grade” claims trigger scrutiny.
5. What WHOOP teaches teams now (even after the “looser” posture)
WHOOP is a useful reality check for teams reading “FDA loosens oversight” too broadly.
FDA’s warning letter to WHOOP focuses on:
- objective intent shown by labeling, statements, UI and context
- the idea that blood pressure estimation is inherently tied to diagnosing hypertension, and
- disclaimers alone not being enough when the experience looks clinical
So yes, there is more room to build, but product framing and UX choices still decide your risk.
2) Clinical Decision Support (CDS) and digital health software
1. What it felt like before
In recent years, many teams interpreted FDA’s posture as tightening around:
- AI-driven recommendations that feel “directive,”
- black-box outputs clinicians cannot independently assess,
- and anything time-critical.
That uncertainty caused real product pauses, especially when “recommendation” started to look like “instruction.”
2. What it’s like now
The Jan 2026 CDS guidance reiterates the statutory “Non-Device CDS” criteria and provides more examples, but two clarifications are especially important for teams:
(A) More explicit support for “single option” recommendations (via enforcement discretion)
FDA states that when a CDS function otherwise meets the statutory criteria, and only one option is clinically appropriate, FDA intends to exercise enforcement discretion (meaning it does not intend to enforce device requirements for that function).
This is a meaningful change in how teams can think about “one best answer” outputs, as long as the overall CDS function remains supportive, reviewable, and non-time-critical.
(B) Stronger emphasis on “independently review the basis”
To stay in the “non-device” lane, FDA emphasizes the clinician’s ability to independently review the basis for the recommendation, and notes that software intended for critical, time-sensitive tasks is unlikely to meet that criterion.
Practically: the more you can show inputs, logic, validation context, limitations, and what’s missing, the better positioned you are for the exemption.
3) What about Digital Health and SaMD
This update does not mean SaMD is “less regulated.” SaMD that meets the definition of a medical device is still subject to the usual pathways.
What did change is that FDA withdrew the SaMD Clinical Evaluation guidance (originally issued in 2017; withdrawal date listed as January 6, 2026).
Several legal and regulatory commentators interpret this as FDA recalibrating its digital health policy framework alongside the General Wellness and CDS updates.
How to interpret this safely as a product team:
- Treat the withdrawal as framework simplification, not “less evidence needed.”
- Expect SaMD evaluation to still rely heavily on validation, clinical performance expectations, and risk-based thinking (often aligned with IMDRF concepts), but with less emphasis on that one specific FDA guidance document as the reference point.
4) So, should teams revisit paused features
Often, yes, but with a disciplined lens. This guidance update creates a clearer path for product work that was previously stuck in “gray-zone fear,” especially in:
1. Wearables and wellness platforms
Good candidates to revisit:
- HRV-based recovery, sleep and stress insights (wellness framing)
- non-invasive estimates presented as trends/baselines for wellness context
- “contextual coaching” that links outputs to lifestyle domains like sleep, activity, recovery (not disease)
High-risk candidates (need more caution):
- anything that names a condition, uses diagnostic thresholds, or suggests medication/treatment changes
- alerts framed as “abnormal” in a clinical sense
- features that look like disease monitoring rather than wellness tracking
1. CDS for clinician workflows
Good candidates to revisit:
- decision-support tools that show their basis clearly and allow clinician judgment
- “single clinically appropriate option” outputs in constrained contexts (still with guardrails)
Higher risk:
- time-critical tools where there is no time to review the basis
- black-box outputs that cannot be explained in plain language
- tools that effectively direct clinical action
5) A practical checklist for teams (to stay truthful while supporting innovation)
If you want your blog’s message to be both optimistic and accurate, anchor it in this reality:
You can move faster when:
- Your intended use is clearly wellness, not diagnosis or treatment
- Your UI, claims, and onboarding match that intended use (no clinical thresholds, no disease framing)
- You validate outputs appropriately, especially if values look clinically familiar
- For CDS, clinicians can understand and review the recommendation basis, and it is not time-critical
And you still need to slow down when:
- You are estimating a metric that users could interpret as diagnostic (WHOOP shows FDA will act here)
- Your product prompts clinical actions, alarms, or management steps
- Your CDS output becomes directive or not independently reviewable
Summary
The FDA’s January 2026 updates do not remove the line between wellness and medical devices, but they make the line easier to see. If your team paused feature exploration because the boundary felt too ambiguous, this is a good moment to reopen the roadmap, re-check intended use, and redesign claims and UX so that “wellness” stays truly wellness. The WHOOP case is a reminder that FDA still watches the edge cases closely. The opportunity is real, but so is the need for careful product framing and validation.
Revisiting your roadmap after FDA’s update? We can help.
If you’re exploring new wearable insights, wellness features, or clinician-support tools, the fastest path forward is usually a structured reset: intended use and claims, risk boundaries, validation plan, and a build approach that won’t create compliance debt later.
AIMDek helps digital health teams design, build, and modernize products with the right guardrails, across connected devices, platforms, data pipelines, and regulated engineering practices.
Yash Dave
Yash Dave is a MedTech, Digital Health, and SaMD specialist at AIMDek, helping teams design and scale platforms spanning mobile apps, cloud backends, and connected device integrations. He supports MedTech and digital health teams building companion apps, full software platforms, and interoperability layers across devices, wearables, EHRs, and third-party tools. His work spans product development through validation, including secure architectures, V&V planning and execution, and quality-ready engineering practices aligned with regulated environments.
