Clinical decision support AI must be assessed from its intended purpose: what clinical question it answers, what data it uses, what output it produces, who acts on the output and with what discretion. That assessment determines whether medical device law applies, whether the Annex I or Annex III route is engaged, and what human oversight, documentation and monitoring are required. A system that presents information for a clinician to consider is assessed differently from a system that directs a clinical action, and a system that is used outside its assessed purpose is a different system for classification purposes. This guide does not give clinical advice and does not determine the status of any decision support product.
What is the intended purpose of the system?
The intended purpose is the use for which the system is intended by its provider, as stated in the instructions for use and the technical documentation, and it is the starting point for every later assessment. For clinical decision support, the purpose should be stated precisely: the clinical condition or question, the population, the input data, the output, the intended user and the setting. A purpose stated as supporting clinicians in general is too broad to assess, while a purpose that names the decision, the data and the user can be tested against the sector definition, Article 5, Article 6 and Annexes I and III. The purpose should also state what the system does not do, including any decisions it is not intended to support and any populations it is not intended for. A deployer that uses the system for a purpose outside the stated intended purpose should treat that use as a new assessment, not as an extension of the existing one.
How is the device question approached?
The device question is whether the system, by its intended purpose, is a medical device or an in vitro diagnostic device under Regulation (EU) 2017/745 or Regulation (EU) 2017/746. Software that provides information used to take decisions with diagnostic or therapeutic purposes can fall within the sector definition, while software that only stores, archives or communicates data, or that provides general information, may not. The distinction turns on the function and the claims made for the system, and it should be assessed with qualified regulatory advice, using the sector guidance and the manufacturer's intended purpose, before the AI Act route is assigned. Where the device question is answered in the affirmative and third-party conformity assessment is required, the Annex I route follows, with the AI Act requirements taken into account in the sector assessment. Where it is answered in the negative, the Annex III route and the other AI Act provisions must still be tested, since a non-device system can still engage biometric, transparency or other duties.
For the broader regulatory framework, see healthcare and biometrics under the AI Act.
What does human oversight mean in a clinical setting?
Human oversight for a high-risk clinical system means that the system is designed and used so that a competent person can understand its output, assess its limitations, decide whether to follow it and intervene or disregard it where appropriate. That requires more than a clinician being present: the clinician needs the information, the time, the competence and the authority to exercise oversight, and the system needs to present its output, its confidence or limitations and its basis in a form the clinician can use. The oversight design should address automation bias, the tendency to follow a system's output without critical assessment, and should provide for a second check where the consequence of an error is serious. The deployer should record who exercises oversight, what training they have received, what information they are given and how overrides are recorded. An oversight arrangement that exists on paper but cannot be exercised in the time available is not effective oversight.
What evidence should a healthcare deployer expect?
A healthcare deployer should expect the provider's instructions for use, the intended purpose and limitations, the performance and validation evidence for the population and setting concerned, the oversight measures, the data requirements, the update and change policy, and the incident and feedback channel. The deployer should check that the validation evidence covers its own patient population and clinical setting, or record why it is transferable, and should not assume evidence from a different population or setting applies without that check. The deployer should also keep its own record of use, including the system version, the clinicians and teams using it, the decisions it supported, the overrides and the outcomes observed. That deployment record is the basis for post-market monitoring feedback to the provider, for incident reporting where required, and for reassessment when the system, the data or the clinical pathway changes.
How should changes and updates be handled?
Changes and updates to a clinical decision support system, including model retraining, new data sources, new features and changes to the user interface, should be handled as a joint review of the sector and AI Act positions. A change can alter the intended purpose, the device classification, the risk profile, the validation evidence and the oversight design, and it can require a new conformity assessment, a new registration or a new deployment approval. The provider should communicate changes in advance, with the nature of the change, the evidence supporting it and the action the deployer should take, and the deployer should record whether it accepts the change, what retraining or revalidation it carries out and when the change goes live. A silent update, applied without notice or record, breaks the evidence chain and can leave clinicians using a system whose behaviour has changed without their knowledge. The change log should be kept with the system's lifecycle file.
Continue with healthcare AI and medical device law.
What does this guide not decide?
This guide does not decide whether any decision support product is a medical device, is high-risk, or is safe or effective for any clinical purpose, and it does not give clinical advice on diagnosis, treatment or patient care. Those are sector and clinical questions for the manufacturer, the notified body, the competent authorities and the clinicians concerned, applying the sector legislation and clinical evidence to the specific product and population. The guide also does not cover the data protection assessment for health data, which must be carried out separately. Where a decision support system is to be deployed in clinical care, confirm the regulatory and clinical position with the competent authorities and qualified advisers before use, and keep the assessment with the deployment record.
Frequently asked questions
Is all clinical decision support AI a medical device?
No. Device status depends on the intended purpose and function under Regulation (EU) 2017/745 or Regulation (EU) 2017/746, assessed with qualified regulatory advice. A system that is not a device can still engage other AI Act provisions.
Does a clinician's presence satisfy human oversight?
No, not by itself. Oversight requires the information, time, competence and authority to understand, assess and override the output, and an arrangement that cannot be exercised in practice is not effective oversight.
Must validation evidence match the deployer's population?
The deployer should check that the evidence covers its population and setting, or record why it is transferable. Evidence from a different population or setting should not be assumed to apply without that check.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689, as amended ↗AI Act Service Desk implementation timeline ↗