SaMD & AI Algorithms in Wearables: FDA 2026 Submission Pathway Decision Tree

If your wearable device ships with an app that claims to detect atrial fibrillation, estimate blood pressure from PPG signals, or predict fall risk using accelerometer data, you are no longer just a hardware company. You are a Software as a Medical Device (SaMD) manufacturer — and the FDA expects you to prove it is safe, effective, and built to a quality system before you ship a single unit.

This article provides a practical, decision-tree-based guide to SaMD submission pathways in 2026, with specific reference to the algorithms most commonly embedded in medical wearables: PPG-based blood pressure estimation, ECG-based arrhythmia detection, SpO₂ trending, and AI-driven risk scores. If you are an OEM developing wearable platforms for brand partners, or a brand evaluating whether your app needs FDA clearance, this is the framework you need.

1. “Is Our App a Medical Device?” — The SaMD Four-Question Test

The International Medical Device Regulators Forum (IMDRF) defines SaMD as “software intended to be used for one or more medical purposes that perform those purposes without being part of a hardware medical device.” The key word is intended. The FDA determines intended use by examining your labeling, marketing claims, app store descriptions, investor decks, and user manuals — not by what your algorithm technically does, but by what you say it does.

To determine whether your wearable companion app qualifies as SaMD, work through these four questions:

Question 1: Does the software have a medical purpose? Under Section 201(h) of the FD&C Act, medical purpose includes diagnosis, monitoring, treatment, prevention, or mitigation of disease. If your app claims to “detect atrial fibrillation,” that is a diagnostic claim. If it claims to “help users track wellness metrics,” you may stay outside the device definition — but only if the claim is genuinely limited to general wellness, not a thinly veiled diagnostic assertion.

Question 2: Is the software independent of a hardware medical device? If the software runs on a general-purpose platform (smartphone, cloud server, hospital workstation) and performs its medical function independently, it is SaMD. If it is firmware embedded in a hardware device (e.g., the code that controls a pulse oximeter sensor), it is Software in a Medical Device (SiMD), regulated as part of the parent device.

Question 3: Does the Clinical Decision Support (CDS) exemption apply? The FDA’s 2026 final CDS guidance clarifies four criteria under Section 3060(a) of the 21st Century Cures Act. All four must be met for the software to be exempt:

1. The software does not acquire, process, or analyze a medical image or signal from an in vitro diagnostic device.
2. The software displays, analyzes, or prints medical information about a patient.
3. The software is intended for use by a healthcare professional who can independently review the basis for its recommendations.
4. The software is not intended to replace clinical judgment, and is not used in a time-critical setting where the HCP primarily relies on its output.

For wearable algorithms, Criterion 1 is the most common failure point. If your app processes raw PPG signals to estimate blood pressure, or analyzes ECG waveforms to detect arrhythmia, it is acquiring and processing a medical signal — and the CDS exemption does not apply. Your software is a medical device.

Question 4: Is the intended use Wellness or Medical? The FDA’s General Wellness Policy distinguishes low-risk products that promote a healthy lifestyle (step counting, sleep tracking, hydration reminders) from those that diagnose or treat disease. The moment your app outputs a clinical risk score, flags a specific arrhythmia, or recommends a medication change, you cross the line into regulated territory.

2. FDA SaMD Risk Classification: The IMDRF Framework

Once you have determined your software is SaMD, the next question is: how risky is it? The IMDRF N12 risk categorization framework uses two axes:

• Significance of the information provided: Inform clinical management → Drive clinical management → Treat or diagnose
• State of the healthcare situation: Non-serious → Serious → Critical

The intersection produces four risk categories:

	Inform Clinical Management	Drive Clinical Management	Treat or Diagnose
Non-serious	Category I	Category II	Category II
Serious	Category I	Category II	Category III
Critical	Category II	Category III	Category IV

Wearable-specific examples:

