What is SaMD? A Brief Look at Software as a Medical Device

When most people think of software, their minds automatically go to computers and smartphones. For regulatory professionals, we think of Software as a Medical Device (SaMD). Earlier this year, I wrote an article about SaMD for MedTech Outlook, since this area has gotten quite a bit of attention at the FDA with the formation of the FDA’s Digital Health Center of Excellence and the release of the “Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) Action Plan”.

The FDA’s focus on SaMD make understanding it within the regulatory field even more important. Let’s define what SaMD is NOT in order to understand what it IS and explore how to navigate SaMD within the ever-changing regulatory landscape.

Before diving into the nitty-gritty, here are three key pieces of information:

• FDA regulates software functions, and some of these functions are considered Software as a Medical Device (SaMD)
• For a number of software functions that are medical devices, FDA does not intend to enforce requirements
• Many standalone software functions are not medical devices (e.g., some general wellness products)

Software Functions and SaMD

First, let’s look at Section 3060 of the Cures Act, which includes a function-specific definition. The functions excluded from the device definition under section 520(o) of the FD&C Act are independent of the platform on which they might run.

According to this FDA document, the functions that are excluded are:

• for administrative support of a healthcare facility…;
• for maintaining or encouraging a healthy lifestyle…;
• to serve as electronic patient records…; and
• for transferring, storing, converting formats, or displaying … data and results, findings by a health care professional…and general background information… unless such function is intended to interpret or analyze…data, results, and findings…

Many Standalone Software Functions are Not Medical Devices or FDA Does Not Intend to Enforce Requirements

FDA has provided a number of examples of the types of software functions that fall into these categories in a general wellness guidance document.

While general wellness claims are not specific to software products, four illustrative examples of general wellness software functions are included in FDA’s guidance document.

The guidance further clarifies, in a non-software example, that how products are regulated by FDA is based on intended use (and the same is true for software products):

Here is Illustrative Example 6 taken from this document to further clarify:

• “A product is intended to mechanically exfoliate the face, hands and feet to make the skin smoother and softer.
• The product cannot be used in a manner that penetrates or pierces the skin.
• This claim relates to self-esteem and does not refer to a specific disease or medical condition, and thus is a general wellness claim
• …this product meets both factors for a low risk general wellness product.

Note: However, if the product is intended to… enhance the delivery of a topically applied product containing  active pharmaceutical ingredient(s)… the product would not be a low risk general wellness product.”

It’s also useful to consider the description from the International Medical Device Regulators Forum (IMDRF), provided in the Final Document: Software as a Medical Device (SaMD), and incorporated into a FDA guidance document:

“A SaMD can best be described as software that utilizes an algorithm (logic, set of rules, or model) that operates on data input (digitized content) to produce an output that is intended for medical purposes as defined by the SaMD manufacturer. The risks and benefits posed by SaMD outputs are largely related to the risk of inaccurate or incorrect output of the SaMD, which may impact the clinical management of a patient.”

“This IMDRF document establishes a framework, discusses how to evaluate and validate SaMD, and lays out a “Pathway for Continuous Learning Leveraging Real World Performance Data.”

FDA and Software Function

In line with the framework outlined in this IMDRF document, FDA announced a pilot for the Digital Health Software Pre-Certification Program in 2017 and selected 9 pilot program participants. This pilot has been focused on and limited to SaMD.

FDA has stated their vision for the program to “help inform the development of a future regulatory model that will provide more streamlined and efficient regulatory oversight of software-based medical devices developed by manufacturers who have demonstrated a robust culture of quality and organizational excellence, and who are committed to monitoring real-world performance of their products once they reach the U.S. market.”

FDA’s Guidance Document on Policy for Device Software Functions and Mobile Medical Applications provides a nice high-level overview of software regulatory history and highlights the functions that are the focus of FDA regulatory oversight, and also provides helpful examples. The three key areas to be aware of are:

• Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data.

• Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors or by including functionalities similar to those of currently regulated medical devices.

• Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations. These types of functions are similar to or perform the same function as those types of software devices that have been previously cleared or approved.

Plus, the FDA’s Guidance Document on Clinical Decision Support Software describes the regulatory history of SaMD, and consistent with the IMDRF Framework, FDA intends to apply a risk-based policy for Clinical Decision Support (CDS) software functions.

With that said, “FDA encourages developers of CDS software functions that are not medical devices or are medical devices for which at this time FDA [is exercising enforcement discretion] to implement a quality system consistent with IMDRF’s Software as a Medical Device (SaMD): Application of Quality Management System and to apply good cyber hygiene, such as through software design and cyber vigilance, consistent with applicable FDA guidance.”

4 points to remember:

1. FDA regulates software functions.
2. Some of these functions are considered Software as a Medical Device (SaMD).
3. For a number of software functions, FDA does not intend to enforce requirements.
4. Many standalone software functions are not medical devices.

What category best fits your device? If you need more help, please contact us to discuss as navigating the regulations can be overwhelming.