US Regulatory Considerations Applicable to Digital Health Providers and Suppliers - Part III: FDCA

This article examines another major regulatory regime relevant to mHealth application developers – the Federal Food, Drug and Cosmetic Act (FDCA), as well as regulatory issues unique to non-US companies. 

The first two articles in our series examine important HIPAA provisions (see Part I and Part II) .

Federal Food, Drug and Cosmetic Act (FDCA)

What is FDCA?

FDCA regulates the safety and effectiveness of medical devices, including certain mobile medical apps.

A “device” or medical device means “an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is … intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease … or intended to affect the structure or function of the body of man or other animals….” [1]

Software intended “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention or treatment of a disease or condition” is specifically excluded from the FDCA’s “device” definition. [2]

The US Food & Drug Administration (FDA) enforces the FDCA.

Application of FDCA to mHealth application developers

Policy for Device Software Functions and Mobile Medical Applications Guidance (2019) explains FDA’s oversight of device software functions including mHealth apps as medical devices. [3]

The guidance confirmed (i) the FDA considers mobile medical apps to be within its regulatory authority and (ii) the FDA’s intent to focus regulatory oversight on a subset of health apps that pose a higher risk if they don’t work as intended.

If the mHealth app (i) meets the definition of a “medical device” and (ii) is intended for any of the following, it may be considered a “mobile medical app” that is regulated under the FDCA. These include if it can:

• act as an accessory to a regulated medical device (for example, an app that alters the function or settings of an infusion pump)
• transform a mobile platform into a regulated medical device (for example, an app that uses an attachment to the mobile platform to measure blood glucose levels)
• perform sophisticated analysis or interpret data from another medical device (for example, an app that uses consumer-specific parameters and creates a dosage plan for radiation therapy)

What if a mHealth application is regulated as a medical device?

If the mHealth app is regulated as “mobile medical app” i.e., medical device, manufacturers of it are subject to the requirements described in the applicable device classification regulation below. Depending on the classification and the associated regulation for the device software function, manufacturers are required to follow associated controls established by the regulation as described below.

Medical Device Classification

Mobile medical apps that undergo FDA review will be evaluated according to the same regulatory standards and risk-based approach the agency applies to other medical devices. The FDA classifies medical devices into three categories, Class I, Class II and Class III, based on the risk the devices pose to consumers, intended use and indications for use. [4] Class I devices are considered low risk and subject to the least regulatory controls. Class II devices are moderate risk devices and require greater regulatory controls to provide reasonable assurance of the device’s safety and effectiveness, and Class III devices are generally the highest risk devices and subject to the highest level of regulatory control.

Associated Controls for Each Class of Medical Device

• Class I devices: General Controls, including:
  • Establishment registration and Medical Device listing (21 C.F.R. pt. 807)
  • Quality System (QS) regulation (21 C.F.R. pt. 820)
  • Labelling Requirements (21 C.F.R. pt. 801)
  • Medical Device Reporting (21 C.F.R. pt. 803)
  • Premarket Notification 510(k) (21 C.F.R. pt. 807) – however, Premarket Notification is exempted for most Class I devices
  • Reporting Corrections and Removals (21 C.F.R. pt. 806)
  • Investigational Device Exemption (IDE) requirements for clinical studies of investigational devices (21 C.F.R. pt. 812)
• Class II devices: General Controls (as described for Class I) – Premarket Notification 510(k) is required for most Class II devices, and Special Controls
• Class III devices: General Controls (as described for Class I) and Premarket Approval (21 C.F.R. pt. 814)

Brief Description of Certain Device Regulatory Requirements

• Establishment registration and Medical Device listing. [5] Medical device manufacturers, regardless of classification, will need to register their establishment and list the devices they market in the FDA’s device registration and listing database, and there are registration fees.
• Quality System (QS) regulation. [6] Under the QS regulation, medical device manufacturers must develop requirements for their products that will result in devices that are safe and effective, and to establish methods and procedures to design, produce and distribute their devices; appropriately verify and validate their device software functions along with the computing platform to ensure safe and effective operation of the device; and ensure that adequate controls and processes are in place through purchasing controls to ensure safe distribution, installation and operation of the device software function.
• Labelling Requirements. [7] Medical device manufacturers are required to comply with applicable labelling regulations found in 21 C.F.R. pt. 801 for medical devices.
• Medical Device Reporting (MDR) (Adverse event reporting). [8] Under the MDR, manufacturers and importers of medical devices are required to submit reports to the FDA whenever they receive or otherwise become aware of information, from any source, that reasonably suggests a device they market may have caused or contributed to a death or serious injury, or has malfunctioned and the device or a similar device they market would be likely to cause or contribute to a reportable death or serious injury if the malfunction were to recur.
• Premarket Submission Process. [9] With a few exceptions, FDA evaluates Class II and Class III devices for their safety and effectiveness before they are allowed to be sold to the public through a premarket submission process. There are fees associated with filing a premarket submission.
• Reporting Corrections and Removals. [10] Medical device manufacturers are required to promptly report, within 10 working days from the time the correction is initiated, to the FDA certain actions concerning device corrections and removals.
• Investigational Device Exemption (IDE) requirements for clinical studies of investigational devices. [11] An IDE allows an investigational device to be used in a clinical study to collect safety and effectiveness data required to support a Premarket Approval (PMA) application or a Premarket Notification 510(k) submission to FDA. Clinical studies with devices of significant risk must be approved by FDA and by an Institutional Review Board (IRB) before the study can begin. Studies with devices of non-significant risk must be approved by the IRB only before the study can begin.

