What Matters: April 2008
Should the FDA Expand Regulation of Medical Software?
By Janice Hogan '88
Photo: ©Dreamstime/Juha Tuom.
In recent years, many media reports have indicated that the Food and Drug Administration just can't get it right. Critics have continued to batter the FDA post-Vioxx, criticizing the agency's record on protecting consumers against unsafe products. Part of the current climate is the natural history of the FDA. Over the past 100 years, a series of public health crises have led to the gradual expansion of the FDA's authority, with each crisis producing an increase in the amount of turf the FDA must cover. However, each increase in authority has not necessarily been accompanied by a commensurate increase in budget or staff. In a March 2008 speech, FDA Commissioner Andrew von Eschenbach explained: "This agency is burdened with an enormous portfolio of responsibilities of incredible scale and scope that have been growing over time. . . . Each one of them may be very important, but the process was done without planning, without precision, and without prioritization."1
One of the practical challenges faced by the FDA is when to say no—not just no to a product because of performance issues, but rather no to extending the scope of its regulatory authority. The FDA cannot simply decline to regulate an entire category of drugs, but it does make regular decisions about how far to take the scope of its jurisdiction.
An important recent illustration of this is the FDA's regulation of medical software. Although the FDA regulates many devices that contain software, ranging from ultrasound equipment to implanted defibrillators, the agency's policy on how to handle stand-alone software was in flux for nearly 20 years. The FDA initially articulated a possible approach that would have applied minimal regulation to software that was sufficiently transparent to allow a medical professional to assess and, if necessary, challenge the software's output.2 For example, if a software program merely automated a mathematical calculation that a physician could perform manually, this generally was not subject to significant FDA regulation. While this approach was never formalized in rules or regulations, it offered a practical manner of applying some regulatory flexibility in an era when medical software was rapidly evolving.
In recent years, however, the FDA has moved away from this minimal regulation policy, deciding to take on regulation of an increasing range of software products. In February, the FDA issued a proposal that would regulate any "medical data system." The rule defines this term expansively, encompassing any device that provides one of the following functions: electronic transfer or exchange of medical data, electronic storage and retrieval of medical device data, electronic display of medical device data, and electronic conversion of data from one format to another. "Medical device data" is also defined in sweeping terms as "numerical or other information available from a medical device in a form suitable for processing by computer."3 The new proposal does not address devices that perform diagnostic functions or monitor patients directly; those products are already separately regulated by the FDA. Rather, the broad sweep of the proposal encompasses a wide range of products that, while technically within the FDA's jurisdiction, were relatively unlikely to be actively regulated in the past. While the new proposal applies a relatively low level of regulation to many software products, its net effect will still be to increase the burden on the FDA's already strained resources.
Given the broad range of products that could be implicated by the proposal, is the FDA enlisting a new army of software engineers to contend with the new workload? It does not appear that this is the case. Instead the FDA has once again expanded its scope of regulation without commensurate resources and this time at its own initiative. Although Senators from both parties recently encouraged the FDA to scrutinize the need for a substantial increase in budget and staff, this was focused on needs to meet existing responsibilities, not new ones. Moreover, the commissioner stated in response that it is not clear how much money or staff the agency can immediately absorb.4
Why did the FDA choose to take further action on medical software at this time? In its proposal, the agency describes its rationale as follows: "[W]hen data are being stored, retrieved, transferred, exchanged, or displayed electronically, an additional element of risk is introduced. This element of risk would not be present for a manual transfer of files or information because the information is readily apparent to the healthcare provider. When manual data is converted to electronic form, data can be altered in such a way as to not be transparent to the user and pose a risk to the patient. In effect, even though manual functions have their risks (e.g., illegible handwriting, wrong charts, etc.), when these functions are automated, users tend to rely entirely on the technology because the technology is assumed to alleviate those risks. This is especially true when software systems are designed to interface with a number of unspecified medical devices. Thus, regulatory oversight of MDDS is critical to ensuring that there is an adequate expectation of performance."
Several of the principles underlying this rationale may be challenged and are likely to come under criticism when comments are received from the public in response to the proposal. For example, there appears to be an inherent assumption that only the FDA can or should address medical software systems, ignoring the layers of oversight that apply to these systems today via other means, including hospital purchasing committee reviews, hospital accreditation requirements, and the liability that would result for both hospitals and software manufacturers in the event of inadequate validation and systemic errors.
As an advocate for regulated medical companies, an expansion in the FDA's authority is generally good for my business, but is it good for the public health? In this instance, one can debate whether this extension of FDA regulation to such a broad scope of medical software products is really warranted. However, regardless of the answer, the more relevant question is whether the FDA can take on this task in a meaningful way that advances the public health without additional resources. Even to create a framework for further regulation of software will itself take resources that the agency may not have. For example, the FDA acknowledges in its recent proposal that the level of regulation applied to medical software should be calibrated to the level of risk it presents, but the agency has thus far only specifically addressed a very few categories of software. For a wide array of innovative medical software products, therefore, manufacturers must operate in a vacuum, without any up-front direction on the level of FDA regulation that will be applied. If the FDA cannot, after over two decades of trying, find sufficient resources to articulate comprehensive policies on medical software, then how can it hope to review and monitor the safety of this vast array of products?
Making matters worse, the FDA's regulation of medical software is fragmentary and diffuse, with software products assigned for review according to therapeutic application, as with all the other types of products the agency regulates. This approach fails to recognize the fundamental differences presented by software products and the differing types of expertise needed to review their performance. If the FDA is going to take on this task, then a new direction is needed. The agency and Congress have both recognized in the past that special types of products require specialized agency expertise. For example, five years ago, a specialized office within the FDA was created to regulate in vitro diagnostic tests, and by many measures this appears to have improved the regulation of this product category. Software demands a similar degree of focused expertise. If the FDA is going to tackle the regulation of medical software, ranging from simple transmission of medical data to complex analytical functions, then creation of a separate office with additional staff expert in medical software is urgently needed. The FDA has applied a similar approach to the regulation of other specialized product categories in the past, ranging from radiological products when those were relatively new and more recently to cellular and gene therapies.
Would the FDA be remiss in refraining from further regulation of all but the most high-risk software products? No. The amount of regulatory oversight that can be accomplished effectively with fixed resources is more or less a zero-sum game. Regulatory resources should therefore be allocated to the areas where there is the most need based on risk, as well as sufficient FDA expertise and manpower to afford a meaningful level of FDA regulation. FDA's software experts already have a tremendous number of safety-critical medical devices with on-board software to regulate. Trying to cover more territory in terms of breadth of regulated software products will not necessarily advance the FDA's mission of protecting the public health. However, if exercising some regulatory restraint is no longer a viable option, then further FDA regulation of medical software warrants a dedicated and specialized entity with appropriate resources.
Otherwise, like a weary policeman asked to cover an ever-expanding beat, the FDA must continue on its patrol with no relief in sight.
Notes
1. "FDA in Danger from Lack of Resources," The Gray Sheet, March 31, 2008.
2. Draft Computer Products Policy (1989).
3. 73 Fed. Reg. 7498 (Feb. 8, 2008).
4. Panel's Bipartisan View: FDA is Underfunded. The New York Times, April 16, 2008.
About the Author
Janice Hogan '88 focuses primarily on the representation of medical device, pharmaceutical, and biological product manufacturers before the U.S. Food and Drug Administration. She is a biomedical engineer and focuses on regulatory counseling related to high-technology medical products. Prior to becoming an attorney, she held positions in marketing/marketing research for a major pharmaceutical manufacturer. She is a frequent lecturer at FDA regulatory law symposia and conferences on topics related to premarket approval of medical products, regulation of combination products, and product development. She received two bachelor's degrees at MIT, one in mechanical engineering and the other in humanities and engineering.
What Matters is a guest opinion column written by a different MIT alumnus or alumna. The views expressed are entirely those of the author and do not necessarily represent the views of the Alumni Association or MIT. Interested in writing a column? Email whatmatters@mit.edu.
