Since 1989, the use of computer-based products and software-based products as medical devices has grown exponentially. In addition, device interconnectivity and complexity have grown in ways that could not have been predicted in 1989. This growth and expansion have created new considerations for elements of risk that did not previously exist. FDA realized that the Draft Software Policy was not adequate to address all of the issues related to the regulation of computer based and software-based medical devices. Based on this history and the complexity and diversity of computer software, FDA decided it would be impractical to prepare one ‘‘software’’ or ‘‘computer’’ policy that would be able to address all the issues related to the regulation of computer- and software based medical devices.
While FDA has proposed the MDDS category, as of this writing the agency has not adopted it in final form. During the interim, however, it seems to be the best guidance available for deciding whether a premarket clearance is required.
Dividing Line Between Software Requiring Premarket Notification And Not
In defining medical device data systems, FDA was merely trying to define one relatively narrow, cohesive type of data set that the agency would regulate but exempt from premarket notification. However, that is only one example, and it is not meant in any way to be the only example of software that would be treated as regulated but exempt. Indeed my understanding is that the agency plans to publish future proposals defining other regulated – exempt and nonexempt– categories.
But what are software companies supposed to do in the meantime? What else fits within this regulated but exempt category? The unfortunate answer is that this represents a huge gray area. The best anyone can do is look at a variety of risk factors to figure out which side of the premarket clearance line again a piece of software falls. Based on FDA comments and actions over the last 20 years, I would propose the following list of factors be considered.
Whether the software is intended or designed to provide any real time, active, or online patient monitoring functions.
The capability to display, create, or detect alarm conditions, or actually sound an alarm, or the capability to create alarms that are not already present from the connected medical devices.
The seriousness of the particular disease or condition which the medical software device is intended to diagnose, cure, mitigate, treat or prevent and how the software contributes to the user’s decision-making for diagnosis or clinical management of the patient. Example: Is it software designed to call attention to imminent hazard conditions or is it software that provides long-term storage for diagnostic information?
The amount of time available before using the information provided by the medical software device, i.e., the time until a therapeutic or additional diagnostic intervention must be implemented by the health care provider after the results of the software have been provided. Example: Is the device an EKG reading and analysis package whose output is “SHOCK NOW” or does it provide a proposed reading with notation that the rhythm itself should be checked?
Whether the data output is provided or manipulated in a novel or non-traditional manner, or whether decision trees within the software depart from customary use. Example: Do the system’s algorithms, parameters, internal decision trees, or other output manipulations depart from customary use or traditional data presentation?
Navigation: ( ←Previous | 1 2 3 4 5 6 7 | Next→ )