Tuesday, August 5, 2014

FDA Mobile App Guidance - The Path Forward

In my last post I described the current state of mobile app regulation, including a summary of the FDASIA Health IT Report, which rather than expand FDA oversight on mobile health applications, recommends that "a better approach is to foster the development of a culture of safety and quality; leverage standards and best practices; employ industry-led testing and certification; and selectively use tools such as voluntary listing, reporting, and training to enable the development of a healthcare environment that is transparent and promotes learning to foster continual health IT improvement."

This approach, while pragmatic, leaves a significant unanswered question: does the risk associated with leaving these apps unregulated outweigh the benefits in allowing them to come to market more quickly? Nathan Cortez, J.D., et al attempt to answer this question in the recent article entitled "FDA Regulation of Mobile Health Technologies" from the July 24, 2014 issue of the New England Journal of Medicine. The authors recognize this dilemma: "The true challenge ... is creating a regulatory framework that encourages high-value innovation while also preventing the market from being overcome with products that are ineffective or unsafe."

While the authors give several examples of apps that have not functioned as designed and raise relevant concerns regarding the process (e.g., "it seems inefficient for app manufacturers to submit repeated [510(k)] applications for each update or change"), they suggest few solutions or alternatives. Aside from increasing FDA resources (possibly through an approval fee imposed on mobile app developers) along with a new center to regulate mobile apps, their single substantive recommendation consists of a conditional approval process, whereby the developers pledge to gather safety and effectiveness data after app release in exchange for expedited premarket review. Also, while the FDA recommends enforcement discretion for all clinical decision support apps, the NEJM article authors recommend that "the FDA should regulate mHealth products that incorporate clinical-decision support."

None of these are bad ideas. If fact, increasing resources to support an expedited approval process would seem to be the only tenable solution, if not for the possibility that - by the authors' own admission - "there could be 1.7 billion mHealth users worldwide" by 2017, and likely over a million mobile health apps (assuming 97,000 mobile health apps in 2013, roughly estimated to double annually per the article).

Let me say that again: there could be over a million mobile health apps by 2017, and if you want a less ephemeral number, there were already 97,000 as of early last year alone. Granted, not all of these will be high-risk clinical decision support apps, but, of course, how could we know which ones are high-risk unless we review them all, at least in a cursory way?

While the policy recommendations in the NEJM article strike me as an idyllic moonshot attempt, the FDASIA Health IT Report is grounded with an acknowledgement of the enormity of the task.

Furthermore, the NEJM authors do not fully account for the perspective of the innovators themselves, who are often mobile developers unfamiliar with the long waits required for 510(k) approval. In fact, they state that "the FDA reports that the average total time from a 510(k) submission to a decision by the FDA is only 110 days." Only 110 days. I recognize that this is short by medical device standards, but we're talking about developers who are already miffed that they have to wait 1 week for initial app approval and several days for each app update. Speaking of updates, mobile apps are updated frequently - monthly or more in many cases. How does that fit with a "short" 110 day approval process?

It's difficult to predict where the next great idea will come from. I recognize the desire to ensure that each of the hundreds of thousands of potential healthcare apps is as risk-free as possible, but the barriers recommended by the NEJM article - including an approval fee and conditional approval with post-marketing follow-up assessments - would all but guarantee that many potential life- and cost-saving clinical decision support innovations never see the light of day (at least those not supported by venture capital).

So what can be done?

I don't have a panacea. This is a hard problem. But I think that the recommendations of the FDASIA Health IT Report serve as an excellent starting point: "foster the development of a culture of safety and quality; leverage standards and best practices; employ industry-led testing and certification; and selectively use tools such as voluntary listing, reporting, and training to enable the development of a healthcare environment that is transparent and promotes learning to foster continual health IT improvement."

For me, this boils down to:
  • Education: help providers understand the risks inherent in new technologies, the danger of over-reliance on such technologies, as well as the importance in following best practices. Providers should learn to integrate new and unfamiliar technologies slowly, or use software trusted by peers.
  • Expertise: as I've discussed earlier, the developer of every mobile health app should enlist appropriate domain expertise to ensure success. Providers interested in mobile health should make themselves available where possible. Lack of provider involvement in the app development process should be seen as a red flag.
  • Environment: a culture of safety and quality accompanied by continual improvement describes the promise of a learning healthcare system. Mobile technology is positioned to deliver on this promise.

I want to stress that of the three categories of health IT functionality described in the FDASIA report (Administrative, Health Management, and Medical Device), the suggestions above are most applicable to decision support apps in the Health Management category. This is the current grey area, but also likely to be the largest of the three in terms of app volume. These apps will still be subject to FDA enforcement discretion (reactive as opposed to proactive), which I feel is appropriate.

On the other hand, apps that purport to be medical devices would fall into the third category, which I feel should be carefully regulated since they would pose far more risk. Examples of such apps currently in the App Store include Instant Blood Pressure & Pulse Oximeter.  Instant Blood Pressure includes a disclaimer at the bottom of the app page ("for recreational use only. It is not an FDA cleared medical device. Consult a doctor if you have any health concern.") while Pulse Oximeter does not. I personally tested pulse oximeter a couple months ago and found it lacking.

I believe that the only practical way to catch these apps prior to release would be to work directly with app store curators (e.g., Apple and Google) to add an additional layer of review to screen for apps that claim medical device functionality. If they are found to meet the definition of a medical device, they should be referred to the FDA prior to app store approval.

We still have a long road ahead of us and I applaud the work of the FDA as well as the perspectives of the authors of the NEJM article. Reaching an appropriate balance of innovation and risk while achieving our goals of improved patient care, safety, and cost savings will be critical to ensure a thriving healthcare system well into the future.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.