When does my software become a regulated medical device?
The test isn't how clever your software is. It's whether the clinician using it has time to check its reasoning.
Answered in short
6 things that decide this
- 01Section 520(o) of the FD&C Act keeps five kinds of software out of the device definition. Clinical decision support is the fifth, and it's the one people argue about.
- 02You lose that exclusion at once if your software reads a medical image, a signal from an in vitro diagnostic device, or a pattern from a signal acquisition system.
- 03Most builds miss one condition: the health professional must be able to check the basis of the advice on their own. It can't be built so they lean mainly on it.
- 04FDA says software meant for a critical, time-sensitive task fails that condition, because the clinician is unlikely to have time to check the basis.
- 05If your software advises patients or carers, rather than health professionals, it's a device.
- 06FDA replaced its clinical decision support guidance in January 2026, and the current version is dated 29 January 2026.
The carve-out is narrower than it reads
Founders read section 520(o)(1)(E) and see a way out. Support the clinician, don't replace their judgement, and you sit outside the device rules. That reading is too hopeful.
The statute opens with an "unless". Does your software read a medical image? A signal from a Blueprint device? A pattern from a signal system? If so, the exclusion doesn't apply. Your imaging tool or waveform reader is out before anything else gets weighed.
For everything else, three conditions have to hold together. The last one decides most cases: your clinician must check the basis of the advice on their own. You can't design it so they lean mainly on it.
What pushes software across the line
Checked 11 August 2026 against 21 USC 360j(o) and FDA's Clinical Decision Support Software guidance dated 29 January 2026.
| Design choice | Effect on the carve-out | Why |
|---|---|---|
| Reads an image or a device waveform | Carve-out unavailable | The statutory "unless" clause excludes it up front |
| Used in a time-critical decision | FDA does not consider Criterion 4 met | The clinician is unlikely to have time to review the basis |
| Outputs a specific directive | Fails Criterion 3 | It provides a specific preventive, diagnostic or treatment output |
| Shows options with the reasoning and sources | Supports the carve-out | The clinician can review the basis independently |
| Speaks to a patient or caregiver | It is a device | The carve-out applies to healthcare professionals |
| Schedules, bills or handles lab workflow | Excluded separately | 520(o)(1)(A) covers administrative support |
FDA writes about automation bias by name
FDA's current guidance names two things it weighs here: how automated your software is, and how time-critical the decision is.
It then defines automation bias as the habit of over-trusting a suggestion from an automated system. That produces both errors of action and errors of omission. When action is urgent, bias rises, because there's no time to weigh other information.
This is a design instruction hiding in a regulatory document. Show your reasoning, name your sources, describe how you built and tested the model. That's what makes independent review real rather than nominal.
- 01Criterion 4 also expects a plain-language account of how you built and tested the algorithm, including where you used AI or machine learning and how well your data matched real patients.
- 02Your class decides the route. Most non-exempt Class I and II devices go through 510(k). Class III needs premarket approval.
- Image or signal?If yes, the carve-out is gone.
- Who reads it?Patient or caregiver means device.
- Directive or options?A specific directive fails Criterion 3.
- How urgent?Time-critical fails Criterion 4.
- Can they check it?Basis, sources, validation, shown.
- Document the answerWritten down before you ship.
The fourth station catches builds that pass everything else. A tool designed for a fast decision is, by FDA's reasoning, one the clinician cannot properly check.
Clinical and regulated systems we have shipped
Related questions
01Does keeping a human in the loop keep us out of device territory?+
Only where that person can really check the reasoning. FDA's condition is about the clinician being able to review the basis on their own, not about somebody clicking approve. A reviewer with no time and no visible reasoning is exactly the automation-bias case the guidance describes.
02We only rank or triage. Is ranking a directive?+
Judge a ranking by what it replaces. Options with the evidence behind each, for a clinician who then decides, work differently from one output telling them what to do. TrialTriage ranks eligible oncology trials from de-identified data. A nurse reviews and finalises every result before it reaches anyone.
03What if the software is only used inside one hospital?+
Your device definition turns on intended use, not how widely you ship. A single-site tool can still meet it. Scale changes your commercial exposure, not your classification, so settle the classification first and let it shape the design.
04How many AI-enabled devices has FDA authorised?+
FDA keeps a public list of AI-enabled medical devices, updated as of 16 June 2026, but it publishes no headline total. Counting unique submission numbers in that table on 11 August 2026 gives you 1,524, with the most recent entry dated 30 March 2026. FDA notes the list doesn't cover every such device.
Related
- Why clinical AI models fail in production →What happens after authorisation, with the published evidence.
- How do you build HIPAA compliant AI →The privacy half of the same build.
- EHR integration →Where clinical documentation and device boundaries meet.
- Clinical research →TrialTriage's problem shape, and the buyers who ask this question most.
- AI, automation and custom software for healthcare →The hub this answer sits under.
