FDA SaMD Classification for EEG Companion Apps: What Mobile Developers Need to Know

DEVSFLOW Neuro · 2026

Your EEG companion app displays brainwave data, computes a "focus score," and maybe even detects when the user is drowsy. Is it a wellness app or a medical device? The answer determines whether you need to spend six months on documentation and quality systems before shipping, or whether you can push updates every two weeks like a normal mobile app. For EEG companies, this question is existential, and the FDA's Software as a Medical Device (SaMD) framework is what governs the answer.

This post explains how the FDA classifies software that processes EEG data, what triggers medical device classification, and what the practical engineering and process implications are for mobile development teams. This is not legal advice. It is a technical overview from the perspective of developers who have built apps on both sides of the regulatory line.

What Is Software as a Medical Device?

SaMD is software intended to be used for one or more medical purposes without being part of a hardware medical device. The key phrase is "intended use." The FDA does not regulate software based on what it technically can do, but on what its manufacturer claims or implies it does.

An EEG app that displays raw waveforms for "general wellness" or "meditation" purposes is not SaMD. The same app, displaying the same waveforms, becomes SaMD the moment it claims to detect seizures, diagnose ADHD, or monitor sleep apnea. The technology is identical. The regulatory status changes entirely based on the intended use communicated through your marketing, app store listing, in-app copy, and user documentation.

The FDA adopted the International Medical Device Regulators Forum (IMDRF) framework for SaMD in 2017 and has continued to refine its approach through guidance documents. The most relevant guidance for EEG app developers is the 2019 "Clinical Decision Support Software" guidance and the 2023 "Predetermined Change Control Plans for AI/ML-Based SaMD" guidance.

The Three-Class System

The FDA classifies medical devices into three classes based on risk:

• Class I (low risk): General controls only. Examples include elastic bandages and tongue depressors. Some simple software that displays or transfers medical data without interpreting it falls here. 510(k) premarket notification is typically exempt.
• Class II (moderate risk): General controls plus special controls. This is where most EEG-related SaMD lands. Examples include EEG signal display systems (product code GWQ) and quantitative EEG analysis software. Requires 510(k) clearance, demonstrating substantial equivalence to a predicate device.
• Class III (high risk): Requires Premarket Approval (PMA) with clinical trials. Examples include seizure prediction devices or closed-loop neurostimulation controllers. The regulatory burden here is massive and typically takes 2 to 5 years and millions of dollars.

For most EEG companion apps, the critical distinction is between "not a medical device" (wellness) and Class II. Crossing from wellness to Class II adds 6 to 18 months of preparation time and requires establishing a Quality Management System (QMS) before you can file a 510(k).

Where the Line Is for EEG Apps

The FDA has provided relatively clear guidance on what makes software a medical device versus a wellness product. Here is how common EEG app features map to regulatory status:

Not SaMD (General Wellness)

• Displaying raw EEG waveforms without clinical interpretation
• Computing and displaying frequency band power (alpha, beta, theta, gamma) as general information
• Providing a "relaxation score" or "focus score" for meditation or productivity purposes
• Neurofeedback training for general wellness (stress reduction, meditation aid)
• Sleep tracking that reports general sleep stages without claiming to diagnose sleep disorders

Likely SaMD (Class II)

• Seizure detection or seizure prediction alerts
• ADHD screening or diagnosis support
• Depression biomarker detection (frontal alpha asymmetry for clinical assessment)
• Quantitative EEG (qEEG) normative database comparison for clinical use
• Sleep disorder screening (detecting sleep apnea events, narcolepsy markers)
• Concussion assessment or traumatic brain injury evaluation

The Gray Zone

Several common EEG app features sit in a gray zone that requires careful analysis:

• Drowsiness detection: If positioned as a "wellness alert" (like a fitness tracker reminding you to move), it is likely wellness. If positioned as a safety system for drivers or machine operators, the clinical intent pushes it toward SaMD.
• Cognitive performance tracking: Tracking attention metrics over time for personal insight is wellness. Claiming to detect cognitive decline or early signs of dementia is SaMD.
• Neurofeedback for clinical conditions: Neurofeedback for ADHD treatment is SaMD (and has existing 510(k)-cleared predicates). Neurofeedback for "peak performance" or "meditation" is wellness.

