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.