25.16 — Medical Devices and Their Own Rulebook

You write an application that reads a chest scan and flags a possible collapsed lung for the radiologist to look at first. No drug, no chemistry, no patient contact. Just a model, a queue and a user interface.

In the United States, that is a medical device. It needs a regulatory submission, a quality system, a risk file, a software lifecycle that meets an international standard, a cybersecurity package including a bill of every software component inside it, and a plan for what happens when you want to retrain the model.

Software engineers walk into this territory constantly without realising it, usually because somebody described the product as "a dashboard". This chapter is the rulebook, and the first section is the one that decides whether the rest applies to you at all.

What counts as a device, and what makes software one

A device is a product intended for diagnosis, treatment, prevention or mitigation of disease that achieves its purpose by physical means — mechanical, electrical, thermal, optical — rather than by chemical action inside the body (Chapter 25.3).

For software, the deciding question is the claim, not the technology. Software that makes a claim about a specific patient's condition or treatment is regulated. Software that manages information without interpreting it clinically is generally not.

Software as a medical device — SaMD — is software that performs a medical function on its own, without being part of a physical device. Your scan-reading application is SaMD. Software embedded in a machine — the control software of an infusion pump — is software in a device, and is regulated as part of it.

The middle ground is clinical decision support, and the line there is worth knowing precisely because so many products aim at it. Software is more likely to fall outside regulation when it displays or summarises information, bases its output on published, transparent reasoning, and gives the clinician enough to understand and independently judge the recommendation rather than relying on it. Software that produces a conclusion the clinician cannot check — the characteristic shape of a machine-learning output — sits inside the regulated category.

And two categories in the middle are treated with deliberate restraint. General wellness products making non-medical claims about fitness or relaxation, and electronic health record functions for storing and displaying data, are largely left alone. "It is just showing them their own data" is a genuine argument; "our algorithm suggests the diagnosis" is not.

The classes, and the pathways that follow from them

Since the Medical Device Amendments of 1976, American devices fall into three classes by risk, and the class determines the route to market.

Class I — low risk. Bandages, examination gloves, manual instruments. Most are exempt from premarket submission, but still subject to general controls: registration, labelling rules, reporting of problems.

Class II — moderate risk. Most devices, including infusion pumps, most imaging equipment, and most SaMD. These usually reach market through a 510(k), which is a notification rather than an approval: you demonstrate that your device is substantially equivalent to a legally marketed device, called the predicate. The agency's review goal is 90 days. Clinical data is often not required, which is the fastest legitimate route in the entire industry.

Class III — high risk, usually life-supporting or implanted. Heart valves, implantable defibrillators, and novel devices with no predicate. These need premarket approval, a PMA: a full evidence package, normally including clinical trials, with a statutory review period of 180 days that in practice runs far longer, often with an advisory panel.

And a fourth route exists for the awkward case. De Novo classification is for a device that is genuinely new — so no predicate exists — but is low or moderate risk, and would otherwise be forced into Class III by default. A successful De Novo creates a new device type, and becomes the predicate for everyone who follows, which makes being first strategically valuable.

The 510(k) route attracts sustained criticism and it is worth being able to state it fairly. A device can be cleared as equivalent to a predicate, which was itself cleared as equivalent to an earlier predicate, back through generations, so that a modern device may trace its lineage to something approved decades ago on evidence that would not be accepted today. That is the substantive concern, and it is why some high-profile device failures involved products that never underwent a full evidence review.

The quality system, and the change that just happened

American device manufacturers were governed for decades by the Quality System Regulation, 21 CFR Part 820, which was similar to but not the same as the international standard ISO 13485. Companies selling worldwide had to satisfy both.

That ended recently. The Quality Management System Regulation — the QMSR — took effect on 2 February 2026. It amends Part 820 to incorporate ISO 13485:2016 by reference, adding FDA-specific requirements on top rather than maintaining a separate American system. The FDA began inspecting against an updated inspection programme on the same date.

What this means in practice for a client, and it is a live topic right now, is that procedures written against the old regulation's clause structure had to be remapped, that the international standard's own vocabulary now governs, and that the remaining differences — record requirements, complaint handling specifics, labelling — sit in the FDA's added sections. Anyone doing quality system work for a device client in this period is dealing with this transition, and knowing the effective date and the shape of the change is immediately useful.

Risk management is a formal, documented discipline

The device world takes risk management further than the drug world, and it is codified in ISO 14971, which every device client will reference constantly.

The process is a loop. Identify every hazard the device could contribute to. For each, estimate how likely it is and how severe the harm would be. Decide whether that is acceptable. Where it is not, apply controls — in a strict order of preference: design the hazard out first; if you cannot, add protective measures such as alarms or interlocks; and only as a last resort, warn the user in the labelling. Then verify the controls work, check whether they introduced new hazards, and evaluate the overall residual risk.

The output is a risk management file, maintained for the life of the product and updated with what the field teaches you.

Two consequences land directly on software design. A warning in a manual is the weakest possible control and regulators treat it as such — "we documented it in the user guide" is not an adequate answer to a hazard a design change could remove. And risk drives verification effort: the higher the risk of a function, the more evidence its testing must produce, which is the same principle you will meet in Chapter 25.21 for validated systems.

The software standard, and what it demands

IEC 62304 is the international standard for the medical device software lifecycle, and it is the one your engineering process will be audited against.

It starts by assigning a safety class to each software item, based on what happens if the software fails. Class A: no injury possible. Class B: non-serious injury possible. Class C: death or serious injury possible. The class determines how much of the standard applies — a Class C item requires detailed architectural design, unit-level verification and full traceability, while a Class A item requires far less.

