BlogA Quick Guide to Categories of SaMD

A Quick Guide to Categories of SaMD

Are you considering developing new types of SaMD (Software as a Medical Device)?

If so, you may already be aware that it is a growing field for medical devices and that rules and regulations have been shifting with that growth. Regulatory bodies worldwide are faced with the challenge of managing how these devices get to market among constant shifts in the technology that powers them.

The IMDRF (International Medical Device Regulators Forum), is a voluntary association of several medical device regulatory authorities. They have developed a set of guidelines, including those for the categorization of SaMD, and aim to provide harmonization across regulatory bodies.

It’s important to understand not only how SaMD is categorized, but the SaMD classification process as well, as this impacts your pathway to market with your new device. 

Here’s our quick guide to the categorization of SaMD.

How are SaMD Categorized?

The first part to understand when it comes to categorizing SaMD is the definition statement. This can be found in Section 6.0 in the IMDRF document. The purpose of the definition statement is to give SaMD developers a framework to help determine how their devices should be categorized.

Like any other type of medical device, the intended use is a starting point for categorization. IMDRF suggests framing the definition statement in terms of:

  1. The “significance of the information provided by the SaMD to the healthcare decision” identifies the intended medical purpose of the SaMD. The statement should include whether the device is used to treat or diagnose, drive clinical management, or inform clinical management.
  2. The “state of the healthcare situation or condition” that the SaMD is intended for. The statement should outline whether the state or condition is; a critical situation or condition, a serious situation or condition, or a non-serious situation or condition.
  3. A description of the SaMD’s core functionality. This should identify only the critical features or functions which are “essential to the intended significance of the information provided by the SaMD to the healthcare decision in the intended healthcare situation or condition.

Regardless of whether you are a beginner SaMD developer or not, the key takeaway here is that the definition statement forms a critical part of the basis for how the SaMD will be categorized. It is a necessary first step, as software as a medical device classification is heavily based on the significance of the information provided by the SaMD.

SaMD Categories 

Once you have your definition statement, your SaMD can be determined to fit one of the categories I – IV. These are based on how vital the information provided by the SaMD is for patient or public health, with category IV being the highest level of impact.

For example, if the information provided by the SaMD treats or diagnoses critical healthcare conditions and is vital to avoid death or serious disability, then it will likely be category IV. If it simply informs a non-serious condition, then it is probably a category I. The diagram below from MobiHealth illustrates this:

Categories of SaMD

 

It’s important to note that if your definition statement indicates your SaMD is for use across multiple different healthcare situations, then it will be categorized at whichever is the highest category for them. So if the situations would warrant a II and a III categorization, your device will be a III.

Another key aspect of categorization is an emphasis on the whole lifecycle of the SaMD. If you were to make any changes to the device that result in a change to the definition statement, then the categorization of your device should be re-evaluated in case it needs to change.

Examples of SaMD Classification

What might SaMD categorization look like in practice? Here are some examples:

Category I 

Category I informs a non-serious, serious, or critical health situation. Consider an app that calculates BMI. This is used as a data point to inform someone that they may need to gain or lose weight, but it doesn’t directly impact patient outcomes. That patient may have a serious or critical condition related to their weight (anorexia, for example), but that information is not directly treating or driving the clinical management of the condition.

Category II 

Category II informs a critical condition, treats or diagnoses a non-serious condition, drives treatment of a serious condition. An example here could be an Apple watch which can detect atrial fibrillation or myocardial ischaemia.

Category III 

Category III drives care for a critical condition, treats or diagnoses a serious condition. The software that controls a pacemaker is treating a serious condition.

Category IV 

Category IV treats or diagnoses a critical condition. For example, you might develop artificial intelligence to examine mammography images and determine whether or not a patient has breast cancer.

Examples of Risks for SaMDs

The categorization of SaMD is based upon relative risk. For example, if someone were reliant on data from the device to inform a treatment plan for a critical illness, then inaccurate data could create a risk that the patient is not treated as they should be.

Some examples of potential risks include:

  • The type of disease or condition the device is intended for. Cardiovascular disease is much more critical than something like acne.
  • The condition of the patient. For example, their relative fragility can be a risk.
  • The disease stage or progression. For example, someone with more advanced Parkinson’s usually has more severe mobility issues than someone at an early stage.
  • The level of dependence the user has on the data output from the SaMD. Is that information being used to make critical decisions? Is the SaMD providing clinical evaluations? How simple or hard is it for users to detect any erroneous information?

These risks can impact how the SaMD is classified, but there are other risks to keep in mind that don’t impact classification, such as technological risks. For example, the usability of the application could be a risk. UX and UI design are critical for all types of software, SaMD included. A confusing interface could result in the software not being used properly.

What About Artificial Intelligence in SaMD?

Artificial intelligence (AI) is recognized by FDA as having the potential to be transformative for healthcare. One of the challenges from a regulatory perspective is that the FDA’s traditional paradigm of medical device regulation was not designed with adaptive intelligence in mind.

If you’re developing a device with a machine learning feature, you’re programming it to learn and adapt over time. We mentioned diagnostics from imaging in the last section – AI tends to get better over time when exposed to more different sets of data. It figures out “breast cancer can look like that, but can also look like this other example.”

In February 2020, FDA issued its first authorization of an AI-backed SaMD, a cardiac ultrasound software. This was via the De Novo pathway and was approved in part due to the manufacturer’s use of a Predetermined Change Control Plan to incorporate future modifications.

The Predetermined Change Control Plan is one of the parts of a proposed regulatory framework for AI/ML-based SaMD. FDA is still considering how to best regulate AI technology and their next step will be to issue draft guidance. It is expected that categorization will follow similar lines to the current SaMD classification, with regulations around change control for the expected constant learning of the AI.

Final thoughts

SaMD are categorized by the role their data plays in the healthcare situation, as well as the seriousness of the condition. Like other medical devices, it’s a risk-based approach that requires manufacturers to apply risk management principles to the lifecycle of the device.

Most SaMD require cloud connectivity for the gathering, sharing, and storage of data, which necessitates a robust platform that follows data security protocols. This is where Galen Data can help.

Our cloud platform is purpose-built for medical devices, accounting for the features of which you need to meet SaMD compliance and regulatory requirements. We support FDA SaMD Classification I, II, III, and CE-marked medical devices, including SaMD. 

Would you like to see how we can help with your connected device? Schedule a free demo here.

ELEVATE YOUR BUSINESS WITH

The Galen Cloud

The ultimate solution for cloud-connected medical devices – fast, safe, powerful and easy to use, all at an incredibly attractive price.

Stay up to date on Galen happenings on LinkedIn!