On July 21, 2011 the FDA released its “Draft Guidance for Industry and Food and Drug Administration Staff – Mobile Medical Application.” We have discussed this draft and mobile apps generally here, here, and here. As with all draft guidance documents, following the release of the draft the FDA is supposed to receive and review comments (reported to be about 130), and then issue a revised draft, a final guidance document, withdraw the draft, or do none of these for an extended period, just letting the draft sit. The latter appears to be the fate of many drafts. The two years that this draft has been out probably qualifies as an extended period. However the FDA did tell Congress, and the public, that the guidance would be released by the end of this fiscal year. Outsiders cannot tell if the appropriate FDA people are hard at work on this item, or if they are distracted in part by other issues. The FDA’s claimed devotion to transparency does not include being able to see how such things are progressing.
Once finalized, the guidance document will provide the FDA’s “current thinking” on the subject, but it does not (or should not) officially create any new regulations since new regulations require actual rulemaking. Thus a guidance document is the FDA’s interpretation of the current law and regulations, but is not itself a regulation. In fact guidance documents include the proviso that alternative approaches can be used if they satisfy the requirements of the applicable statues and regulations. Guidances are also easier to change or abandon than regulations, which might meet the concern that mobile apps, and health IT generally, are arenas that are too rapidly changing to have fixed regulations.
During the two-year toddlerhood of the app draft, regulatory uncertainty has been widely cited as a challenge to developers and funders, although at least some developers have self-identified their products as being regulatable medical devices, possibly influenced by the draft guidance, and they have already sought and received appropriate FDA permission to market without waiting for the new guidance. In this regard it should be noted that there is nothing new about medical software being regulated by the FDA, whether that software is part of a device or is the device. Other app developers are either ignorant of FDA regulation, choose to pretend to be, or are actively trying to position their product to support their assertion that it is not subject to regulation.
Since the purpose of FDA regulation is to assure a reasonable level of safety and efficacy, those who claim to be held back by current or pending regulation would seem to want to avoid undertaking the effort to provide such assurance. If this constitutes a regulatory restraint on entrepreneurship, then perhaps that is exactly the objective, i.e., do we really want medical apps that have been developed without adequate regard for whether or not they can fulfill their claimed performance? The excuses of its-only-for-education, or for the amusement of the well, should not continue to allow diagnostic and medical advice apps to be used by the public without proper controls. In this regard the FDA did issue a letter to the developer of one such app saying that it was indeed a medical device and was therefore being improperly marketed because it lacked proper clearance. This letter may indicate increased enforcement generally, or it may be a result of the media attention to the app (and associated hardware) in question. In addition, the marketing material for this device seems to both tout medical applications and then deny them via a disclaimer. Regulatory geeks will be interested in the fact that the letter in question was a “It has come to our attention” letter, rather than a Warning Letter. A come-to-attention letter is a relatively unusual creature. If the FDA was in part forced into addressing this app by media interest, others may see the situation as triggering more FDA attention to apps than they might otherwise desire.
While most interested parties eagerly await a final guidance, more recently there has been a call for the FDA to deliberately delay its release (as opposed to just not getting it done). As cited in a blog by Brian Dolan (here), a coalition of companies urged the FDA in a letter to wait until the FDASIA created inter-agency Health IT workgroup finishes its task to develop a risk-based framework for health IT regulations. (This FDASIA requirement was discussed in these pages here.) The workgroup effort began in April, and there was a call for comments to guide the workgroup in May. Per FDASIA, the anticipated delivery date for the workgroup report is January, 2014. .
While some now call for delays, others call for speedy action. For example the mHealth Regulatory Coalition (MRC) has urged that FDA complete the draft guidance as soon as possible. The MRC notes that in part the guidance will help in determining what will not be regulated which is helpful to those in that space, and it will stem the flow of apps that have reached the market without bothering with regulation, even though they seem to be medical devices under the definition dictated by law and used by the FDA. The guidance might also identify apps that would be Class I, the lowest level in terms of FDA before-market scrutiny. It might be recalled that the FDA previously defined Medical Device Data Systems (MDDS), and then put them in Class I, as discussed here, relieving developers of such systems of a more burdensome route to market.
Regulatory uncertainty is no doubt not a good thing, and multi-year guidance development doesn’t help. On the other hand there should be little sympathy for those that want to churn out apps that purport to give the user reliable medical information, but which have not been subject to any demonstration that they are reliable in doing so. App developers, whether working in their proverbial garage or otherwise, cannot be given a pass on the FDA regulatory framework that applies to other medical software.