As medical applications for mobile devices have proliferated,  regulatory questions have proliferated nearly as fast, at least in some quarters. The key questions are what kinds of apps are medical devices, and among those, which will the FDA focus on for regulatory action.  To date these apps range from home use  adviser's, guides and "toys", which may or may not have real health care implications, to serious medical devices which have clear health care functions, despite in at least some cases, pretending they do not really, perhaps in an attempt to avoid the FDA.

On July 19, 2011 the FDA announced its proposed official action in this regard, including defining "mobile medical applications"  that are the subject of this action. (I will use the acronym MMA, although the FDA did not.) . This includes a new FDA web page for mobile apps (here), with links to a new Draft Guidance, information for consumers, and a press release. This action by the FDA has a parallel to the recent final rule on Medical Device Data Systems (MDDS), discussed by Tim here, which also addressed what is it, what is it not, and how that which is will be regulated.

The Draft Guidance, dated July 21, 2011, defines an MMA as a "software application that can be executed (run) on a mobile platform, or a web-based software application that is tailored to a mobile platform but is executed on a server", where that software already meets the general definition of a medical device as found in 210(h)of the FD&C act. In brief, the relevant part of this definition is that a medical device is used in the diagnosis, treatment, cure, mitigation or prevention of disease.  If there was any prior doubt, this again establishes that software that is intended to do any of those things is a medical device, even in this case  if downloaded from the app store, and run on a smart phone. Intent here can  be a key issue in that general purpose software that might be used for a medical application is in general not regulated as a medical device, unless the software manufacturer promotes such applications. This guidance does not specifically address wireless safety considerations, classification and submission requirements related to clinical decision support software (once called expert systems), or the direct application of quality systems to software, all challenging issues.

That software can be a regulated medical device has been asserted by the FDA on a number of occasions, and they note in this guidance multiple examples of medical device software that has already been defined and classified. The FDA's justification for doing this is also familiar; besides its congressional mandate, the FDA notes that "As is the case with traditional medical devices, mobile medical apps can pose potential risks to public health". However the FDA makes clear here that the mobile device itself (the mobile platform) is not considered to be a medical device, even if it is running an MMA - unless the seller of the platform makes a corresponding claim for its medical use.

Among all mobile apps, the FDA in this guidance has defined the MMA subset that is the subject of the guidance. However we are reminded that other mobile apps may still be medical devices, and therefore potentially subject to regulation, but under the FDA's "enforcement  discretion" they will not be actively regulated at this time. However manufacturers of even these devices are invited to register and list with the FDA, and it is suggested that they follow the FDA's Quality Systems Regulations, even if they don't register at this time. Enforcement discretion is one of my favorite regulatory categories because that discretion can end at any time, and that which was previously not being actively regulated can easily become actively regulated. A no doubt bad automotive analogy here is to the long alleged grace speed overage before being subject to a speeding ticket.  However true or not true this is, a ticket can still be issued for speeds over the limit but under the rumored true limit.

The guidance goes on to define the scope of regulated apps (MMA) , and who is a MMA manufacturer. I will not repeat this information here, except to note that the download store distributors, like the platform makers,  are defined as not being manufacturers. Further, it is the creator of the software concept and its specifications, not the code writer  who is on the regulatory hook. Good news for programmers who aren't the originator of the device. Time here for some perhaps artificial humility in the form of, "Hey, I just wrote the code to make the software do what they said it should do." Also of particular interest to some, devices that create alarms are expressly addressed as being included. This is consistent with the FDA's attention to alarm issues, which will be the subject of a forthcoming multi-sponsored Alarms Summit.

The appropriate FDA classification for MMAs will vary depending on the actual intended use. Thus, there is no reclassification here as there was in the MDDS final rule.

This FDA action can be viewed as one of several efforts in which the FDA must address rapidly evolving technologies, and systems of technologies, that in some cases have been deployed ahead of the FDA's ability to deal with them under existing regulatory frameworks. Or as perhaps in this case, where developers have charged ahead with product introductions with disregard for medical device regulatory requirements, either from not knowing these regulations, or intentionally ignoring them.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.