Ultimate Guide to Software as a Medical Device (SaMD)

Only recently has the medical device industry began designing software-based products that have no direct relationship to hardware devices at all.

Software as a medical device (SaMD), while nothing like traditional medical devices, have just as much potential to improve the quality of life for patients everywhere.

They are, however, still categorized as medical devices by regulatory bodies around the world. In this guide, I want to help demystify these devices and offer you insight into how they’re regulated and what you can expect as you set out to build one. 

Let’s take it from the top.

What is software as a medical device (SaMD)?

Software as a medical device or SaMD is “software intended for one or more medical purposes that perform those purposes without being part of a hardware medical device,” as defined by the International Medical Device Regulators Forum (IMDRF).

FDA defines SaMD as “Software that meets the definition of a device in 181 section 201(h) of the FD&C Act and is intended to be used for one or more medical purposes without being part of a hardware device.”

While these definitions are a great starting point, there’s plenty of nuance around what exactly SaMD is and how you know if your product is SaMD. So, let’s take a closer look at what software as a medical device is, what it isn’t, and how you can figure out if your product fits the definition. 

How do I know if my product is SaMD?

FDA is a member of the IMDRF, and it’s clear that both definitions of SaMD share a similarity in structure. According to both FDA and IMDRF definitions, there are two points that need to be fulfilled for software to achieve the status of SaMD.

To start, we need to consider whether the software can be characterized as a medical device at all. The IMDRF simply states that it must be “intended for one or more medical purposes”, while FDA specifically references the definition of a device in 181 section 201(h) of the FD&C Act, which states that a device is:

An instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

1. 1. recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,

   2. intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or

   3. intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and

which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes. The term "device" does not include software functions excluded pursuant to section 520(o).

To appropriately use this definition, you need to define your product’s intended use and its indications for use. As a refresher:

• Intended use is the purpose of your device. It’s what your device will be used for.

• Indications for use are the diseases or conditions that your device will diagnose, treat, prevent, cure, or mitigate. Indications for use describe who your device will be used on and why.

Once you’ve defined these uses, points two and three in the FDA’s definition of a medical device should make it fairly clear whether your product will be regulated as a medical device. 

If you plan on marketing your software product in the US, I highly encourage you to read carefully through this FDA guidance on Policy for Device Software Functions and Mobile Medical Applications. This guidance offers clear stances on what software functions FDA considers to be a medical device, as well as those it does not consider to be medical devices, or those which it does not regulate as such. 

However, if you’re still not sure if your product is a medical device, your best bet is to contact FDA directly. 

Is my software considered SaMD or SiMD?

Let’s say you’ve determined that your product meets the definition of a medical device. You still need to consider the second half of the SaMD definitions from the IMDRF and FDA.

• The IMDRF definition tells us that the software must perform its purposes “without being part of a hardware medical device.”

• FDA uses almost the exact same language, stating that SaMD “is intended to be used for one or more medical purposes without being part of a hardware device.”

This narrows the scope of SaMD again. Software that is used to power hardware or drive a hardware device does not meet the criteria for SaMD.

Instead, that type of software is what’s known as SiMD, or “software in a medical device.”

Simply put, any software that helps to run a hardware medical device—say, by powering its mechanics or producing a graphical interface—is software in a medical device. Some examples include:

• Software that controls the inflation or deflation of a blood pressure cuff

• Software that controls the delivery of insulin on an insulin pump

• Software used in a closed loop control of a pacemaker

These types of software are also known as “embedded software” of “firmware”, or “micro-code” so if you hear those terms, know that they indicate SiMD, not SaMD. 

For a product to be classified as SaMD, the software must stand alone from any hardware as it performs the functions that categorize it as a medical device. IMDRF guidance on Possible Framework for Risk Categorization and Corresponding Considerations adds several clarifying points to the SaMD definition:

• SaMD is a medical device and includes in-vitro diagnostic (IVD) medical device.

• SaMD is capable of running on general purpose (non-medical purpose) computing platforms.

• “without being part of” means software not necessary for a hardware medical device to achieve its intended medical purpose.

• Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device.

• SaMD may be used in combination (e.g., as a module) with other products including medical devices.

• SaMD may be interfaced with other medical devices, including hardware medical devices and other SaMD software, as well as general purpose software.

• Mobile apps that meet the definition above are considered SaMD. 

NOTE: While it’s important to differentiate between SaMD and SiMD, the two types of software share many of the same standards for development, such asIEC 62304,the international standard for software lifecycle processes. If your software is actually SiMD, you’ll still find many of the guidance documents and standards in this guide useful. 

What are some examples of SaMD?

Theory is one thing, but it’s often easier to grasp real examples. I’ll go over a few examples of SaMD here, but you can find more in the same IMDRF guidance on risk classification mentioned above: 

• Software that allows a mobile device to view images from an MRI, ultrasound, or X-ray that are used for diagnostic purposes

• Software that processes images to help detect breast cancer

• Software that diagnoses a condition using the tri-axial accelerometer on a smartphone

• Software that collects patient data in real-time that is monitored by a medical professional and used to develop treatment plans.

How is SaMD regulated and classified around the world?

While there are many markets for medical devices around the world, the US and the EU are by far the largest, so these are the markets we’ll focus on in this section.

The first point that I want to make is that a SaMD product is still a medical device, and is regulated as such. 

For starters, you will need a quality management system (QMS). In the US, you must follow the Quality System Regulations (QSR) from the FDA. Likewise, in the EU, your SaMD will be governed by the EU MDR (or EU IVDR if it is an in vitro diagnostic device). And finally, your device will still be classified according to the applicable regulations in either market. 

Basically, it pays to remember that while your SaMD may be significantly different from a traditional, hardware medical device, you still need to follow the same regulations as any other medical device.

With that in mind, let’s get into some of the nuances of the SaMD regulatory landscapes in the US and EU.

How is SaMD regulated and classified in the US?

First, we have the US system for classifying SaMD. FDA classifies SaMD using the samerisk classesas it does for traditional medical devices:Class I,Class II, andClass III. 

However, the FDA has also put out a guidance document on the content of premarket submissions for device software functions to help manufacturers better understand the documentation they will need to submit for devices that include software. 

Note on terminology: While SaMD is the widely used term for software as a medical device, in recent guidance documents, the FDA has begun using the term “device software function” or DSF. The agency defines DSF as:

Software function that meets the device definition in section 201(h) of the FD&C Act. The term “function” is a distinct purpose of the product, which could be the intended use or a subset of the intended use of the product.

There are two levels of documentation, enhanced and basic, which are defined by the FDA thusly: 

• Enhanced Documentation: should be provided for any premarket submission that includes device software function(s) where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use. These risks should be assessed prior to implementation of risk control measures. Sponsors should consider the risks in the context of the device’s intended use (e.g., impacts to safety, treatment, and/or diagnosis), and other relevant considerations.

• Basic Documentation: should be provided for any premarket submission that includes device software function(s) where Enhanced Documentation does not apply.

It’s the sponsor’s job to consider all the risks that are part of their device’s risk assessment (including cybersecurity risks) and individually assess their device to determine the appropriate level of documentation. However, there are some devices that the FDA recommends should have enhanced documentation, including: 

• Devices intended to test blood donations for transfusion-transmitted infections

• Devices used to determine blood donor and recipient compatibility

• Automated blood cell separator devices intended for collection of blood and blood components for transfusion or further manufacturing use

• Blood establishment computer software (BECS)

The FDA also recommends enhanced documentation for:

• Devices that are a constituent part of a combination device

• Class III devices

Just remember, documentation levels do not correspond directly with risk class. While Class III devices will almost certainly require enhanced documentation, that does not mean Class II or Class I devices will only require basic documentation. Again, you are required to individually assess each of your devices to determine the appropriate level of documentation. 

How is SaMD regulated and classified in the EU?

