- Draft guidance documents propose a framework for clinical and patient decision software and explain policy changes driven by 21st Century Cures Act
- Final guidance document adopts International Medical Device Regulators Forum principles for addressing “clinical evaluation” of Software as Medical Device
- Public Workshop (January 2018) will discuss progress of pilot precertification program
The FDA’s December 8 announcement of the availability of three new guidance documents, and of a public workshop to be held in January 2018, demonstrates the agency’s commitment to prioritizing the development of digital health software policy. As we previously reported here, Commissioner Gottlieb made it the subject of his first public statement and shortly afterward led the FDA’s rollout of a framework – the Digital Health Innovation Action Plan – for ensuring that its policies enable innovators to efficiently deliver safe and effective digital health technologies to patients and consumers. The publication of these documents and announcement of the workshop fulfill a few of the ambitious promises contained in the agency’s Action Plan.
Draft Guidance Documents
Two draft guidance documents provide FDA’s interpretation of legislation enacted in December 2016 – the 21st Century Cures Act (the Cures Act) – that reduces FDA’s jurisdiction over several types of “low risk” software. One explains how the FDA plans to regulate software intended to support clinical decisions. The other more generally describes how FDA regulation of certain categories of software will change, including software relating to medical device data systems, medical image storage devices, medical image communications devices, laboratory workflow, and general wellness products. Notably, this announcement comes ahead of schedule, as the clinical decision support guidance was not slated for publication until the first quarter of next year.
Public comments are being accepted in connection with both draft guidance documents until February 6, 2018. Please contact one of the authors if you would like assistance with submitting comments.
Clinical and Patient Decision Support Software
The draft guidance titled “Clinical and Patient Decision Support Software” addresses how FDA intends to regulate various types of software intended to support a decision relating to, for example, a diagnosis or treatment. It distinguishes software intended for healthcare professionals from software intended for patients or caregivers who are not healthcare professionals, and addresses section 3060(a) of the Cures Act, which generally excludes from the statutory definition of “device” a software function that meets all of the following criteria:
- it is not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system;
- it is intended to display, analyze, or print medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);
- it is intended to support or provide recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition; and
- it is intended to enable the healthcare professional to independently review the basis for the software’s recommendations so that he or she does not rely primarily on those recommendations when making a clinical diagnosis or treatment decision.
This exclusion does not apply to any device that (1) constitutes a Class III device under section 513(a)(1)(C) of the Federal Food, Drug and Cosmetic Act (FDCA) (21 USC 360c(a)(1)(C)), or (2) is used in the manufacture and transfusion of blood and blood components to assist in the prevention of disease in humans.
For purposes of the guidance, FDA adopts the term “Clinical Decision Support (CDS),” defined as a software function that meets the first three of these criteria. FDA notes that not all CDS will be excluded from FDA regulation, because CDS not meeting the fourth criterion (i.e., CDS that does not provide the healthcare professional with the ability to independently review the basis for the software’s recommendations) will be subject to regulation as a device. To avoid regulation, the CDS function must enable a healthcare professional to primarily rely on their own judgment (rather than the software’s recommendations) when making a clinical decision for a patient, and this can be achieved only if the software provides visibility to the basis of any recommendations.
In addition to elaborating upon each of the above four criteria, the guidance includes examples of CDS that may or may not be regulated. Examples of CDS that FDA will not regulate include:
- software that provides healthcare professionals with recommendations on the use of a prescription drug that are consistent with the FDA-required labeling;
- software that suggests an intervention or test, consistent with clinical guidelines and/or drug labeling, based on or in response to a physician’s order; and
- software that, following input of patient parameters and laboratory test results such as fasting plasma glucose and oral glucose tolerance test results, suggests whether a patient’s condition meets the definition of diabetes according to established guidelines.
Examples of CDS that FDA will regulate include:
- software that uses a patient’s image sets (e.g., MRI) to create an individual treatment plan for patients undergoing radiation therapy treatment with external beam or brachytherapy, where the healthcare professional is intended to rely primarily on the treatment recommendations of the software to determine the plan;
- software that analyzes multiple physiological signals (e.g., sweat, heart rate, eye movement) to monitor whether a person is having a heart attack or narcolepsy episode; and
- software that analyzes near-infrared camera signals of a patient intended for use in determining and/or diagnosing brain hematoma.
For software intended for patients and caregivers who are not healthcare professionals, FDA will exercise enforcement discretion and apply a standard similar to that applied to CDS. The agency refers to such software products as “Patient Decision Support (PDS)” and uses essentially the same criteria, except that it is now the patient or caregiver who is not a healthcare professional who must be able to independently review the basis for the software’s recommendations, so that he or she does not rely primarily on the software.
Examples of PDS that would not be regulated include:
- software that assists a patient in choosing an appropriate over-the-counter cold or allergy medication based on symptoms; and
- software that provides information to a patient about the use of a prescription drug that is consistent with the FDA-required labeling, such as reminding the patient how or when to take a prescribed drug.
Other Changes Resulting from the 21st Century Cures Act
The draft guidance titled “Changes to Existing Medical Software Policies Resulting from Section 3060 of 21st Century Cures Act” addresses other types of software excluded from the definition of “device” by the Cures Act, including the following:
- software function intended for administrative support of a healthcare facility;
- software function intended for maintaining or encouraging a healthy lifestyle;
- software function intended to serve as electronic patient records; and
- software function intended for transferring, storing, or converting formats, or displaying data and results.
Many (or perhaps all) of the changes described in the document are technical formalities that do not reflect a substantive change in FDA policy but merely require FDA to amend the way in which that policy is implemented. For example, FDA noted that some examples provided in the Mobile Medical Applications guidance would be moved to the appendix identifying apps that were not devices (Appendix A) from the appendix describing apps that were devices but that would not be subject to regulation due to the exercise of enforcement discretion (Appendix B).
The following current guidance documents are impacted:
- Guidance for Off-the-Shelf Software Use in Medical Devices – Section 3.2.2 (“Exemption of Laboratory Information Management Systems”) is deleted, because LIMS no longer meet the definition of device;
- General Wellness Guidance – certain examples are deleted;
- Mobile Medical Application Guidance – certain examples will be revised or deleted;
- Medical Device Data System Guidance – revised to clarify that products intended solely to transfer medical device data, store data, convert the format of data, or display data and results do not meet the definition of device; and
- Guidance for the Submission of Premarket Notifications for Medical Image Management Devices – the guidance will be withdrawn, because some software functions described in that guidance no longer meet the definition of device, and the guidance for submitting 510(k)s for the narrow category of such products that continue to be devices (e.g., those that generate alarms for which immediate clinical action is needed) is outdated.
Final Guidance: Software as Medical Device: Clinical Evaluation
The guidance titled “Software as Medical Device (SaMD): Clinical Evaluation” was drafted by the International Medical Device Regulators Forum (IMDRF) and established common principles for regulators to use in evaluating the safety, effectiveness, and performance of Software as a Medical Device (SaMD). The IMDRF is a voluntary group of medical device regulators from around the world (including FDA) who are attempting to accelerate international medical device regulatory harmonization and convergence.
The guidance demonstrates a converged approach for planning the process for clinical evaluation of a SaMD to establish that there is a valid clinical association between the output of a SaMD and the targeted clinical condition (to include pathological process or state) and that the SaMD provides the expected technical and clinical data.
Public Workshop: Fostering Digital Health Innovation: Developing the Software Precertification Program (January 30 – 31, 2018)
This public workshop will be held at the National Institutes of Health (NIH) campus in Rockville, Maryland and will provide an opportunity for anyone to provide input on the development of the precertification program (discussed here). The agency is accepting applications to make oral presentations and will accept written comments until June 29, 2018. Topics to be covered include:
- Criteria and measures to assess whether a company consistently and reliably engages in high-quality design and testing;
- Levels of precertification and how they correlate to the digital health product’s risk;
- Types of digital health products that should be marketed based on the levels of precertification without FDA premarket review or after a streamlined, less-burdensome FDA premarket review; and
- Considerations of streamlined premarket review and postmarket data collection and analysis.
* * * * * * * * * *
Please contact the authors if you have any questions regarding the guidance documents, workshop, or other aspects of digital health regulation.