|Home | About | Journals | Submit | Contact Us | Français|
The market success of a medical device depends in large part on how well its software is programmed. Focusing heavily on the device while treating the software as an afterthought can lead to costly recalls and liability concerns.
Medical devices have become a vital part of the global healthcare market, with more than 2,000 premarket notifications, or 510(k)s, approved for marketing in the first three quarters of 2007 (CBER 2007). Of these, 39 are biological devices such as diagnostic assays, rapid tests, and cell separation systems.
The U.S. Food and Drug Administration must ensure a device is safe and effective while determining whether it is either legally equivalent to a previously approved device or represents a new category. Whether applying for a 510(k) or a premarket authorization (PMA), the burden falls on the manufacturer to ensure the entire product suite meets FDA standards. All too often, manufacturers, particularly startups and companies new to software development, focus on the device to be submitted for approval while paying little attention to the accompanying software required for analysis and quality control. This proves to be a costly and time-consuming mistake, as software rework, patching, and even complete rewrites often result.
Given that most medical devices contain software, successful submission of a 510(k) rests heavily on the manufacturer’s ability to demonstrate that the software will perform as required. The FDA’s Center for Devices and Radiological Health (CDRH) has developed guidance to help manufacturers clear this regulatory hurdle, but because of the wide range of devices that fall under CDRH purview, the guidance is necessarily vague (CDRH 2002). This gives a great deal of discretion to a 510(k) reviewer or an onsite auditor in deciding whether the device and software will perform as they should.
Developing a rigorous software development methodology with built-in controls is critical. Software developers often neglect this step and wind up wasting time backfiling the required documentation while introducing errors into their software.
Software production differs from traditional manufacturing in that making exact copies is not a major concern, whereas the quality control process in manufacturing ensures that exact copies of a device are made. This means that a flaw in the initial software results in a flaw in all the devices, rendering standard statistical defect-analysis tools such as Six Sigma ineffective. Software errors reflect the binary nature of computing — either it works or it doesn’t; a degree of conformance does not exist.
Software errors can range from trivial, such as a missing icon in the-menu bar, to fatal, such as massive doses of radiation emitted from improperly implemented software safety interlocks (Leveson 1993).
Since 1997, the FDA has required software validation for all medical devices containing software regardless of device class. From 1992 to 1998, 242 medical device recalls resulted from software problems, representing 7.7 percent of total medical device recalls. According to CDRH, that share climbs each year as more software-related devices are introduced. Although some may view the FDA regulations as a hassle, integrating the process of software validation at the beginning of the development cycle has the potential to save money by identifying and resolving errors at a point where the cost to eliminate them are much lower. Regulatory compliance also can reduce liability and speed the approval process.
The CDRH guidance document states that validation is required for software that is used in the following ways: as a component, part, or accessory of a medical device; as a medical device itself (a program running on a personal computer); in the production of a device, e.g., a controller on a manufacturing line; or in implementation of the manufacturer’s quality system, e.g., software used to create and store device records (CDRH 2002).
The amount of work involved in verification and validation (V&V) efforts may seem daunting, but taking time to plan for V&V will help to ensure realistic delivery dates — always an important step, especially for a start-up — and reduce time to 510(k) approval. It may be helpful to think of the workflow as beginning with the creation of the system requirements specification (SRS) and consisting of three general tasks: development; project management; and V&V (see Figure, next page).
Increasingly, project management tasks are an important part of professional software development, as the FDA and the military require documentation of the V&V tasks as a condition of software acceptance. A well-written SRS provides a solid foundation upon which to base software development. Good software requirements have the following elements: they are written in the language of the user, not of the programmer; they are testable; and they are written to a level of completeness such that they could be given to an independent group to implement. Properly written, the requirements define the intended use of the software.
A technology plan defining specific requirements that are to be implemented –and when – is essential to good V&V documentation.
Everything that happens in development and testing must be rooted in the SRS, and every requirement in the SRS must have source code that implements it. In turn, every line of source code must be present, because the SRS requires it. A technology plan that defines specific requirements to be implemented — and when — is essential to good V&V documentation.
A common source of confusion on projects relates to the difference between requirements and specifications, because the terms are often used interchangeably. Functional definitions might be what the software is supposed to do (requirements) and how the software will be implemented (specifications).
When creating testing plans, validation applies to requirements and verification applies to specifications. In the end, the distinction may not be as important as showing that the software meets its intended use and is safe. But the terms are commonly used, and working definitions are solid mental aids to help determine the goal of a particular test.
To provide the proper degree of V&V, the software developer must identify the level of concern pertaining to the software must be determined. The FDA defines three levels of concern: major, moerate, and minor (Table, p.57).
This level would be assigned if failure of, or a latent flaw in, a device or its software could result in death or serious injury to the patient or operator. Such death or injury could derive not only directly from the device, but also indirectly, such as from delayed or incorrect information given to a clinician.
This level involves a failure or flaw that could directly or indirectly result in minor injury to the patient or operator.
In this case, a failure or flaw would be unlikely to cause any injury to the patient or operator. For example, it may be possible for a patient to swallow a tongue depressor, but the minor probability of such an event does not give the device a higher level of concern.
As device classifications, these do not automatically determine the software level of concern. Consider a robotic surgery device operated remotely by a surgeon. The embedded software that transmits the surgeon’s motions to the device would be of major concern, as the potential for serious harm to the patient is clear. Software on a separate PC that merely logs the time the machine was turned on, the surgeon’s name, and other bookkeeping data would be of minor concern, because even if it fails completely, no harm would come to the patient. The FDA guidance document on software has a straightforward checklist of questions to determine the level of concern for software.
Knowing the level of concern provides the amount of V&V documentation required. Good software engineering practice demands that these tests be performed as matter of course, but results need not be submitted as part of the 510(k).
V&V activities must be taken into account when determining a realistic project schedule. Here is a road-map for determining activities for each of these three areas of concern.
Because validation requirements are an integral part of the software development process for FDA medical device certification, it is to manufacturers’ benefit to account for the time, effort, and expense of V&V at the earliest stage of the product development cycle. Costly software design errors that go undetected at this point can result in product recall, liability issues for the manufacturer, 510(k) rejection by the FDA, and total redesign of products and software. Planning from the beginning stages should also include software and product updates so that the entire process is documentable and scalable for future product iterations.
Proper planning and careful guidance from experienced professionals in product design and approval will limit the total cost of bringing devices to market as well as speeding the overall process and time to revenue realization.
Kevin Stevens and Anthony Johnson report no financial arrangements or affiliations that might constitute a conflict of interest with respect to this article.