AI in medical devices · Basic · 13 min lesson
AI and machine learning landscape in healthcare: device types, claims and stakeholders
MDR 2017/745 Article 2(1), Annex VIII Rule 11 and Annex I section 17; Good Machine Learning Practice principles; FDA list of AI-enabled devices
What you will learn
- Distinguish machine learning from conventional software and tell software as a medical device from software in a medical device.
- Write and test an intended use and performance claim for an AI device, and explain why the claim drives class and evidence.
- Map the stakeholders around an AI device and spot the roles and risks a weak record leaves out.
Key takeaways
- Machine learning behaviour comes from data, so data sources, splits and gaps are design inputs that need records.
- Software as a medical device stands alone; software in a medical device is assessed with its hardware (MDR Article 2(1)).
- The intended use names purpose, patient group, user, setting and limits, and drives class (Rule 11) and clinical evidence (Article 61).
- A performance claim needs a defined test set, confidence bounds and subgroup results; marketing wording must match (Article 7).
- Stakeholders include deployers, suppliers and patients; learning systems add bias, overfitting, drift and opacity risks.
Free practice question
Halcyon Diagnostics sells a program that reads chest CT images from any scanner and ranks them by suspected stroke. It is installed on the hospital server, sold separately and has its own licence.
How should Halcyon describe the product?
Software in a medical device, because the images come from a scanner.
Not quite. Supplying images does not make the program part of the scanner; it has its own purpose, so Article 2(1) treats it separately.
Not a device, because a clinician makes the final call.
Not quite. A clinician's final decision does not remove the medical purpose; Rule 11 in Annex VIII covers software that informs decisions.
Software as a medical device with a medical purpose, assessed on its own.
Correct. MDR Article 2(1) includes software with a medical purpose and nothing makes this program part of hardware.
An accessory of the scanner under Article 2(2).
Not quite. An accessory under MDR Article 2(2) must enable a device to be used as intended; a stand-alone triage program has its own medical purpose.
Key terms
- machine learning: A method in which a system learns patterns from data instead of following rules written by a person.
- SaMD: Software intended for a medical purpose that performs it without being part of a hardware medical device.
- intended use: The medical purpose, patient group, user and setting for which the manufacturer designs and claims the device (MDR Article 2).
- locked and adaptive: A locked model is fixed after validation; an adaptive model changes as it receives new data.
- data drift: A change in real world data after release that makes the model perform differently from its validation.
- automation bias: The tendency of people to follow a confident automated output even when it is wrong.
- deployer: The organisation, often a hospital, that installs and uses the AI device in its own workflow.
- GMLP: Ten guiding principles for good machine learning practice across the device lifecycle, published by IMDRF in 2025.
Official sources
- FDA - Artificial Intelligence-Enabled Medical Devices (list)
- FDA - Good Machine Learning Practice for Medical Device Development: Guiding Principles
- European Commission - MDCG 2025-6, FAQ on the interplay between MDR/IVDR and the AI Act
- Regulation (EU) 2017/745 on medical devices
Go further
The full lesson has narrated slides, more scenario questions with explained answers and a simulation.
Open the AcademyWatch on YouTubeIllustrative example. Educational only, not legal advice.