We’ve previously blogged about the “FDASIA Workgroup” and section 618 of the Food and Drug Administration Safety and Innovation Act (FDASIA), which directed FDA to issue a report to Congress by January of 2014 on the regulation of health technology.  This post covers some of the differing views on Health IT regulatory issues and open questions that FDA might address in its report.

To recap, section 618 required FDA submit a report to Congress recommending a “risk-based regulatory framework pertaining to health information technology, including mobile medical applications.”  Section 618 also directed FDA to create a diverse working group of Health IT experts to assist it in this task.  That group held its final meeting in August and provided a set of recommendations to FDA.  Then, on September 23rd, FDA released a final version of its guidance document on mobile medical applications.  (See our post here.)  A few weeks ago, Rep. Marsha Blackburn (R-TN) introduced the Sensible Oversight for Technology which Advances Regulatory Efficiency (“SOFTWARE”) Act, which was co-sponsored by a bi-partisan group of lawmakers.  (See our post here.)

Despite some common threads, the FDASIA Workgroup report, the final mobile medical apps guidance, and the SOFTWARE Act offer three different approaches to the regulation of Health IT.  These differing approaches also provide possible insight into the issues FDA may address in its upcoming report to Congress.  Below we outline some of the areas of common ground in these positions and key open questions that FDA may cover.

Common  Ground.  A common element of the FDASIA Workgroup recommendations, FDA’s guidance document, and the SOFTWARE Act is the need for a risk-based approach to regulating Health IT products.  It seems reasonable to assume, then, that a risk-based approach will be a key element of FDA’s recommended regulatory framework.  Consistent with the basic framework of the mobile medical apps guidance document, and the agency’s historical policy to not regulate all software products that meet the definition of medical device, FDA likely will recommend that it regulate only a subset of Health IT products that meet the definition of a medical device.  Indeed, this has been FDA’s basic approach to software regulation since its “FDA Policy for the Regulation of Computer Products 11/13/89 (Draft).”  That document, withdrawn in 2005, proposed to exempt certain types of software from regulation, including those products that performed “library” functions or were intended to involve competent human intervention before any impact on human health occurs.

Key Open Questions.  Despite the general consensus that FDA should apply a risk-based approach to Health IT regulation, key open questions remain about specific aspects of that regulatory framework.

  • How Should FDA Regulate Clinical Decision Support Software?  One of the least settled issues in Health IT is how clinical decision support (CDS) software is (or should be) regulated by FDA.  FDA’s mobile medical apps guidance stated expressly that it does not address “software that performs patient-specific analysis to aid or support clinical decision-making.”  The guidance went on, however, to address apps that analyze patient-specific information, stating that some of these apps should be regulated as devices.  FDA also has stated in the past that it intends to release a guidance document addressing its approach to regulating CDS software.  The FDASIA Workgroup noted that FDA’s regulation of CDS software was a key area of ambiguity and recommended that only certain high-risk CDS software be subject to premarket review.  The SOFTWARE Act proposes to largely remove CDS software from FDA’s regulation.
  • How Should FDA Address Software as a Device Accessory?  The FDASIA Workgroup observed that the regulation of software as an accessory to other devices remains an area in need of FDA clarification.  In the draft version of the mobile medical apps guidance, FDA itself noted that the traditional accessory approach — in which an accessory is regulated in the same manner as its parent device — “may not be well-suited for mobile medical apps that serve as an accessory to another medical device because of the wide variety of functions mobile medical apps can potentially perform.”  The SOFTWARE Act creates a new category of “medical software” that it removes from the definition of a “device” but states will be regulated in the same manner as devices.  The bill carves out from this definition software “whose primary purpose is integral to the functioning of a drug or device” or software that is a “component of a device;” such software presumably would continue to be regulated as part of the “parent” device or drug product.
  • Does FDA Need More Expertise?   The FDASIA Workgroup recommended that “[a]dditional funding might be needed to appropriately staff and build FDA expertise in Health IT and mobile medical apps.”  Last year, Representative Mike Honda introduced the Health Care Innovation and Marketplace Technologies Act of 2012, which would create an Office of Wireless Health Technology within FDA.  Will FDA ask Congress for more resources to build greater Health IT expertise?

In sum, the report could offer a valuable insight into FDA’s current thinking on these topics, and might influence future Congressional action.  The report is due to Congress by January 9, 2014.