GxP Lifeline
Software as a Medical Device: What Does It Mean and Why Should I Care?
A little over a year ago, the U.S. Federal Drug Administration (FDA) released its draft guidance (1) regarding a newer, skyrocketing segment of the medical device industry—that of Software as a Medical Device (SaMD). The guidance means to address the emergence of thousands of stand-alone, health-oriented software apps that fall into a gray area in terms of regulation. Obviously, SaMDs aren’t traditional medical devices, but neither are they Pokémon Go. The guidance, originally drafted by the International Medical Device Regulators Forum (IMDRF)—of which the FDA is a member, recognizes intent for the guidelines to be applicable to SaMD developers worldwide.
However, there are inherently “unique” aspects of SaMD referred to in the draft that differentiate them with typical medical devices that may signal a willingness toward more fluid future FDA guidelines, FDA Commissioner Scott Gottlieb said in July (2).“FDA’s traditional approach to medical devices is not well-suited to these [digital health] products. We need to make sure our approach to innovative products with continual updates and upgrades is efficient and fosters, not impedes, innovation,” Gottlieb said. “Recognizing this, and understanding that the potential of digital health is nothing short of revolutionary, we must work toward establishing an appropriate approach that’s closely tailored to this new category of products. We need a regulatory framework that accommodates the distinctive nature of digital health technology, its clinical promise, the unique user interface, and the industry’s compressed commercial cycle of new product introductions.
How does the FDA define SaMD?
Since the concept of SaMD is in its infancy, relatively speaking, and is likely to grow exponentially in coming years, the FDA guidance at this point is essentially advice based on best-practices as to help developers prepare to demonstrate the apps’ safety, effectiveness, and performance. The guidance defines SaMD as “software intended to be used for one or more medical purposes without being part of a hardware medical device.” More specifically, SaMD is a medical device that:
- Includes mobile apps and in-vitro diagnostic (IVD) medical devices.
- Can run on general purpose (non-medical purpose) computing platforms, such as a smartphone, tablet, or PC.
- May be used in combination or interfaced with other products, including medical devices, other SaMDs, and general-purpose software.
However, the definition exempts software whose intended purpose is to drive a hardware medical device, such as a CT scanner. SaMD software solutions serve a variety of purposes, generally related to diagnosis, disease prevention, modernizing care, or treatment of an illness or injury. Specific examples include an algorithm to detect atrial fibrillation; EEG analysis; coronary physiological simulation software; and viewing MRI images for diagnostic purposes.
How specifically are SaMDs unique?
As spelled out in the FDA document, SaMDs, in most instances, do not directly affect or have contact with a patient. [SaMD] operates in a complex highly connected-interactive socio-technical environment in which frequent changes and modifications can be implemented more quickly and efficiently,” the guidance states. “Development of SaMD is also heavily influenced by new entrants unfamiliar with medical device regulations and terminology developing a broad spectrum of applications.” So not only are regulators and developers working with a technology format that is dynamic, fluid and capable of real-time connectivity, they’re also seeing newcomers to the field that aren’t necessarily your traditional medical device companies. For that reason, the new guidelines appear to have some built-in flexibility based on a software’s targeted function and risk categorization. Jeffery Shapiro writes in the FDA Law Blog (3) that this elasticity is purposeful. From the agency’s “Digital Health Innovation Action Plan,” he said that regulators are trying to “get out of the way” of SaMD development wherever possible as not to stifle the sector’s innovation. Thus, the FDA:
• Focused oversight on mobile medical apps to only those that present higher risk to patients while choosing not to enforce compliance for lower risk mobile apps • Chose not to focus oversight on products that only promote general wellness That being said, many of the compliance guidelines applicable to medical devices still hold true for SaMDs. This means that developers will still need a robust electronic quality management system for document control, verification, validation, and other functions to ensure that the development aligns with regulation guidelines and best practices.
What does the FDA guidance about SaMD mean?
As SaMD is a relatively new technology bursting onto the scene with unknown potential, the FDA’s guidance on SaMD is essentially advice based on best-practice estimations. Thus, the guidance acts as navigation aid to developers through uncharted waters so that they can more efficiently get their products to market while simultaneously ensuring their safety, effectiveness, and performance. The document also provides recommendations on methods of clinical evaluation and the level of clinical evidence necessary to support the use of a given SaMD based on its risk categorization. The FDA maintains that the process of clinical evaluation conducted during the product’s lifecycle is an integral part of the quality management system. It’s then incumbent upon developers that code SaMD software to assess and analyze that clinical data to document and verify its safety, effectiveness, and performance.
The FDA has grouped SaMD by risk category (I-IV) based on two main factors: the significance of the information provided by the SaMD (inform clinical collection, drive clinical management, or treat or diagnose) (4) and the state of the healthcare situation or condition (non-serious, serious, or critical). Based on this framework, the guidance outlines levels of evidence necessary for clinical evaluation by category and device type. These types of evidence include: • Analytical validity (ability of the SaMD to reliably generate intended output from input data) • Scientific validity (establishes how accurately the output of the SaMD correlates with its intended use) • Clinical performance (ability of the SaMD to yield a clinically meaningful output associated with its targeted output) Clinical performance can be determined during the development of the SaMD both before and after marketing the product. For each type of evidence, the draft guidance explains general methods for generating that evidence. An independent review of the evidence is critical here because a SaMD’s designated category corresponds with its assessed risk level to users and patients.
Why should I care?
Ultimately, the draft guidance on SaMD seeks to ensure that appropriate principles for clinical evaluation are applied to software as a medical device similarly as it would be for other medical devices through a risk-based approach. But it also acknowledges the unique qualities of the mushrooming use and demand for these products also inform methods for “continuous” clinical evaluation and potential evolution. Major takeaways for SaMD developers and companies: • Unlike other medical devices, SaMD can leverage technology and connectivity to devices and people that can continuously monitor its safety, effectiveness, and performance • Due to the unique nature of SaMD, the FDA has focused oversight only on apps that present a higher risk, i.e., diagnosis of skin melanoma • Developers and quality professionals will still need to make risk-based criteria and clinical evaluation a priority despite the unique nature of stand-alone healthcare apps • Aggregation of specific data for compliance, the demand for efficiency, and the need for best practices underscore the importance of a reliable and robust electronic quality management system • Independent review remains a staple of SaMD though its traditional premarket review will likely evolve
References:
- Software as a Medical Device (SAMD):Clinical Evaluation; Guidance for Industry and Food and Drug Administration Staff https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm524904.pdf. Accessed Dec. 5, 2017.
- FDA Announces New Steps to Empower Consumers and Advance Digital Healthcare https://blogs.fda.gov/fdavoice/index.php/2017/07/fda-announces-new-steps-to-empower-consumers-and-advance-digital-healthcare/. Accessed Dec. 5, 2017.
- When It Comes to Software as a Medical Device (SAMD), FDA Acknowledges that New Terminology No Longer Fits the Old Regulatory Paradigm http://www.fdalawblog.net/2017/08/when-it-comes-to-software-as-a-medical-device-samd-fda-acknowledges-that-new-technology-no-longer-fi/ Accessed Dec. 5, 2017.
- Software as a Medical Device: FDA Releases Draft Guidance https://www.lexology.com/library/detail.aspx?g=d2c016d6-2291-4d5b-85f3-dee7ed98dd4f
- Accessed Dec. 5, 2017.
Mike Rigert is a content marketing specialist at MasterControl’s headquarters in Salt Lake City, Utah. A native of the Chicago area, he has nearly a decade and a half of experience creating journalism and marketing content for the news media, public safety and higher education. He has a bachelor’s degree in political science from Brigham Young University.
