DMS Insights from Cognidox

How is SaMD regulated by the FDA? | Cognidox

Written by Joe Byrne | 27 Jan, 2023

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.   

Software as Medical Device (SaMD)

Software in a Medical Device

Software that evaluates MRI images and helps physicians make diagnosis recommendations.

Software that controls the operation of an MRI machine

A mobile app that monitors a patient’s heart rate or glucose levels and makes treatment recommendations to the patient and/or patient’s doctor.

Software that allows a patient to control their insulin pump based on glucose readings

Software that allows a patient to control their insulin pump based on glucose readings

Software that controls the operation of a breast scanner

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:

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:

Software documentation

Minor Concern

Moderate concern

Major Concern

Level of concern

A statement indicating the level of concern and a description of the rationale for that level.

Software description

A summary overview of the features and software operating environment.

Device Hazard Analysis

Tabular description of identified hardware and software hazards, including severity assessment and mitigations.

Software requirements specification (SRS)

Summary of functional requirements from SRS

The complete SRS document.

Architecture Design Chart

No documentation is necessary in the submission.

Detailed depiction of functional units and software modules. May include state diagrams as well as flow charts.

Software Design Specificiation  (SDS)

No documentation is necessary  in the submission.

Software design specification document.

Traceability analysis

Traceability among requirements, specifications, identified hazards and mitigations, and Verification and Validation testing.

Software Development Environment Description

No documentation is necessary in the submission

Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities.

Summary of software life cycle development plan. Annotated list of control documents generated during development process.  Include the configuration management and maintenance plan documents.

Verification and validation documentation

Software functional test plan, pass/fail criteria, and results.

Description of V&V activities at the unit, integration, and system level.  System level test protocol, including pass/fail criteria, and tests results.

Description of V&V activities at the unit, integration, and system level.  Unit, integration and system level test protocols, including pass/fail criteria, test report, summary and tests results.

Revision Level History

Revision history log, including release version number and date.

Unresolved Anomolies (bugs or defects)

No documentation is necessary in the submission.

List of remaining software anomalies annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors.

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.