When does my software become a regulated medical device?
The test is not how clever the software is. It is 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 the one people argue about.
- 02That exclusion is lost at once if the 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, so it is not meant that they lean mainly on it.
- 04FDA says software meant for a critical, time-sensitive task fails that condition. The clinician is unlikely to have time to check the basis.
- 05Software that advises patients or carers, rather than health professionals, is a device.
- 06FDA replaced its clinical decision support guidance in January 2026. 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, do not replace their judgement, and you sit outside the device rules. That reading is too hopeful.
The statute opens with an "unless". Does your software acquire, process or analyse a medical image? A signal from an in vitro diagnostic device? A pattern from a signal acquisition system? Then the exclusion does not apply at all. Imaging tools and waveform readers are out before anything else is weighed.
For everything else, three conditions must hold together. The last one decides most cases. The clinician must be able to check the basis of the advice on their own. It cannot be meant that 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
The current guidance names two things FDA weighs here. How automated the software is. 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. And it says that where action is urgent, automation bias rises, because there is no time to weigh other information.
This is a design instruction hiding in a regulatory document. Show the reasoning. Name the sources. Describe how the model was built and tested. Those are what make independent review real rather than nominal.
- 01Criterion 4 also expects a plain-language account of how the algorithm was built and tested. That includes where AI or machine learning was used, and how well the data matched real patients.
- 02The 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 the automation-bias case the guidance describes.
02We only rank or triage. Is ranking a directive?
A ranking is judged by what it replaces. Presenting options with the evidence behind each, for a clinician who then decides, sits differently from one output telling them what to do. TrialTriage ranks eligible oncology trials from de-identified data with a nurse reviewing and finalising every result before it reaches anyone.
03What if the software is only used inside one hospital?
The device definition turns on intended use, not on how widely you ship. A single-site tool can still meet it. Scale changes your commercial exposure, not the classification. 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. It publishes no headline total. Counting unique submission numbers in that table on 11 August 2026 gives 1,524. The most recent entry is dated 30 March 2026. FDA notes the list does not 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.
- Human in the loop →The oversight this whole question turns on.
- Healthcare software development →Where we build under these constraints.
- PHI →What counts as protected health information.
