FDA Creates Medical App Regulation Maze

Developers struggle to find the line between unregulated health apps and regulated medical apps. Here's some guidance.

Stephanie Kreml, Contributor

March 3, 2014

5 Min Read
InformationWeek logo in a gray background | InformationWeek

10 Mobile Health Apps From Uncle Sam

10 Mobile Health Apps From Uncle Sam


10 Mobile Health Apps From Uncle Sam (click image for larger view and for slideshow)

When the US Food and Drug Administration (FDA) issued its final guidance for medical apps, inventors and investors alike pored through the document, seeking answers on what was to be regulated and what wasn't. While they indeed found more specific information than has been available from the agency, the guidance also showed the agency's uncertainty over how the world of medical apps is going to evolve.

The September 2013 guidance did specify that it would require device approval of any app intended to diagnose, treat, mitigate, or prevent a disease. But it also left an open door, possibly due to the sheer volume of mobile medical apps, vowing to exercise "enforcement discretion" if an app meets the technical definition of a medical device but poses a low risk to the patient.

An example of this gray area is the case of a hypothetical diabetes management app. At a recent panel of regulatory and industry experts, we discussed whether an app that measures glucose levels in patients with diabetes; reads QR codes to gather nutrition information from food labels; and provides carbohydrate counts, meal options, and recipes is a regulated device under the new FDA guidance. We concluded that the app could fall under several degrees of FDA scrutiny, depending on the inclusion of specific functions.

The FDA would not regulate diet recommendations, recipes, or the tracking of glucose, carbs, and exercise, as these are common diary functions that could be performed with a pen and paper and that pose relatively low risk to the patient. Reminding users to take glucose readings and medications at certain times might trigger enforcement discretion because of possible increased risk to patients. But these functions can be performed by almost any calendar application, and the FDA certainly does not want to be regulating all generic calendar apps. However, the addition of an insulin-dosing calculator based on all of the other data collected by the app would definitely trigger the need for the app to be FDA regulated, as the patient risk potential is high if there are errors in calculations.

[Wearable fitness devices can offer great health benefits. Here's how two of the market leaders compare. Moov Vs. Fitbit: Fitness Faceoff.]

Why would the FDA create this murky scenario while clarifying other uses for apps? The FDA has no interest in regulating all smartphones. Traditionally, the agency has dealt with hardware and embedded software or firmware, which have much longer design revision life cycles than mobile software applications. Today, mobile apps and even broadband-fueled software applications and operating systems for PCs are very easy to change. And if your FDA-cleared software on your device changes (and it's the driving force for the device), then technically every revision would need to be resubmitted to the FDA. I don't believe either side -- industry or agency -- wants that to happen.

As more technology experts and programmers enter the medical arena, this guidance (and the software question) creates the need for new business strategies. The most important question: Are you still using your app for its intended purposes? If consumers and patients increasingly use an app that's designed for physicians, could that new use trigger a regulatory reaction from the FDA? What are the risks each function poses to the patient?

Here are some strategies to deal with these questions:

  • Find a partner who can share the regulatory burden. Some companies already have QC processes in place and could help with regulatory compliance.

  • Consider linking with a contract manufacturing firm or a software development firm that's familiar with FDA regulatory requirements.

  • Contact the FDA early and often in your development process to ensure that all anticipated regulatory issues are properly addressed.

  • When appropriate, find ways to match your software with legacy devices that could confer a lower regulatory risk to your application under the accessory rule.

  • If you're designing an internal app intended for use by clinicians, keep it internal. Once such an app is distributed or marketed outside your hospital or organization, it may require regulation.

Not surprisingly, the debate over regulating medical apps continues. Some industry figures are even expressing concern about the dangers of deregulating this technology. Critics of the proposed PROTECT and SOFTWARE Acts now circulating in Congress warn that the legislation could put high-risk calculators in the hands of untrained consumers, force hurried doctors to make uncertain smartphone-based decisions, or arrive at diagnostic conclusions (such as radiation doses) without displaying how these conclusions were reached.

Of course, the medical calculators that replaced the paper and pencil have not been under the purview of the FDA, even though errors can occur using both old and new technologies. Here's my take on that, given my clinical experience and work within the mHealth industry: Regardless of who uses the application, the overwhelmingly important question is, what is the risk to the patient if the app were to not function as intended?

Download Healthcare IT In The Obamacare Era, the InformationWeek Healthcare digital issue on changes driven by regulation. Modern technology created the opportunity to restructure the healthcare industry around accountable care organizations, but ACOs also put new demands on IT.

About the Author

Stephanie Kreml

Contributor

Stephanie Kreml, M.D., is a Principal at Popper and Company. In her current role, she develops and implements business strategy for start-up companies and new business units in existing companies; consults in areas of clinical need, commercialization, and technology assessment; performs due diligence for investment and acquisition targets in the life science industry; critically evaluates unmet clinical needs and technologies; and provides guidance to accelerate new product development activities.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights