Regulatory Answers (510(k), eSTAR, SaMD, LED)

“Do I need a predicate for 510(k)?” “What is eSTAR for 510(k)?” “How long does a 510(k) take?” “What testing is required for my device?” “Is my software SaMD?” “Do LED devices need FDA clearance?”

Q1Do I need a predicate for 510(k)?

Yes—most 510(k)s require at least one legally marketed predicate device to support a substantial equivalence comparison. If you cannot identify a defensible predicate (same intended use and similar technological characteristics), a different pathway (such as De Novo) may be more appropriate.

A strong predicate typically aligns on intended use, indications, and core technology.
If differences raise new questions of safety/effectiveness, the predicate strategy may need revision.

Q2What is eSTAR for 510(k)?

eSTAR is the FDA’s electronic submission template that standardizes how 510(k) content is organized and submitted. It helps reduce administrative errors by prompting required elements, enforcing structure, and making it easier for FDA reviewers to navigate the file.

Designed to improve completeness and consistency at submission.
Still requires the same technical evidence—eSTAR is the format, not the “approval shortcut.”

Q3How long does a 510(k) take?

Timing depends on testing scope and iteration, but many projects take several months end-to-end. Preparation often takes 2–6+ months (especially if standards testing is needed), and FDA review includes an initial acceptance screen plus substantive review that may involve additional information requests.

The biggest schedule driver is usually testing (lab queues + retesting if scope changes).
Clear claims + a strong predicate strategy reduce review friction.

Q4What testing is required for my device?

Testing is driven by intended use, risk, device technology, and recognized standards. Many devices require some combination of bench performance testing, biocompatibility (when patient-contacting), electrical safety/EMC (for powered devices), software verification/validation (for software-enabled devices), cybersecurity (when networked), and usability/human factors (when user interaction can impact safety).

Test plans should be built to match your claims—over-claiming often triggers additional testing.
Standards selection and justification are a core part of a defensible submission.

Q5Is my software SaMD?

Software is generally considered Software as a Medical Device (SaMD) when it performs a medical function on its own (e.g., analyzes, diagnoses, or drives clinical decisions) without being part of a specific hardware medical device. If your software only supports general wellness, administrative tasks, or non-medical functions, it may not be SaMD—your claims and intended use language are the deciding factors.

The same core software can fall in or out of scope depending on how you market it.
Clinical performance evidence may be needed when software drives or significantly influences decisions.

Q6Do LED devices need FDA clearance?

Sometimes. If an LED product is intended to diagnose, treat, mitigate, or prevent disease—or makes medical claims—it may be regulated as a medical device and require the appropriate pathway (often 510(k)). If it is positioned strictly for general wellness/cosmetic purposes with non-medical claims, it may have reduced regulatory burden, but the line depends on your intended use, labeling, and marketing.

Medical claims (acne treatment, disease outcomes) increase the likelihood of device regulation.
Claim strategy and labeling are as important as the hardware specs for regulatory scope.