Putting a rubber stamp on the SOFTWARE Act


The House Energy and Commerce Subcommittee on Health is scheduled to hold a hearing today "examining federal regulation of mobile medical apps and other health software." In a Nov. 15 memo to subcommittee members, the majority committee staff explained that the hearing will focus on the FDA's recently released final guidance on mobile medical apps and the SOFTWARE Act, a bill that was introduced late last month by Rep. Marsha Blackburn (R-Tenn.) to amend the Federal Food, Drug, and Cosmetic Act and to limit the regulatory agency's authority.

"Prior to FDA releasing the final guidance announcement in September, some patient advocates and experts in the field of emerging technologies raised concerns with FDA's decision to regulate software technologies as medical devices," states the committee memo. "The [SOFTWARE Act] bill would create regulatory certainty by giving FDA a new tool to regulate some forms of these emerging technologies without regulating them as medical devices."

Towards that end, the bill establishes three categories of software--clinical, health and medical--with the two former software types not subject to regulation under the proposed legislation. In an earlier editorial, I railed against the SOFTWARE Act, arguing that this proposed legislation should be allowed to die in committee. I continue to stand by my assessment that the bill's language is majorly flawed and potentially counterproductive to the FDA's "tailored approach" which seeks to apply its regulatory oversight to only those mobile apps that are medical devices whose functionality is of a kind that FDA already regulates and that present a greater risk to patients if they do not work as intended.

Clearly, the agency's final guidance states that it does not want to impose a heavy regulatory burden on mHealth developers. Still, the FDA's document does not address software that performs "patient-specific analysis to aid or support clinical decision-making." Because the FDA provides no clarification on what types of apps would be viewed as clinical decision support software, this software category (software to aid a healthcare practitioner or patient in making a decision) remains a gray area. 

Nevertheless, at a September 23 media briefing announcing the FDA's final guidance, Jeffrey Shuren, M.D., director of the agency's Center for Devices and Radiological Health, stated that clinical decision support software will be addressed separately in a congressionally-required plan. This risk-based regulatory framework for health IT, which includes mobile medical apps, is near completion. Currently, the FDA is working with the FCC and Office of the National Coordinator for Health IT to provide the FDASIA-mandated report to Congress by January 2014. 

Given that this report on a risk-based regulatory framework for health IT is just weeks away, why wouldn't House members wait to see the plan? The reason is that lawmakers are eager to get the SOFTWARE Act on the legislative agenda. That's why industry witnesses have been hand-picked for today's hearing who will testify in support of the SOFTWARE Act and urge Congress to pass the proposed legislation. 

These witnesses will also make the case that what is needed is a new risk-based regulatory framework for "clinical" and "health" software, for which the existing FDA regulatory framework is not well suited. In that context, today's hearing is meant to merely serve as a rubber stamp for the SOFTWARE Act's cheerleaders. - Greg (@Slabodkin)

Suggested Articles

The newly launched Center for Connected Health will be largest telehealth hub in the Philadelphia region, according to Penn Medicine.

The FDA commissioner wants to use additional funding under Trump's budget to advance digital health initiatives and integrate real-world data.

The FDA's approval of an app that uses AI to notify specialists of a potential stroke offers new possibilities for triage software that uses CDS.