FDA Continues Implementation of 21st Century Cures Health IT Software Provisions

The U.S. Food and Drug Administration (FDA), on September 27, 2019, released final and draft guidance implementing provisions of the 2016 21^st Century Cures Act (Cures) that clarify the regulatory status of health IT software. These provisions, complementing a recent Cures-related proposed rule from the Office of the National Coordinator for Health IT (ONC), culminated years of efforts to resolve the regulatory status of electronic health records (EHRs) and other health IT software. Section 3060(a) of Cures amended Section 520 of the Federal Food, Drug, and Cosmetic Act (FD&C Act), removing some software functions from the definition of a device subject to FDA regulation.

The FDA’s first guidance, released in final form (subject to continued comment), updates a December 2017 draft guidance and provides the agency’s “current thinking” on the Cures device definition and its impact on existing FDA guidance on medical device software. The second guidance, a draft that updates a December 2017 draft (and FDA work that predates Cures), focuses on clinical decision support (CDS) provisions of Section 3060(a) of Cures. It defines which CDS will be subject to FDA regulation as a device and how FDA will approach such regulation. This new guidance is part of the FDA’s broader Digital Health strategy.

In general, software that is not a device would not be subject to FDA regulation. In some cases however, safety aspects of non-device health IT software would be regulated by ONC via the ONC certification process, for example for use of quality management programs and usability testing/safety-enhanced design. ONC also maintains a Health IT Feedback process to handle software complaints.

These new guidance documents have important implications for eHI members, including provider organizations, that develop health IT software. At a minimum, they will affect compliance plans, quality management, product development, and marketing

Guidance: Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act

The changes described in this final FDA guidance are also reflected in conforming revisions to:

• General Wellness: Policy for Low Risk Devices
• Mobile Medical Applications
• Off-The-Shelf Software Use in Medical Devices
• Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices; and withdrawal of
• Guidance for the Submission of Premarket Notifications for Medical Image Management Devices

Section 520 of the FD&C Act states that “device” will not include a software function intended:

(A) for administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow;

Note: FDA has generally not considered such functions to be a device and makes clarifying changes regarding aspects of Laboratory Information Systems.

(B) for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;

Note: FDA clarifies that the exclusion from the device definition applies only to software and not hardware and also does not apply where the function is related to “diagnosis, cure, mitigation, prevention, or treatment of a disease or condition,” with updated examples and pointers to updates in the General Wellness and Mobile Medical Application guidance.

(C) 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, so long as—

(i) such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals;

(ii) such records are part of health information technology that is certified under section 3001(c)(5) of the Public Health Service Act; and

(iii) such function is not intended to interpret or analyze patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;

Note: The definition of an “electronic patient record” is narrow, treating the EHR as an electronic version of a paper record.  It is unclear how far it extends to the full range of modern EHRs and likely does not apply to many CDS functions used in EHRs, which are addressed in the separate FDA guidance on 520(o)(1)(E). FDA also indicates that it will not enforce the Cures requirement that only certified functions are eligible for this exclusion. Important for EHRs and similar health IT, FDA also indicates that it will issue future guidance on software that combines device and non-device functions. FDA also provides examples that address apps and other tools that enable patients to interact with EHRs, consistent with the Administration focus on consumer-focused apps connected to EHRs via APIs.

(D) for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or mother device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and finding . . .

Note: Medical Device Data Systems (MDDS), the subject of one of the FDA’s first forays into health IT software regulation in 2011, are now not FDA-regulated devices (software only) and FDA is revising existing MDDS and Mobile App guidance accordingly, including revised examples. FDA also states that, if a multiple function product contains MDDS hardware functions, FDA does not, at this time, intend to enforce FD&C Act requirements.

Draft Guidance: Clinical Decision Support Software

The second FDA guidance released on September 27 covers CDS. It updates the December 2017 draft Cures-related guidance based on comments, notably by (consistent with stakeholder recommendations)  implementing a risk model from the International Medical Device Regulators Forum (IMDRF). Comments are due December 26, 2019.

As amended by Cures, 520(o)(1)(E) of the FD&C Act states that certain CDS software functions are excluded from the definition of device, if they meet all the following four criteria:

1. 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;
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);
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; 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.

