Is Clinical Decision-Making (CDS) Software Expanded or More Legally Ambiguous under the CURES Act?

The CURES Act codifies the way FDA has regulated clinical decision-making software, but is this better or worse for healthcare startups that are trying to position their software within the CDS model?

Do you Have a Medical Device

When thinking about potential FDA exposure and wanting to consult an FDA lawyer, remember that one of the first things FDA does is classify (or categorize) your product into one of the major regulatory categories, such as:

• Food
• Dietary supplement
• Cosmetic
• Drug (OTC v. Rx v. homeopathic)
• Medical device
• Biologic
• Radiological health device

When you have software or an app devoted to medical information gathering or health care data, a key question is whether you have a regulatable medical device.

Let’s first go back to the FDA legal definition of “medical device.”

Section 201(h) of the federal Food, Drug, & Cosmetic Act (“FDCA”) includes in the definition of “medical device” “an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is … (2) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals.”

FDA has established classifications for approximately 1,700 different generic types of devices and grouped them into 16 medical specialties referred to as panels. Each of these generic types of devices is assigned to one of three regulatory classes based on the level of control necessary to assure the safety and effectiveness of the device.

Class III devices generally require premarket market approval (PMA), while a Class I or Class II device, is not exempt, requires clearance of a premarket notification (510(k)), which means that a “predicate device” is already being legally marketed and FDA deems that the predicate is “substantially equivalent” to the device in question.

Device classification depends on the intended use of the device and also upon indications for use. In addition, classification is risk based, that is, the risk the device poses to the patient and/or the user is a major factor in the class it is assigned. Class I includes devices with the lowest risk and Class III includes those with the greatest risk.

Manufacturers of medical devices must comply with various regulatory requirements known as “general controls,” and in some cases, also “special controls.”

Do you have a Mobile Medical App?

With the advent of mobile apps, FDA issued a Guidance document entitled, Mobile Medical Applications (“MMA Guidance”), so as to clarify what kinds of mobile apps would be considered to be medical devices.  The MMA Guidance divided apps into three categories: “mobile medical apps,” which FDA would regulate as medical devices; apps that FDA would not regulate as medical devices; and apps for which FDA would exercise enforcement discretion.

FDA stated that in determining whether the app met the definition of a medical device, FDA would look to the intended use of the app (as shown by labeling claims, advertising materials, or oral or written statements by manufacturers or their representatives).

The MMA Guidance now indicates that the 21^st Century Cures Act (“Cures Act”) amends the definition of “medical device” to exclude certain software functions (see further below); and, the MMA Guidance refers readers for updates to the Cures Act and to FDA’s webpage on Digital Health.

So FDA has updated and modernized its very navigable web pages so as to reference digital health, mobile health, connected health, online health, software, mobile medical apps, and all the other terms FDA uses in this healthcare space.

Medical Device Data Systems, Medical Image Storage Device, & Medical Image Communications Device

The Digital Health webpage in turn refers readers to various resources, including FDA’s webpage on Medical Device Data Systems (“MDDS”).  FDA states (emphasis added):

Medical Device Data Systems (MDDS) are hardware or software products that transfer, store, convert formats, and display medical device data. An MDDS does not modify the data or modify the display of the data, and it does not by itself control the functions or parameters of any other medical device. MDDS are not intended to be used for active patient monitoring.

Examples of MDDS include:

• software that stores patient data such as blood pressure readings for review at a later time;
• software that converts digital data generated by a pulse oximeter into a format that can be printed; and
• software that displays a previously stored electrocardiogram for a particular patient.

The quality and continued reliable performance of MDDS are essential for the safety and effectiveness of health care delivery. Inadequate quality and design, unreliable performance, or incorrect functioning of MDDS can have a critical impact on public health.

FDA then references its Guidance document, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices (“MDDS Guidance”).  Notably, the MDDS Guidance repeats:

An MDDS does not modify the data, and it does not control the functions or parameters of any connected medical device. An MDDS does not include devices intended for active patient monitoring.

The MDDS Guidance goes on to note that “devices intended for active patient monitoring include the following characteristics:

• The clinical context requires a timely response (e.g. in-hospital patient monitoring). As noted in the preamble of the MDDS regulation, the word “active” represents “any device that is intended to be relied upon in deciding to take immediate clinical action” (21 CFR 8637 at 8644).

According to the MDDS Guidance, FDA does not intend to enforce compliance with regulatory controls, for MDDS, as well as for two other regulatory categories:

• A medical image storage device, defined under 21 CFR 892.2010, is a device that provides electronic storage and retrieval functions for medical images.
• A medical image communications device, defined under 21 CFR 892.2020, is a device that provides electronic transfer of medical image data between medical devices.

The Cures Act

The 21st Century Cures Act (Cures Act) was signed into law on December 13, 2016.

The significant portion for our purposes is Section 3060 (“Regulation of Medical and Certain Decisions Support Software”), which amends Section 520 of the FDCA (21 U.S.C. 360j) so as to provide five important exclusions from the definition of a regulatable medical device.

