Establishes the procedure by which competent authorities (CAs) in EU Member States consult one another on complex borderline and classification questions under the MDR (2017/745) and IVDR (2017/746), producing consistent EU-wide positions published in the Manual on Borderline and Classification. Manufacturers and trade associations can request an EU-wide opinion via a CA. The initiating CA submits a standardised enquiry describing the device, its intended purpose and the classification issue; other CAs respond within about one month. If more than 75% agree, a draft Manual entry is prepared and put to a vote (adoption requires a 75% majority); where consensus is not reached, the case is escalated to CA meetings or a task force, with coordination from other MDCG working groups (e.g. the New Technologies Working Group) for technology-specific questions. The full process, from enquiry to publication, takes roughly 5.5 months. The procedure is not limited to any particular product category and can be used for unclear qualification/classification questions involving SaMD.

Explains how manufacturers meet the cybersecurity-related general safety and performance requirements (GSPRs) in Annex I of the MDR (2017/745) and IVDR (2017/746) across the full device lifecycle, for medical devices and IVDs that include programmable electronic systems or software -- SaMD, embedded software, mobile apps, networked devices, and systems relying on hospital networks or cloud services. Its central principle is that "security is part of safety and risk management," and it distinguishes between (1) built-in security capabilities -- authentication, authorization, integrity protection, logging, backup/recovery, and secure update mechanisms -- and (2) security information that must be documented, covering the operating environment, configuration, accounts, network controls, updates and residual risk. Pre-market expectations include linking threat analysis to the safety risk management file, applying defence-in-depth controls (least privilege, strong identity management, protected communications, audit logging), and defining testable operating-environment requirements. Post-market expectations include active monitoring of vulnerability sources (databases, researcher reports, supplier notices, threat intelligence), risk assessment, coordinated disclosure, security updates and communication to users. The guidance frames cybersecurity as a shared responsibility between manufacturer and healthcare provider, while stressing that a manufacturer cannot transfer its own design and regulatory obligations to the hospital or user, and aligns with IMDRF's international guidance on medical device cybersecurity.

Sets out how manufacturers determine the level of clinical evidence needed for medical device software (MDSW) under the MDR (2017/745) and IVDR (2017/746), built around three components: (1) valid clinical association / scientific validity -- whether the software's output is meaningfully linked, per accepted medical knowledge or peer-reviewed literature, to the targeted clinical or physiological state; (2) technical/analytical performance -- whether the software accurately, reliably and precisely generates the intended output from its input data; and (3) clinical performance -- whether the software yields a clinically relevant result in line with its intended purpose. The required evidence level scales with device classification: MDR Class III and implantable devices generally require clinical investigation data (subject to the Article 61(4)-(6)/(10) exceptions), while IVDR generally requires performance studies regardless of class, unless an alternative evidentiary route is justified. Clinical evaluation is treated as part of the quality management system and as an iterative, ongoing process across the software's lifecycle, supported by Post-Market Clinical Follow-up (PMCF) / Post-Market Performance Follow-up (PMPF) to keep the evidence current. Annex II gives six worked examples -- covering a sleep-quality analyser, an image segmentation tool, a semi-quantitative IVD calprotectin detector, embedded device-driving software, an insulin-pump companion app, and closed-loop ventilator CO2-control software -- illustrating when MDSW can be evaluated independently versus when it must be evaluated jointly with the hardware it drives or influences.

Clarifies, for software that is placed on the market either as a standalone medical device or as a component of another medical device, when manufacturers must assign a new Basic UDI-DI as opposed to simply updating the UDI-PI (production identifier) for a minor version change. A new Basic UDI-DI is required when a change affects the software's original performance, safety, or interpretation of data -- for example, new or modified algorithms, database structures, operating platforms, architecture, user interfaces, or new interoperability channels -- or when the Basic UDI-DI itself, the name/trade name, version/model number, critical warnings or contraindications, or the user-interface language changes. By contrast, minor revisions such as bug fixes, non-safety-related usability improvements, security patches, or operating-efficiency changes do not require a new Basic UDI-DI; these are tracked instead through the manufacturer's own version/release identification scheme reflected in the UDI-PI. The guidance notes that UDI placement (labelling/display) criteria are addressed in a separate, later guide, and should be read together with MDCG 2018-1 on UDI assignment.