SaMD regulation in the EU is similar to regulation in the US, in that it does not differ from the way traditional medical devices are regulated. You will still need to comply with all the relevant requirements in the EU MDR and EU IVDR.

It’s important to note, however, that EU regulations do not use the term “software as a medical device.” Rather, they use the term “medical device software” or MDSW for short.

Fortunately, the European Commission (EC) has put out several guidance documents relevant to SaMD manufacturers. 

• MDCG 2021-24 - Guidance on classification of medical devices

• Infographic - Is your software a medical device?

• 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

I’ll get into some of these later in the guide, but for now, I’d encourage you to read or at least bookmark these resources for easy reference. You’ll find them immensely helpful, especially if you’re wondering whether your software meets the definition of medical device software in the EU. 

Medical device software risk class and “Rule 11” in the EU

As with the US, there is no MDSW-specific risk classification in the EU. Medical device software uses the same risk classification as traditional medical devices: class I, class IIa, class IIb, and class III.

But the EU MDR has an outline for how you should go about determining your medical device software risk class, identified as Rule 11.

Rule 11, which can be found in Annex VIII of EU MDR, states:

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: 

• • death or an irreversible deterioration of a person's state of health, in which case it is in class III; or

  • a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb. 

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. 

All other software is classified as class I.

The EC has elaborated on Rule 11 and its process for classification in MDCG 2021-24 and MDCG 2019-11. However, as you may have noticed reading Rule 11, most medical device software will be classified as at least class IIa under the rule.

If you know your device is MDSW and you want to make sure you’re complying with EU MDR requirements, using this free guidance document and gap assessment tool from Greenlight Guru is a great way to assess your compliance and determine the appropriate regulatory route for your medical device software.

SaMD categorization according to IMDRF

The IMDRF has also put out guidance on categorizing SaMD. What you’ll notice immediately when you read this document is that the IMDRF categorization has four possible categories, rather than three, and requires a table to help you identify what category your device falls under. 

This table is two-dimensional, requiring the identification of both situation or condition and the significance of the information provided by the SaMD.

^{"Software as a Medical Device": Possible Framework for Risk Categorization and Corresponding Considerations, IMDRF}

Currently, the IMDRF categorization is not widely used, probably because it seems to add a second, confusing layer to SaMD classification. However, the IMDRF categorization can be useful in helping to determine your risk class in the EU, and this is what most companies use it for. 

One of the aforementioned EU guidance documents, MDCG 2019-11, includes a table that combines both the IMDRF categorization and EU risk classes.

^{Table 1: classification Guidance on Rule II, MDCG 2019-11}

So, if you intend to sell your device in the EU, the IMDRF categorization can be a useful tool for helping you determine the risk class of your SaMD.

Software safety classification according to IEC 62304

Finally, we have the software safety classification of IEC 62304, the international standard on software lifecycle processes. I’ll get into IEC 62304 in more depth later in this guide, but for now, I want to focus on its classification system. 

The IEC 62304 classification system has three levels based on the severity of injury that a software failure could cause: 

• Class A - no injury

• Class B - non-serious injury

• Class C - serious injury or death

NOTE: Software safety classification is not a determination of how safe your software is. Instead, it is the basis for determining how rigorous your software development process must be. 

The actual safety of your device depends on your design and development processes, not on a safety classification. 

Something you should keep in mind is that your safety classification under IEC 62304 does not directly correspond with risk classification under US or EU regulations. Safety classification does, however, have a strong correlation with risk class.

For example, if your safety classification is class C, then there’s a good chance your device will be class III (for either US or the EU). But you could conceivably have a device that is safety class C, yet falls into a lower risk class. 

The point being, the IEC 62304 classification system is about safety, but it only indicates the level of rigor you should use during software development. It is not a perfect proxy for risk classification and it does not tell you anything about the actual safety of a finished SaMD.

If you’re still with me, then give yourself a pat on the back. This is tricky stuff, but depending on where you’re planning to market your device, you may need to understand how to use every one of these classification methods. 