What the standard requires across the lifecycle: a defined development plan; requirements that are complete and verifiable; an architecture that identifies where the risky parts are; documented design; verification against each requirement; a specific and rigorous process for software of unknown provenance — meaning any third-party or open-source component you did not develop under this process, which must be identified, risk-assessed and justified; configuration management; problem resolution; and a maintenance process for post-release changes.

That third-party component clause is the one that catches modern software teams. A framework pulled in from a package registry is software of unknown provenance, and it must be identified, assessed for what its failure could do, and controlled. This is why the cybersecurity requirements below fit naturally rather than arriving as an extra burden.

Cybersecurity became law, not guidance

A connected device that can be attacked is a device that can harm patients, and the American requirement is now statutory rather than advisory.

Section 524B of the Food, Drug, and Cosmetic Act applies to "cyber devices" — those with software that can connect to the internet — and requires a manufacturer to submit, as part of its marketing application, a plan for monitoring and addressing vulnerabilities, processes and procedures providing reasonable assurance the device is cybersecure, including making updates and patches available, and a software bill of materials covering commercial, open-source and off-the-shelf components.

A software bill of materials is exactly what an engineer would expect: a machine-readable list of every component and version inside the product. Its purpose is speed on the day a widely used library is found to be vulnerable — the manufacturer must be able to answer "is that library in our device, and which versions shipped it" in hours rather than weeks.

Labelling expectations follow: what communication interfaces exist, how to configure and patch the device securely, and what known unresolved vulnerabilities remain. If you have ever produced a dependency manifest and a patch policy for an ordinary product, you already know how to do this; the difference is that here it is submitted to a regulator and maintained for the product's life.

Artificial intelligence, and the problem of a model that changes

Traditional device regulation assumes the product is fixed after approval. A machine-learning model is valuable precisely because it can be improved with new data, and retraining it is, in regulatory terms, changing the product.

The answer is the predetermined change control plan. In the marketing submission, the manufacturer describes in advance which modifications it intends to make, the exact methods and data it will use to implement and validate them, and the impact assessment — and once authorised, it may make those specific changes without a new submission.

The FDA finalised its guidance for this on 4 December 2024, and the final version widened the scope from machine-learning-enabled devices to AI-enabled devices generally, and added detail on which modifications remain outside such a plan and therefore still need a new submission.

Read that as an engineer and it is a familiar idea in unfamiliar clothing: you are pre-registering your retraining pipeline, its acceptance criteria and its guardrails, and then living inside them. The systems consequence is that your monitoring, evaluation datasets and release process become regulatory evidence, which means they need the same rigour as the model itself.

Once the device is out there

Post-market obligations are heavier for devices than for drugs, because a device can fail mechanically in one patient rather than pharmacologically in many.

Unique device identification. Every device carries a UDI — a code identifying the model plus production information such as lot and serial number — in both human-readable and machine-readable form, submitted to a public database. Its purpose is a fast, precise recall: knowing exactly which units are affected and where they went.

Adverse event reporting. Manufacturers must report events where a device may have caused or contributed to a death or serious injury, and malfunctions likely to cause harm if they recurred — normally within 30 days, and within 5 days where remedial action is needed to prevent unreasonable risk. Hospitals and other user facilities have their own reporting duties.

Corrections and removals. Field actions must be reported, and recalls are classified by risk exactly as in Chapter 25.12.

And post-market surveillance studies can be required for certain devices, particularly implants.

Europe, and why so many companies complain about it

The European Union replaced its old device directives with the Medical Device Regulation, and the transition has been genuinely difficult.

The structure differs from the American one in a way that surprises people. There is no single European device approver. Manufacturers work with a notified body — a private organisation designated by a member state to assess conformity — which issues the certificate allowing the CE mark.

The regulation raised evidence requirements, expanded post-market obligations, required a person responsible for regulatory compliance inside each manufacturer, and demanded re-certification of products already on the market. Notified body capacity could not absorb it, and the deadlines had to be extended by law to prevent shortages.

The current transition dates are worth having exactly, because clients plan around them: 31 December 2027 for higher-risk products — Class III devices and Class IIb implantable devices, with a list of common exceptions such as sutures, staples, dental fillings and screws — and 31 December 2028 for medium and lower-risk products, meaning other Class IIb devices, Class IIa devices and the sterile, measuring and reusable Class I categories. A separate date of 26 May 2026 applies to Class III custom-made implantable devices. The "sell-off" provision was removed, so devices lawfully placed on the market may continue to be made available without a time limit.

In-vitro diagnostics have their own parallel regulation with its own timetable, and the European device database, EUDAMED, has been rolled out in stages.

The practical consequence for a services company is that European device compliance is a large, deadline-driven remediation market: technical documentation to rebuild, clinical evaluations to strengthen, post-market surveillance systems to implement, and traceability to prove.

What to check before you build anything

Five questions, asked early, prevent nearly every expensive surprise in a device software project.

Is this a regulated device at all, in each market it will be sold? The answer can differ between the United States and Europe for the same product.

What class, and therefore which route and which evidence?

What is the software safety class under IEC 62304, and does the architecture isolate the risky parts so that most of the code can sit at a lower class? This is a design decision with a large cost consequence, and it must be made early because it is nearly impossible to retrofit.

Does the client have a compliant quality system already, or are you building the product and the system that governs it at the same time?

And if there is a model in it, is there a predetermined change control plan — or is every improvement going to require a new submission?

Next: Chapter 25.17, the quality system as a working machine — deviations, nonconformances, CAPA, change control and complaints, which is the vocabulary you will hear every single day inside any regulated client.