Computers, software, and medical devices have become much more complex since I first developed medical device software in the 1980s. Equally important, FDA’s premarket review of software in medical devices has become orders-of-magnitude more rigorous since that time. In 510(k) submissions for devices containing software prepared in the 1980s, the description of the software could consist of a single sentence: The device has software. FDA’s approach to premarket evaluation of medical device software changed in response to the deaths of three patients between 1985 and 1987. They were exposed to lethal doses of radiation caused by software failure of the Therac 25 radiation therapy device. As a result, the software information in a typical 510(k) submission today can easily constitute half of the total submission, if not more.
Starting in 1991, FDA has issued prescriptive guidance describing the key elements its reviewers want to see in a premarket medical device software submission. FDA’s guidance has evolved as its understanding of software and its role in medical devices has grown. The most recent guidance was issued in 2005 and is titled, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices. (It is available from FDA’s web site and is subsequently referred to in this article as the Software Reviewer’s Guide).
FDA’s approach to evaluating software documentation in a premarket submission is proportional to the potential safety risk associated with possible failure of the software, its complexity, and the nature of the device. The Software Reviewer’s Guide provides a method for determining the software’s safety category, and it prescribes the documentation FDA will expect to review based on its safety category: minor, moderate, or major level of concern (LOC).
The fact that the LOC prescribes the software documentation required to support a premarket submission doesn’t mean that all submissions in the same safety category will have the same documentation. Software complexity and architecture also play a role. Since LOC is largely based on intended use, relatively simple devices can have major LOC software while complex devices may have minor LOC software. Supporting documentation in these cases must reflect software complexity within the LOC framework. Moreover, specification methodologies will vary with software architectures and programming languages.
Let’s look at two of the 11 prescribed software documentation categories required for premarket submissions per the Software Reviewer’s Guide. All submissions for moderate and major LOC software must include a software requirements specification (SRS) and software design specification (SDS). The following examples illustrate the impact of device architecture on software documentation in these submissions.
Consider a glucose meter with a single embedded controller whose software performs assays and displays results on a built-in screen. The software documentation provided with this submission would likely include a single SRS and a single SDS.
Now consider an IV pump with one embedded controller that delivers IV fluids and another embedded controller (in the same pump housing) that performs user interface functions. The submission likely would include a single SRS for all of the software in the device and separate SDS documents to describe the software for each controller.
Lastly, consider a vital signs monitoring system with a bedside unit that interfaces with a PC at a nurse station. The bedside unit has one or more embedded controllers for data acquisition and user interface functions. The PC performs alarm functions. The submission could include a single SRS if the bedside unit requires the PC for its clinical utility, but it could include multiple SRS files if the bedside unit can provide standalone clinical utility. It might even make sense to submit separate 510(k)s for the bedside unit and the nurse station PC, especially if the PC can interface with other types of devices.
In a perfect world, assembling software documentation to support a 510(k) submission would be a simple matter of pulling documents from the design history file (DHF). In the real world, the DHF is often inadequate to support a 510(k) submission and software documentation must be created or enhanced accordingly. Creating software documentation that will adequately support a 510(k) submission will yield the additional benefit of improving the DHF.
Certainly, the amount of software documentation required to support 510(k) submissions has increased dramatically over the past decades. Implementing key strategies using critical thinking to identify the level and types of documentation required for the appropriate risk level is key for a focused successful review by FDA and for improved software quality system documentation in the DHF.
Marc Goodman is senior consultant with Noblitt & Rueland. He is a specialist on issues and strategies related to FDA software compliance with emphasis in software verification and validation, software quality assurance, software development procedures, and project planning and management. Goodman has developed software for critical and noncritical medical devices, manufacturing and test software, laboratory information systems, information systems and work-flow control for clinical laboratories, data communications, real-time database access, and many aspects of medical devices since 1982. Since 1975, he has pursued not only software engineering for the medical device and FDA-related industries but also has developed real-time process control and data communications software for the telecommunications, utilities, and aerospace industries. Goodman is a member of the Institute for Electrical and Electronic Engineers (IEEE) and the IEEE Computer Society. He holds a master’s degree in computer science and a bachelor’s in economics from the University of Pittsburgh. For more information about Noblitt & Rueland, view its listing in the Consultants Directory or go to the company’s Web site.