What is FDA 510(k) clearance for software? A technical explainer
FDA 510(k) clearance is routinely described as "FDA approval." It is not. Understanding the actual legal and technical meaning of the clearance — and how it applies to software specifically — is a prerequisite for building software that can survive a regulatory submission.
What 510(k) actually clears
The 510(k) pathway allows a device to enter the US market by demonstrating substantial equivalence to a predicate device — an already-marketed device with the same intended use and similar technological characteristics. The FDA reviews the submission and determines that your device does not raise new safety questions relative to the predicate. It does not independently test your device, and it does not certify that the device is safe.
For engineering teams, this distinction matters practically. Substantial equivalence is comparative, not absolute. The evidentiary standard is: does your device perform the same intended use as the predicate, and do its technical characteristics create any new risks? If the answer to both is no, clearance is granted.
For software, this creates a specific constraint: the predicate relationship applies to the intended use and technical performance of the cleared algorithm or system. Changing the implementation — even if you believe the output is identical — can affect whether substantial equivalence holds. The onus is on you to produce evidence that it does not.
Software as a Medical Device (SaMD)
The FDA distinguishes between Software in a Medical Device (SiMD) — software embedded in hardware, like firmware in a wearable — and Software as a Medical Device (SaMD) — software that is itself the medical device, such as a clinical decision support algorithm or a monitoring dashboard.
Both can require 510(k) clearance depending on their risk classification.
The FDA has adopted the IMDRF SaMD classification framework, which uses two axes: the seriousness of the healthcare situation and the significance of the information the software provides to clinical decisions. Software that directly drives treatment or diagnostic decisions in serious conditions sits at the highest tier. Software that informs — but does not drive — decisions about non-serious conditions may fall under enforcement discretion entirely.
For practical purposes: if your software processes physiological sensor data and generates clinical interpretations — tremor severity, arrhythmia detection, sleep quality, off-wrist detection — your classification is almost certainly at a tier that requires a formal submission.
The Software Level of Concern
Within a 510(k) submission, the FDA uses a "Software Level of Concern" — Minor, Moderate, or Major — to determine the documentation depth required.
Minor applies when the software cannot contribute to a hazardous situation. Minimal documentation required.
Moderate applies when software failure could contribute to a hazardous situation that would be caught and corrected before patient harm. Requires full software description, architecture, and testing records.
Major applies when software failure could cause serious harm, and the failure might not be detected before injury occurs. Requires comprehensive documentation across the full IEC 62304 lifecycle.
Most clinical monitoring and diagnostic algorithms — anything generating clinically actionable output from sensor data — fall at Major. If you are building a wearable movement disorder monitor, a cardiac rhythm classifier, or a sleep staging algorithm, plan for Major.
What the documentation package contains
A Major-level submission requires:
Software Description Document. What the software does, its operating environment, and its intended use. This anchors the software's function to the device description in the submission.
Software Requirements Specification. A formal enumeration of what the software must do, expressed so that each requirement can be verified by a test. Requirements must be traceable through design, implementation, and test evidence.
Architecture Design Chart. A decomposition of the software into modules with data flows, interfaces, and component relationships. Regulators use this to evaluate failure modes and their propagation.
Hazard Analysis. Software-specific failure contributions mapped to risk mitigations — typically feeding into the device-level risk management file (ISO 14971).
Testing Documentation. Unit, integration, and system test protocols with expected and actual results. For algorithms, this includes performance characterisation on clinically representative datasets. Passing your unit tests is not sufficient — you need evidence of clinical performance at the operating boundary.
Traceability Matrix. A table linking every requirement to a design element, an implementation module, and a test case. Regulators use this to verify that nothing was specified and not tested.
This documentation cannot be produced retroactively from a codebase that was not built with it in mind. The structure needs to exist before the code does, or alongside it. Treating it as paperwork to complete after the engineering is finished produces documentation that does not pass review.
The change control problem
510(k) clearance is version-specific. Once cleared, the FDA's software change guidance (most recently updated in 2023) distinguishes between changes that require a new 510(k) submission and changes that can be documented internally through change control.
The key question is whether the change could affect the safety or effectiveness of the device. Algorithm changes — anything that modifies how the software generates clinical output — are high-risk from a regulatory standpoint. UI changes, infrastructure changes, and bug fixes to non-safety-critical paths can often be handled internally, with documented justification.
This is the engineering reality we worked with directly during our 2.5-year engagement with PKG Health, now Empatica. The work involved refactoring six cleared movement disorder algorithms — bradykinesia, dyskinesia, tremor severity, off-wrist detection, sleep scoring, and walking detection — from their original implementations into Python, and later porting them to embedded C for new device platforms.
Every change required demonstrating numerical equivalence to the cleared reference implementation, with documented evidence across the full clinical operating range. The output of each re-implemented algorithm had to match the cleared Python reference within defined numerical tolerances, on real patient data, at the clinical edge cases. That evidence is what supported the regulatory file for the new platform. Full details of the methodology are in the PKG Health case study.
This is what clinical algorithm development means under regulatory constraints. Not writing algorithms that work — writing algorithms with a validation methodology that produces regulatory evidence as a first-class output.
What this means for your engineering team
Documentation structure before code. Requirements, architecture, and hazard analysis are easier to produce as you build than to reconstruct from finished code. The traceability matrix is impossible to produce cleanly from a codebase that was not tracked against requirements.
The cleared version is a contract. Any maintenance, optimisation, or platform port of cleared software needs a formal change assessment. Organisations that treat cleared code as "just code" consistently underestimate the regulatory consequence of changes that seem minor.
IEC 62304-aware QA from the start. Software testing for medical devices under IEC 62304 has specific documentation requirements — test protocols, test reports, anomaly resolution records — that are different from conventional QA. The test infrastructure and documentation standards need to be in place before the software is complete, not after.
Plan the performance test dataset early. For algorithms, the most time-consuming part of the submission package is often the clinical performance characterisation. Building the test harness and sourcing the validation dataset is not a last-mile problem.
The 510(k) pathway is not designed to be easy. It is designed to produce reliable evidence. Engineering teams that build the documentation and validation process into the development workflow produce better software and smoother submissions. Teams that treat it as a post-engineering compliance exercise produce neither.
If you are working on a wearable algorithm or clinical software project and need to understand what the regulatory requirements mean at the engineering level, we are glad to help. We have been through this on FDA 510(k) Class II cleared devices and understand both the engineering and the regulatory file requirements from the inside.