What makes software a medical device

Whether a piece of software counts as a medical device depends on what it is intended to do, not on what it happens to run on. That distinction catches people building clinical software for the first time, because the Food, Drug, and Cosmetic Act really does exclude certain software functions from the device definition — but the exclusions are conditional, and failing one condition puts the whole product back inside FDA’s jurisdiction.

Why “it’s just an app” isn’t a regulatory answer

Before the Cures Act, the device definition didn’t carve software out by function at all, and a lot of clinical software occupied a genuine gray zone. The 2016 amendment fixed that by naming specific categories of software function — administrative support, certain general wellness software, software for transferring or storing data, electronic health record software, and conditionally, clinical decision support software — and excluding them from the device definition when they meet the statute’s conditions. None of that turns on the platform. A function that qualifies for the exclusion running in a web browser is treated the same as the identical function running on a dedicated device, and a function that doesn’t qualify doesn’t become exempt because it ships as a consumer app instead of a piece of hardware.

What actually moves clinical decision support software in or out

The CDS exclusion lives in section 520(o)(1)(E) of the FD&C Act and sets out a multi-part test, not a single question. Two conditions come up in nearly every analysis of it: the software can’t acquire, process, or analyze a medical image, an in vitro diagnostic signal, or a signal from a pattern or signal acquisition system directly, and it has to leave a healthcare professional able to independently review the basis for its recommendation rather than simply accepting an output it can’t interrogate. Read the statute and FDA’s own guidance directly before relying on a secondhand summary of the remaining conditions — the agency’s interpretation of this test has moved before and is worth checking against the current version, not whatever guidance was current when a product was first designed.

Why the intended user is half the test

The same underlying software can land on different sides of the line depending on who it’s labeled for. A version built for a clinician who can independently evaluate the recommendation is a different regulatory question than a patient-facing version of the identical algorithm, because the professional-judgment condition assumes a trained user in the loop. That means the regulatory answer isn’t fixed the day the algorithm ships — it has to be revisited whenever the intended user or labeling claim changes, the same way a predetermined change control plan has to account for a modification that changes what a cleared device’s software actually does, not just how well it does it.

None of this makes clinical software something to avoid building — it makes the regulatory question worth asking at the design stage, not after the product is finished. The same discipline that tracks whether a change moves a device’s software outside what FDA already cleared also shows up in what a device cybersecurity submission has to document, regardless of which side of this line the software landed on.