Perhaps the most important takeaway here is that you should never assume that one classification method, such as level of concern or software safety class, will directly correspond with another. 

Software development for SaMD

Start talking about software development in the medical device world, and you’re likely to hear a lot of pointed opinions. 

The big reason for this is simple. A lot of regulations, like FDA’s QSR, were written with traditional, hardware medical devices in mind. As such, they assume a very linear style of product development, where one task is accomplished before you proceed to the next. This is generally known as the waterfall methodology, and because regulations and standards like IEC 62304 are written this way, it causes a lot of angst among software developers. 

Most developers today use an agile methodology, a more flexible approach based on a continuous loop of iteration. On top of that, many emerging SaMD companies don’t come from the traditional medical device world. As a result, many of these teams think it’s impossible to apply an agile methodology in medical device development based on current regulations.

So let me set the record straight right here and now. Yes, the regulations are written in a linear style that easily tracks with a waterfall approach. However, it is very much still possible to use agile product development and still maintain compliance with all the relevant regulations and standards. 

For instance, when you first look at IEC 62304, you’ll notice that it has a very linear structure. But it is still possible to fulfill its requirements while using agile product development. In fact, there is another standard AAMI TIR 45 that offers guidance on the use of agile practices in the development of medical device software.

With that out of the way, let’s take a closer look at IEC 62304 and how it’s used in SaMD development.

IEC 62304 - software lifecycle requirements

IEC 62304 is a process standard, as opposed to a product standard. It will not tell you specific requirements for your product. Instead, it offers a method for structuring your processes that will result in safe and effective software, if carried out properly. 

After the general requirements, IEC 62304 explains the five processes you’ll need to follow during the lifecycle of your software: 

• Software development process

• Software maintenance process

• Software risk management process

• Software configuration management process

• Software problem resolution process

Keep reading for a brief description of each of these processes.

Software development process

The software development process, according to IEC 62304, begins with software development planning and ends with the software release. Between those points, you’ll need to carry out a number of essential steps, including:

• Software requirements analysis

• Software architectural design 

• Software unit implementation and verification

• Software integration and integration testing

• Software system testing

However, once the software has been released, you’re by no means finished with your responsibilities. Remember, IEC 62304 is a software lifecycle standard, which means you'll need to maintain the software and resolve problems as they arise.

Software maintenance process

IEC 62304 lists the requirements for a software maintenance process. These requirements will look very similar to complaint handling requirements from ISO 13485 and FDA 21 CFR Part 820. 

The software maintenance process outlined in IEC 62304 consists of three parts:

• Establishing your software maintenance plan

• Analysis of problems and modifications

• Implementing modifications

TIP: Study your existing complaint handling process before you create a new process for software maintenance. There may already be a lot of overlap between the two, and you may not need two separate processes. 

With Greenlight Guru’s dedicated Complaint Management Software, feedback and complaints are captured in the same single system as your product’s design, management, and risk with interlinking capabilities so you can see everything impacted by customer feedback.

Software risk management process

If you’re coming to IEC 62304 from a medical device manufacturing background, then the software risk management process it outlines should look pretty familiar to you. That’s because the risk management requirements in IEC 62304 correlate with those in ISO 14971, the international standard on the application of risk management to medical devices. 

And remember, SaMD manufacturers are expected to follow ISO 14971, just like any other medical device manufacturer. If you’re unclear about anything related to risk management, then check out our Definitive Guide to ISO 14971.

You’ll quickly notice the connection between ISO 14971 requirements and those of IEC 62304, such as:

• An analysis of software contributing to hazardous situations

• Risk control measures

• Verification of risk control measures

• Risk management of software changes

Keep in mind, just because risk management gets its own section, that doesn’t mean it isn’t relevant to other processes. In fact, the software development process itself can be used as a risk control measure when it’s carried out according to IEC 62304.

Software configuration management process

Software configuration is like accounting for your software. You’re keeping track of everything you would need to recreate the software, which is foundational for traceability and release management.

The requirements laid out in IEC 62304 include:

• Configuration identification 

• Change control

• Configuration status accounting 

Many companies use a configuration matrix to help them with configuration management. This matrix combines both the software items you want to control and when they were released in one handy table, like the one illustrated below. 

Software problem resolution process

The term “software problem resolution process” is a bit of a misnomer, because it implies that you need one problem resolution process. In reality, you will need several different problem resolution processes because you’ll encounter different types of problems throughout the software lifecycle. 

IEC 62304 does lay out a general outline for a problem resolution process:

• Prepare problem reports

• Investigate the problems 

• Advise relevant parties

• Use change control process

• Maintain records

• Analyze problems for trends

• Verify software problem resolution

• Test documentation contents

As a rule of thumb, you’ll likely encounter fewer problems over time as your product matures. However, the severity of the problems you encounter later on are likely to be more severe—and will require a more rigorous process for resolution.

Software validation for SaMD development

According to the FDA’s Quality System Regulations,

When computers or automated data processing systems are used as part of production or the quality system, the [device] manufacturer shall validate computer software for its intended use according to an established protocol.

For those coming from a software development background, without much insight into the medical device industry, the requirement to validate software that’s used to build other software may be an unexpected speed bump. However, this type of validation is essential to producing safe medical devices, whether they’re hardware or software.

How much validation is required? Well, in FDA’s guidance on the General Principles of Software Validation, it states, “The level of validation effort should be commensurate with the risk posed by the automated operation.”

For instance, if the software application that you’re using for testing doesn’t work correctly and gives you a false pass, or doesn’t test everything it should have, then you’re looking at a serious issue that could affect patient health and safety. 

Additionally, in September 2022, the FDA released a draft guidance document called Computer Software Assurance for Production and Quality System Software. This guidance lays out the concept of computer software assurance (CSA), which is the risk-based approach to testing software. 

As FDA states in its guidance document:

Broadly, this risk-based approach entails systematically identifying reasonably foreseeable software failures, determining whether such a failure poses a high process risk, and systematically selecting and performing assurance activities commensurate with the medical device or process risk, as applicable.

The goal of the CSA guidance is to help medical device companies reduce the overall burden of software validation while allocating resources to ensure that high-risk software is meeting its intended uses.

Just remember that all of your validation must be done in accordance with a documented protocol. And the results of that validation must be documented, as well. 

Ultimately, the decision about whether or not to validate a software tool comes down to you. Keep in mind, however, that whatever your decision, you will be expected to justify it. 

Cybersecurity and SaMD

Safety is always paramount when it comes to medical devices. And creating safe SaMD means considering an extra element: cybersecurity. 

Whether you’re coming from the software development world or the medical device industry, the need for cybersecurity measures should be clear by now. There have been a number of high-profile attacks in the healthcare industry in the past decade, and new vulnerabilities are being discovered all the time. In fact, healthcare is regularly cited as one of the most at-risk industries for cyberattacks.

All of this means that device makers can no longer afford to put cybersecurity on the back burner or try to add it into a finished device. The threats are real, and it’s critical that you take them seriously to protect the safety of your device users. 

Software bill of materials (SBOM) for software as a medical device

On May 12, 2021, the Biden administration issued the Executive Order on Improving the Nation’s Cybersecurity. One important aspect of this executive order was its focus on a software bill of materials (SBOM). Congress then passed the PATCH Act in 2022 (which came into effect on March 29, 2023) codifying the need for an SBOM and requiring manufacturers to address postmarket cybersecurity vulnerabilities.

An SBOM is a nested inventory of all third party software that exists within SaMD or SiMD. A software bill of materials is crucial to the safety and security of your product, because it provides a list of ingredients for your device. 

If a vulnerability is found in some widely used software component, you can quickly check whether that component is in your list of ingredients. If it is, you’ll know which products are affected and can quickly alert providers and work to fix the issue. 