Enforcement Discretion

FDA intends to exercise enforcement discretion, i.e., not to enforce compliance with its regulatory requirements, for mHealth apps that: 1) may meet the definition of a “device” under the FDCA, but 2) present a “minimal risk” to patients.

This “minimal risk” device includes mHealth apps that: a) help patients/users self-manage their disease or condition without providing specific treatment suggestions; or b) automate simple tasks for healthcare providers.

Examples of software functions subject to enforcement discretion include those that:

• Provide or facilitate supplemental clinical care, by coaching or prompting, to help patients manage their health in their daily environment
• Provide easy access to information related to patients’ health conditions or treatments (beyond providing an electronic “copy” of a medical reference) providing easy access to information related to health conditions or treatments
• Are specifically marketed to help patients communicate with healthcare providers by supplementing or augmenting the data or information by capturing an image for patients to convey to their healthcare providers about potential medical conditions
• Perform simple calculations routinely used in clinical practice.

What if an mHealth application is not regulated as a medical device?

HIPAA (see above) or other laws (see below) may still be applicable to anything related to the mHealth application. A full analysis of the application of each regulatory framework is required.

FDCA And Covid-19

FDA has issued some guidance to address the Covid-19 Public Health Emergency. The following are examples:

• Enforcement Policy for Digital Health Devices For Treating Psychiatric Disorders During the Coronavirus Disease 2019 (Covid-19) Public Health Emergency (April 2020), [12] where FDA has shown 1) its intention not to object to the distribution and use of computerised behavioural therapy devices and other digital health therapeutic devices for psychiatric disorders without compliance with certain regulatory requirements (e.g., premarket notification under section 510(k) of the FDCA, reporting corrections and removals requirements) and 2) other flexibilities in regulations on digital health products.
• Enforcement Policy for Non-Invasive Remote Monitoring Devices Used to Support Patient Monitoring During the Coronavirus Disease 2019 (Covid-19) Public Health Emergency (June 2020), [13] where FDA has showed its intention not to object to limited modifications to the indications, claims, functionality or hardware or software of certain non-invasive remote monitoring devices that are used to support patient monitoring during the declared public health emergency without prior submission of a premarket notification under section 510(k) of the FDCA, where such submission would be required.

Regulatory Issues Unique to Non-US Companies

If IT companies, such as mobile app developers, currently have no presence in the US, they must further review and analyze regulations unique to foreign companies as well as regulations on digital health which are already discussed above.

US Agent Requirement for Foreign Establishment – FDCA

Overview of US Agent Requirement

As discussed above, medical device manufacturers (including mobile medical app developers) are required to register their establishment and list the devices they market in FDA’s device registration and listing database. When a medical device manufacturer engages in the manufacture, preparation, propagation, compounding or processing of a “mobile medical app” (i.e., a medical device) for import into the United States at an establishment located outside the United States, the foreign manufacturer must identify a US agent for that foreign establishment as part of the establishment registration process.

Qualification of US Agent

The US agent must either reside in the United States or maintain a place of business in the United States. The US agent cannot use a post office box as an address. The US agent cannot use just an answering service. They must be available to answer the phone or have an employee available to answer the phone during normal business hours.

Responsibility of US Agent

The responsibilities of the US agent are limited and include: [14]

• assisting FDA in communications with the foreign establishment
• responding to questions concerning the foreign establishment’s devices that are imported or offered for import into the United States
• assisting FDA in scheduling inspections of the foreign establishment
• if FDA is unable to contact the foreign establishment directly or expeditiously, FDA may provide information or documents to the US agent, and such an action shall be considered to be the equivalent of providing the same information or documents to the foreign establishment.

US agents have no responsibility related to reporting of adverse events under the MDR regulation, or premarket submission process. A foreign establishment may obtain Premarket Approval or submit Premarket Notification 510(k), as applicable, under its own name as an owner of such Premarket Approval or Premarket Notification 510(k) and shall be responsible for such reporting of adverse events as the owner.

Other Considerations

Some States within the United States have licensing requirements that are in addition to the FDA requirements. These requirements vary in each State and are dependent on the type of medical device (e.g., prescription versus over-the-counter) and the activity an entity is undertaking (e.g., manufacturer, wholesale distributor, third-party logistics provider). Therefore, manufacturers should evaluate the applicable State licensing requirements prior to importing medical devices into the United States.

Our final article examines US regulations relevant to non-US companies seeking to navigate the US digital health market. It focuses on the Federal Trade Commission Act (FTCA), telemedicine laws, as well as fraud and abuse laws that mHealth application developers should know.