LIFE SCIENCES CLIENT ALERT: The FDA and the Digital Age: FDA Releases Guidances on the Proposed Limits of its Regulation of Digital Health Technologies
In an effort to encourage innovation and bring efficiency and modernization to regulation, the U.S. Food and Drug Administration (FDA) has issued draft guidance documents that define the types of software functions that the FDA will not regulate. These documents come in response to the 21st Century Cures Act (Cures Act) which was legislation that removed certain low-risk health software from the jurisdiction of the FDA. These guidance documents represent clarity from the FDA regarding the applicability of FDA regulations to digital health technologies. To be clear, the FDA’s policy structure in this subject area is a work in progress.
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.
- Proposed Hours of Service Rules: Balancing Safety and Economy
- Ninth Circuit Holds BIPA Class-Action Plaintiffs Have Article III Standing
- PROFESSIONAL LIABILITY CLIENT ALERT: Attorney Liability Under the FDCPA
- Five Words & Phrases Defense Attorneys Should be Mindful of in Trucking Litigation
- CYBER RISK CLIENT ALERT: BIPA Cutbacks Stalled in Springfield - For Now.
- PROFESSIONAL LIABILITY CLIENT ALERT: The Development of Michigan's Attorney Judgment Rule
- Another BIPA Violation Alleged in Illinois
- LIFE SCIENCES CLIENT ALERT: United States Supreme Court holds that the judge, not the jury, makes pre-emption determination in failure-to-warn pharmaceutical cases.
- Michigan No-Fault Reform Update
- Missouri Joinder/Venue Reform Bill Heading to Governor for His Signature
- Professional Liability
- Class Action
- Insurance & Reinsurance Litigation & Counseling
- Complex Commercial Litigation
- Insurance Coverage
- Cyber Risk & Liability
- Toxic Tort
- Professional Development
- Employment Litigation & Counseling
- Workers' Compensation
- Construction Litigation & Counseling
- Product Liability
- Discrimination, Harassment & Hostile Workplace Claims
- Medical Negligence & Healthcare Liability
- Pharmaceutical & Medical Device Litigation
- Social Media & Privacy