Healthcare AI Risk: SaaS vs SaMD
Physician-friendly AI concepts by Machine Learning for MDs
Healthcare specific risk
Last week we looked at AI-specific risk, and this week we’ll focus on healthcare-specific risk. Software that qualifies as a medical device involves all the risks of a normal company that includes AI, plus an element of clinical risk.
Today we’ll look at what software ‘qualifies’ as a medical device and therefore is thought to impart clinical risk and how the FDA defines and quantifies that risk.
High-level Summary
Most of the software you encounter clinically is either SaaS or SaMD. Software is considered a medical device if it diagnoses/treats or affects the structure/function of the body. It’s then required to go through the same basic steps as any other medical device. The FDA categorizes clinical risk based on the severity of the condition and how much input the device has, and assigns different requirements for devices based on the clinical risk.
Software as a Service (SaaS) vs SaMD
A crucial distinction for many AI companies is whether they qualify as “Software as a Service” (SaaS) or Software as a Medical Device (SaMD). You use SaaS all the time: Slack, Netflix, Spotify, etc.
A huge amount of the software you use in your clinical practice is actually SaaS, not SaMD. This includes the EHRs and wearables.
SaMD is way less intuitive. SaMD is defined as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Note: The FDA also recently released guidelines about AI as part of SaMD, which can be tricky since the algorithm may change over time, unlike traditional software.
That begs the question: what is a medical device? According to the FDA, “to be considered a medical device and therefore subject to FDA regulation, your software must meet one of two criteria:
It must be intended for use in diagnosing or treating a patient; or
It must be intended to affect the structure or any function of the body”
The implicit belief is that SaMD has more risk than SaaS, and therefore requires additional review and regulation.
To make things more confusing, there are 3 kinds of software that could be associated with medical devices:
“There are three types of software-related medical devices:
SaMD: Software-as-a-Medical-Device is software that on its own is a medical device
SiMD: Software-in-a-Medical-Device is software that is integral to (embedded in) a medical device
Software used in the manufacture or maintenance of a medical device”
This is all murky enough that the FDA developed a specific navigator tool to help companies figure out if their product counts as SaMD, with the following possible outputs:
Why does SaMD vs SaaS matter?
If you finally figure out if something qualifies as SaMD, why do you care? You care because SaMD requires the same process of approval and regulations as a hardware medical device like a cardiac defibrillator. This can add years and an enormous amount of money to the process of getting the product to customers.
Once something is considered a medical device, it then has different safety requirements based on clinical risk. So how does the FDA determine clinical risk?
How the FDA puts clinical risk into buckets
The FDA considers how clinically risky a medical device is based on two categories:
Then the FDA takes those factors and assigns a number that represents a combination of ‘how bad is condition’ and ‘how much input does the product have’ into a simple framework for clinical risk.
The following table is a nice summary of the different ways software can be used in a medical context:
Summary
Now we’ve seen:
General AI risk considerations
How the National Institute for Standards and Technology frames AI risk
How the FDA defines clinical risk