How is SaMD regulated by the FDA? | Cognidox

Does the fertility tracking app you are developing count as a medical device? What about the imaging software you are developing for use in clinic? When is your software considered to serve a medical purpose in its own right? When is it regarded as an integral part of another device? And when is it not a medical device at all? Here’s a short guide to how SaMD is regulated by the FDA.

Medical devices are not just physical instruments for diagnosis and treatment anymore. They now include stand-alone software and apps that can capture and process data to inform and direct life-altering medical decision-making. For app and software developers who are bringing new and disruptive computing technology to the med tech sector, it’s important you know the classification of your device and what your future regulatory obligations are likely to be.

How does the FDA define software as a medical device (SaMD)

The FDA draws a distinction between software as a medical device (SaMD) and Software In a Medical Device (SiMD). The regulator defines SaMD as:

“Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."

To explain this a bit more, they also offer the following clarification:

• 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.

SaMDs can take data from other devices, but if the software supports a medical device, and that medical device does not work without that software, then it is considered SiMD, not SaMD.

SaMD may not be an integral part of a hardware device or responsible for controlling it. But in the way it processes, analyses and presents data to users and clinicians it is equally important to safe and effective medical diagnosis and treatment.   

Given its ‘stand-alone’ status the FDA regulatory requirements for SaMDs are significantly different from those for  physical devices or where software is part of the device itself.

Why SaMD software requires a different regulatory approach

There are unique risks for those creating or using Software as a Medical Device:

• Software as medical device needs to work on different platforms, so must be updated frequently as hardware and operating systems change.  This increases the risk of failure as updates need to be tested for bugs and validated against requirements.
• Agile software development practices can seem contrary to the highly prescribed processes necessary for a compliant medical device design and development project.  
• Product testing must take into account the unique and varied conditions where software is operated.  Validation requirements can be more complex and onerous.

So, while you will be expected to meet all the normal regulatory requirements of medical device development, there are other SaMD specific regulations and guidelines you will need to follow.

What FDA classification does your SaMD fall into?

The FDA classifies SaMD using the same risk classes they use for medical devices: Class I, Class II, and Class III. As a developer, you will be expected to build a Quality Management System (QMS) in line with FDA 21 CFR 820 and FDA 21 CFR Part 11, and follow the clinical evidence and approval submission guidelines appropriate to your device class.

But there are other guidelines you will need to use and standards you will need to meet, including:

• IEC 62304 the functional safety standard for medical device software 
• FDA Guidance for the Content of Premarket Submissions of SaMD
• Software as a Medical Device (SAMD): Clinical Evaluation guidance

What are ‘Levels of concern’ in SaMD classification?

In their software development guidelines the FDA divide SaMD into three categories, known as “levels of concern”. These are based on the severity of injury that could arise from device failure or design flaws:

• Minor - failures or latent design flaws unlikely to cause any injury to the patient or operator.
• Moderate - failures or latent design flaws could directly result in minor injury of the patient or operator, including through delayed or incorrect information or through the actions of a provider.
• Major - failures or latent design flaws could directly result in death or serious injury to the patient or provider, including through delayed or incorrect information or through the actions of a provide.

The FDA guidelines maps required documentation to the ‘level of concern’ your device falls under:

Source FDA

Post-launch requirements

Beyond design and development there are requirements for post-market surveillance common to all medical devices to ensure that any issues are uncovered and their root causes corrected.  They include:

• Customer feedback,
• Customer claims,
• Vigilance events,
• Trend reports,
• Usability data and usage statistics,
• Clinical data

But for SaMD these need to be supplemented with other data as required by clauses 6.1 and 9 of IEC 62304:

• Software issues -  from the field or found internally,
• SOUP (Software of Unknown Provenance issues) e.g. new SOUP versions, SOUP obsolescence
• Cyber-security issues

Finally, given the amount of potential updates involved in maintaining functional SaMD, developers need to be informed about change control and validation requirements for software upgrades.  

There is specific guidance published by the FDA on this topic.   

Deciding When to Submit a 510(k) for a Software Change to an Existing Device

This detail illustrates just how complex and demanding the SaMD regulatory regime can prove for the under-prepared and unwary.

Conclusion

The FDA have a very specific definition of Software as Medical Device. They also have a clear set of regulations and guidelines defining the process, clinical evidence and documentation you need to have in place for your product to be approved for use in the US market.

Understanding the classification of your software is the first step to developing a plan for its compliant design and development. But your duties and responsibilities don’t stop there. Your Quality Management System will need to support adequate change control for future updates and a range of post-marketing surveillance activities that will protect users from harm throughout your product’s lifecycle.