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.
I wonder why the FDA has to approve medical SOFTWARE. They aren’t approving every way a practice is run. I’m not saying that software shouldn’t have to be approved, I’m just wondering if it should be by a different organization.
There is a 7/21/11 Federal Register Notice announcing the MMA documents with some additional discussion.
To round out our coverage, please see these posts on the draft guidance:
Brad Thompson’s comments on LinkedIn offers a nice summary.
Shahid Shah looks at the draft rule from a health IT perspective.
And MobiHealthNews has three posts on the draft guidance, an announcement and one story each covering what’s covered and what’s not covered by the draft guidance.
I agree with William’s comment. Why does the FDA moderate these apps? I am really curious to see how mobile apps can affect the performance in health clinics and offices. Are many behavioral health software systems implementing mobile technology to help input data? It seems to me like that could save both time and money for health firms, particularly larger ones. Thoughts?
Another take on the subject can be found at the usually interesting FDA Law Blog from the law firm Hyman, Phelps & McNamara. (That Hyman and I are not related.)
Medical Software, great questions.
Why does FDA regulate software?
The legal definition of a medical device includes, “…a contrivance that is used in the diagnosis and treatment of disease…” (this is an excerpt of the definition) . The key here is the word contrivance, which means, “a thing that is created skillfully and inventively to serve a particular purpose.” Software clearly falls under the definition of a contrivance.
Isn’t FDA attempting to dictate how medical practices are run?
While it might seem so, the FDA is barred from regulating the practice of medicine. This is why physicians can use a drug or medical device “off label” or in a way that is not consistent with the manufacturer’s intended use. How a physician decides to use a medical device is considered to fall under the practice of medicine.
If you mean that by controlling what types of products are available to physicians to use in the practice of medicine, the FDA is indirectly controlling the way medicine is practiced, you are right - and they would whole heartedly agree.
As an aside, the FDA can only regulate medical device manufacturers. Now if a physician creates their own medical device, or modifies an existing medical device, and uses it in clinical practice, they meet the legal definition of a manufacturer and could be subject to enforcement by FDA.
Tim explains correctly above that software that meets the US definition of a medical device is indeed a medical device, and therefore falls under FDA’s umbrella, and in fact their obligation. While is-software-included has been argued at times by definition and on the merits, the FDA has made clear their lack of doubt on this subject, and has routinely classified and regulated “software only” products. Both the MDDS rules and the new mobile medical apps draft reiterate this position (or fact perhaps).
Other countries have improved upon if not ended the discussion by including software explicitly in the medical device definition. For example in the UK/EEC the relevant part of the general definition was “including the software necessary for its proper application EEC a medical device”, perhaps implying that the software in question was part of another device. This was amended to explicitly address software that is not part of (embedded in or an accessory to) another device: ” Standalone software: the definition of a medical device has been changed to state that software intended by its manufacturers to be used specifically for diagnostic and or therapeutic purposes are now regarded as medical devices in their own right”. http://www.mhra.gov.uk/Howweregulate/Devices/RevisionstothemedicaldevicesandAIMDDirectives/index.htm
In Canada, Health Canada has stated that “Software that is intended or represented for use in the diagnosis or treatment of an abnormal physical state of a patient meets the definition of a medical device under the Food and Drugs Act and must therefore comply with the requirements of the Medical Devices Regulations.” http://www.hc-sc.gc.ca/dhp-mps/alt_formats/pdf/md-im/activit/announce-annonce/md_notice_software_im_avis_logicels-eng.pdf
If there is reason to regulate medical devices to protect the public from harm, then software devices must logically be included. A review of software recalls (and “upgrades” ) shows that software is not immune from being dangerous as a result of design errors.
Technology seems to push the way for every innovation but not without it’s own complications.
Also, thanks time “Thanks for mentioning As an aside, the FDA can only regulate medical device manufacturers. Now if a physician creates their own medical device, or modifies an existing medical device, and uses it in clinical practice, they meet the legal definition of a manufacturer and could be subject to enforcement by FDA.”
Insight like this, especially in regard to software, is what will be interesting as technology continues to develop in the future. More-so when it makes or assists in the process of diagnosis.
The FDA has announced a Mobile Apps Public Meeting.
Sept 12-13, 2011
Silver Spring MD
The FDA Law Blog reports that the FTC has also weighed in on medical mobile apps, bringing charges against an acne “treatment” app available at iTunes. The actual claimed treatment was alledgedly achieved by holding the mobile device to the effected area. Perhaps not surprisingly the FTC says the claims made have not been substantiated.
(As previously noted, that Hyman and I are not related.)
The FDA Law Blog has reported on the September 12-13 FDA Mobile Medical Apps public meeting. This includes a discussion of clinical decision support systems.
FDA criticized for loose app regulation.
Here is a discussion of an app Dear Doctor letter:
And here an app recall (for not being cleared in the US)
FDA comments of 3/21/12 re House hearings:
My comments on House hearings at:
It’s amazing to go to see this site and reading the views of all mates regarding this piece
of writing, while I am also eager of getting know-how.