• Category I: A wellness dashboard that displays heart rate trends without clinical interpretation — Inform × Non-serious.
• Category II: An ECG analysis algorithm that flags atypical morphology for clinician review in a routine cardiology setting — Drive × Serious.
• Category III: A PPG-based blood pressure estimation algorithm that provides a diagnostic reading for hypertension management — Treat or Diagnose × Serious.
• Category IV: An autonomous stroke detection algorithm that triages patients to thrombectomy pathways based on wearable data — Drive × Critical.

IMDRF categories do not map 1:1 to FDA device classes, but the general alignment is: Category I → Class I (exempt or enforcement discretion), Category II → Class II (510(k)), Category III → Class II (510(k) or De Novo), Category IV → Class III (PMA). The IMDRF category drives the rigor of your clinical evidence, software documentation level (Basic vs. Enhanced per IEC 62304), and post-market surveillance requirements — even if the regulatory pathway is a straightforward 510(k).

3. FDA’s 2026 AI/ML Policy: The Predetermined Change Control Plan (PCCP)

AI/ML models are not static. They are retrained, fine-tuned, and updated as new data becomes available. Under the traditional regulatory framework, every significant change to a cleared device requires a new premarket submission. For an AI model that retrains quarterly, that would mean four submissions per year — an unsustainable model that the FDA recognized as incompatible with modern software development.

The FDA’s PCCP guidance, finalized in August 2025, is the agency’s framework for regulating AI that evolves after clearance. A PCCP is submitted as part of the initial premarket submission and describes:

1. Planned modifications: What types of changes you intend to make post-clearance (e.g., retraining on expanded datasets, adding new patient demographics, expanding the input range of a physiological parameter).
2. Modification protocol: The methodology you will use to validate each change — performance thresholds, statistical tests, dataset requirements, and acceptance criteria.
3. Impact assessment: How each modification type will be evaluated for its effect on safety and effectiveness, including the risk of introducing new failure modes.

Practical example for a wearable PPG blood pressure algorithm: Your initial 510(k) submission covers an algorithm trained on 5,000 subjects with a specific demographic distribution. Your PCCP might specify that you will retrain the model when you reach 10,000 subjects, using the same training pipeline and validation protocol, with a pre-specified agreement limit of ±5 mmHg against a reference-grade sphygmomanometer. As long as the retrained model meets those acceptance criteria, you update the model without a new 510(k). If it does not, you assess whether the deviation requires a new submission.

The PCCP is not a blank check. The FDA reviews the plan as part of the original submission, and post-market changes must stay within the scope described. But for wearable AI/ML developers, it provides a regulatory mechanism for continuous improvement without the friction of repeated submissions — and it is rapidly becoming a standard expectation in 510(k) submissions for AI-enabled devices.

4. 510(k) vs. De Novo vs. PMA: The Decision Tree

Selecting the right regulatory pathway is arguably the single most consequential decision in your SaMD development program. The three pathways differ dramatically in cost, timeline, evidence requirements, and post-market obligations.

Dimension	510(k)	De Novo	PMA
When to use	Predicate device exists	Novel, low-to-moderate risk	High-risk (Class III)
Total cost	$150K–500K	$300K–800K	$1M–5M+
Timeline	3–6 months	6–12 months	12–24 months
Evidence	Performance testing; clinical data sometimes	Performance + clinical validation; risk-benefit analysis	Prospective clinical trials
User fee (FY2026)	~$22,000	$0	~$440,000
AI/ML share	~85%	~12%	<3%

Decision tree for wearable algorithm developers:

1. Is there a predicate device with the same intended use? If yes, 510(k) is your primary pathway. As of December 2024, the FDA has authorized 1,016 AI-enabled devices, and the installed base of cleared wearable algorithms — particularly ECG analysis and arrhythmia detection — provides a growing pool of predicates. For AI-enabled SaMD, approximately 85% of clearances use the 510(k) pathway.
2. Is your device genuinely novel with no predicate, but low-to-moderate risk? De Novo is the correct route. There is no user fee, and the De Novo grant creates a new classification regulation — making your device the predicate for future competitors. This is a strategic advantage: your device defines the category.
3. Is your device high-risk, supporting or sustaining human life? PMA is required. Autonomous diagnostic or therapeutic systems for life-threatening conditions — such as a closed-loop insulin delivery algorithm driven by wearable CGM data — fall here. Very few AI-enabled SaMD products have gone through PMA.

