On September 25th, the FDA issued its final guidance for medical app developers. This guidance, in draft form for over two years, describes how the FDA intends to apply existing regulations to the world of medical apps. In brief, the guidance hasn’t changed much.

As in the draft guidance, the FDA is taking a pragmatic approach to this area by trying to balance the need for oversight with the sheer size and scope of the market. They are focusing on apps that meet criteria to be considered medical devices and pose significant risks if they don’t work as intended (1).

For clinicians, it is particularly important to know what falls under the purview of formal FDA regulation and what does not.

Here’s our review of the final guidance for healthcare professionals.

What is being regulated

There are nearly 40,000 medical and health/wellness apps in the App Store alone (2) – the FDA rightly asserts that it simply cannot and shouldn’t try to regulate the entire market.

Many mobile apps are not medical devices…and the FDA does not regulate them. Some mobile apps may meet the definition of a medical device but because they pose a lower risk to the public, FDA intends to exercise enforcement discretion over these devices…The majority of mobile apps on the market at this time fit into these two categories.

According to the final guidance, the FDA plans to regulate apps that are

  • An extension of a medical device
  • Transform the mobile platform into a regulated medical device
  • Perform patient-specific analysis, providing diagnosis/treatment recommendations.

They make a valiant effort at providing some clarity by giving a lot of examples.

Apps that don’t meet the definition of medical device: Most of the list here are general reference and education apps for both healthcare professionals and patients. These include textbooks, dictionaries, translation, billing code look-up, procedure tutorials, pill identifiers, drug reference, and general patient education. They also note that apps that perform administrative functions – say related to scheduling or billing – don’t make the cut. Finally, general purpose apps are left out (flashlights for example) as long as they don’t make medical claims.

Apps may be medical devices but won’t be regulated: Here we get several examples of apps that could technically be considered medical devices but because of their risk profile will not be regulated. Examples include apps that help patients manage chronic diseases through behavioral interventions such as using GPS location to alert asthmatics to allergens, smoking cessation support apps, games to promote healthy behaviors, various chronic disease diaries, symptom checkers, medication reminder/tracking apps, and more.

They also note that apps that automate simple tasks will be excluded – this includes interaction checkers, apps that provide general references based on patient specific factors (e.g. ePSS-like apps), skin lesion trackers, general calculators, and EHR access apps.

In this last group, it gets a bit more nuanced – in a footnote, they comment that their intent is to exclude apps that can be “safely used by a patient without oversight…[and] is not intended to replace or discourage seeking treatment.” Mention is made elsewhere that apps that calculate patient-specific radiation dosing would be regulated; we would presume that apps that provide functionality beyond view-only EHR access, provide risk assessments of skin lesions would be regulated, or make specific dosing/treatment recommendations would also be regulated.

So what’s left: We are finally left then with the apps that both meet the definition of a medical device and pose a high enough risk to warrant FDA oversight. In general, apps that use peripheral sensors (e.g. ECG leads, analyze a test strip, etc) or connect to and manage regulated devices fall in this category.

They are additionally interested in apps that use the native device functions – camera, microphone, speaker, etc – to either capture physiologic data or for some diagnostic/therapeutic purpose. Examples would include apps that detect tremors as well as apps that claim to treat a specific disease.

Finally, they note that apps that display patient-specific data (think Airstrip) also fall under their regulatory purview.

One area that remains a bit unclear to us are apps that make specific treatment recommendations i.e. drug dosing apps like insulin calculators. As chronic disease management shifts increasingly to the patient being a more active manager, we can expect an increasing number of apps that support this self-management – think apps that recommend when a heart failure patient should double up on their lasix or an asthmatic should fill their prescription for a prednisone taper. While some sections note that apps that make patient specific recommendations would be regulated, other areas note that apps that automate simple calculations would not be. While it would make sense that perhaps an app that simply calculates a weight based maintenance fluid rate should not be regulated, we would think one that calculates insulin dosing should be – it’s not entirely clear though where the line will be drawn.

Responsibilities of App Developers

Special mention is made of the responsibilities of mobile medical app developers – developers whose apps meet the definition of a medical device – to follow good manufacturing and design practices.

The FDA strongly recommends that manufacturers of all mobile apps that may meet the definition of a device follow the Quality System regulation (which includes good manufacturing practices) in the design and development of their mobile medical apps and initiate prompt corrections to their mobile medical apps, when appropriate, to prevent patient and user harm. Among other things, this includes testing and validating the app to ensure it is not only safe but also does what it claims to do.

Disclosure of these of practices for apps in this category is something clinicians and patients should look for going forward.

Conclusion

Taking a pragmatic approach, the FDA intends to regulate a very small subset of medical apps – those that can be classified as medical devices and pose significant risk if they don’t function correctly. For clinicians, that means the vast majority of apps that we and our patients use will not have regulatory oversight.

While programs like in-depth app certification may become available, the sheer size of the market as well as the speed of development make it unlikely that such programs will be able to capture more than a small fraction of the market. Additionally, while peer-reviews like that provided by iMedicalApps can be broader and more responsive, even we cannot get to everything that is out there.

As such, it will be the responsibility of healthcare professionals and patients to make individualized assessments and decisions regarding any specific app. That includes looking at information sourcing, quality control (like error correction), information time stamping, and other key parameters to determine whether the app can be considered reliable. It also involves determining whether it fits the clinical situation.

(1) Final Guidance
(2)148apps.biz