As noted, FDA had previously stated that it would use enforcement discretion to not enforce compliance with medical device regulatory controls for MDDS, medical image storage devices, and medical image communications devices.

The Cures Act codifies some of this prior posture of restraint from enforcement.  The five categories of software that Section 3060 excludes from the definition of a medical device, are as follows (emphasis and notes added below).

1. Administrative Support: Software intended for administrative support of a healthcare facility.

Note: FDA traditionally has not viewed such software as meeting medical device definitions; Section 3060 codifies that interpretation.

2. Maintaining or Encouraging Healthy Lifestyle: Software intended for maintaining or encouraging a healthy lifestyle and unrelated to the diagnosis, cure, mitigation, preventing, or treatment of a disease condition.

Note: Such software probably would not fall within the definition of a medical device anyway, and would probably fall within FDA’s enforcement discretion, under FDA’s General Wellness guidance, so long as low-risk.

3. EHR (Electronic Health Record): Software intended to serve as electronic patient records to the extent such records are intended to transfer, store, convert formats, or display the equivalent of a paper medical chart, with certain caveats, including that the 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.
4. MDDS: Software intended 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 other device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and findings.

Note: This is generally consistent with FDA policy excluding MDDS from regulation as a medical device, though note that software will be regulated as a medical device if its function is to interpret or analyze data.

5. CDS (Clinical Decision-making Software): Unless 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, software intended for the purpose of—

(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);

(ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and

(iii) 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.

Note: While this provides a robust exclusion—i.e., removing CDS from medical device regulation—a clinical decision-making software tool that in essence takes the health professional’s place in making a determination for the patient, would raise scrutiny as a possible medical device.

Note that the above statutory language is subject to implementing regulations to be developed by FDA over time, and, still leaves considerable ambiguity which still subjects companies to FDA enforcement discretion. For example: when is the software being used in “supporting or providing recommendations,” or “enabling such health care professional to independently review the basis for such recommendations?”  This is a factual, case-by-case, analysis.

Under the Cures Act, if the product has multiple functions, where one is included above and another excluded, FDA can assess the safety and effectiveness to determine whether the product should be as a medical device.

Also, FDA can still regulate the product as a medical device if it finds that the software “would be reasonably likely to have serious adverse health consequences” or meets the criteria for a Class III medical device.

Lastly, many categories of software outside Section 3060, still remain subject to current FDA enforcement policy and guidance documents.

Consumer Tests that Evaluate Genetic Health Risks (GHR)

FDA regulates direct-to-consumer (DTC) access to Genetic Health Risk (GHR) tests.

We mentioned this, because genetic tests and clinical decision-making tools based on genetic data and genetic information are increasingly coming under FDA scrutiny.

FDA is currently revising its thinking regarding rules governing marketing of such tests.

See, for example, FDA, Statement on Implementation of Agency’s Streamlined Development and Review Pathway for Consumer Tests that Evaluate Genetic Health Risks.

In this document, FDA notes that consumers are increasingly embracing GHR testing and such testing is now available through testing in technology such as with small saliva samples. However:

While these tests can offer significant amounts of personal risk information, they’re not without their own risks – especially if they provide consumers with incorrect or misleading information that may be used to make health choices without considering the advice of a medical professional. Consider the consequences of a person who is told they’re not at risk for coronary heart disease and incorrectly opts to forgo dietary changes or drugs that reduce their risk of heart attack and death

Consequently, FDA states that it is exploring novel regulatory approaches for the regulation of GHR tests.

Specifically, today the agency issued a notice of its intent to allow GHR tests to be exempted from premarket review under certain conditions. If and when finalized, manufacturers of these types of tests would have to come to FDA for a one-time review to ensure that they meet the FDA’s requirements, after which they may enter the market with new GHR tests without further review. The agency also established special controls for these tests in a separate de novo classification order, which outline requirements for assuring the tests’ accuracy, reliability and clinical relevance and describe the type of studies and data required to demonstrate performance of certain types of genetic tests. This approach is similar to the proposed firm-based, pre-certification model that we developed for digital health technologies.

See also FDA Commissioner, FDA allows marketing of first direct-to-consumer tests that provide genetic risk information for certain conditions (describing authorization for marketing of DTC GHR tests by 23andMe).

On 11/7/17, FDA published Medical Devices; Exemptions From Premarket Notification; Class II Devices; Request for Comments.

In this document, FDA requested public comment on FDA’s announcement of its intent to exempt a list of class II devices from premarket notification requirements, subject to certain limitations, based on a determination that these devices no longer require premarket notification to provide reasonable assurance of safety and effectiveness.

FDA generally considers the following factors to determine whether premarket notification is necessary for class II devices: (1) The device does not have a significant history of false or misleading claims or of risks associated with inherent characteristics of the device; (2) characteristics of the device necessary for its safe and effective performance are well established; (3) changes in the device that could affect safety and effectiveness will either (a) be readily detectable by users by visual examination or other means such as routine testing, before causing harm, or (b) not materially increase the risk of injury, incorrect diagnosis, or ineffective treatment; and (4) any changes to the device would not be likely to result in a change in the device’s classification.

Among these, FDA listed the Genetic Health Risk Assessment System (Product Code PTA) as exempt (i.e., no longer requires premarket notification under Section 501(k) of the FDCA); provided, however, that the exemption is limited to devices that have received a first-time FDA marketing authorization (e.g., 510(k) clearance) for the genetic health risk assessment system (a “one-time FDA reviewed genetic health risk assessment system”).

 

Clearly, this FDA is liberalizing its approach to what it allows on the market and also simultaneously making examples of outliers and those companies and products and practices that FDA considers dangerous or inadequately tested or substantiated.

Clinical decision-making software (CDS) has a greater allowance under the CURES Act and this FDA’s interpretation and enforcement of medical device rules.  At the same time, companies continue to innovate by offering patients and physicians access to interpretation of genetic information and other data so as to accelerate health and wellness.  FDA has considerable enforcement discretion and FDA guidance documents, while useful, do not necessarily guarantee that FDA will or will not take enforcement action in a given domain.  As always, legal prevention is the best medicine.  Check with your healthcare and FDA lawyer to assess your enforcement risk when you plan to bring a healthcare app or piece of software to market.

Section 3060 of the Cures Act

“(o) Regulation Of Medical And Certain Decisions Support Software.—

“(1) The term device, as defined in section 201(h), shall not include a software function that is 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;

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

“(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;

“(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 other device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and findings; or

“(E) unless the function is 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, for the purpose of—

“(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);

“(ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and

“(iii) 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.

“(2) In the case of a product with multiple functions that contains—

“(A) at least one software function that meets the criteria under paragraph (1) or that otherwise does not meet the definition of device under section 201(h); and

“(B) at least one function that does not meet the criteria under paragraph (1) and that otherwise meets the definition of a device under section 201(h),

the Secretary shall not regulate the software function of such product described in subparagraph (A) as a device. Notwithstanding the preceding sentence, when assessing the safety and effectiveness of the device function or functions of such product described in subparagraph (B), the Secretary may assess the impact that the software function or functions described in subparagraph (A) have on such device function or functions.

“(3) (A) Notwithstanding paragraph (1), a software function described in subparagraph (C), (D), or (E) of paragraph (1) shall not be excluded from the definition of device under section 201(h) if—

“(i) the Secretary makes a finding that use of such software function would be reasonably likely to have serious adverse health consequences; and

“(ii) the software function has been identified in a final order issued by the Secretary under subparagraph (B).

“(B) Subparagraph (A) shall apply only if the Secretary—

“(i) publishes a notification and proposed order in the Federal Register;

“(ii) includes in such notification the Secretary’s finding, including the rationale and identification of the evidence on which such finding was based, as described in subparagraph (A)(i); and

“(iii) provides for a period of not less than 30 calendar days for public comment before issuing a final order or withdrawing such proposed order.

“(C) In making a finding under subparagraph (A)(i) with respect to a software function, the Secretary shall consider—

“(i) the likelihood and severity of patient harm if the software function were to not perform as intended;

“(ii) the extent to which the software function is intended to support the clinical judgment of a health care professional;

“(iii) whether there is a reasonable opportunity for a health care professional to review the basis of the information or treatment recommendation provided by the software function; and

“(iv) the intended user and user environment, such as whether a health care professional will use a software function of a type described in subparagraph (E) of paragraph (1).

“(4) Nothing in this subsection shall be construed as limiting the authority of the Secretary to—

“(A) exercise enforcement discretion as to any device subject to regulation under this Act;

“(B) regulate software used in the manufacture and transfusion of blood and blood components to assist in the prevention of disease in humans; or

“(C) regulate software as a device under this Act if such software meets the criteria under section 513(a)(1)(C).”.

(b) Reports.—The Secretary of Health and Human Services (referred to in this subsection as the “Secretary”), after consultation with agencies and offices of the Department of Health and Human Services involved in health information technology, shall publish a report, not later than 2 years after the date of enactment of this Act and every 2 years thereafter, that—

(1) includes input from outside experts, such as representatives of patients, consumers, health care providers, startup companies, health plans or other third-party payers, venture capital investors, information technology vendors, health information technology vendors, small businesses, purchasers, employers, and other stakeholders with relevant expertise, as determined by the Secretary;

(2) examines information available to the Secretary on any risks and benefits to health associated with software functions described in section 520(o)(1) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360j) (as amended by subsection (a)); and

(3) summarizes findings regarding the impact of such software functions on patient safety, including best practices to promote safety, education, and competency related to such functions.

(c) Classification Of Accessories.—Section 513(b) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360c(b)) is amended by adding at the end the following:

“(9) The Secretary shall classify an accessory under this section based on the intended use of the accessory, notwithstanding the classification of any other device with which such accessory is intended to be used.”.

(d) Conforming Amendment.—Section 201(h) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 321(h)) is amended by adding at the end the following: “The term ‘device’ does not include software functions excluded pursuant to section 520(o).”.