In the world of mobile apps, things change quickly, and it stands to reason that, as mobile phone makers added better processors, cameras, gyroscopes, and accelerometers, software developers followed with new apps that took advantage of the upgrades, perhaps offering apps that the hardware makers hadn’t even considered.  Some of those apps did things that were medical in nature, and many of us in the medical device industry asked, “does the FDA regulate that?”   The answer, of course, has been changing, and I’ll provide some background plus the latest on the rules, at least as of the date of this article.

FDA Guidance Documents- they’ve been busy

While the FDA has been on top of this subject since at least 2013, their most recent guidance document, “Mobile Medical Applications: Guidance for Industry & FDA Staff,” issued in February of 2015[1], contains an opening disclaimer that says they are “assessing how to revise” the guidance to represent the FDA’s “current thinking” since the 21st Century Cures Act (Cures Act) became law in December of 2016.[2] Among other things, the Cures Act changed the definition of a medical device.  Indeed, the FDA has added that disclaimer to several of their guidance documents in this area[3] and their mobile medical app website hasn’t been updated since before the Cures Act was passed.[4]

Now, for those of you who work on fast-paced technology projects and are lamenting the FDA’s ten-month delay in updating the mobile medical app guidance, allow me to put this into perspective, as the FDA is not being slow.  The life cycle of an FDA device guidance is typically several years, and some have been around for well over a decade.  And the FDA’s drug and device divisions have been busy, with each issuing about two dozen guidance documents from August through October of 2017, or two per week for several months.

In the last week of October, the FDA’s device group, the Center for Devices & Radiological Health (CDRH) issued about seven device guidance documents, including one on breakthrough devices[5] and another, a 77-page tome[6], that explains when a new 510(k) needs to be filed for an existing medical device, replacing a 20-year old guidance on the same topic.  CDRH has at least two more statutorily-required guidance documents due before the end of the year[7], and those are in addition to the FDA’s public commitment to issue a guidance that includes post-Cures Act device-related clarification, including on mobile medical apps, by the end of 2017.[8]

So, with a new guidance on the way that will include mobile medical apps, how are software developers to apply the current rules, and what are the FDA’s changes, if any, likely to be?

Three Levels of Analysis

In the mobile medical app guidance and in other digital health guidance documents, the FDA has been clear that they intend to apply the rules as they do with all medical devices, by using a risk-based approach.  Specifically, the FDA intends to regulate “only those mobile apps that are medical devices and whose functionality could pose a risk to a patient’s safety if the mobile app were to not function as intended.”[9]  That concept won’t change in future guidance documents and the Cures Act preserves the FDA’s authority to deem any software regulated if the FDA determines there is a risk to public health.

Following the FDA’s way of sorting mobile apps, there are four possible groups, and companies developing apps might want to consider these while conducting a regulatory assessment:

Group 1: The app is not a medical device,

Group 2: The FDA has said they won’t regulate it, even if it is a medical device,

Group 3: The FDA has said it’s an app they will regulate, or

Group 4: None of the above- grey area

As you consider these groups, you’ll want to be in Groups 1 or 2 unless the company has decided to enter the regulated medical device space.  If you are in Group 3, the app is probably a regulated medical device.   Finally, if your product has no analogues in any known examples, then you are in the Group 4 “grey area,” and, while I have a separate article on the general question of when digital health technology is not a medical device[10], the app, like Group 3, is likely to be a regulated device.

Group 1- Not a Device

The FDA’s definition of medical device is broad enough to allow virtually any healthcare-related mobile app to be regulated as a device if it is “intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals.[11]  Luckily, the FDA (in guidance documents) and the Cures Act (by statutory definition) provide some clarity in a few key areas where one may review specific lists or definitions and conclude that a given mobile app is not a medical device.

General Wellness, Medical Device Data System (MDDS), and Clinical Decision Support (CDS)

Before the Cures Act, the FDA had issued guidance documents saying, essentially, that they did not intend to regulate either:  i) software whose purpose was to promote general wellness or, ii) software that passively transferred, stored, converted, or displayed existing medical device data (aka MDDS).  However, the FDA still defined MDDS as a Class I device, which held true until December of 2016.  Under the Cures Act, the general wellness and MDDS categories are not medical devices at all.  But the biggest medical device-related change under the Cures Act was what the FDA calls “limited” Clinical Decision Support, a category that has been discussed for years but on which the FDA never issued a guidance.