FDA uses the statutory CDS definition for this guidance and, based on its interpretation of Cures, identifies Non-Device CDS and Device CDS. Following Cures, the FDA’s primary determinants of whether CDS is a device are its use by a health care professional, the advisory nature of the CDS, and the ability of the professional to do independent review of input data, the basis for rules and algorithms, etc. Developers seeking to confirm or maintain non-device status will want to focus on the latter two criteria, especially for application of artificial intelligence and machine learning.

For Device CDS, FDA proposes a regulatory approach using the IMDRF risk model for Software as a Medical Device (SaMD). It asks if the condition being addressed is Critical, Serious, or Non-Serious (defined in the guidance) and whether the SaMD information Treats or Diagnoses, Drives Clinical Management, or Informs Clinical Management. (CDS that informs and also allows “independent review” is not a device.)

FDA proposes that, if the software goes beyond informing clinical management (i.e., driving clinical management or treating/diagnosing), it is not CDS per Cures and not subject to this guidance and its proposed regulatory flexibility. The FDA uses the IMDRF definition for driving clinical management: “the information . . . will be used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition will be used to guide next diagnostics or next treatment interventions:

• To aid in treatment by providing enhanced support to safe and effective use of medicinal products or a medical device.
• To aid in diagnosis by analyzing relevant information to help predict risk of a disease or condition or as an aid to making a definitive diagnosis.
• To triage or identify early signs of a disease or condition.”

For Device CDS that informs, FDA focuses on the seriousness of the condition, proposing enforcement discretion for CDS for Non-Serious Conditions and oversight (i.e., regulatory focus) on health care professional-oriented CDS aimed at Serious or Critical conditions. Where the intended user is a patient or caregiver, FDA will apply oversight (regulation) to all scenarios except non-serious conditions where the user can independently verify the basis for the recommendation (subject to enforcement discretion).

FDA provides examples for each category of CDS (but not for CDS that is not defined as such in this guidance, for example, because it meets the “drive” criterion”).

Commentary on the CDS Guidance

• The FDA’s definitions of Inform and of Drive (especially with Drive including “guide) are not very different and do not seem to reflect the intent behind the concept “drive” or its plain meaning. It would be very easy for much CDS on the market today to meet the definition of “drive”. It is unclear whether the FDA will rely on the IMDRF “inform” definition in determining whether CDS is a device or only once that determination has been made.
• Many CDS software functions could apply across the full range of condition seriousness, notably those in an EHR or not disease specific, so the actual extent of enforcement discretion may be limited.
• Where it applies enforcement discretion, FDA could choose at a later time to require some device requirements, such as a quality system, while not requiring premarket clearance or approval. Notably, the FDA “encourages developers of CDS software functions that are not medical devices or are medical devices for which at this time FDA does not intend to enforce compliance . . . to implement a quality system consistent with IMDRF’s Software as a Medical Device (SaMD): Application of Quality Management System and to apply good cyber hygiene, such as through software design and cyber vigilance, consistent with applicable FDA guidance”.
• This guidance does not describe how the FDA will regulate CDS for which is applies oversight.

Implications for eHealth Initiative Members and Action Steps

Understanding these guidance documents is important for eHI members that develop health IT software. They finalize (for now) provisions of Cures that limit the extent of FDA regulation of EHRs and other health IT (other than CDS, which remains at a draft stage). They also highlight the limits of Cures-related regulatory relief, whether for EHRs, CDS beyond narrow confines, and certain patient/consumer-facing apps. They will affect how developers approach designing for and communicating the intended use of their products and, especially for CDS, how they enable healthcare professionals to independently review the basis for CDS recommendations.

Health IT software developers should review these new guidance documents, submit timely comments to FDA on the CDS draft guidance and on the finalized guidance documents if issues remain, and monitor how FDA will regulate health IT that it considers a device.

Mark Segal, PhD, FHIMSS, Principal, Digital Health Policy Advisors, LLC. Member and Past Chair of the eHI Policy Steering Committee. October 21, 2019. Twitter @msegal111

eHI thinks Mark Segal is a super cool guy and is providing his opinions for informational purposes only. The opinions presented, do not represent those of eHealth Initiative, our members or the Foundation.