Wearable-specific pathway guidance: An ECG-based AFib detection algorithm running on a smartwatch (Apple Watch, Fitbit, or OEM equivalent) follows the 510(k) pathway — there are multiple cleared predicates. A PPG-based cuffless blood pressure monitor that provides a diagnostic reading is also likely a 510(k), though the predicate landscape is sparser. A novel algorithm that autonomously diagnoses stroke from wearable accelerometer and heart rate data, with no existing predicate, would likely go De Novo. For more detail on the 510(k) submission process, see our guide on FDA 510(k) submission cost and timeline.

5. Algorithm Clinical Validation: What the FDA Expects

Clinical validation for SaMD is not the same as a drug trial. The FDA expects performance data that demonstrates your algorithm is accurate, reliable, and generalizable — but the specific evidence package depends on the risk category and the clinical claim. For a 510(k) wearable algorithm, the core validation components include:

Dataset construction: Your training, tuning, and validation datasets must be demographically representative of the intended use population. The FDA expects you to document the data sources, inclusion/exclusion criteria, and demographic distributions (age, sex, race/ethnicity, and relevant clinical variables such as skin tone for PPG-based algorithms, which has been a known source of performance variation).

Reference standard (ground truth): Every algorithm output must be compared against a clinically accepted reference standard. For ECG arrhythmia detection, the reference standard is over-read by board-certified cardiologists. For PPG blood pressure, the reference is a validated, calibrated sphygmomanometer following a standardized measurement protocol (e.g., ISO 81060-2). For SpO₂, the reference is arterial blood gas co-oximetry or a predicate pulse oximeter.

Independent validation set: The dataset used for final performance reporting must be completely independent of the training and tuning datasets — no data leakage, no overlap. The FDA has issued multiple warning letters for submissions where the validation set was contaminated by training data.

Performance metrics: Report sensitivity, specificity, positive predictive value, negative predictive value, and area under the ROC curve for classification algorithms. For regression algorithms (e.g., blood pressure, SpO₂), report mean absolute error (MAE), root mean square error (RMSE), and Bland-Altman limits of agreement. Include subgroup analyses by demographic variables and clinical confounders.

Software documentation: IEC 62304 compliance is mandatory. Determine your software safety class (A, B, or C) based on the severity of harm from a software failure. Most wearable SaMD algorithms that drive clinical decisions will be Class B (non-serious injury possible) or Class C (death or serious injury possible). Class C requires full architecture documentation, detailed design, unit testing of every software unit, and bidirectional traceability from requirements through risk controls to test cases.

6. Case Studies: PPG Blood Pressure and ECG AFib Validation

6.1 PPG-Based Cuffless Blood Pressure Estimation

PPG blood pressure algorithms present a unique validation challenge because they estimate a continuous physiological parameter rather than classifying a discrete condition. The FDA expects:

• Sample size: A minimum of 85 subjects, consistent with ISO 81060-2:2018 requirements for non-invasive sphygmomanometers. However, many successful 510(k) submissions use 200–500 subjects to ensure adequate demographic representation and statistical power for subgroup analyses.
• Endpoint: Mean error ≤ ±5.0 mmHg and standard deviation ≤ 8.0 mmHg against the reference standard, per ISO 81060-2 criteria. Note that these are the same criteria the FDA applies to traditional cuff-based monitors — the bar is not lower for PPG.
• Statistical method: Bland-Altman analysis with 95% limits of agreement. Report bias (mean difference) and precision (SD of differences). Include scatter plots of reference vs. device readings, correlation coefficients, and error distribution histograms.
• Confounders to address: Skin tone (Fitzpatrick scale), motion artifact, ambient temperature, sensor placement, and patient position (sitting, standing, supine). The FDA has specifically flagged PPG performance across skin tones as an area of concern since 2023.
• Calibration stability: If the algorithm requires periodic calibration against a cuff-based reference, document the calibration protocol, frequency, and drift over time. The FDA will want to see that performance remains within specification throughout the calibration interval.

