Keeping Up to Date on SaMD Regulations

Software as a medical device continues to evolve with advances in machine learning. So do the federal regulations governing these digital tools.

By John Halamka, M.D., president, Mayo Clinic Platform, and Paul Cerrato, senior research analyst and communications specialist, Mayo Clinic Platform

The term software as a medical device (SaMD) may sound cryptic to anyone not familiar with health care IT. To explain the term, the U.S. Food & Drug Administration (FDA) quotes the International Medical Device Regulatory Forum’s definition: "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." This kind of standalone software is having a major impact on the delivery of medical care worldwide, and when coupled with machine learning, has the potential to transform patient care in ways that were unimaginable a few years ago. Whether you’re a clinician or technologist/developer, understanding the basics may help you make informed decisions, regardless of your role.

The first step in evaluating standalone software is to determine whether regulators will even consider it a medical device; if it does not fall into that category, there’s probably no need for FDA review. The agency uses three criteria to label software or hardware as a medical device:

  • Used in the diagnosis of disease
  • Used to cure, mitigate, or treat disease
  • It affects bodily function or structure

As an example, if an app only collects a patient’s weight and sends it, unchanged, to a clinician, it is probably not SaMD and can be marketed without FDA clearance or approval as such. That doesn’t mean there are no limits on its development. It still must adhere to sound manufacturing criteria. On the other hand, if the software collects body weight, blood glucose readings, and food intake and offers clinicians advice on how to interpret the data, it would likely be classified as SaMD and subject to a set of rules on its development and use.

FDA has three broad categories in which it can place SaMD:

  • Premarket clearance, 510K
  • DeNovo classification
  • Premarket approval

Which category the software falls in depends on the level of risk it poses to patients.

  • Class I devices are low risk, only require FDA general controls, and don’t usually need premarket review. Latex gloves used during a medical exam fall into this category.
  • Class II devices pose a moderate risk and need FDA general and special controls. To be given a 510k FDA clearance, developers must show that the device is substantially equivalent to devices that already have been cleared by the FDA, for example, an infusion pump.
  • Class III pose the highest risk to patients and are often life sustaining; they require premarket approval rather than clearance. A pacemaker would fall into that group.

DeNovo classification, on the other hand, applies to devices for which general and special controls provide a “reasonable assurance” of the device's safety and effectiveness, even though there are no legally marketed devices of the same type.

While FDA has been satisfied with these three classifications in the past, it realizes that they don’t apply very well to the new wave of AI and machine learning based algorithms now being developed. With these shortcomings in mind, the agency published a new set of guidelines, Artificial Intelligence/Machine Learning (AI/ML)-based Software as a Medical Device (SaMD) Action Plan, the purpose of which is to accommodate the many iterations expected from these new digital tools as they respond to new data and adapt algorithms accordingly. The agency explains: “The FDA envisions a ‘predetermined change control plan’ in premarket submissions. This plan would include the types of anticipated modifications—referred to as the ‘Software as a Medical Device Pre-Specifications’—and the associated methodology being used to implement those changes in a controlled manner that manages risks to patients —referred to as the ‘Algorithm Change Protocol.’

In this potential approach, the FDA would expect a commitment from manufacturers on transparency and real-world performance monitoring for artificial intelligence and machine learning-based software as a medical device, as well as periodic updates to the FDA on what changes were implemented as part of the approved pre-specifications and the algorithm change protocol.”

The medical software industry continues to push the envelope, hoping to develop innovative solutions to challenging clinical problems. Fortunately, federal regulators are doing their best to keep up.

Recent Posts