Regulation and governance

In plain words

In the United States, a medical device, including some software and AI tools, normally needs the FDA's permission before it can be marketed. There are three main routes:

• 510(k): the manufacturer shows the device is "substantially equivalent" to a device already legally on the market (the "predicate"). The result is called clearance.
• De Novo: for a genuinely new kind of device of low to moderate risk with no suitable predicate. The result is a De Novo grant.
• PMA (premarket approval): for the highest-risk devices. The result is called approval.

Healthcare example (illustrative)

Imagine three hypothetical tools. One measures heart chamber size on echocardiograms in much the same way as a tool already on the market; its maker would probably look at the 510(k) route. A second, first-of-its-kind tool predicts delirium after surgery from anaesthetic records, with nothing similar available; De Novo might fit. A third directly controls a high-risk therapy; PMA would be more likely. The manufacturer and the FDA decide the route, not the clinician.

A little more technical

The route depends on the device's risk and on whether a comparable device exists, not on whether it uses AI. The FDA's guidance on change plans for AI devices applies to all three routes (see #31). The FDA keeps a list of authorised AI-enabled devices, which it says is not comprehensive (see #116); checking it is a quick first step when a vendor says a tool is "FDA authorised". Pathway details are set by the FDA and can change, so rely on the primary source rather than summaries.

Don't learn this yet

Skip submission contents, review procedures, fees and device classification codes. That is the work of regulatory affairs teams. As a clinician, knowing which route a tool took and what that implies is enough.

Go deeper (optional)

• Artificial Intelligence-Enabled Medical Devices (list) #116
• Artificial Intelligence in Software as a Medical Device #117
• How AI is used in FDA-authorized medical devices: a taxonomy across 1,016 authorizations #205

In plain words

These words are not interchangeable. Cleared means the device went through the 510(k) route. Approved means it went through PMA, the route for the highest-risk devices. A De Novo device is granted. Authorised is often used as an umbrella term for all three, and the FDA's own list of AI-enabled devices uses it (see #116).

Healthcare example (illustrative)

A vendor presents to a hospital's emergency department and calls its CT triage tool "FDA-approved". A careful clinician looks the tool up on the FDA list, finds which route it actually took, and asks what intended use and patient group the authorisation covers. If the tool was cleared rather than approved, the sales wording is loose. That is worth noticing because it may signal loose claims elsewhere.

A little more technical

Any FDA authorisation covers a specific intended use described by the manufacturer, not every way a hospital might want to use the tool. It is also a US market decision: it does not mean the tool is permitted in India or the EU. It does not show that the tool works well on your patients, which is why local evaluation (Track 3) still matters. Published research on the FDA list also uses "authorised" as the umbrella term (see #118). The FDA's own consumer page, "Is It Really 'FDA Approved'?", explains the difference in plain terms (see #159).

Don't learn this yet

You don't need the legal fine print of device labelling or FDA enforcement. Learn to ask "cleared, granted or approved, and for what use?" and to check the answer against the FDA list.

Go deeper (optional)

• Artificial Intelligence-Enabled Medical Devices (list) #116
• How AI is used in FDA-authorized medical devices: a taxonomy across 1,016 authorizations #205
• Is It Really 'FDA Approved'? (consumer update) #159

In plain words

AI models are often updated after release, for example retrained on newer data. A PCCP (predetermined change control plan) is a plan the manufacturer submits in advance. It sets out which changes it intends to make and how it will check them. The idea is that changes within the agreed plan can then be made without a fresh submission each time. The FDA's final guidance says a PCCP has three parts: Description of Modifications, Modification Protocol and Impact Assessment (see #31).

Healthcare example (illustrative)

Imagine a hypothetical tool that estimates fetal growth from obstetric ultrasound, and its maker plans to retrain it as more scans become available. Its PCCP would describe what may change, set out how the retrained model will be tested, and assess the effect on safety and performance. For the obstetric unit using it, the practical questions are: does the tool have a PCCP, and how will we be told when the model changes?

A little more technical

According to the resource list, the FDA guidance applies to all AI-enabled devices and a PCCP is available for the 510(k), De Novo and PMA routes. It was first finalised in December 2024 and an updated version was published on 18 August 2025, so cite both (see #31). The FDA, Health Canada and the MHRA have also published five joint guiding principles for PCCPs: focused, risk-based, evidence-based, transparent and lifecycle. They are aligned with good machine learning practice (GMLP) (see #32).

Don't learn this yet

You don't need to know how to write a PCCP or what goes into each part in detail. Remember that an AI device can change after you start using it, and ask how changes are controlled and communicated.

Go deeper (optional)

• Marketing Submission Recommendations for a PCCP for AI-Enabled Device Software Functions (final) #31
• PCCPs for ML-Enabled Medical Devices: Guiding Principles #32
• Artificial Intelligence in Software as a Medical Device #117

In plain words

Not all clinical decision support (CDS) software is regulated as a medical device in the US. The FDA's CDS guidance sets out four criteria for CDS software that falls outside the device definition. The one that matters most to clinicians is Criterion 4: the clinician can independently review the basis for the recommendation, rather than simply having to trust it (see #33).

Healthcare example (illustrative)

Imagine two hypothetical nephrology tools. One flags possible acute kidney injury and shows the creatinine trend and the guideline rule it applied, so the clinician can check its reasoning. The other gives a risk score from a model whose reasoning is not shown. The first looks closer to the spirit of Criterion 4 than the second. Whether either is actually a device depends on all four criteria and on the guidance's detail, which is for the organisation's regulatory lead to judge.

A little more technical

The guidance was issued on 6 January 2026 and replaced by a version dated 29 January 2026, so cite the 29 January version (see #33; the FDA's webinar slides walk through it, see #34). The resource list notes that it loosens some positions from 2022 and does not mention AI explicitly, so applying it to an AI tool means reading the criteria carefully rather than looking for an AI section. A revised General Wellness policy (January 2026) is described in the resource list as a broader carve-out for non-invasive wearables (see #35). Remember the hierarchy: laws and regulations bind, FDA guidance sets out the agency's current thinking, and professional-body recommendations guide practice.

Don't learn this yet

Skip the history of earlier CDS guidance and the legal wording of the device definition. Hold on to Criterion 4: if you cannot see the basis for a recommendation, you cannot verify it.

Go deeper (optional)

• Clinical Decision Support Software (final guidance) #33
• FDA CDS final guidance webinar slides #34
• General Wellness: Policy for Low Risk Devices (revised) #35

In plain words

In the European Union, medical devices, including medical software, are regulated under the Medical Device Regulation (MDR), with a separate regulation (IVDR) for in-vitro diagnostics. The AI Act, Regulation (EU) 2024/1689 of 13 June 2024, is a general law on AI across all sectors (see #120). Medical devices count as high-risk AI under the AI Act through the MDR and IVDR. An AI medical device in the EU therefore sits under two layers of rules.

Healthcare example (illustrative)

Imagine a hospital in an EU country considering an AI tool that grades photographs of skin lesions in its dermatology clinic. The procurement team would ask about the tool's conformity under the MDR (its CE marking) and about the manufacturer's obligations under the AI Act. The clinicians would still ask the Track 3 questions: was it tested on patients like ours? A tool authorised in the US is not automatically permitted in the EU, and the reverse is also true.

A little more technical

An EU "regulation" is binding law that applies directly in every member state, unlike guidance. The AI Act's official text is free in every EU language (see #120). How the AI Act and the MDR fit together, and when each obligation applies, is detailed and still being clarified. The resource list has not yet verified the MDR text or secondary guidance on it, so check the primary texts and your organisation's regulatory lead rather than relying on summaries.

Don't learn this yet

Skip article-by-article reading, notified-body procedures and application dates. You need the two-layer picture (device regulation plus AI law) and the habit of asking a vendor which rules it has met.

Go deeper (optional)

• Regulation (EU) 2024/1689 — Artificial Intelligence Act (official text) #120

In plain words

Four pieces matter for AI in Indian healthcare:

• Medical Devices Rules, 2017 (MDR 2017): the legal base for medical devices in India (see #38). Not to be confused with the EU MDR.
• CDSCO Medical Device Software guidance: explains how those rules apply to software, including AI (see #37).
• ABDM: the national digital health building blocks, such as ABHA and the HIE-CM (see #121).
• DPDP Act 2023 and DPDP Rules 2025: govern personal data, which covers patient data in any Indian AI workflow (see #40).

Healthcare example (illustrative)

Imagine an obstetric unit in an Indian district hospital considering an AI tool that helps interpret fetal heart-rate traces. The team would ask: is this medical device software, and which risk class? Who licensed it? Where does patient data go, and does its handling meet the DPDP rules? Does it connect to ABDM records? An AI tool that only schedules appointments or handles billing would fall outside the software guidance.

A little more technical

According to the resource list, the CDSCO guidance uses risk classes A to D: classes A and B are licensed by state authorities, and classes C and D by the Central Licensing Authority; it also covers technical files, quality management systems and post-market duties. The DPDP Rules are phased in under Rule 1: some rules applied on publication, the consent-manager rule one year later, and most others after 18 months (see #40). The ICMR's ethical guidelines add ten patient-centric principles, including the right to refuse AI, plus ethics review and informed consent (see #39). Phasing and interpretation can change, so check the primary documents and your organisation's regulatory or data-protection lead.

Don't learn this yet

Skip licence applications, ABDM integration work (that is for builders) and rule-by-rule DPDP dates. Know the four pieces, what each one covers, and whom to ask.

Go deeper (optional)

• Guidance Document on Medical Device Software (Doc No. CDSCO/MD/GD/MDSW/01/2026) #214
• Medical Devices Rules, 2017 #38
• Digital Personal Data Protection Act 2023 + DPDP Rules 2025 #40
• Ethical Guidelines for Application of Artificial Intelligence in Biomedical Research and Healthcare #213
• ABDM Sandbox (developer portal & API docs) #121

In plain words

Before an AI tool affects patients, a hospital needs a consistent way to decide whether to adopt it, who watches it, and when to switch it off. A checklist makes that routine repeatable. The one below is a teaching aid, not a legal standard. Local law, policy and your governance lead come first.

Healthcare example (illustrative)

Imagine a paediatric ward that wants an AI early-warning score. The hospital's AI governance group works through the checklist and finds that the tool was tested only on adult patients, and that no one has been named to review its performance after go-live. It agrees to a limited pilot with local evaluation, a named clinical owner and a clear route for staff to report problems. Nurses and doctors still assess every flagged child themselves before acting.

A little more technical

An illustrative checklist:

• Intended use: what decision does it support, and who acts on the output?
• Regulatory status: is it a device, and is it authorised for this use in this country?
• Evidence: external and local validation (Track 3).
• Data: what data leaves the hospital, and is that lawful under data-protection rules such as DPDP?
• Human oversight: who verifies each output, and how is disagreement recorded?
• Monitoring and change: who tracks performance and drift, and how are model updates communicated?
• Exit: how can it be switched off safely?

The WHO's guidance on large multi-modal models gives over 40 recommendations, including some for health care providers (see #115). The ICMR guidelines cover governance and informed consent (see #39).

Don't learn this yet

Skip enterprise risk frameworks, contract clauses and procurement law. Know the questions, and bring them to your organisation's governance lead.

Go deeper (optional)

• Ethics and governance of AI for health: Guidance on large multi-modal models #115
• Ethical Guidelines for Application of Artificial Intelligence in Biomedical Research and Healthcare #213
• Artificial Intelligence-Enabled Medical Devices (list) #116

In plain words

The NIST AI Risk Management Framework (AI RMF) is a voluntary framework from the US National Institute of Standards and Technology. It helps organisations identify and manage the risks of AI systems. It is not healthcare-specific and it is not a law. The resource list has not yet verified it, so treat this as a short overview only.

Healthcare example (illustrative)

Imagine a hospital's clinical safety and IT teams planning to introduce an AI note-drafting tool in general practice. They use the framework's structure to organise their questions: who is accountable, where the tool could cause harm, how they will measure errors, and what they will do when errors appear. The GPs still read and correct every draft before it enters the record.

A little more technical

The framework is organised around four functions: Govern, Map, Measure and Manage. Roughly, Govern is about accountability and policy, Map about context and intended use, Measure about evaluation, and Manage about acting on risks over time. These line up with the hospital governance checklist above. Unlike FDA or CDSCO rules, which regulate products, the framework helps an organisation manage its own use of AI.

Don't learn this yet

Skip the companion documents, profiles and mappings to other standards unless you lead AI governance. A clinician only needs to know the framework exists and what the four functions mean.