In connection with its efforts to support technological innovation and advancement of digital health, the U.S. Food and Drug Administration (FDA) has announced two new resources: 1) the creation of a new centralized Digital Health Unit within its Center for Devices and Radiological Health (CDRH) and 2) the issuance of draft guidance on Software as a Medical Device (SaMD): Clinical Evaluation released last fall.
SaMD is an area of digital health where FDA guidance has been rapidly evolving.
Why is the FDA Focusing on Digital Health?
The FDA defines digital health to include categories such as mobile health (mHealth), health information technology (HIT), wearable devices, telehealth and telemedicine, and personalized medicine. According to the FDA’s digital health website, many medical devices now have the ability to connect to and communicate with other devices or systems. Devices that are already FDA approved or cleared are being updated to add digital features. New types of devices that already have these capabilities are being explored. Many stakeholders are involved in digital health activities, including patients, health care practitioners, researchers, traditional medical device industry firms, and firms new to FDA regulatory requirements, such as mobile application developers.
The FDA’s new Digital Health Unit seeks to better protect and promote public health and provide continued regulatory clarity by:
1. Fostering collaborations and enhancing outreach to digital health customers, and
2. Developing and implementing regulatory strategies and policies for digital health technologies.
What is Software As a Medical Device (SaMD)?
SaMD is “software that is intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device.” Per the draft guidance, SaMD includes some mobile apps and in-vitro diagnostic medical devices such as glucometers used by diabetic patients. For example, an app that is available on a smart phone that allows the user of the smart phone to view images for diagnostic purposes obtained from a computerized tomography (CT) scan is a SaMD. In contrast, SaMD is not software that solely organizes data or automates a health care protocol, such as software used to create an electronic medical record or input billing codes. Nor is it software used in a closed loop medical intervention, such as software in an implantable pacemaker.
How are SaMDs Unique and Different from other Health Technologies?
SaMDs are unique because of the interconnected, rapidly changing technical environment in which they are regulated and compete. Some SaMDs have multiple uses per application making it possibly more difficult to label them accurately and test them for clinical validity. Also, SaMDs may not have direct contact with a patient even though its data output influences clinical decision making and indirectly affects clinical outcomes.
How are SaMDs Classified?
FDA’s draft SaMD guidance generated over a thousand comments from interested parties, developers, and healthcare providers. FDA is likely spending time to meaningfully review those comments in an effort to create a final guidance document. Until then, the draft guidance gives developers important insight when clinically validating the safety, effectiveness, and performance of SaMDs. To get ahead of the curve, developers might consider internally validating their SaMDs in accordance with the draft guidance.
FDA guidance classifies SaMDs into four categories: Category I, II, III, IV (See Table 1). Each category reflects the seriousness of the condition(s) targeted and how much the SaMD influences the process or decision-maker. The categories are important because the guidance suggests that different, increasing levels of clinical evidence are necessary for each category, and independent review is thought of as more important for some categories than others.
Table 1 – adapted from SaMD guidance
How Can Digital Health Developers Demonstrate Safety, Effectiveness, and Performance of SaMD?
The SaMD guidance provides four areas where a developer should demonstrate a SaMD’s safety, effectiveness, and performance: Clinical Validity, Analytical Validity, Scientific Validity, and Clinical Performance (See Figure 1).
Figure 1
• Clinical Validity is categorized into two types, non-diagnostic and diagnostic. Non-diagnostic SaMD developers have to show scientific validity that demonstrates the usefulness of the output in patient care. In contrast, diagnostic SaMDs have a higher demonstration burden and need to show clinical performance along with scientific validity.
• Scientific Validity can be demonstrated using either a well-known association or a novel association. A well-known association links the SaMD to an already validated standard such as the correlation between cholesterol levels and heart disease. A novel association is an association with a novel input to detect a condition, such as eye color to retinal damage.
• Clinical Performance may be completed throughout a SaMD’s lifecycle. Because most technology has an iterative component, the changes may be made in real time based on the data output.
• Analytical Validity evaluates the SaMD’s ability to generate the intended output from the input. To determine this, developers should ask whether the SaMD was properly designed and constructed and whether the right software was built, so that it adapts to consumer needs.
Depending on the category of SaMD, different areas will need to be addressed with Category I, requiring the least amount of evidence, and Category IV, requiring the most. As CDRH continues to develop guidance around SaMDs, developers and providers should keep abreast of current changes to maintain compliance and market competitiveness.
Other FDA Guidance for Digital Health Developers
FDA is not the only federal agency with guidance for SaMD and mHealth app developers. For example, if you are developing a digital health app that collects, creates, or shares consumer information, a very useful tool is the Mobile Health Apps Interactive Tool, a joint resource developed by the FDA, the Federal Trade Commission (FTC), and the HHS Office for Civil Rights (OCR).
The views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of Becker's Hospital Review/Becker's Healthcare. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author and any liability with regards to infringement of intellectual property rights remains with them.