News 01.03.18

Life Sciences Client Alert: The FDA and the Digital Age: FDA Releases Guidances on the Proposed Limits of its Regulation of Digital Health Technologies

Clinical and Patient Decision Support Software

The goal of the FDA with this draft guidance is to clarify the scope of its oversight on two types of software: clinical decision support (CDS) and patient decision support (PDS).

As background, Section 3060 of the Cures Act excludes certain CDS software functions from the definition of “device” if the software:

  • 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;
  • Is intended to display, analyze, or print medical information about a patient or other medical information, like clinical practice guidelines;
  • Is intended to support or provide recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
  • Is intended to enable health care professionals to independently review the basis for the software’s recommendations so professionals do not primarily rely on the recommendations when making a clinical diagnosis or treatment decision.

In the draft guidance, the FDA proposes to define CDS software as software functions that meet the first, second and third criteria of Section 3060, above. In order to avoid consideration as a “device,” a CDS function would also have to meet the fourth criterion, which requires “independent review” by the health care professional.  In defining what is required in finding such “independent review,” the FDA states that the software 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.

Notwithstanding the above, the FDA intends to continue to regulate the following as “devices” as defined by the Cures Act:

  • Software that is Class III, meaning software that is intended for a use in supporting or sustaining human life or for a use which is of substantial importance in preventing impairment of human health, or that presents a potential unreasonable risk of illness or injury;
  • Software intended to generate treatment and diagnostic recommendations on which the health care professional will rely primarily in making clinical decisions or determining therapy plans; and
  • Software designed to acquire, process or analyze a medical image, a signal from an in vitro diagnostic device that can detect diseases, or a pattern or signal from a signal acquisition system (a machine that receives, as inputs, signals from sensors on the body).

The FDA provides examples of the types of software functions that the FDA intends to regulate, which perhaps unsurprisingly includes software that is used to plan for surgery or for diagnosing major physiological events. The examples given include software that suggests surgical plans for orthopedic implant procedures, and software that is used to determine whether a person is having a heart attack or brain hematoma or narcolepsy episode.

Regarding low-risk PDS software, the FDA will not enforce compliance with applicable regulatory requirements if the PDS meets the same four criteria that CDS must meet, as outlined above, except that the fourth criterion would require transparency of the basis for the software recommendations to laypersons rather than health care professionals.

Changes to Existing Medical Software Policies

The second draft guidance addresses the FDA’s decision to exclude the following types of software from its oversight:

  • 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; and
  • Medical Device Data Systems: Medical software intended for transferring, storing, converting formats, or displaying clinical laboratory tests, or other device data and results.

The FDA stated however that certain software that fall into the above categories will not be excluded from the definition of “device” if the FDA makes a finding that the software meets certain substantive and procedural criteria or if the device is Class III.

Software as a Medical Device: Clinical Evaluation

Lastly, the FDA has released another draft guidance regarding its involvement in the International Medical Device Regulators Forum and that group’s mission to harmonize medical device regulation across the world.  This guidance establishes principles for regulators to use in evaluating the safety, effectiveness and performance of software as a medical device. In the introduction of the guidance, the FDA states that it “intends to consider the principles of this guidance in the development of regulatory approaches for Software as a Medical Device and digital health technologies.” How heavily the FDA actually “considers” these principles is yet to be seen and will be a topic to follow closely.

We will continue to monitor these issues and will advise of any developments, including if/when the Guidances are finalized.