A June interview with FDA’s Bakul Patel, author of FDA's draft guidance on mobile medical apps, revealed that the majority of mobile health apps FDA has reviewed to date are classified as Class II Medical Devices. Of the 27,000 medical apps available today, FDA has reviewed less than .003%. Classifying even ten percent of the 27,000 medical apps as Class II Medical Devices risks bringing FDA to its knees, dramatically increasing the number of inspections and enforcement actions FDA needs to take each year.
As more developers around the world jump into the fast paced medical app business, the problem will get worse. Compounding this is the lifespan of the average mobile app: 14 months. And during that time, the app will be significantly revised or completely rewritten 3-4 times. In device terms, that’s a new model every 3-4 months. And yet FDA needs an average of 67 days to review a medical app. So by the time FDA has finished its review and clearance, the version the agency reviewed may well be obsolete.
This is going to be problematic if the majority of mobile medical apps are classified as Class II Devices as suggested by FDA's draft guidance on mobile medical apps.
Class II Medical Devices are higher risk than Class I devices. Example Class II devices today include powered wheelchairs and infusion pumps. Class II devices require their maker to fully comply with FDA's Quality System Regulation (21 CFR § 820) and the Medical Device Reporting (21 CFR § 803) rules, from design control to supplier (including distributor) qualification to postmarket monitoring. Assuming a firm takes a traditional approach to compliance with the QSR and MDR, their cost of doing business will increase an average 30%.
Many questions about QSR and MDR compliance for medical apps abound. Is Apple a distributor of the medical mobile app? What about Google’s Android store? Or Amazon.com? How should a maker of a mobile health app qualify Google or Amazon.com or Apple? If a user posits a poor review and bug problems he/she had on the app store’s reviews section, what responsibility does the developer – or Apple or Google – have to consider that user review for postmarket reporting? How strict will FDA be in inspecting and enforcing design controls when device models completely change every 3-4 months. Far too few firms today get design control right with an 18 month development lifecycle. What is the agency’s compliance expectation for a 90-day development lifecycle? And for apps that include the ability for a healthcare provider to enter patient data and track treatment plans, for instance, who is responsible for ensuring the app is 21 CFR § 11 compliant such that any data within it has integrity, much less remains confidential and private?
FDA’s current draft guidance on mobile medical apps is woefully short of such practical specifics. And yet it’s these specifics that will get even the most forthright medical app developer in trouble with FDA-483s and Warning Letters. Warning Letters have been shown to reduce product sales by at least 8% the first year and for three years thereafter. For many of these developers, a Warning Letter might be the kiss of death and bring a painful chill to the innovation marketplace.
FDA will need to tread carefully in its final guidance. I am less concerned about apps that clearly turn a smartphone into a medical device or diagnostic tool (a perfect example is the recent “It Has Come to Our Attention Letter” to Biosense Technologies in California for its mobile medical app, uChek Urine Analyzer). I am more concerned about missteps in two areas:
1. Misinterpretations around technological capabilities vis-à-vis wellness versus treatment versus diagnosis. Many mobile medical apps help healthcare providers and patients track conditions – from weight loss to insulin levels. It seems to me that FDA’s draft guidance identification of apps doing calculations as Class II devices is extremely broad. After all, if my weight loss app calculates my body mass index, doesn’t that technically meet the criteria defined by FDA: “Apps that act as calculators or utilize algorithms to produce an index, score, scale, or other similar calculations.” And what if my doctor decides to rely upon that to prescribe a weight loss drug or exercise regimen? Or a clinician, in the midst of a clinical trial, decides that this is how he/she is going to verify and track dosing?
2. Enforcement of the QSR and MDR requirements. How will FDA enforce these regulations given the enormous numbers of medical apps and the comparative dearth of FDA investigators and reviewers? Few app developers today use anything like design control for their rapid development and release cycle. And many medical app developers are virtual companies. What is the actual likelihood they will comply versus simply shutdown shop after 14 months (the lifespan of their app) only to re-open under another name? Think about how the video game development industry operates. Game studios open and close all the time. Individual developers jump ship to form a new studio, release a game, and then shut down the studio, only to reform with a slightly different group of developers and reopen a new studio 30 days later. I can easily foresee this happening in the mobile medical app space, particularly as more and more overseas developers join the fray. FDA can clarify all it wants that app developers need to register as device makers and comply with the QSR and MDR, but enforcement needs to be realistic to work. The ability of an app maker to open up, develop the app, sell it for 14 months, and then close up shop faster than FDA can realize the app even existed is going to make for a lot of frustration in FDA, in the marketplace, and among patients and providers.
While FDA continues its case-by-case enforcement and tries to craft guidance-based rules in which to understand and frame the fast-paced mobile health landscape, the market marches forward at double time.
Let’s hope mobile medical app makers are not surprised when FDA finalizes the rules of the game.