If an app is general wellness, MDDS, or limited CDS, it is exempt from FDA regulation.   Let’s consider each category in turn.

On general wellness, the Cures Act excludes from the definition of medical device software that is intended “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.[12]”  While that definition still leaves one with the nebulous concept of interpreting the word “related,” there are lists of examples to help.

One list, maintained by the FDA and more current than the one originally provided in the mobile medical app guidance, identifies about 40 examples grouped into five categories, all of which the FDA says are NOT medical devices (and that assessment will not change in the future).[13]   In addition, the FDA gave another six examples in their general wellness guidance, and those exclusions from the definition of medical device will not change, either.[14]  While reviewing lists may be tedious, it is time well-spent if your apps’ functionality is named and you may confirm your product is not a medical device per FDA guidance.

On MDDS, the Cures Act expanded the FDA’s original MDDS definition[15] by allowing the data source to be broader than just a medical device, and the new rule excludes from the definition of medical device software that is intended “for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and findings.”[16]

Unfortunately, the FDA doesn’t keep updated lists of apps that are or are not MDDS, and this is one of the areas where the current FDA websites and rules need to be updated since everything says that MDDS is a medical device, and that stopped being the case in 2016.  However, there are a few examples that could be reviewed like the “this is not a medical device” list from general wellness as one may assume that anything meeting the definition of MDDS is no longer regulated under the Cures Act.   Those nine or ten examples are in the MDDS guidance[17] and they will not change, but one must remember that they are narrower than today’s rule, as, for example, the data source could be findings from a healthcare professional or general information about such findings.

