FDA Further Eases Restrictions on Areas of Potential mHealth Innovation

I recently reviewed the timeline for FDA regulation of mobile apps and devices and shared my perspective on the path forward.  At the time, I was unaware of another recent draft document released by the FDA on August 1, 2014 explaining their "Intent to Exempt Certain Class II and Class I Reserved Medical Devices from Premarket Notification Requirements."  Given that the devices listed in this document have been targets for mHealth innovation, this is a positive development for the industry.

The document lists devices in the following categories (items currently relevant in mHealth are emphasized, this is not a complete list):

• Anesthesiology Devices
• algesimeters, NO2 analyzers, cutaneous O2 monitors, pneumotachometers, rocking beds, portable air compressors
• Cardiovascular Devices
• trocars, lung sound monitors, oscillometers, body composition analyzers
• Dental Devices
• pulp testers, denture pads/cushions/reliners, plastic dentures, endodontic splits, parallelometers, teething rings
• Ear, Nose & Throat Devices
• hearing aids, middle-ear molds
• Gastroenterology - Urology Devices
• fiberoptic/endoscopic light sources, colostomy rods, hemorrhoidal/esophageal ligators, biliary lithotriptors, urethrotomes, esophageal dilators, ostomy irrigators
• General and Plastic Surgical Devices
• alcohol pads, talking first aid kits, surgical drapes/lights
• General Hospital and Personal Use Devices
• electrical thermometers, support stockings, finger cots, UV water purifiers, patient restraints
• Neurological Devices
• vibration threshold devices, temperature discrimination testers, ataxiagraphs, preformed cranioplasty plates
• Obstetrical and Gynecological Devices
• fertility diagnostic devices, cervical drains, obstetrical forceps, vaginal specula, umbilical clamps, perineal heaters, menstrual cups/pads, genital vibrators
• Ophthalmic Devices
• ophthalmic cameras, photorefractors, euthyscopes, transilluminators, trephine engines, electrolysis units, headlights/lamps, magnets, sponges
• Physical Medicine Devices
• reflex hammers, finger-sucking devices, hydro-massage baths, sitz baths, paraffin baths, measuring exerciser, external limb overload warning devices

Given that mHealth regulation will likely require increased resources, this notably has the potential to free-up resources in the low-risk device categories arena so that the FDA can focus on high-risk devices and applications.

I applaud the FDA for their consideration and attention to this area.

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.

FDA Mobile App Guidance for Dummies (or, why Mobile Health Apps ≠ Drugs)

I've heard a lot of assumptions and misconceptions with respect to FDA regulation of mobile health technologies. This is partly due to the fast-moving nature of this field, but also due to the reputation the FDA have earned over the years for slowing the pace of innovation through appropriate regulatory oversight, particularly in the pharmaceutical industry.

It takes many years and hundreds of millions of dollars to develop a blockbuster new drug and then see it through regulatory approval. On the other hand, a mobile health app could be developed in weeks to months with nothing more than sweat equity. Only a fool would have trouble distinguishing these two, or would attempt to apply the regulatory framework of the former to the latter.

Fortunately, the FDA are not fools, and should be given credit for anticipating the trend towards proliferation of mobile healthcare at least as quickly as would seem reasonable in the current political climate.

Mobile Apps Regulation Timeline

Just over three years ago, on July 21, 2011 (back when only 23% of all adults used a smartphone to go online in a typical day, and most iPhone users were running iOS 3 and iOS 4), the FDA released draft guidance on mobile medical applications.

One year later, on July 9, 2012, the Food and Drug Administration Safety and Innovation Act, or FDASIA, was signed into law. One important component of this act was to "Promote Innovation," which included a provision to "further medical device innovation."

Fourteen months later, on September 23, 2013, the FDA issued "final guidance on mobile medical apps" that included a report summarizing their nonbinding recommendations. Despite the common misconception that the FDA plan to regulate all apps with any component of clinical decision support, this document makes clear that the FDA plan to focus "its oversight on mobile medical apps that:

• are intended to be used as an accessory to a regulated medical device – for example, an application that allows a health care professional to make a specific diagnosis by viewing a medical image from a picture archiving and communication system (PACS) on a smartphone or a mobile tablet; or
• transform a mobile platform into a regulated medical device – for example, an application that turns a smartphone into an electrocardiography (ECG) machine to detect abnormal heart rhythms or determine if a patient is experiencing a heart attack."

Note that there is no mention of clinical decision support here, which the agency makes explicit in a prior disclaimer (emphasis mine): "The agency intends to exercise enforcement discretion (meaning it will not enforce requirements under the Federal Drug & Cosmetic Act) for the majority of mobile apps as they pose minimal risk to consumers. The FDA intend to focus its regulatory oversight on a subset of mobile medical apps that present a greater risk to patients if they do not work as intended."

In April 2014, as a result of the FDASIA, a report was published that detailed "Proposed Strategy and Recommendations for a Risk-Based Framework" for health IT. The report recommended "that no new or additional areas of FDA oversight are needed," and also called for the creation of a "Health IT Safety Center" created by ONC (in collaboration with FDA, FCC and AHRQ) "with the ultimate goal of assisting in the creation of a sustainable, integrated health IT learning system that avoids regulatory duplication and leverages and complements existing and ongoing efforts."  The report describes three distinct groups of medical apps, each requiring varying levels of oversight:

Three categories of health IT functionality as described in the FDASIA Health IT Report, April 2014

Oversight is as follows:

• Administrative Functionality (billing and claims processing, practice and inventory management, and scheduling): no additional oversight
• Health Management Functionality (health information and data exchange, data capture and encounter documentation, electronic access to clinical results, most clinical decision support, medication management, electronic communication and coordination, provider order entry, knowledge management, and patient identification and matching): no intention to focus oversight here if the product meets the statutory definition of a medical device
• Medical Device Functionality (computer aided detection software, remote display or notification of real-time alarms from bedside monitors, and robotic surgical planning and control): oversight required

Finally, on June 20, 2014, draft guidance was issued in the form of an update to the September 2013 guidance on mobile medical apps that further limited the scope of regulatory oversight with respect to Medical Device Data Systems (MDDS).

The Path Forward

To summarize, the FDA's current guidelines reflect a pragmatic approach to regulation of the 97,000+ healthcare apps currently available, with emphasis placed on apps that mimic the functionality of medical devices, and not on most clinical decision support apps. Rather than significantly augment the the abilities of the FDA to handle this accelerating volume of healthcare apps, the FDASIA Health IT Report 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."

Despite the guidance provided by the FDA to date, tremendous uncertainty remains, especially for the developers of these mobile applications who often are not medical or policy experts. Thus far, however, there's been a clear trend towards minimizing regulatory oversight.

Some argue that there may be significant risk in allowing so many unregulated healthcare apps to flood the market.  In my next post, I'll share my opinion on the FDA guidance to date and compare the guidance with a summary article just released in the July 24, 2014 issue of the New England Journal of Medicine entitled "FDA Regulation of Mobile Health Technologies", which includes additional policy recommendations.

Update: click here to read my assessment of the current landscape and the path forward for FDA mobile app regulation.