IEC 62304: Software Lifecycle for Medical Devices

If your app is classified as SaMD, you must comply with IEC 62304, the international standard for medical device software lifecycle processes. This standard defines three software safety classes (A, B, C) and prescribes increasingly rigorous development processes for each.

For a Class II EEG companion app, you will typically need IEC 62304 Class B compliance, which requires:

• Software development planning: A documented plan covering your development process, tools, coding standards, and integration/testing strategy. This is not a retroactive document. It must exist before you start coding the regulated features.
• Software requirements specification: Every feature that has clinical significance must have traceable requirements. "The app shall display EEG spectral power" is not sufficient. "The app shall compute spectral power using Welch's method with 1-second Hanning windows at 50% overlap and display absolute power in microvolt-squared for each standard frequency band (delta: 0.5-4 Hz, theta: 4-8 Hz, alpha: 8-13 Hz, beta: 13-30 Hz, gamma: 30-100 Hz)" is closer to what is expected.
• Software architecture documentation: A description of your app's major components, their interfaces, and data flows. For a BLE-connected EEG app, this means documenting your BLE communication layer, signal processing pipeline, data storage format, and display layer, including how each component handles error conditions.
• Verification and validation: Unit tests, integration tests, and system-level tests with documented test protocols and results. For signal processing code, this means testing against known input signals with expected outputs. For BLE communication, this means testing connection, reconnection, and data integrity under various conditions.
• Risk management: Compliant with ISO 14971. You must identify hazards (what could go wrong), estimate risks (how likely and how severe), and implement mitigations. For an EEG app, hazards include displaying incorrect data that leads to a wrong clinical decision, failing to alert on a detected seizure, and data corruption that invalidates a clinical recording.

Quality Management System Basics

The QMS is the organizational infrastructure that ensures your development process is consistent, documented, and auditable. For SaMD, the relevant standard is ISO 13485. The core elements a mobile development team needs to implement include:

• Document control: Every version of every requirements document, design document, test protocol, and test result must be controlled, versioned, and retrievable. Git version control covers your code, but you also need controlled documents for non-code artifacts.
• Change control: Changes to the regulated software must go through a formal change request process that evaluates the impact on safety, efficacy, and regulatory status. This does not mean you cannot deploy fast, but you need to document why each change was made and what was evaluated.
• Complaint handling: A process for receiving, evaluating, and responding to user complaints that might indicate a safety issue. If a user reports that seizure detection failed, you need a documented process for investigating that report.
• CAPA (Corrective and Preventive Action): When you find a bug that affects clinical functionality, you need to document the root cause, the correction, and the preventive measures to ensure it does not recur.

Practical Implications for Mobile Teams

If you determine that your EEG app is SaMD, here is what changes in your day-to-day development workflow:

Your git workflow needs to support traceability. Every commit that touches regulated code should reference a requirement or change request. Pull requests need documented review by someone with appropriate authority. Your CI/CD pipeline should run the full verification test suite on every merge to main, and the results should be archived.

You cannot use beta users as your testing strategy. Clinical functionality must be verified against documented test cases with expected results before release. This does not mean you cannot do iterative development, but it does mean each release of regulated features requires a documented verification cycle.

Over-the-air updates to SaMD are permitted, but each update to regulated functionality needs its own verification cycle and risk assessment. Non-regulated features (UI cosmetics, non-clinical settings) can be updated with a lighter process, which is why cleanly separating regulated and non-regulated code modules is essential from the start.

Staying on the Wellness Side

If your business model does not require clinical claims, design your app to stay clearly in the wellness category. This means careful attention to language throughout your product:

• Use "relaxation" instead of "anxiety reduction." Use "focus" instead of "attention deficit."
• Never use the words "diagnose," "treat," "prevent," or "cure" in connection with any medical condition.
• Do not reference clinical studies that validate your algorithms for medical purposes, even in blog posts or press releases. The FDA looks at the totality of your communications.
• Include clear disclaimers that your app is not a medical device and is not intended to diagnose or treat any condition.

The line between wellness and SaMD is ultimately about intent, and intent is determined by the totality of your communications, not just a disclaimer buried in your terms of service.