Classify under Rule 11 and complete the corresponding conformity assessment
Severity CriticalAnnex VIII §6.3 (Rule 11);Art. 10(2)
Classify the software under Rule 11 in Annex VIII section 6.3: software providing information used to take decisions with diagnosis or therapeutic purposes is class IIa, rising to class III where the decisions may cause death or an irreversible deterioration of health, or class IIb where they may cause serious deterioration or a surgical intervention; software monitoring physiological processes is class IIa, or class IIb where it monitors vital physiological parameters whose variations could cause immediate danger; other software is class I. The classification drives the notified body route, the depth of the technical documentation and the clinical evaluation, so it must be fixed in a written classification rationale and re-assessed whenever the intended purpose wording changes.
- Applies when
- Manufacturers placing AI medical software on the EU market and own-branders selling under their own name in the EU.
- Evidence to retain
- · Finalised intended purpose with indications, users and use environment
- · Rule 11 classification rationale and conclusion
- · Notified body selection and application dossier
- · Conformity assessment certificates and technical documentation review records
- · Re-classification record whenever the intended purpose changes
Estimated first-time effort: 30–90 person-days (estimate, not a commitment)
Establish the Article 10(9) quality management system and maintain the technical documentation
Severity CriticalArt. 10(2), 10(9);Annexes II–III;Art. 120(3c)(d)
The manufacturer must establish, document, implement and maintain a quality management system covering the regulatory compliance strategy, risk management, clinical evaluation, product realisation, post-market surveillance and vigilance, and must draw up and keep up to date the technical documentation under Annexes II and III. For AI software the QMS must cover the provenance and management of training, tuning and test data, model versioning and traceability, algorithm change control and revalidation, and the software lifecycle processes; the technical documentation must support the notified body review of algorithm performance, generalisation and clinical evidence.
- Applies when
- All manufacturers under the MDR; those relying on the extended transition must show the QMS was in place by 26 May 2024.
- Evidence to retain
- · Quality management system documentation (quality manual, procedures, regulatory compliance strategy)
- · Complete Annex II/III technical documentation with version records
- · Provenance, annotation and quality control records for training, tuning and test data
- · Model version register and algorithm change control and revalidation records
- · Risk management file and clinical evaluation report
Estimated first-time effort: 60–180 person-days (estimate, not a commitment)
Non-EU manufacturers must appoint an EU authorised representative
Severity CriticalArt. 11
A device from a manufacturer not established in the Union may only be placed on the EU market after a single authorised representative has been designated. The authorised representative accepts its tasks by written mandate: verifying the declaration of conformity and technical documentation, keeping copies, cooperating with competent authorities, forwarding information requests and adverse event information, and in defined circumstances sharing liability for defective devices with the manufacturer. For Chinese AI medical software companies the choice and mandate scope of the authorised representative is the first step of the market route, and its details are registered in EUDAMED with the device.
- Applies when
- Chinese medical AI manufacturers without a registered entity in the EU.
- Evidence to retain
- · Written mandate of the authorised representative setting out the tasks and termination conditions
- · Due diligence and capability assessment of the authorised representative
- · Inventory of technical documentation and declaration of conformity copies held by the representative
- · Consistency check of the representative details across labelling, instructions for use and registration data
Estimated first-time effort: 5–15 person-days (estimate, not a commitment)
Implement the UDI system and complete economic operator and device registration
Severity HighArt. 27, 29, 31;Art. 87
Manufacturers must implement the Unique Device Identification system under Article 27, and the UDI must be used when reporting serious incidents and field safety corrective actions under Article 87. Device registration under Article 29 and registration of manufacturers, authorised representatives and importers under Article 31 must be completed. For software devices the UDI versioning rules couple most tightly to the release cadence, so the release process must fix which changes trigger a new UDI-DI.
- Applies when
- Manufacturers, authorised representatives and importers.
- Evidence to retain
- · UDI assignment rules and the UDI-DI / UDI-PI register
- · Rules and execution records for which software version changes trigger a new UDI-DI
- · Confirmation of device registration and economic operator registration
- · Evidence linking UDIs to serious incident reports and field safety corrective action records
Estimated first-time effort: 15–40 person-days (estimate, not a commitment)
Operate post-market surveillance and update the periodic safety update report at the class-specific frequency
Severity HighArt. 83, 84, 85, 86
Manufacturers must operate a post-market surveillance system proportionate to the risk class under Article 83, a PMS plan under Article 84 and a PMS report under Article 85. For class IIa, IIb and III devices a periodic safety update report under Article 86 must summarise the results and conclusions of the analyses of PMS data, including the benefit-risk determination conclusions, the main PMCF findings, and the sales volume with an estimate of the size and characteristics of the user population and, where practicable, usage frequency. Class IIb and III manufacturers must update the PSUR at least annually; class IIa manufacturers when necessary and at least every two years. For class III and implantable devices the PSUR is submitted to the notified body through the electronic system; for other devices it is made available to the notified body and, on request, to competent authorities. Where PMS identifies a need for preventive or corrective action, the measures must be implemented and the competent authorities and, where applicable, the notified body informed.
- Applies when
- All manufacturers under the MDR; for AI software, model drift monitoring, real-world performance metrics and user feedback must be part of the PMS data sources.
- Evidence to retain
- · Post-market surveillance plan and post-market surveillance report
- · PSUR updated at the class-specific frequency, with submission or provision records
- · PMCF plan and evaluation report
- · Real-world model performance metrics and drift alert records
- · Records of preventive or corrective actions and of notifications to competent authorities and the notified body
Estimated first-time effort: 20–60 person-days (estimate, not a commitment)
Report serious incidents and field safety corrective actions within the Article 87 deadlines
Severity CriticalArt. 87(1), 87(2), 87(3), 87(4), 87(5);Art. 88;Art. 92
Manufacturers must report serious incidents involving devices made available on the Union market, except expected side-effects that are clearly documented in the product information, quantified in the technical documentation and subject to trend reporting under Article 88. The reporting period must reflect the severity: as a general rule the manufacturer reports immediately after establishing a causal relationship between the incident and the device, or that such a relationship is reasonably possible, and not later than 15 days after becoming aware of the incident; in the event of death or an unanticipated serious deterioration in a person state of health, immediately after establishing or as soon as it suspects a causal relationship and not later than 10 days after becoming aware; and in the event of a serious public health threat, immediately and not later than 2 days after becoming aware.
- Applies when
- Manufacturers, with authorised representatives forwarding adverse event information they receive; for AI software, incidents include diagnostic or therapeutic decision errors caused by incorrect algorithm output.
- Deadline: Generally within 15 days of awareness; within 10 days for death or unanticipated serious deterioration; within 2 days for a serious public health threat
- Evidence to retain
- · Vigilance procedure with the deadline triage rules
- · Records of incident intake, causality assessment and the point in time of reporting
- · Serious incident reports submitted to competent authorities with acknowledgements
- · Field safety corrective action plan and field safety notice
- · Quantification basis in the technical documentation for expected side-effects subject to Article 88 trend reporting
Estimated first-time effort: 10–30 person-days (estimate, not a commitment)