On December 8, 2017 – nearly a year after President Obama signed into law the 21st Century Cures Act (“Cures Act”) – the Food and Drug Administration (“FDA”) released two new draft guidances that aim to implement section 3060 of the Cures Act, and provide clarity on the Agency’s regulatory approach to software as a medical device. As explained in a statement by FDA Commissioner Scott Gottlieb, the new draft guidances “offer additional clarity about where the FDA sees its role in digital health, and importantly, where we don’t see a need for FDA involvement.”
Section 3060(a) amended section 520 the Federal Food, Drug, and Cosmetic Act (“FDCA”) to remove certain software functions from the definition of device in section 201(h) of the FDCA. The first draft guidance – Clinical and Patient Decision Support Software – focuses on the provision of the Cures Act that exempts certain clinical decision support (“CDS”) software from the definition of a medical device. The second guidance – Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act – outlines FDA’s interpretation of other types of software that are no longer considered medical devices.
Clinical and Patient Decision Support Software
In the first draft guidance, FDA aims to clarify the scope of its regulatory oversight for: (i) CDS software intended for use by health care professionals (“HCPs”); and (ii) patient decision support (“PDS”) software intended for use by patients and their caregivers (i.e., non-HCPs). As a reminder, the Cures Act excludes certain CDS software functions from the definition of device, if the software functionalities are:
- Not intended to acquire, process, or analyze medical images or signals from an in vitro diagnostic device or from a signal acquisition system (which is defined in the guidance to mean “a signal acquisition system is the electronic circuitry and processor that receives signals from sensors that are within, attached to, or external to the human body”);
- Intended for displaying, analyzing, or printing medical information about a patient;
- Intended for supporting or providing recommendations to an HCP about disease treatment, diagnosis, or prevention; and
- Intended for enabling the HCP to independently review the basis of the recommendations, such that the HCP is not relying primarily on such recommendations to make a clinical diagnosis or treatment decision.
FDA broadly defines CDS software to include any software function that meets the first three criteria. Importantly however, a software function that meets the definition of CDS software is not automatically excluded from FDA regulatory oversight. In order to be excluded, the CDS software must also meet the fourth criterion – enable the HCP to independently review the software’s recommendation. To enable such independent review, the software functions must clearly explain: (i) the purpose or intended use of the software function; (ii) the intended user; (iii) the inputs used to generate the recommendation (e.g., patient age and gender); and (iv) the rationale for the recommendation. In addition to these requirements, the sources supporting the software’s recommendations must be easily accessible to the intended user. FDA believes that if sources for recommendation are not publically accessible, the HCP would be unable to independently evaluate the recommendation. FDA provided in the draft guidance a list of examples of CDS software that are not devices, and those that remain devices.
With respect to PDS software, FDA adopts a regulatory framework that parallels that of CDS software described above. In particular, FDA intends to exercise enforcement discretion for PDS software that both meets the first three statutory criteria, and is also intended to enable non-HCPs to independently review the basis of the software’s recommendation without primarily relying on that recommendation to make patient decisions. As with CDS software, FDA includes in the draft guidance examples of PDS software for which it intends to exercise enforcement discretion, as well an example of PDS software that would be subject to the Agency’s regulatory oversight.
The clarification in scope of regulatory oversight offered in the draft guidance is particularly encouraging to software manufacturers and digital health companies whose products meet the four statutory criteria – and so would not have to jump through the hoops of regulatory clearance or approval, or other post-approval requirements. However, while the examples provided by FDA in this draft guidance are quite illustrative, they do not capture every variety of CDS or PDS software. Thus, stakeholders are advised to consult closely with FDA on the regulatory status of their products before distributing them commercially.
Once this guidance is finalized, FDA will make corresponding updates to the Mobile Medical Applications guidance.
Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act
The second draft guidance addresses FDA’s oversight of the following types of software:
- Administrative Support Software: Medical software intended for “administrative support of a health care facility”
- General Wellness/Lifestyle Software: Medical software intended for “maintaining or encouraging a healthy lifestyle” that is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition
- Electronic Patient Records: Medical software intended to serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats, or display the equivalent of a paper medical chart
- Medical Device Data Systems (“MDDS”): Medical software intended for transferring, storing, converting formats, or displaying clinical laboratory tests, or other device data and results
The draft guidance provides the greatest insight into FDA’s thinking on software intended to serve as electronic patient records. The Cures Act defined three criteria for such software to be considered exempt from the definition of a medical device: (i) the records must have been created, stored, transferred, or reviewed by HCPs; (ii) the records must be part of information technology certified by the Office of the National Coordinator for Health Information Technology (“ONC”) Health IT Certification Program; and (iii) the software functions must not be intended for interpretation or analysis of patient records, for the purpose of the diagnosis, cure, mitigation, prevention or treatment of a disease or condition. In a departure from the statutory framework, the Agency states in the guidance that it “does not intend to enforce the FDA requirements for software functions that are not certified by the ONC, if they meet the other [two] criteria.”
Once this guidance is finalized, the Agency will make corresponding updates to other of its guidance documents, including General Wellness: Policy for Low Risk Devices, and Mobile Medical Applications, among others.
Finally, FDA notes in the draft guidance that it will address products with multifunctionality (i.e., products with at least one device function and at least one software function) in a separate guidance document.
Software as a Medical Device (SaMD): Clinical Evaluation
Along with the two draft guidances discussed in this post, FDA adopted a final guidance in fulfillment of its involvement in the International Medical Device Regulators Forum (IMDRF), and that group’s mission to reach harmonization on medical device regulation across the globe. The final guidance – Software as a Medical Device (SaMD): Clinical Evaluation – was produced by the IMDRF and establishes common principles for regulators to use in evaluating the safety, effectiveness and performance of software as a medical device. In an introduction to the guidance, FDA states that it “intends to consider the principles of this guidance in the development of regulatory approaches for SaMD and digital health technologies.”
Comments to the draft guidances should be submitted by February 6, 2018, at http://www.regulations.gov/.