Considerations for Mobile Health Technology Developers: Part 2

In Part 1 of this series, general wellness devices and mobile medical applications (MMAs) were considered.  Part 2 of this series is devoted to clinical decision support (CDS) software.

On 27th September 2022, the Food and Drug Administration (FDA) issued its final guidance for industry and FDA staff clinical decision support (CDS) software, which has been anticipated since the Center for Devices and Radiological Health (CDRH) listed the guidance as a top priority for fiscal year 2022.

The final guidance follows the draft CDS software guidance issued on the same date in  2019.  Since then, developers have sought clarity regarding the regulatory status of CDS, which is described as a variety of tools including, but not limited to: computerized alerts and reminders for providers and patients; clinical guidelines; condition-specific order sets; focused patient data reports and summaries; documentation templates; diagnostic support; and contextually relevant reference information.

Criteria for regulation

The FDA regulates software that meets the definition of a medical device in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act).  In the final guidance, the FDA clarifies that certain types of CDS software functions are excluded from the definition of a medical device when such products meet all four of the criteria articulated in section 520(o)(1)(E) of the FD&C Act.  Such non-device CDS are:

(1) not intended to acquire, process, or analyse a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system (Criterion 1);

(2) intended for the purpose of displaying, analysing, or printing medical information about a patient or other medical information (e.g. peer-reviewed clinical studies and clinical practice guidelines) (Criterion 2);

(3) intended for the purpose of supporting or providing recommendations to an HPC about prevention, diagnosis, or treatment of a disease or condition (Criterion 3); and

(4) intended for the purpose of enabling such HCPs to independently review the basis for such recommendations that such software presents, so that it is not the intent that such HCPs rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient (Criterion 4).

Criterion 1

The FDA noted that if the type of data described in Criterion 1 (i.e. a medical image or a signal from an IVD or a pattern/signal from a signal acquisition system) is used as an input, then the software function remains a regulated medical device.

The FDA considers a “medical image” to include images generated by medical imaging systems (e.g. computed tomography, x-ray, ultrasound, magnetic resonance imaging) to view any part(s) of the body or images acquired for a medical purpose.  Images that were not originally acquired for a medical purpose, but are processed or analysed for a medical purpose, are also considered “medical images”.

The FDA considers “signal” to refer to signals that typically require use of either an IVD (e.g. photometric response generated by an assay and instrument that is further processed by software to generate a clinical test result) or a signal acquisition system that measures a parameter from within, attached to, or external to the body for a medical purpose (e.g. ECG leads).

The FDA interprets “pattern” to refer to multiple, sequential, or repeated measurements of a signal or from a signal acquisition system.

Note, however, that activity monitors or other signal acquisition systems that measure physiological parameters that are not specifically intended or marketed for a purpose identified in the device definition are not medical devices.

Criterion 2

Software functions intended to display, analyse, or print medical information about a patient or other medical information (e.g. peer-reviewed clinical studies or clinical practice guidelines) meet Criterion 2 and are not medical devices subject to FDA regulation and oversight.

The FDA considers “medical information about a patient” to be the type of information that normally is, and generally can be, communicated between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision, meaning that the relevance of the information to the clinical decision being made is well understood and accepted.

The FDA interprets “other medical information” to include information such as peer-reviewed clinical studies, clinical practice guidelines, and information that is similarly independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.

The FDA notes that frequency is important when determining if information is considered “medical information” or a “signal” or “pattern”, such that a single test or measurement result (e.g. a blood glucose test result) is considered medical information, whereas continuous sampling of the same would be considered a pattern or signal subject to FDA regulation as a medical device.

The FDA explains that Criterion 1 and Criterion 2 describe the types of data inputs used in devices (Criterion 1) and the types of data inputs used in non-Device CDS (Criterion 2).

Criterion 3

Criterion 3 software functions support or present recommendations to HCPs, who may then incorporate this information into their decision-making about the care of a patient, along with other information and factors of which the HCP is aware.

The FDA interprets Criterion 3 to refer to software that provides condition-, disease-, and/or patient-specific recommendations to an HCP to enhance, inform and/or influence a health care decision (e.g. drug-drug interaction and drug-allergy contraindication notifications to avert adverse drug events) but is not intended to replace or direct an HCP’s judgment and does not include in time-critical decision-making or a specific preventive, diagnostic, or treatment output or directive because such functions are not intended for the purpose of supporting or providing recommendations to HCPs.

The FDA considers software functions that provide the following outputs to be non-device CDS as long as they are not intended to support time-critical decision-making and/or replace or direct an HCP’s judgment:

• A list of preventive, diagnostic, or treatment options;
• A prioritized list of preventive, diagnostic, or treatment options; or
• A list of follow-up or next-step options for consideration.

The FDA notes that two aspects of software functionality may affect whether a software function is being used to support or provide recommendations to an HCP: (1) the level of software automation, and (2) the time-critical nature of the HCP’s decision making.  Automation bias may occur if software provides an HCP with a single, specific, selected output or solution, as opposed to a list of options or complete information for the HCP’s consideration.

Criterion 4

Under Criterion 4, the software function enables HCPs to independently review the basis for the recommendations presented by the software, so that HCPs do not rely primarily on such recommendations, but rather on their own judgment, to make clinical decisions for individual patients.

The FDA explains that regardless of the complexity of the software and whether or not the software is proprietary, the output or labelling should provide HCP users with adequate background information in plain language on the input(s), algorithm logic or methods, datasets, and validation.  Additionally, relevant sources should be identified and made available to the HCP user.

While the draft guidance opined upon clinical decision support (CDS) software intended for use by patients or caregivers, the final guidance noted that the FDA’s existing digital health policies continue to apply to such software functions, such that software functions that support or provide recommendations to patients or caregivers – not HCPs – meet the definition of a device.

The final guidance released by the FDA includes several examples of device and non-device CDS, which should be carefully reviewed by developers when designing and implementing an FDA regulatory strategy.

About the author

Kyle Faget is a partner and business lawyer with Foley & Lardner LLP. She is the Co-Chair of the firm’s Health Care Practice Group, Co-Chair, Health Care & Life Sciences Sector – Medical Devices, and a core member of the firm’s life sciences and telemedicine industry teams. Kyle advises investors, academic medical centres, physician practices, and consultants on a range of business, legal, and regulatory issues affecting the telemedicine industry. Kyle helps companies build and refine corporate compliance programs, including advising clients on regulatory and compliance matters involving the Food, Drug and Cosmetic Act, the False Claims Act, the Anti-Kickback Statute, the AdvaMed Code and the PhRMA Code.  She regularly drafts and negotiates agreements required for the development and commercialization of pharmaceutical and medical device products, including licensing agreements, collaboration agreements, clinical trial agreements, and an array of services agreements. Prior to joining the firm, Kyle held in-house positions at pre-commercial and commercial stage companies.