Software as a Medical Device (SaMD) is terminology under the aegis of a work group of the International Medical Device Regulators Forum (IMDRF) of which the FDA is a member. SaMD is distinct from software in a medical device although “in” these days may have a looser meaning closer to is a part of. 

The notion that “stand alone” software, operating on a general purpose computer could be or is a medical device was at one time debated by some but this has been resolved by various regulatory bodies who declared that the discussion was now over and that software is a medical device if it meets the definition of a medical device. The IMDRF and some national bodies have clarified this by adding the term “software” to the defining list of things that could be medical devices.  The FDA definition (instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article) does not have an explicit inclusion of software, but the FDA has declared that all the other words used in the definition includes software.

The SaMD work group has produced three final documents on definitions, risk assessment and quality management. In addition, a draft entitled “Software as a Medical Device (SaMD): Clinical Evaluation” has now been circulated by the FDA as a Draft Guidance Document. In fact the FDA just added one page to the front of the IMDRF that says it is draft guidance.

Before turning to Clinical Evaluation itself, some definitions are in order including what is SaMD. It is software that, except in limited cases, does not directly affect or have contact with a patient, nor does it control the operation of a medical device. Instead it only performs computation on data derived elsewhere and provides output to a user to inform or guide clinical management, or for use in the diagnosis or treatment of the patient. The computational aspect of SaMD separates it from Medical Device Data Systems (MDDS). Some may remember that the MDDS category was created by the FDA and then classified as low-risk (Class I). Subsequently the FDA announced that they would not enforce compliance with the applicable regulatory controls. Note that this is distinct from saying MDDS are not medical devices.

SaMD will often operate in a connected environment which makes them relevant here. To the degree that they receive data from medical devices this is likely to be connected via the network. The results of the SaMD analysis will then likely be communicated over the network. Although SaMD by itself cannot (by definition) do anything directly to a patient, or control a device that could do something to a patient, the nature of the SaMD output can affect patients, positively or negatively, through the intermediary health care providers who receive their output.  Clinical Decision Support (CDS) systems operate in this domain, although this terminology is absent from the draft.

Clinical evaluation as used in the draft is the gathering and assessment of scientific validity, analytical validity and clinical (real-world, obtained from patients) performance of a SaMD. Scientific validity is evidence gained from other than a clinical trial that establishes how well the output of an SaMD accurately correlates to the intended clinical health care situation or condition of the intended use of the SaMD. This is the underlying basis for data processing and the communicated results. The analytical validity of a SaMD is its ability to accurately and reliably generate the intended output from the input data, i.e., whether the programming is correct. Performance is different in that it includes the ability to produce clinically meaningful  output for the target use of SaMD in the health care situations or conditions identified in the SaMD definition statement (disease type, target user, and intended population). Or as I see it, performance includes that the output is correct and also that it matters. It is noted in the draft that these considerations are part of life cycle management rather than only occurring pre-launch.

It is recognized in the draft that not all SaMDs should require the same level of proof. This parallels device classification in which low-risk devices get light scrutiny and high-risks devices get more intensive scrutiny. Like CDS considerations, this means that SaMDs whose results are actually important have a higher obligation to prove that they actually work whereas SaMDs whose purpose is of low importance need not pursue that same level of proof. Not addressed in the draft is the idea that importance might include the health care provider’s ability to reach the same conclusions on their own with a functionally reasonable effort.

SaMD is of course not the only FDA foray into software. Back in August we discussed an FDA Draft Guidance on when software changes needs a new 510(k) and before that we have covered a variety of software issues. Software also was among the material covered in the 996-page 21st Century Cures Act recently passed by the House and expected to pass the Senate. The Act seeks to exempt certain software from FDA scrutiny (unless the Secretary declares otherwise) by altering the definition of a medical device. A number of the things being exempted are those that already weren’t medical devices or which the FDA has already chosen not to regulate. I have addressed the software component of Cures elsewhere.