Risk Classification of Software Medical Devices

The process of determining the risk level of your Software as a Medical Device. It determines the level of clinical evidence and regulatory oversight your product requires.

Classifying the risk of a product is standard practice across international jurisdictions. It’s a way to categorise your product by the possible harm caused to the patient or user if something went wrong. However, different jurisdictions have different classification systems.

EU - Medical Device Regulations (MDR) Guidance

The EU MDR outlines 4 main risk classes: I (lowest risk), IIa, IIb and III (highest risk). In terms of medical software in particular, the following classification rules apply, according to MDCG 2021-24 guidance. Briefly, software is categorised as Class I, unless it is used to inform diagnostic or therapeutic purposes (which makes most software class IIa). Treating or diagnosing critical conditions or monitoring vital physiological parameters puts your software in Class IIb. If the situation is life-threatening, it’s Class III. In essence, most SaMD is Class IIa or above under the EU MDR.

Software is Class I, unless

It provides information used to take decisions with diagnosis or therapy, making it Class IIa, unless

It monitors physiological processes, making it Class IIa, unless

It monitors vital physiological processes where incorrect monitoring could lead to immediate danger to the patient, making it Class IIb

The decision impact can cause serious deterioration in health or surgical intervention, making it
Class IIb

The decision impact can cause death or irreversible deterioration, making it
Class III

UK Medical Device Regulations

Until 30th June 2027, the UK will continue to follow the old EU Medical Device Directive regulations (EU MDD) to issue UKCA marks under the UK MDR and therefore use an older risk classification system. Broadly speaking, under EU MDD, more standalone software is categorised under class I (lowest risk), rather than IIa, IIb or III. Guidance on standalone software classification can be found in the MEDDEV 2.1/6 guidance, but given the complexity of market access with UKCA marking, we suggest you get in touch with Hardian to discuss if this strategy is the best fit for your product and company.

US - FDA Guidance

The US has a similar framework, classifying devices into 3 main classes: class (low to moderate risk), class II (moderate to high risk) and class III (high risk). Based on the device class, there are other regulatory controls (either general controls for the class or special controls for the subclass). These are additional requirements that need to be met in terms of demonstrating the safety and performance of the device in question.

The importance of risk classification

Why does risk classification matter? In simple terms, the lowest-risk devices (Class I) tend to have the lowest regulatory oversight. In both the US and the EU, Class I devices are often β€˜self-certified’, in that the companies with Class I devices do not need to seek formal external review of their certification. However, the level of evidence to prove safety and performance may not be lower! However, for Class II and III devices, either the FDA, EU notified body or UK approved body will audit companies and review the clinical and technical requirements to make sure they are aligned with the regulatory requirements.

Best Practices

Align with internationally recognised standards.

Particularly for Software as a Medical Device, we recommend referring to the International Medical Device Regulators Forum (IMDRF) guidance on the risk classification of SaMD, so you can properly determine how risky your SaMD is. 

First, you need to consider what your software is being used for:

  1. Directly treating, diagnosing or detecting a disease: does your software/AI device directly impact a patient or the diagnostic capabilities of healthcare professionals?

  2. Driving clinical management: does your device give information that is then later used to drive further diagnostic tests, treatments or investigation decisions?

  3. Informing clinical management: does your device give non-urgent clinical information either by aggregating data or by informing future options for treatment, investigation and diagnosis?

Then, you need to consider how critical the clinical condition is where your software is deployed:

  1. Critical: situations where a time-sensitive response is needed to avoid long-term disability, death or serious deterioration. The disease state is life-threatening.

  2. Serious: situations where the software functioning properly is vital to avoid unnecessary interventions or tests. The disease state is moderate and may not require major interventions.

  3. Non-serious: situations that are not time critical, but where accurate diagnosis and treatment are still important. The disease state is usually chronic, mild and predictable.

The table below shows how the IMDRF classifications map onto the EU Medical Device regulation classifications described in MDCG 2021-24.

Treating or diagnosing

EU Class III

Critical risk for patient

EU Class IIb

Serious risk for patient

EU Class IIa

Non-serious risk for patient

Driving clinical
management

EU Class IIb

Critical risk for patient

EU Class IIa

Serious risk for patient

EU Class IIa

Non-serious risk for patient

Informing
clinical management

EU Class IIa

Critical risk for patient

EU Class IIa

Serious risk for patient

EU Class IIa

Non-serious risk for patient

Best Practices for US FDA classification

In the US, the best way to determine what risk classification your software is in is by finding a predicate device with similar characteristics to your software. If you can’t find a predicate device, you may need to apply for a De Novo classification request. This can be a lengthy process, but Hardian can assist you throughout.

Case Study

How Hardian solves the problem.

Hardian worked with a digital therapeutics company to achieve regulatory approval in multiple jurisdictions. By first writing a clear Intended Use Statement, and then determining the possible situations in which the device may have risky outcomes, the device classification decision drove the future requirements for designing clinical investigations and developing a suitable quality management system to maintain the quality of the product in that risk class.

Get in touch

Getting healthtech to market doesn’t have to be difficult.

Next steps

Previous
Previous

Intended Use

Next
Next

Notified / Approved Body Engagement