The executive order directed the National Telecommunications and Information Agency (NTIA) to create a list of the minimum elements that are required for an SBOM, which the NTIA has since published. The minimum elements include:

• Data Fields - Document baseline information about each component that should be tracked: Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.

• Automation Support - Support automation, including via automatic generation and machine-readability to allow for scaling across the software ecosystem. Data formats used to generate and consume SBOMs include SPDX, CycloneDX, and SWID tags.

• Practices and Processes - Define the operations of SBOM requests, generation and use including: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes. 

Now, you may be looking at these minimum elements and thinking that this looks like a lot of work to put together. And you’re not wrong—it’s true that compiling an SBOM on your own and monitoring every component for new vulnerabilities is a heavy lift. This is why I’d recommend using an automated SBOM tool that will compile all of this for you and proactively monitor the elements in your SBOM for new vulnerabilities. 

There are a number of tools out there for you to use, including the SBOM Analysis and Vulnerability Management Tool from our partners at MedCrypt. I’d encourage you to explore your options before building your SBOM manually. 

Cybersecurity regulations, guidance, and resources

Cybersecurity is a relatively new and ever-evolving field for regulators and medical device professionals alike. However, regulatory bodies are catching up, publishing guidance documents and resources that every SaMD professional should read and understand.

I’ve compiled a short list of them here and it’s a good place to start if you’re wondering what regulatory bodies will expect from you and your product regarding cybersecurity:

• Playbook for Threat Modeling Medical Devices. Threat modeling is one of the best methods for strengthening the security and safety of your SaMD. That’s why FDA has developed this threat modeling playbook. In it you’ll find resources for developing and adapting your company’s threat modeling practices. 

• Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software. This is the FDA guidance on the use of off-the-shelf (mass marketed) software in medical devices. A vulnerability in this type of software may pose a risk to the operation of medical devices and generally requires ongoing maintenance throughout the product lifecycle. This guidance clarifies how regulations like the QSR apply to cybersecurity maintenance activities. 

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions This document provides FDA’s recommendations to industry regarding cybersecurity device design, labeling, and the documentation that FDA recommends be included in premarket submissions for devices with cybersecurity risk

• Postmarket Management of Cybersecurity in Medical Devices. This FDA guidance document provides the agency’s recommendations for managing postmarket cybersecurity vulnerabilities in medical devices. It offers specific recommendations and encourages a total product lifecycle approach to cybersecurity. 

• MDCG 2019-16 - Guidance on Cybersecurity for Medical Devices. This guidance document is meant to help manufacturers fulfill the requirements of Annex I of both EU MDR and EU IVDR, with regard to cybersecurity. It also includes the expectations from other stakeholders, such as integrators, economic operators, and users. 

• IMDRF Principles and Practices for Medical Device Cybersecurity. This guidance was issued to offer best practices and general principles for medical device cybersecurity. The IMDRF’s stated goal for the guidance is to “facilitate international regulatory convergence on medical device cybersecurity,” and it offers recommendations for both device manufacturers and external stakeholders, such as providers.  

For an even deeper dive, check out the cybersecurity page from FDA, which contains a lengthy list of news and updates, white papers and reports, guidance documents, known vulnerabilities, and other resources on cybersecurity.

If there’s one thing I can impress upon you about cybersecurity, it’s that you need to start thinking about it early on. The expectation is that you’re addressing cybersecurity throughout the design process, rather than treating it as an “extra” that’s tacked on once your product is finished. 

The sooner you start thinking about cybersecurity for your SaMD, the easier it will be to meet regulatory expectations. Most importantly, however, baking cybersecurity into the design of your device will result in a safer, more secure product for the patients and providers using it. 

Postmarket requirements for SaMD

It bears repeating that while there are certainly nuances and added issues to deal with regarding SaMD (like cybersecurity), software as a medical device is still subject to the same regulations as hardware medical devices. 

