Mobile health ("mHealth") application ("app") developers, manufacturers, investors, healthcare providers and others received welcome news late last month when the U.S. Food and Drug Administration ("FDA") published its long-awaited final guidance on mobile medical applications ("MMA") under the Federal Food, Drug, and Cosmetic Act (the "Act"). It is vital for any app developer to understand whether the guidance applies to their product from the initial design stage. Those who are already marketing software and apps that involve healthcare should also review the guidance with care to try to determine how FDA's new regime impacts both business plans and continuing operations.
The 43-page final guidance1 is written and organized in a direct and helpful manner. It answers many questions industry had about FDA's intentions in the mHealth arena, including alleviating a key concern that the agency might regulate the actual mobile platforms upon which apps operate. To assist in understanding the key features of the guidance, we have prepared a summary of the guidance. While the guidance clarifies FDA's views on many of the issues impacting the mobile medical app world, unanswered questions remain that warrant consideration to ensure the success of an mHealth product. We will address some of those questions in this Alert.
The Guidance Says the App Is a Device Subject to FDA Regulation, What Can Be Done Now to Legally Get the App on the Market?
The final mobile medical application guidance clarified many key issues on how FDA will regulate mobile apps that are medical devices and those that develop, make or market them. However, app makers should understand that the guidance does not provide any advice on the specific information and data that an app maker will need to develop and, in many cases, submit to FDA either in a premarket notification submission ["510(k)"] or premarket approval application ("PMA") to be able to sell their app.
Defining an App or What Device Regulation Classification Applies?
What can be done if it is not apparent what regulation an app falls under … or if there is even a regulation that covers it? As an initial step, the guidance provides, in Appendix C, details on possible regulations and/or product codes that would govern various types of apps that FDA says are subject to regulation that an app maker should review.
However, if Appendix C does not provide an example of an existing device to which an app matches, both as to technological characteristics and intended use, the guidance provides in Question #1 of the Frequently Asked Questions (FAQ) several mechanisms for gaining clarity from FDA in that circumstance, including, in particular, the "513(g) Request" process. Under that approach, which is provided by the Act, a person can request formal written feedback from FDA on the device classification (if any) that might apply to an app and related regulatory requirements. FDA then has 60 days to reply to the 513(g) request, which also is subject to a user fee.2
For many apps, a potentially likely result of the 513(g) process may be that FDA concludes the app is a medical device, but also finds that the technological characteristics of the device and/or its intended use are such that no existing FDA regulation classifying the device exists. In that scenario, by operation of Section 513(f) of the Act, such a mobile medical app is automatically classified into Class III, and to be lawfully marketed, the app maker will need to file and secure approval by FDA of a PMA.
App makers facing this issue have a mechanism they can pursue to reclassify their app from its automatic Class III status to Class II or even Class I. Known as the "de novo petition" process, and while not without challenges, FDA has used it on numerous occasions over the past 15 years to move lower-risk devices out of Class III into Class II. In a similar situation, FDA initiated the reclassification of the Medical Device Data System ("MDDS") device from Class III all the way to Class I in February 2011.3 If an app maker needs to pursue the de novo process, a key challenge it will face is demonstrating to FDA that its device is of a nature—especially the risks that it presents—that it can be adequately regulated by special controls (Class II) or general controls (Class I).4
What Data Would Satisfy FDA?
Even if an app maker can determine with confidence what device classification regulation covers its app, it still will face a significant challenge in determining what data it will need to submit to support a marketing filing. While FDA has cleared or approved about 100 apps over the past 10 years, information on what those applicants had to do to secure FDA market clearance/approval is not easily ascertainable. For those apps cleared under the 510(k) process, the publicly available "510(k) summaries" describing possible predicate devices typically provide little information of practical use for developing a comprehensive data package to support clearance of a later 510(k). Device-specific guidances, which often provide the foundation for data development to support submissions for more conventional devices, are virtually nonexistent for apps that are medical devices.
Facing that situation, an app developer will likely need to seek input from FDA. While the agency is open to advising applicants, the formal process for securing feedback on product development plans—the "pre-submission" meeting5—can be slow and does not preclude FDA from later changing its mind on data requirements. However, submitting a 510(k) to FDA without vetting one's data plan via the agency runs the risk of having too little, too much or simply the wrong data to support the submission.
What Is a Minor, Iterative Change to a Regulated App?
Nestled into FDA's webpage discussion of the final guidance was this statement that we could not find in the guidance:
FDA's mobile medical apps policy does not require mobile medical app developers to seek Agency re-evaluation for minor, iterative product changes.6 [Emphasis in the original]
While the mobile app industry likely welcomes this statement, what does it mean? App makers that are subject to cleared 510(k)s or PMAs for regulated apps should not regard this as a free pass to disregard regulatory requirements governing how they currently handle changes to their devices.
Is "Enforcement Discretion" a "Get-Out-of-Jail-Free Card"7 for Every Device Regulatory Duty FDA Law Creates?
In the guidance, FDA states that six types of mobile apps are (or "may be") medical devices that will be subject to "enforcement discretion." However, the guidance does not define or provide any parameters to this key phrase. It broadly states, in Footnote 18, on page 12 of the guidance that:
This indicates that for certain mobile medical app devices, such as those in Appendix B, the FDA intends not to pursue enforcement action for violations of the FD&C Act and applicable regulations by a manufacturer of a mobile app that meets the definition of a device in section 201(h) of the FD&C Act as specified in this guidance ….
Taken literally, Footnote 18 implies that a manufacturer of a mobile medical app that is a device subject to enforcement discretion does not have to comply with any part of the FD&C Act or any regulation promulgated under it. Is that what FDA meant? In other instances involving enforcement discretion (e.g., in the food arena), the agency has been more specific about what duties were subject to enforcement discretion.
What does enforcement discretion augur for those companies that pursued a 510(k) for an app that may now be subject to enforcement discretion? Can they now ignore any duty to update their 510(k) in the event they want to change their device? Or should they withdraw the 510(k) to avoid the need to update?8 If they keep their 510(k), can they now expect FDA to impose the same 510(k) duties on their competitors as they had to go through? What incentives do the competitors have now to submit a 510(k)?
What Is the Level of Risk That Will Cause a Mobile Medical App That Is a Medical Device to Fall into the "Regulated" Category If It Does Not Fall into Any of the Three Subtypes of Regulated Apps?
The guidance clarifies that it does not address every type of app that is or might be a medical device. In that situation, an app maker may find itself with an app that does not neatly fall into any of the subsets of devices that either are regulated under the guidance or are subject to enforcement discretion.
In an ensuing dialogue with FDA over whether an app should be regulated or subject to enforcement discretion, the key issue based on the guidance is the level of risk presented by the app should it fail to function properly. However, the degree of risk that caused FDA to place some devices into the regulated category and others into enforcement discretion is not articulated with clarity in the guidance. The agency says, at page 4 of the guidance, that it intends to regulate only those apps that are medical devices whose functionality "could pose a risk to a patient's safety" if the app failed. In contrast, when articulating its approach to apps that are medical devices, but will be subject to enforcement discretion, the agency says at page 16 of the guidance that this category covers apps that "pose a low risk to patients."
Left unaddressed in the guidance is when the risk linked to a mobile medical app's potential failure moves from low risk (i.e., enforcement discretion) to a risk to the patient's safety (i.e., regulated). To advance a position on this issue, an app maker will likely need to conduct a robust risk analysis to support a 513(g) request (see discussion above) seeking FDA's agreement that enforcement discretion is warranted.
A Key Subject Dodged – Clinical Decision Support Software
The agency avoided at least one question in the guidance. Specifically, the agency stated that the guidance did not address so-called "clinical decision support (CDS) software," an undefined subset of apps. At page 12 of the guidance, the agency stated:
This guidance does not address the approach for software that performs patient-specific analysis to aid or support clinical decision making.
Given that several types of apps covered in the guidance contain descriptions resembling the CDS description in the quote above, further clarification awaits on where the line exists between those covered by the guidance and those excised from its ambit under the above statement. As CDS software is key to the growth of mHealth by providing the physician or other caregiver with the tools to make diagnosis and treatment decisions, app makers should continue to follow FDA developments in the CDS arena. FDA previously has said it will issue guidance on how it plans to regulate CDS software.
Do Not Overlook the FTC
Mobile app makers, who understandably have focused on FDA's role as the gatekeeper to the marketplace, should keep in mind that the Federal Trade Commission ("FTC") has the power to regulate their apps due to the FTC's jurisdiction over the advertising of a large segment of medical devices sold in the United States.9
The FTC's position on the amount and nature of the data needed to support an advertising claim for an app may even exceed the parallel requirements of the FDA to secure marketing. For example, in 2011, the FTC took regulatory action against two apps that claimed to treat acne. In that proceeding, the FTC took the position that the advertising claims needed to be supported by two adequate and well-controlled clinical investigations to meet its substantiation standard.10
The Future – "Kind" Enforcement (at Least for Now)?
Early indications are that at least in the short term, while greater clarity exists due to the guidance, FDA will prefer to educate and work with app makers that now find themselves in the regulated category rather than taking enforcement action. How long any such enforcement grace period will continue is unknown at this time. App developers, manufacturers, investors and others are likely to continue to press for greater clarification from the FDA.