6.2 ECG-Based Atrial Fibrillation Detection

AFib detection algorithms have a well-established predicate landscape, and the validation pathway is relatively mature:

• Sample size: Typically 300–600 subjects, with a target of at least 100 subjects with confirmed AFib (to ensure adequate sensitivity estimates). The FDA has accepted studies with as few as 90 AFib-positive subjects when combined with a large non-AFib cohort.
• Endpoints: Sensitivity (ability to detect AFib when present), specificity (ability to correctly identify sinus rhythm), and the unclassifiable rate (the proportion of recordings where the algorithm cannot make a determination). For a screening device, sensitivity ≥ 90% and specificity ≥ 95% are typical performance targets.
• Reference standard: Simultaneous 12-lead ECG over-read by two independent board-certified cardiologists, with a third for adjudication. Single-lead wearable ECG strips must be time-synchronized with the reference 12-lead.
• Statistical method: Report sensitivity and specificity with exact binomial 95% confidence intervals. Include ROC analysis for the detection threshold. For consumer-facing devices, also report the positive predictive value in the intended use population — a device with 95% sensitivity and 95% specificity will still generate a high proportion of false positives in a low-prevalence population, which has implications for healthcare resource utilization.

7. EU MDR Rule 11 vs. FDA: Key Differences

If your wearable SaMD is heading to both the US and EU markets, you must navigate two fundamentally different classification systems. Under EU MDR 2017/745 Annex VIII Rule 11:

• Class IIa (minimum): Software intended to provide information used to make decisions with diagnosis or therapeutic purposes. This is the default classification for most diagnostic SaMD.
• Class IIb: If the decisions could cause serious deterioration of health or require surgical intervention.
• Class III: If the decisions could cause death or irreversible deterioration of health.
• Class I: Only software that does not meet any of the above — effectively limited to administrative tools and non-clinical data logging.

Critical differences from FDA:

1. No predicate concept: EU MDR does not have a 510(k)-style substantial equivalence pathway. Every device must stand on its own clinical evidence.
2. Notified Body required: Class IIa and above require a Notified Body review — adding cost, timeline, and the uncertainty of Notified Body capacity constraints (a well-documented bottleneck under MDR).
3. Rule 11 pushes classification upward: Many software products that were Class I under MDD are now Class IIa or IIb under MDR. The result is a dramatic increase in the number of SaMD products requiring Notified Body involvement.
4. Post-market surveillance: EU MDR mandates a PMS plan, periodic safety update reports (PSURs), and post-market clinical follow-up (PMCF) — all of which are more prescriptive than FDA’s post-market requirements for Class II devices.

For a wearable OEM serving both markets, the practical strategy is to build the technical documentation and quality system to the higher standard (EU MDR) and use that documentation as the foundation for both submissions. The clinical evidence package can be shared, but the regulatory strategy and submission format differ significantly.

8. OEM Scenarios: Who Owns the Algorithm, Who Files the Submission?

In the wearable OEM model, the hardware manufacturer, the algorithm developer, and the brand partner are often three different entities. This creates a regulatory triangle that must be resolved before the first submission:

Scenario A: OEM owns the hardware, algorithm is licensed from a third party. The OEM is the legal manufacturer of the integrated device (hardware + software) and files the submission. The algorithm developer is a critical supplier. The OEM must have access to the algorithm’s training data, validation reports, and software documentation — not just the executable. The quality agreement between the OEM and the algorithm developer must specify who owns the design history file, who handles post-market surveillance, and who is responsible for adverse event reporting.

Scenario B: Brand partner owns the algorithm, OEM provides the hardware platform. The brand partner is the legal manufacturer of the SaMD and files the submission. The OEM is a contract manufacturer of the hardware component. The brand partner must have sufficient control over the hardware design to ensure compatibility and safety — including the right to audit the OEM’s manufacturing facility and quality system.

Scenario C: Brand partner licenses both hardware and algorithm from OEM. The OEM is the legal manufacturer for the integrated device and holds the regulatory clearance. The brand partner is a distributor or private-label reseller. The OEM’s labeling must include the brand partner’s name, and the OEM must ensure the brand partner’s marketing claims do not exceed the cleared indications for use.

Data ownership: This is the most contentious point in OEM negotiations. The algorithm training data, the clinical validation data, and the post-market real-world data all have significant commercial value beyond the regulatory submission. The contract must specify who owns the data, who can use it for future algorithm development, and what happens to the data if the partnership ends.

9. Common Pitfall: Wellness Claims That Become Diagnostic Claims

The single most expensive mistake in wearable SaMD is crossing the line from wellness to medical claims without realizing it — and without the regulatory infrastructure to support a medical device. The FDA determines intended use by examining the totality of your communications, not just the formal indications for use statement. Marketing copy, investor presentations, app store descriptions, social media posts, and trade show materials all count.

Red flags that turn a wellness claim into a diagnostic claim:

• “Detects” or “diagnoses” — These words are radioactive. “Identifies patterns” is safer; “detects atrial fibrillation” is a diagnostic claim.
• “Monitors” + a disease name — “Monitors heart rate” is wellness. “Monitors hypertension” is medical.
• “Alerts” + a clinical condition — “Alerts you when your heart rate is elevated” is borderline. “Alerts you to possible arrhythmia” is clearly medical.
• Clinical risk scores — If your app outputs a 10-year cardiovascular risk score, you are making a diagnostic prediction, regardless of how you label it.
• Treatment recommendations — “Consider consulting your doctor” is acceptable. “Reduce your medication dose” is a therapeutic claim.

Regulatory consequences of getting it wrong: The FDA can issue a Warning Letter, require a recall, impose civil monetary penalties, and refer cases for criminal prosecution. For a startup or an OEM entering the US market, an FDA enforcement action is effectively a business-ending event — it blocks market access, destroys partner relationships, and makes future submissions exponentially more difficult.

10. Downloadable Resources: SaMD Pathway Decision Tree + PCCP Template

To help you apply this framework to your specific wearable algorithm, we have prepared two resources:

1. SaMD Submission Pathway Decision Tree: A one-page flowchart that walks you through the SaMD classification, risk categorization, and pathway selection decisions described in this article. Print it, pin it to your wall, and use it as a decision-making tool in every product development meeting.
2. PCCP Template Outline: A structured template covering planned modifications, modification protocols, impact assessments, and acceptance criteria — designed to be adapted to your specific AI/ML algorithm and integrated into your 510(k) or De Novo submission.

Contact our team at jine@xdunmedical.com to request these documents. We are happy to share them with partners and prospective clients who are navigating the SaMD regulatory pathway.

Conclusion

The regulatory landscape for wearable SaMD in 2026 is more mature and more demanding than it was even two years ago. The FDA’s CDS guidance, the PCCP framework, and the growing body of cleared AI/ML predicates have created a clearer path to market — but also a higher bar for clinical evidence, software documentation, and post-market surveillance. For wearable OEMs and brand partners, the key decisions are: (1) whether your app is a medical device, (2) which regulatory pathway applies, (3) whether you need a PCCP, and (4) who owns the submission. Get these four answers right, and the rest of the program is execution. Get them wrong, and you will spend months or years rewinding decisions that should have been made at the start.

For more on the regulatory requirements for wearable medical devices, see our guides on FDA 510(k) submission cost and timeline, wearable cybersecurity under FDA guidance, and ISO 10993 biocompatibility testing for wearables. For the role of real-world evidence in post-market surveillance, read our upcoming article on RWE and post-market surveillance for medical wearables.