Software as a Medical Device (SaMD)

What is Software as a Medical Device (SaMD)?

SaMD, is a software that complies with the definition of a device and is intended for use for one or more medical purposes without being part of a hardware device.”

These criteria are a wonderful place to start, but there is a lot of complexity in what SaMD is and how to tell whether your product is SaMD. Let’s examine what software as a medical device is, what it isn’t, and how to determine whether your product satisfies the criteria.

How Do I Know if My Product is SaMD?

Since FDA is a participant in the IMDRF, it is obvious that both definitions of SaMD have structural similarities. For software to qualify as SaMD, it must accomplish two requirements that are outlined in the criteria provided by the FDA and IMDRF.

We must first decide if the software can even be referred to as a medical device. The IMDRF just indicates that it must be “intended for one or more medical purposes”.

Anything—including a component, part, or accessory—that is an instrument, equipment, implement, machine, contraption, implant, in vitro reagent, or other similar or related product, and that is:

Listed in the official National Formulary, the United States Pharmacopoeia, or any addition to either of those two publications
Intended for use in treating, preventing, or curing disease in humans or other animals, or in the diagnosis of disease or other disorders
Intended to influence the composition or any bodily function of humans or other animals, and not accomplished primarily by chemical activity within or on the human or animal body.

which is not dependent on being metabolised for the accomplishment of its primary intended goals and which does not achieve its primary intended purposes through chemical activity within or on the body of a man or another animal. Software functions that are disallowed under section 520(o) are not included in the definition of “device”.

You must specify the intended purpose and usage instructions for your product in order to use this definition properly. Just a reminder:

Intended use: Your device’s intended usage is its purpose. It is what will be done with your device.
Indications for use: The diseases or ailments that your gadget will diagnose, treat, prevent, cure, or alleviate are known as indications for use. Indications for use specify who and why your gadget will be used.

Is My Software Considered SaMD or SiMD?

Consider the case when you have found that your product satisfies the criteria for a medical device. The second half of the IMDRF and FDA’s SaMD criteria must still be considered.

According to the IMDRF definition, software must fulfil its functions “without being a part of a hardware medical device.”
The FDA nearly exactly uses the same words when it declares that SaMD “is intended to be used for one or more medical purposes without being part of a hardware device.”

SaMD’s reach is once more constrained by this. The requirements for SaMD are not met by software that is used to drive or power hardware.

As opposed to that, this kind of software is referred to as SiMD, or “software in a medical device.”

Simply simply, a medical device’s software is any programme that aids in the operation of its hardware, such as by generating a graphical user interface or powering its mechanics. Here are a few instances:

Software that regulates a blood pressure cuff’s expansion or contraction
A programme that regulates the insulin delivery on an insulin pump
Computer programmes for pacemaker closed-loop control.

If you hear the terms “embedded software,” “firmware,” or “micro-code” used to describe this kind of software, remember that these refer to SiMD rather than SaMD.

What are Some Examples of SaMD?

Real-world examples are frequently simpler to understand than theoretical ones. Below mentioned are a few examples of SaMD.

Software that enables viewing of diagnostic pictures from an MRI, ultrasound, or X-ray on a mobile device
Image processing software for breast cancer detection
Software that analyses data from a smartphone’s tri-axial accelerometer to determine a condition.
Real-time patient data collection software that is overseen by a medical expert and utilised to create treatment recommendations.

How is SaMD Regulated around the World?

Even though there are other medical device markets throughout the world, the US and the EU are by far the biggest; therefore, in this section, we will concentrate on these markets.

Start off by saying that a SaMD product is still considered a medical device and is subject to the same regulations as such.

A quality management system (QMS) will be necessary to get started. You must abide by the FDA’s Quality System Regulations (QSR) in the US. The EU MDR (or EU IVDR if it’s an in vitro diagnostic equipment) will also apply to your SaMD in the EU. The regulations that apply in each market will still be applied to your device’s classification.

Basically, it’s important to keep in mind that even if your SaMD may differ greatly from a conventional, hardware medical device, you still need to adhere to the same rules that apply to all other medical devices.

Considering this, let’s discuss some of the specifics of the SaMD regulatory environments in the US and EU.

What You Need to Know about SaMD Regulation in the US & UK?

Recently the FDA is aware that the standards for medical devices were created with traditional medical devices in mind, they have recently issued guidance guidelines that are specifically for software in areas like premarket filings.

Its initial guidance on SaMD premarket submissions was released in 2005. You are correct if you believe it to be a little dated. Because of this, the FDA revised its premarket submissions guidance for SaMD in 2021.

The hard part comes at this point. The paperwork you must submit is listed in both the draught guidance and the current guideline according to the intended usage of your SaMD.

The current recommendations, which date from 2005, categorise SaMD into three “levels of concern” based on the seriousness of injury that could result from a device failure or design flaw:

Minor: Latent design defects or breakdowns are unlikely to result in any harm to the patient or operator
Moderate: Failures or hidden design defects could cause mild injuries to the patient or operator as a direct outcome, either through the provision of delayed or inaccurate information or through provider actions.
Major: failures or latent design defects could directly cause patient or provider death or serious injury, including through the provision of inaccurate or delayed information or through provider actions.

The current advice document then describes the supporting documentation you must provide based on the level of concern that applies to your device. Please be aware that “level of concern” differs from the risk class assigned to your device.

Let’s now examine the draught guidance. In this instance, two layers of documentation have taken the place of the three degrees of concern:

Basic Documentation
Enhanced Documentation

What You Need to Know about Medical Device Software Regulation in the EU?

The EU’s regulation of SaMDs is comparable to that in the US in that it does not differ from the regulation of conventional medical devices. All pertinent requirements of the EU MDR and EU IVDR must still be followed.

