Two New Draft Guidances Helping to Implement The Cures Act

The field of digital health is relatively new and is growing fast. Because many uses of software for health‑related purposes are within the statutory definition of a medical device, the Food and Drug Administration (FDA) is a major player in determining how digital health will be regulated.  Fortunately, FDA some years ago decided it would regulate with a “light touch.”  This approach was ratified and further delineated by Congress in the Cures Act (Section 3060).  We described that provision in detail in a previous post.   We explained why a “light touch” is the right approach for FDA’s regulation of digital health here and in this piece appearing in a recent issue of Digital Legal Health.

Last week, a couple more pieces of the puzzle fell in to place. On December 8, FDA issued two new draft guidances indicating how it will implement the Cures Act as it relates to software.

The first draft guidance is entitled, “Clinical and Patient Decision Support Software” (December 8, 2017).  This guidance was greatly anticipated back in the 2013-14 time frame, but it was post­poned after Congress began considering legislation.  It has finally been issued in draft.  The guidance has a very good summary of the key statutory provision excluding certain categories of software from the definition of a medical device in the Food, Drug, and Cosmetic Act (FD&C Act).  It is worth reproducing in full:

Specifically, section 520(o)(1)(E) of the FD&C Act excludes, from the definition of device, software functions that meet all of the following four criteria: (1) not intended to acquire, process, or analyze a medical image or a signal from an vitro diagnostic device or a pattern or signal from a signal acquisition system (section 520(o)(1)(E) of the FD&C Act); (2) intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines) (section 520(o)(1)(E)(i) of the FD&C Act); (3) intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition (section 520(o)(1)(E)(ii) of the FD&C Act); and (4) intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient (section 520(o)(1)(E)(iii) of the FD&C Act).  [Emphasis in the original.]

The guidance then proceeds to provide information about how FDA’s interprets these four prongs.

Perhaps most interesting is FDA’s commentary on the first prong. It is obvious from the statutory provision that FDA will continue to regulate medical images acquisition/processing/analysis and in vitro diagnostic devices.  It has been somewhat mysterious, however, what technologies would qualify as a “signal acquisition system.”  The statute lacks a definition.  FDA now clarifies that a signal acquisition system “receives, as inputs, signals from sensors that are within, attached to (e.g., EEG, ECG), or external to (e.g., CT, MRI) the human body or sample from the human body (e.g., digital pathology). Id. at 6 n.1.  Technologies that “analyze physiological signs and provide diagnostic, prognostic and predictive functionalities are devices.” Id. at 6.

The other major interpretive issue relates to the fourth prong, which specifies that clinical decision support (CDS) software will be regulated by FDA unless it allows health professionals to “independently” review the basis for clinical recommendations and is not intended to be “primarily” relied upon in a diagnosis or treatment decision. There are a number of ways in which these phrases could potentially be interpreted.  FDA specifies its position this prong is met if the software function explains:

1) The purpose or intended use of the software function;

2) The intended user (e.g., ultrasound technicians, vascular surgeons);

3) The inputs used to generate the recommendation (e.g., patient age and gender); and

4) The rationale or support for the recommendation.  [Id. at 8.]

This approach generally makes sense. It does not require any disclosure of the technical programming and algorithmic complexity underneath the software functionality, but rather, focuses on making transparent  the clinical basis for a recommendation.  It would probably be helpful if item 4) inserted the word “clinical” prior to rationale.”  The clinical rationale appears to be what FDA is describing.

FDA also adds that sources supporting a recommendation or underlying rationale must be identified, made easily accessible, understandable by the intended user, and publicly available. Id at 8.  On this last point, FDA gives the examples of clinical practice guidelines and published literature as “publicly available” sources.   Apparently, a recommendation based upon non‑public information, in FDA’s eyes, does not allow independent evaluation.  It is not clear why that problem cannot be cured by full disclosure of the non‑public information to the intended user.  Or perhaps FDA would agree that it does?  FDA needs to expand this discussion in its final guidance.

The Cures Act did not address the status of patient decision support software. That is unfortunate, because a great deal of useful software is being developed in this realm.  Fortunately, FDA has addressed it in this draft guidance (Section V), and has taken the position that, as a matter of enforcement discretion, it will treat patient decision support software the same as clinical decision support software.  Thus, all of the four prongs in the Cures Act must be met, with due allowances made for the difference between a patient and healthcare professional as the intended user.  The idea is that if these four prongs are met, the software is likely to be low risk.  This approach is very smart and will enable the development of many potentially useful software products for patients.

We have hit the highlights of this draft guidance. It is worth reading all of it, especially because FDA provides many examples to illustrate their position.  Industry often complains about the lack of examples in guidance; that should not be the case for this particular draft guidance.

The other draft guidance issued on December 8 does not require extended discussion. It is entitled, “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act.”  It primarily indicates how FDA will update existing software guidance to square it with the requirements of the Cures Act.  The most important examples of earlier guidance that requires updating include the General Wellness: Policies for Low Risk Devices guidance and the Mobile Medical Applications guidance.

Perhaps the biggest news from this guidance relates to electronic patient health records. In Section 520(o)(1)(C)(ii) of the FD&C Act, Congress specified that such records would not be exempt from device regulation unless, among other things, “certified by the Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program.”  In this draft guidance, FDA proposes that it will not enforce this requirement. Id. at 10.  On the merits, FDA’s decision probably makes sense, but it is inappropriate for FDA to declare that it will, on a blanket basis, decline to enforce a recently enacted statutory requirement.  The statute set forth three specific prongs to define electronic health records that will be exempt from regulation, and FDA has proposed to broaden the exemption by disregarding one of the prongs.

As a constitutional matter, the President must “”take Care that the Laws be faithfully executed.” Const., Art. II, sec. 3.  This requirement applies to agencies within the Executive Branch, including FDA.  Therefore, FDA must enforce all three prongs relating to electronic health records until Congress revises the statute to say otherwise.  It is true that FDA has broad enforcement discretion, Heckler v. Chaney, 470 U.S. 821 (1985), but that authority does not go so far as to allow FDA to significantly modify a duly enacted congressional command.

This case can be distinguished from FDA’s ordinary exercise of enforcement discretion to narrow the scope of a very broad statute, based upon lack of resources, among other things. For instance, FDA’s adaptation of the exclusion of clinical decision support (CDS) software to patient decision support (PDS) software is much more defensible.  The statute is so broad that it could sweep up a great deal of PDS software, or not, depending upon how it is applied.  FDA undoubtedly lacks the resources to regulate all PDS software within the scope of the statute.  As set forth in the draft guidance discussed above, FDA is exercising enforcement discretion by borrowing from the provisions Congress enacted as to CDS software to define the type of PDS software FDA views as low risk, and which it will therefore not regulate.  That is qualitatively different than expanding the exemption Congress created for electronic health records by knocking out one of the three conditions Congress set forth as a prerequisite for the exemption.