This means all of the postmarket requirements from regulations like FDA’s QSR, EU MDR or IVDR still very much apply to your SaMD. Additionally, if you’ve been following IEC 62304 for software development, your software maintenance process and software problem resolution process will help you fulfill some of these postmarket requirements.

For a more comprehensive understanding of these regulations, check out some of the postmarket-related guides, podcasts, and webinars from our library of free medical device resources.

With that said, let’s talk about some of the features inherent in SaMD that require a different approach in the postmarket stage of a medical device’s lifecycle. 

When does a SaMD require a new submission?

Making a change to a medical device that is on the market will always require scrutiny. At the very least, you’ll need to document the change you’ve made. But if a change is significant enough, it may require you to resubmit documentation you needed to get the device on the market in the first place. 

When your product is software, deciding whether you need a new submission is even more complicated. So, let’s take a look at how you’ll make that decision.

Making changes to SaMD in the US

Software as a medical device is similar to traditional medical devices in that if you want to makes changes to your device, you have two options:

• Notify FDA of the change via a new 510(k), a special 510(k), or PMA supplement

• Document the change internally via a letter-to-file

The choice you make depends on the significance of the change you’re making and whether it affects the safety, efficacy, or performance of the device. For a hardware medical device, it’s usually easier to know whether your change is significant enough to warrant notifying FDA. But with software, the decision can be a little trickier.

Fortunately, FDA has released a guidance on Deciding When to Submit a 510(k) for a Software Change to an Existing Device to help SaMD manufacturers. As with all the guidance documents listed in this guide, I encourage you to read the entire thing. However, this flowchart will give you an idea of the questions you should ask during the decision-making process.

^{Deciding When to Submit a 510(k) for a Software Change to an Existing Device, FDA}

Making changes to SaMD in the EU

The requirements for a notification of a change in your device in the EU are similar. Annex X of EU MDR states:

The applicant shall inform the notified body which issued the EU type-examination certificate of any planned change to the approved type or of its intended purpose and conditions of use.

Changes to the approved device including limitations of its intended purpose and conditions of use shall require approval from the notified body which issued the EU type-examination certificate where such changes may affect conformity with the general safety and performance requirements or with the conditions prescribed for use of the product. The notified body shall examine the planned changes, notify the manufacturer of its decision and provide him with a supplement to the EU type-examination report. The approval of any change to the approved type shall take the form of a supplement to the EU type-examination certificate

Changes to the intended purpose and conditions of use of the approved device, with the exception of limitations of the intended purpose and conditions of use, shall necessitate a new application for a conformity assessment.

Although the MDR requirements are not exactly the same as the FDA guidelines for making changes to SaMD, you should be able to notice a similar theme running through both: modifications that change the intended use of the device require a new submission to FDA or application to your notified body.

Artificial intelligence and machine learning in SaMD

There’s one more wrinkle in the decision-making process for a new submission: artificial intelligence (AI).

AI is one of the fastest growing technologies being applied to medical devices, and that includes machine learning (ML), a subset of AI that has exploded in use across many industries in recent years. 

Machine learning refers to an algorithm that has the ability to change or improve its outputs as it “learns” from an increasing amount of inputs. The more data an ML algorithm receives, the more accurate its results can become. 

This technology offers incredible potential for diagnostics and many other medical devices, but it does pose a dilemma. When we’re talking about SaMD, the change in the algorithm that allows it to improve is technically a change in the device itself. 

So, how do you know if that change has reached the level of requiring a new submission for your SaMD? 

In 2019, FDA released a Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) to begin addressing this issue. While I highly recommend reading the full document, there are a couple things I want to point out here. 

First, FDA still expects manufacturers to refer to and use the guidance document, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, which we discussed earlier in this section. 

However, FDA has also created guidance for what it calls a Predetermined Change Control Plan (PCCP). Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions is a mouthful, but it includes some important information for companies with devices that use AI/ML. 

The PCCP is a document that a manufacturer includes along with their marketing submission. The PCCP establishes the parameters of any anticipated modifications to your device's algorithm before it's on the market. It describes the modifications that will be made to the device and how they will be assessed. 

