Know where your 510(k) software package stands, from CDS determination and IEC 62304 documentation to 524B cybersecurity and AI validation, and what to fix first.
Readiness
90%
Sample: NeuroPulse AI
Evidence coverage
93%
Referenced evidence
Completeness
100%
Requirements answered
Confidence
97%
Evidence-backed
Critical blockers
eSTAR preparation
Supported today
FDA Traditional 510(k) for non-IVD, software-only medical devices, including AI-enabled software.
Not yet supported
De Novo and PMA scoring, IVD software, software in a hardware device, EU MDR and the EU AI Act. These are flagged for review, not scored.
Device determination, the four statutory non-device CDS criteria, product code, predicate and intended use.
Basic or Enhanced documentation level, architecture, SRS, design specification, V&V and unresolved anomalies, aligned to IEC 62304.
ISO 14971 software risk, IEC 62366-1 usability and performance validation against the intended use.
For cyber devices under FD&C Act 524B: threat model, SBOM, vulnerability management plan and security testing.
Only when your software uses AI: dataset independence, subgroup performance, transparency and an optional PCCP.
Software as a medical device (SaMD) is software intended for a medical purpose that is not part of a hardware device. Most SaMD reaches the US market through a 510(k), which shows substantial equivalence to a legally marketed predicate and is cleared, not approved. FDA expects software documentation scaled to risk, a risk management file, validation against the intended use and, for software that can connect to the internet, the cybersecurity content required by section 524B, including an SBOM.
SaMD Readiness applies the approach behind our Device Readiness product to software, without hardware topics such as biocompatibility or sterility.
Tell us about your software, intended use and predicate, and we will follow up within one business day.