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.

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.