EU MDR classification workflow

Begin with the exact intended purpose in the label, instructions for use, promotional or sales materials, and clinical evaluation. Article 2 defines intended purpose by those manufacturer-supplied materials, and MDCG 2021-24 warns that it is the manufacturer's intended purpose, not accidental use or the class of similar products, that determines the class.

Record the clinical purpose, patient or user group, body contact, duration of use, invasiveness, active function, measuring function, medicinal or biological interaction, software output, and whether the device is used alone, in combination, as a system, or as a procedure pack.

Confirm whether the product is a medical device, an accessory for a medical device, software, a system or procedure pack, an Annex XVI product without an intended medical purpose, or outside MDR scope. Article 2 includes software in the medical device definition where the manufacturer intends it for a listed medical purpose, and it defines accessories as articles intended to enable or directly assist a device's medical functionality.

For software, separate three questions: whether it has its own medical purpose, whether it drives or influences a hardware medical device, and whether it only performs storage, archival, communication, simple search, or non-medical administrative functions. MDCG 2019-11 treats software with a medical purpose as medical device software and explains that software driving or influencing a hardware device can be covered as a part, component, or accessory.

Apply Annex VIII from the product facts, not from the preferred route. Start with non-invasive, invasive, active, and special-rule categories, then document why each potentially relevant rule applies or does not apply. MDCG 2021-24 identifies the classification criteria as duration of contact, invasiveness, local or systemic effect, toxicity, affected body part, and dependence on an energy source.

If more than one rule or sub-rule applies based on the intended purpose, apply the strictest rule that results in the higher classification. For systems and procedure packs, classification depends on the intended use of the combination; where the combination includes non-CE-marked devices, incompatible use, or sterilisation outside manufacturer instructions, the pack may need to be treated as a device in its own right.

For medical device software, test Rule 11 specifically. Software that provides information used for diagnosis or therapeutic decisions is class IIa unless the decision impact can cause death or irreversible deterioration, making it class III, or serious deterioration or surgical intervention, making it class IIb. Software intended to monitor physiological processes is class IIa, unless it monitors vital physiological parameters where variations could create immediate danger to the patient, making it class IIb. All other software is class I.

Also check Annex VIII implementing rules. Software that drives or influences the use of another device falls in the same class as that device; independent software is classified in its own right. Where Rule 11 and another rule both apply, use the strictest applicable rule.

Use the final class to choose the conformity assessment route under Article 52 before placing the device on the market. Class III, IIb, and IIa devices generally require notified body assessment under the Article 52 routes and Annexes IX to XI. Class I devices are generally declared by the manufacturer after technical documentation is drawn up, but class I sterile devices, devices with a measuring function, and reusable surgical instruments require limited notified body involvement for the relevant sterile, metrological, or reuse aspects.

The classification outcome also changes the depth of clinical, PMS, PSUR, UDI, SSCP, and notified-body evidence expected in the technical file. Do not close classification until regulatory, quality, clinical, software, and notified-body planning have checked that the selected route matches the class and special features.

The classification rationale should be reviewable without reconstructing the workflow from meetings or emails. Keep it with the technical documentation and refresh it when claims, software functions, hardware combinations, body-contact facts, clinical use, or applicable guidance change.