In September 2013, the Food and Drug Administration (FDA) issued final guidance regarding its regulation of mobile device medical apps. As expected, it reserved its scrutiny for apps that are truly “medical devices” (because they diagnose or treat ailments, or alter the human body in some fashion), and then only if they could pose a safety risk if they were to malfunction. This limited approach was generally seen as a continuation of its largely “hands-off” policy concerning medical apps, and a concession not only to congressional pressure to avoid over-regulation, but the practical realities of attempting to regulate a rapidly growing category of more than 20,000 apps.
The FDA’s lengthy and detailed guidance was widely considered thoughtful and reasonable. A contingent of congressional representatives, however, apparently thought it insufficiently permanent. In late October, a group of three Republicans and three Democrats introduced the “Sensible Oversight For Technology Which Advances Regulatory Efficiency Act” (or, inevitably, “SOFTWARE”). The bill, H.R. 3303, appears to enshrine the FDA’s guidance in statute, presumably to foreclose the possibility that the agency might reverse course or create exceptions in the future.
SOFTWARE creates three categories of medical apps. “Medical software” encompasses apps that fit the existing definition of medical devices, over which the FDA would have continued purview. “Clinical software,” meaning technology used only by healthcare providers to analyze patient information, would be exempt from FDA oversight. So would “health software,” referring to technology that analyzes patient data outside the delivery of healthcare – such as calorie counters and the like. The goal, said the bill’s supporters, is to focus the FDA’s efforts “onto products that pose a potential risk to human health.”
In that regard, the bill more or less duplicates the FDA’s guidance. But it is the novel aspects of the bill that could prove most problematic. Specifically, SOFTWARE seems to create a competing regulatory regime for clinical software, in particular. Not only does it seek to establish “a risk-based regulatory framework for such clinical software” (which the FDA is already working to create), it seems to envision a new regulator to enforce it. Thus, whatever difficulties of FDA regulation SOFTWARE might remove for clinical software makers, it will likely replace them with the vagaries of an unknown agency, whose purview – in general and relative to the FDA – remains to be defined.