What is SAMD?

The FDA defines Software as a Medical Device (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.”

The International Medical Device Regulators Forum (IMDRF) defines SaMD as “software intended for one or more medical purposes that perform those purposes without being part of a hardware medical device”

While these definitions may seem convoluted, if they are considered together, both definitions share a common structure. Both the FDA and IMDRF definitions include two points that need to be met for software to be considered SaMD.

The first consideration that needs to be made is if the software can be characterized as a medical device at all. In regard to this, the IMDRF definition is broader, simply stating that it must be “intended for one or more medical purposes.” Meanwhile, the FDA is more precise in referencing 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. 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 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).

In order to use the FDA definition above, the product’s intended use and indications for use must be defined. Once defined, points two and three in the FDA’s definition of a medical device can be evaluated.

If it is determined that the product meets the definition of a medical device, then the second half of the SaMD definitions from IMDRF and FDA need to be considered. The definition from IMDRF states that the software must perform its purposes “without being part of a hardware medical device.” While the FDA uses similar language stating that a SaMD “is intended to be used for one or more medical purposes without being part of a hardware device.”

As you can see in both definitions, software that is used to power hardware or drive a hardware device does not meet the criteria for SaMD. SaMD must stand alone from any hardware while it performs the functions that make it a medical device. Software that does not stand alone and helps to run a hardware medical device is what is known as Software in a Medical Device (SiMD).

SaMDs are regulated like any medical device even though they may be significantly different from a traditional, hardware medical device and therefore use the same Class I, II, and II risk classes according to the level of regulatory controls that are necessary to reasonably assure safety and effectiveness. The currently finalized FDA Guidance document, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (May 2005)  details what information should be included in a premarket submission [510(k), De Novo, or PMA] for SaMD based on the devices’ level of concern. This 2005 FDA Guidance, however, is being replaced with the new draft guidance,  Content of Premarket Submissions for Device Software Functions (November 2021). This new 2021 guidance differentiates between SiMD and SaMD and what specifically should be included in a SaMD submission. The November 2021 draft guidance considers four (4) risk-based factors to help determine the device’s Documentation Level, which is either Basic or Enhanced. The purpose of the Documentation Level is to help identify the minimum amount of information that is required to support a premarket submission that includes device software functions. The Documentation Level is based on the device’s intended use, among other factors. The FDA states that Basic Documentation should be provided for any premarket submission that includes device software functions where Enhanced Documentation does not apply. Enhanced Documentation should be provided for any premarket submission that includes device software functions, where any of the following factors apply:

1. The device is a constituent part of a combination product.

2. The device (a) is intended to test blood donations for transfusion-transmitted infections; or (b) is used to determine donor and recipient compatibility; or (c) is a Blood Establishment Computer Software.

3. The device is classified as class III.

4. A failure or latent flaw of the device software function(s) could present a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use. These risk(s) should be assessed prior to implementation of risk control measures. You should consider the risk(s) in the context of the device’s intended use; the direct and indirect impacts to safety, treatment, and/or diagnosis; and other relevant considerations.

In addition, IEC 62304 Medical device software – Software life cycle processes can be used as a framework for determining what risk class your SaMD may fall in. The IEC 62304 classification system has three levels based on the severity of injury that a software failure could result in: Class A – no injury, Class B – non-serious injury, and Class C – serious injury or death. Although the classes in IEC 62304 do not directly correspond with the risk classification under FDA regulations it does have a strong correlation with the FDA risk class. For example, if your classification under IEC 62304 is Class A, then there is a good chance your device will be class I and so on for Class B/II, and Class C/III.

The SaMD FDA classification will determine what type of premarket submission is required before you can market your device in the US. Some Class I SaMD products do not require a premarket submission and are 510(k) exempt. The Class II SaMD products typically require a 510(k) premarket submission. A 510(k) is a premarket submission made to the FDA to demonstrate that the device to be marketed is at least as safe and effective, that is, substantially equivalent (SE), to a legally marketed device (predicate) [21 CFR 807.92(a)(3)] that is not subject to premarket approval (PMA). 

For SaMD devices with no predicate device, the De Novo process provides a pathway to classify novel medical devices for which general controls alone, or general and special controls provide reasonable assurance of safety and effectiveness for the intended use. De Novo classification is a risk-based classification process. Through a De Novo Classification Request (De Novo request) devices are classified as either Class I or II and may be marketed and used as predicates for future premarket notification [510(k)] submissions.

For Class III SaMD products, a Premarket approval (PMA) is the FDA process of scientific and regulatory review to evaluate the safety and effectiveness. A PMA is a much lengthier submission requiring not only data to show substantial equivalence, but information on the manufacturers quality management system.

Another guidance document that needs to be taken into account while developing SaMD is, Policy for Device Software Functions and Mobile Medical Applications. In this guidance the FDA describes the regulations for software functions intended for use on mobile platforms or general-purpose computing platforms. This includes both SaMD and SiMD that are either used as an accessory to a regulated medical device or are used to transform a mobile platform into a regulated medical device.

Lastly, FDA has developed a tool (Digital Health Policy Navigator) to help determine whether your product’s software functions will fall under FDA oversight as a device, and if so, the applicable FDA-specific regulatory requirements and recommendations. This Digital Health Policy Navigator uses a seven step questionnaire to navigate the FDA’s existing policies and regulatory status of a given software function. Although the results of the Navigator are not formal FDA device determinations for your product, if you follow the seven steps you will identify the most relevant regulations, guidances, and policies to consider for each of your product’s software functions and highlight certain considerations in specific guidances or policies.

Folio Consulting Group, LLC has experience helping SaMD developers successfully complete their premarket submissions and gain access to the US market. Contact us today to help develop your regulatory strategy and file your 510(k), De Novo, or PMA  for your SaMD.