In November 2021, the FDA drafted a “guidance document” regarding recommendations for documentation submitted by sponsors in connection with Premarket submissions for the FDA’s evaluation of the safety and effectiveness of device software functions, as set forth in the Food Drug & Cosmetic Act Section 201(h), which defines a “devices” as “instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is …intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man … or intended to affect the structure or any function of the body of man…” and “does not include software functions excluded pursuant to section 520(o) of the FD&C Act.” Recognizing the ever-evolving applications of software in the healthcare setting, the FDA’s guidance has provided a long-needed update for sponsor submission recommendations when applying for a premarket submission. In particular, the FDA guidance provides sponsor guidance as to specific device software functions, including software in a medical device (SiMD) and software as a medical device (SaMD).
But when is software considered a “medical device? As defined by the International Medical Device Regulators Forum (IMDRF) as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” The IMDRF consists of medical device regulators from around the world who have attempted to harmonize the labyrinth that is medical device regulation. The IMDRF’s working group (WG) promulgated key definitions in December 2013 for software as a medical device. The IMDRF WG prepared final guidance for the clinical evaluation of software as a medical device in June 2017. Critically, this guidance included 3 important clinical evaluations that developers and manufacturers should ask: 1. Is there a valid clinical association between your SaMD output and your SaMD’s targeted clinical condition?; 2. Does your SaMD correctly process input data to generate accurate, reliable, and precise output data? & 3. Does use of your SaMD’s accurate, reliable, and precise output data achieve your intended purpose in your target population in the context of clinical care?
With the advent of applications, smartphones and traditional software programs, both SiMD and SaMD issues will continue to arise for both software developers and device manufacturers alike. For instance, in today’s market, many consumers rely on real-time health metrics from their smartwatch and/or smartphone. These metrics are typically biometric in nature (heart-beat, Vo2 Max and blood oxidization readings, among others) which would fall under the traditional definition of a “medical device”, SiMD or SaMD.
The FDA’s guidance provides a refreshing approach to modernize premarket application process for both programmers and manufacturers alike.