However, it’s significant to note that EU rules do not make use of the phrase “software as a medical device.” Instead, they refer to it as “medical device software” or simply MDSW.

Fortunately, the European Commission (EC) has released a number of directives that apply to SaMD producers.

MDCG 2021-24 – Guidance on classification of medical devices
MDCG 2020-1 – Guidance on clinical evaluation and performance evaluation of medical device software
MDCG 2019-16 – Guidance on cybersecurity for medical devices
MDCG 2019-11 – Qualification and classification of software

How is SaMD Classified across Global Regulatory Markets?

We have already heard about the SaMD-related rules, recommendations, and worldwide standards.

Unfortunately, the IMDRF and IEC 62304 both include techniques for classifying SaMD in addition to the fact that the US and the EU have separate risk categories for medical devices. This can soon become confusing, so let’s utilise this part to explain each class and category and how they are related to one another.

SaMD Risk Class and “Levels of Concern”

The US approach for classifying SaMD comes first. The FDA categorises SaMD using the same risk classes—Class I, Class II, and Class III—as it does for conventional medical devices.

Just to emphasise, your risk class is not determined by the “level of concern” you select for your pre-market submission to the FDA. Simply put, the level of concern informs you of the supporting materials your pre-market submission will need. Your level of concern is not considered when determining the risk class for your device, even though it may be significantly connected with it.

Medical Device Software Risk Class and “Rule 11” in the EU

There is no MDSW-specific risk classification in the EU, like the US. Class I, class IIa, class IIb, and class III risk categories are used for medical device software in the same way as they are used for conventional medical devices.

However, Rule 11 of the EU MDR provides guidance on how to identify your medical device software risk class.

Rule 11 of the EU MDR’s Annex VIII reads as follows:

Software that is designed to give data required to make judgements for diagnosis or treatment purposes is classed as class IIa, unless those decisions may:

Class III refers to death or an irreparable decline in a person’s health
Class IIb refers to a substantial decline in a person’s health or a surgical procedure

Software meant to track physiological processes is categorised as class IIa, unless it’s meant to track vital physiological parameters, in which case it’s categorised as class IIb because variations in those parameters have the potential to put patients in immediate danger.

All other software is categorised as class I.

In MDCG 2021-24 and MDCG 2019-11, the EC goes into more detail on Rule 11 and its classification procedure. Most medical device software will, however, be categorised as at least class IIa under the regulation, as you may have noted after reading regulation 11.

SaMD Categorization according to IMDRF:

The IMDRF has also released guidelines for classifying SaMD. When reading this paper, you’ll note right away that the IMDRF categorization includes four rather than three possible categories and needs a table to help you determine which category your device belongs to.

Due to the two-dimensional nature of this table, it is necessary to identify both the scenario or condition and the importance of the data supplied by the SaMD.

Software Safety Classification according to IEC 62304:

The worldwide standard on software lifecycle procedures, IEC 62304, also classifies software safety.

There are three categories in the IEC 62304 categorization system based on the seriousness of the harm that a software failure could result in:

Class A: No harm
Class B: Non-serious injury
Class C: Severe harm or death

Software Development for SaMD:

If you start bringing up software development in the context of medical devices, you’ll probably get a lot of sharp opinions.

The main cause of this is straightforward. Many laws, including the FDA’s QSR, were drafted with the use of conventional, hardware-based medical devices in mind. As a result, they presumptively follow a relatively linear method of product development, where each task is finished before moving on to the next. This is commonly referred to as the waterfall process, which creates a lot of frustration among software engineers because it is how rules and standards like IEC 62304 are established.

Most developers today work with an agile methodology, a more adaptable strategy built on an ongoing cycle of iteration. Additionally, a lot of young SaMD businesses don’t originate in the traditional medical device industry. Because of the current laws, many of these teams believe it is difficult to use an agile methodology in the development of medical devices.

Cybersecurity and SaMD:

Safety is always of utmost importance when it comes to medical technology. And to create safe SaMD, you must take cybersecurity into account.

The necessity of cybersecurity measures should be obvious by this point, regardless of your background in the software development or medical device industries. In the past ten years, the healthcare sector has experienced several high-profile hacks, and new vulnerabilities are always being found. In fact, one of the sectors with the highest risk of cyberattacks is the healthcare sector.

Because of everything said above, device manufacturers can no longer afford to ignore cybersecurity or attempt to incorporate it into a finished product. In order to ensure the security of the users of your device, you must take the dangers seriously because they are actual.

Postmarket Requirements for SaMD:

It is important to reiterate that software as a medical device is still subject to the same rules as hardware medical devices, despite the subtleties and additional concerns that come with SaMD (such as cybersecurity).

This indicates that your SaMD is still subject to all postmarket obligations from laws like the FDA’s QSR, the EU MDR, or the IVDR. Additionally, your software maintenance process and software problem resolution process will assist you meet some of these postmarket standards if you have been using IEC 62304 for software development.

Check out some of the postmarket-related guides, podcasts, and webinars in our collection of free medical device resources for a more thorough knowledge of these rules.

After that, let’s discuss some of the characteristics of SaMD that call for a distinct strategy during the postmarket phase of a medical device’s lifecycle.

Final Thoughts on Software as a Medical Device:

In the upcoming years, it will be necessary to resolve the remaining unclarified areas in the SaMD laws and guidelines. Around topics like cybersecurity, there is still a lot of work to be done. Additionally, both software developers and medical device manufacturers must undergo a challenging learning curve.

However, there is also a tonne of opportunity and excitement in this field. There is no reason why your organisation can’t provide high-quality SaMD that enhances the quality of life for millions of patients if you have the greatest resources and expert counsel at your disposal.