For CDS, it’s unfortunate that the FDA never issued a guidance, as we are left with only the statutory definition from the Cures Act and a promise from the FDA to issue a guidance on CDS in Q1 of 2018[18].  As a threshold matter, CDS does not include software that handles data from a medical imaging device, an in-vitro diagnostic, or a signal acquisition system.  With that “exception-to-the-exception” set aside, CDS apps will not be considered a medical device if the software is intended for the purpose of “(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines); (ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and (iii) enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.[19]

A few things should be noted about that mouthful of a definition.   First, because of the “and” between the sections, an app must meet all three elements of the CDS definition.  Second, the software has to support or provide recommendations to a health care professional about a patient-level decision, so the intended audience cannot be consumers alone.  The last element, which will likely be the crux of the FDA’s future CDS guidance, is meant to clarify that the software cannot replace the judgment of someone who is licensed to practice medicine.[20]

Group 2-  Maybe a device, but not regulated

Let’s assume that, after initial review, you don’t think your app fits into the general wellness, MDDS, or CDS categories.  Your product might be Group 2, where the FDA has stated that they do not intend to enforce the FDA rules even if the app is a medical device.   While the industry will rely upon that, it’s important to remember that the FDA can change their position since the statement, like any FDA guidance document, is not binding upon the FDA.   A conservative approach would include at least a discussion of whether your company would be comfortable entering the regulated medical device industry, at least with a Class I device (requiring, among other things, compliance with FDA’s quality system regulation[21]).   A less conservative but reasonable approach is to act as though you were in Group 1, relying upon the likely political backlash if the FDA were to announce a reversal of their previous enforcement decision, and that seems very unlikely, at least under current leadership.

As with the first Group, the FDA maintains a helpful list of mobile medical apps where they won’t enforce the rules even if it’s a medical device (FDA uses the phrase “exercise enforcement discretion”), and you may find that your app is like one of the 37 listed as of August 2017.[22]

Groups 3 & 4

I’m putting the last two groups together because they end up being the same- which is that you need to do further analysis to determine whether your app is regulated by the FDA.   Unfortunately, falling into either of these groups means that your app is probably a medical device.

For Group 3, the FDA also maintains a list of mobile medical apps that they intend to regulate.  Except for outdated references to MDDS as a medical device, most of that list is unlikely to change because they are higher-risk situations where, for example, the mobile app directly controls a Class II medical device or allows the hardware platform (e.g., a phone) to do something that the FDA has already classified as a regulated device function (e.g., real-time feedback on the quality of CPR being administered).[23]   If your app is like the 20-or-so listed, you may need to file with the FDA before you go to market.

For Group 4, this means that everything discussed thus far does not address your app, and you are in the grey zone.    Of course, this group also requires more analysis, and the chances are high that, if you reach out to the FDA, they will suggest that your app is a medical device under their jurisdiction.

Conclusion

Assuming that one hopes a mobile app will fall outside of the FDA’s regulations, there are three steps to follow.   First, you need to review the mobile medical app definitions (and lists of examples) to check whether your app is a “general wellness” product, a medical device data system, or a (low-risk) clinical decision support application.  If so, then the app is not a medical device.  Second, if your app doesn’t meet any of those definitions/examples, you may still be ok if your app is among those where the FDA has said they do not intend to enforce the rules, even if the app is a medical device.  Lastly, more analysis is needed for an app that doesn’t find a home in the first two steps, and it’s probably a regulated medical device.


References:

[1] https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366.pdf

[2] http://docs.house.gov/billsthisweek/20161128/CPRT-114-HPRT-RU00-SAHR34.pdf

[3] The same disclaimer has been added to the FDA’s guidance documents on Medical Device Data System (2015): https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM401996.pdf  and General Wellness software (2016): https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM429674.pdf.

[4] Most of the FDA’s Mobile Medical App site is from 2015, but the most recent update of one section was August 9, 2016:  https://www.fda.gov/MedicalDevices/DigitalHealth/MobileMedicalApplications/ucm368744.htm

[5] https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM581664.pdf?elqTrackId=0681E5C32089A1F5C4C2E0F6A0D2B26F&elq=32a7fe86713b4c86aa3af8565f33d596&elqaid=999&elqat=1&elqCampaignId=544

[6] https://www.fda.gov/ucm/groups/fdagov-public/@fdagov-meddev-gen/documents/document/ucm514771.pdf

[7] CDRH must issue a final guidance on cleaning instructions by November 7, 2017 and a draft guidance on CLIA waiver improvements by December 13, 2017.

[8] See page 4 of: https://www.fda.gov/downloads/MedicalDevices/DigitalHealth/UCM568735.pdf

[9] See page 4 of: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366.pdf

[10] https://mddionline.com/when-digital-technology-not-medical-device-us

[11] https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/ClassifyYourDevice/

FDA’s definition of a device is:  “an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is – (1) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them; (2) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or (3) intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.”

[12] See page 258 of http://docs.house.gov/billsthisweek/20161128/CPRT-114-HPRT-RU00-SAHR34.pdf

[13] As of May, 2016, the FDA has 40 examples listed, as opposed to the 37 in the guidance from February of 2015:

https://www.fda.gov/MedicalDevices/DigitalHealth/MobileMedicalApplications/ucm388746.htm

[14] See the last three pages of: https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm429674.pdf

[15] https://www.gpo.gov/fdsys/pkg/CFR-2016-title21-vol8/xml/CFR-2016-title21-vol8-sec880-6310.xml

[16] See page 259: http://docs.house.gov/billsthisweek/20161128/CPRT-114-HPRT-RU00-SAHR34.pdf

[17] See pages 7-8: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM401996.pdf

[18] See Section 1(B) on page 5: https://www.fda.gov/downloads/MedicalDevices/DigitalHealth/UCM568735.pdf

[19]  See pages 259-260: http://docs.house.gov/billsthisweek/20161128/CPRT-114-HPRT-RU00-SAHR34.pdf

[20]  If this CDS element pertains to your product, there is more detail about CDS is my other article:  https://mddionline.com/when-digital-technology-not-medical-device-us

[21] See page 20 and Appendix E of: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366.pdf

[22] https://www.fda.gov/MedicalDevices/DigitalHealth/MobileMedicalApplications/ucm368744.htm

[23] https://www.fda.gov/MedicalDevices/DigitalHealth/MobileMedicalApplications/ucm368743.htm