Though the PCCP can become complex depending on the device, its essential parts are fairly straightforward. You need to be able to describe the modifications that will occur, how you’ll implement them, and an assessment of their risk and benefits. Here’s what the FDA expects in a PCCP: 

1. Description of Modifications: This section details the planned changes, such as retraining algorithms or incorporating new datasets, and how they support device improvements.

2. Modification Protocol: This includes specific methodologies for:

   • Data management practices.

   • Retraining algorithms.

   • Performance evaluation.

   • Update procedures to ensure consistent safety and effectiveness.

3. Impact Assessment: Manufacturers must evaluate the risks and benefits of proposed changes and outline risk mitigation strategies.

The PCCP is meant to help manufacturers avoid a situation where they are constantly re-submitting to FDA as their algorithm learns. The agency is saying that MedTech companies may instead use a PCCP to lay out the boundaries of any changes to the algorithm in advance. By obtaining FDA authorization for this plan as part of the initial marketing submission, manufacturers can implement approved modifications without needing additional submissions.

The AI Act and high-risk AI systems

The EU's Artificial Intelligence Act (AIA) came into force in August 2024 with goal of fostering responsible AI development and deployment in the EU. The act categorizes AI in medical devices as "high-risk," meaning it must comply with specific requirements within the act. While we won't cover the AIA in full here, it's worth noting that the MDCG has put out a guidance document that covers the interplay between the AIA and EU MDR and EU IVDR. 

Section V of this guidance document covers Substantial Modifications/Significant Change to high-risk AI. The guidance states: 

In accordance with Article 43(4) of the AIA, high-risk MDAIs that have been subject to a conformity assessment procedure shall undergo a new conformity assessment procedure in the event of a substantial modification, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer. 

However, the guidance goes on to say that:

In addition to MDR/IVDR requirements for the implementation of procedures to manage updates and modifications to MDAIs, high-risk MDAIs that continue to learn after being placed on the market or put into service have the possibility of having predetermined changes plan checked at the time of the conformity assessment (Article 43(4) AIA). Changes to high-risk MDAIs that have been pre-determined by the manufacturer and assessed at the moment of the initial conformity assessment and are part of the information contained in the technical documentation referred to in AIA Annex IV point 2(f) shall therefore not constitute a substantial modification.

So, much like the FDA's PCCP guidance, the MDCG guidance is saying that if a change was pre-determined (and assessed during the initial conformity assessment) and is recorded in the device's technical documentation, then it would not constitute a substantial modification that requires a new conformity assessment. 

Finally, in addition to the EU's AIA and FDA's guidance documents, FDA, Health Canada, and the United Kingdom’s Medicines and Healthcare Products Regulatory Agency have come together to issue guiding principles for Good Machine Learning Practice for Medical Device Development. This resource is short and to the point, and it’s essential reading for anyone building a product that includes ML.

This is still a developing field, but these principles should help guide manufacturers interested in using AI/ML technologies with a SaMD.

Final thoughts on software as a medical device

If you’ve made it to this point of the guide (even if you’ve just skimmed the headers), I think you’ll agree that the world of SaMD is both complex and evolving. 

There are still gray areas within regulations and guidances for SaMD that will need to be addressed in the coming years. There is still much work to be done around issues like cybersecurity. And there’s a steep learning curve for software developers entering the medical device world, and vice-versa.

But there’s also immense opportunity and excitement in this space. The last thing I want is for you to finish this guide and be put off by the work that goes into building safe and effective software as a medical device. With the right tools, and the best expert advice on hand, there’s no reason why your company can’t create high-quality SaMD that improves the quality of life for millions of patients. 

At Greenlight Guru, we understand the unique dynamics of software development in the medical device industry. Our QMS acts as a bridge between your development work and regulatory requirements, providing the necessary guardrails to ensure compliance without stifling innovation. Learn what Greenlight Guru can do for you.Get your free demo ➔