Advancing Technologies Put Device Software on the Fast Track

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

Steven Halasey

In the past decade, the medical device industry has witnessed a proliferation of software-controlled products, including everything from handheld diagnostics to radiological treatment devices. Yet the inner workings of these products have remained, for most, a grand mystery. Device software, for all its importance, is still a great black box. And that, according to many analysts, is a major problem.

"It's a well-known phenomenon in the software industry that two years after a product is released, the original developer is generally no longer the person supporting the code," says Nancy George, president of SQM, Inc. (Towson, MD), a software consulting firm. "In the case of medical devices, this can cause serious problems if the system needs to be modified because of a life-threatening failure."

Fortunately, instances of such failures are rare--but they aren't nonexistent. Patients have been killed or severely injured by infusion pumps and radiation therapy units whose software algorithms failed to control dose delivery as they were intended to do. And, according to FDA, many other nonreportable events have occurred in which the software controlling health-related technologies such as blood banks and clinical laboratory equipment failed.

FDA SCRUTINY

To resolve such software-related problems, FDA has begun to place greater emphasis on its reviews of medical device software.

"What's new in software regulation is the fact that FDA is increasing its scrutiny of the software portions of product submissions," says Dennis Rubenacker, a device-software specialist at Noblitt and Rueland (Irvine, CA), a management and software consulting firm. "Ten years ago, a 510(k) submission that included software might have skated through without intense review; but today FDA wants documented proof that the manufacturer conducted a formal requirements review, a hazard analysis, verification and validation, and so on."

However, the agency's policies do not require manufacturers to use the latest software development tools or methods, nor do they specify any particular software development model that must be followed. "FDA is more concerned that whatever process a company has, it should be in control," says Rubenacker. "FDA's philosophy is that the device company should pick a process that fits its culture, and then make certain to control all aspects of that process."

A company may decide to use multiple processes to design software for its products, in keeping with the project at hand; some may be highly sophisticated, while others may be very simple. In any case, the manufacturer should see that it has standard operating procedures for all aspects of its software development process.

The agency is equally open to various methods of documenting software development activities. "There are a variety of approaches to documentation," notes George. "But ultimately, FDA wants companies to document their standard operating procedures for software development, to be able to show design links to good manufacturing practices (GMPs) and to the product submission documents, and to provide documentation for long-term product support. These requirements pose some hard questions for manufacturers, and more specific guidance from FDA would be helpful."

Rubenacker agrees: "There is not a lot more guidance for software now than there was five years ago. The agency's 'Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) Review' is useful, but its latest edition was issued in 1991."

While not a guidance, a glossary of software terminology recently distributed by FDA presents the agency's interpretation of certain standard terms for the first time. In many cases the agency has adopted definitions established by the Institute of Electrical and Electronics Engineers (IEEE) or the National Institute of Standards and Technology, but in some cases the agency's definition is unique. "Device manufacturers should reorient themselves to come into compliance with these interpretations," advises George. "The glossary doesn't change definitions, but formalizes them in a way that had not been done before. The section on validation is especially useful."

Now the agency is preparing to go further, proposing a new risk-based scheme for assessing medical device software and determining what requirements developers should meet. The new scheme is expected to be developed with industry input gathered at a September workshop on device software to be sponsored by the Office of Science and Technology at FDA's Center for Devices and Radiological Health.

The new policy will update the definition of device software to include stand-alone planning and processing software. It is also expected to establish a three-tiered risk-based scheme in which the requirements for approval will be greatest for software that poses the greatest risk to patients or users. Other issues to be addressed by the policy include the clarity of the software algorithm, and whether the software affects only an individual patient (e.g., software for a surgical planning simulator) or an aggregate (e.g., software that controls equipment in a clinical reference laboratory).

All together, FDA's efforts to regulate device software have been a positive contribution to the advancement of the field. "The higher levels of scrutiny haven't been all bad," says Rubenacker. "Lots of companies have gotten their software processes into shape because of that scrutiny, and as a result they are now more efficient in getting their products onto the market. Companies are seeing the real benefits of the process, and they're also making better products."

MATURING INDUSTRY

Even so, software experts disagree about the readiness of the device industry to satisfy FDA's new and evolving requirements. While some companies are still in the starting blocks, needing to select and define their development processes, others are following extremely mature models for creating software.

"I'm not sure that companies are thinking too much about the process they're using," comments Bill Wood, director of product development at RELA, Inc. (Boulder, CO). "If their process works, they tend not to change it. But if a company makes a change in its products, it should also go back and look at its software development process with an eye toward making it as efficient as possible."

"Most device companies have some acceptable level of maturity in their software development process--they have to in order to get a PMA or 510(k) cleared," says Michael Bousquet, director of sales and marketing at Mesa Systems Guild, Inc. (Warwick, RI), an integrated project management, software tools, and consulting firm. "But the desire is to have a more mature, managed, and optimized process, so that each new product can improve upon the last."

A truly mature development process enables a company to select from a variety of methods to match the project at hand, he explains. "Many companies are feeling pressure to apply object-oriented methods and languages. But it takes a lot of effort to apply these evolving methods and tools in order to build good reusable and maintainable models and software objects. That effort doesn't make business sense if the product is embedded code required for a singular application. Instead, what is needed is a clear assessment of the need for reusability, portability, and maintainability prior to selecting a particular development methodology."

But in deciding what development model to use, companies shouldn't automatically throw their old system out the window, cautions Bob Kay, president of Elite Engineering, Inc. (Westlake, CA). "Economics and company culture have a great deal to do with selecting an appropriate software development methodology."

Companies can find themselves in trouble when attempting to change their development process, says Jim Barley, president of Business and Regulatory Consultants (Laguna Niguel, CA). "Often there is no one at the company who has a good grasp of FDA requirements. The company may have too many hands involved in the design process, or may not know how to implement a formal change control program. A company that has an experienced regulatory staff can sometimes come out of this okay, but too often the company tries to tweak its process and ends up making matters worse and even getting into trouble with FDA."

In some instances, the trouble comes from attempting to solve systemic problems by using more-sophisticated development tools. "Many companies seeking to solve their software engineering problems have invested heavily in more tools," says Bousquet. "But usually the root of a problem is in the engineering process, which needs to be evaluated and improved."

Companies need to avoid the trap of selecting a development process that doesn't lend itself to the tools they have, or of buying tools that don't integrate well into their existing process. These can be difficult problems because of the complex nature of the development tools that are now becoming available.

"Although industry has come a long way in the past few years, there is still a long way to go before the new tools will be standardized," says Rubenacker.

"The technology is improving," agrees Kay, "but we are still building on software platforms that are not fully understood, and there are some basic problems in software development that have still not been solved."

Recent advances in software development have included efforts to make wider use of existing methods as well as unique combinations of methods. Rubenacker notes that several companies have attempted to use graphical user interfaces, but usually not as device control software. "There have also been some attempts to create hybrids that combine object-oriented programming with other types of programming, in order to match the development culture of the company. But in medical devices, embedded software systems are typically not yet using object-oriented programming."

The most difficult problems arise because of the growing complexity of the devices themselves, says Kay. "No single person can now understand such systems well enough to track the systemic impact of making changes on a subsystem. Understanding even a simple handheld analyzer now requires the expertise of a chemist, a software engineer, and a process engineer. To make matters worse, there are no integrated tools to help perform software analysis or to carry out verification and validation."

Companies whose products encounter problems in the field can find themselves in a difficult situation. "In the short term, these companies are simply looking for a fix that will get their products back onto the market, but in the long term they need a solution that will enable the company to restructure its development process so that it consistently meets FDA requirements," says Barley.

MIL-SPEC AND BEYOND

Despite FDA's overpowering influence on the U.S. device industry, in the area of software development the agency has generally taken a back seat to others. Many of its current and projected software requirements are based on standards and processes that originated in the defense and aerospace industries, and many others have been developed by national and international standards-writing bodies.

"The key elements of FDA's design control requirements are no different from those in the defense industry," says George Brower, deputy director at Analex Corp. (Littleton, CO), an independent verification and validation consulting firm. "The only difference is that FDA doesn't use a standard format like the Pentagon uses."

The similarities among the software standards for defense contracts and medical devices have invited more than a few comparisons between the two industries. In the aftermath of budget cutbacks that reduced or eliminated many military contracts, Defense Department vendors have been eager to ride the wave of technology transfer into the device industry. Some of what they've encountered has not met their expectations.

"In the device industry, testing is generally not as rigorous as in the defense industry," notes Brower. "Often device software is tested without the system in mind, rather than as a part of a whole system. Device companies also tend to be weak in testing the backup modes and failure conditions related to their devices."

To some, however, such differences have been advantageous. "Rigid military and aerospace approaches to medical device software haven't been very influential or successful so far," says Rubenacker. "In part, this is because FDA recognizes that medical device companies come in many sizes with many cultures, and that such a rigid approach might unnecessarily restrict them.

"Instead, FDA has for years adopted a flexible approach: its guidances are voluntary, its templates are regarded as merely examples, and it acknowledges standards compiled by IEEE and ANSI [American National Standards Institute] that are appropriate for the field. In some ways, in fact, IEEE and ANSI have had more of an impact on device software development than have the military or aerospace industries."

How long the device industry will enjoy such an advantage, however, is doubtful. "Device software technology is changing and becoming increasingly complex," says George. "As a result, a systems engineering approach is increasingly the method of choice. FDA is encouraging companies to take such an approach when appropriate, and standards in this area are being developed even at the international level."

Thus U.S. device companies may also face the challenge of meeting software standards for the international market. To make this simpler, FDA's stated policy is to harmonize its requirements with similar international standards such as ISO 9001-3, the software quality standard compiled by the International Organization for Standardization (ISO).

"At present there is still a gap between FDA's expectations and the requirements of ISO 9001-3, but that gap is narrowing," says George. "ISO 9001-3 is a voluntary standard and device companies approve of the latitude that it gives them."

Barley advises clients that expect to do business in international markets to make full use of the ISO certification process. "ISO certification requires a lot of time and paperwork. If a company is getting ISO certified, they should also make a point of using only ISO-certified vendors for their raw materials and components."

Wherever standards have originated, device software developers are now in the process of making them their own. "In the past, the most sophisticated processes--those with the greatest rigor and traceability--originated in the mission-critical military, aerospace, and defense sectors," says Mesa's Bousquet. "But now, many device companies are starting to realize that engineering process rigor can solve and even prevent lots of problems in complex software development projects."

LIABILITY DRIVES IMPROVEMENTS

One problem that is driving many of the improvements in the device software development process is product liability. In the past, device companies were sometimes satisfied with quick-and-dirty software development processes that enabled them to rapidly produce a prototype for testing, but those days are gone. "As recently as three years ago a company could have avoided performing software verification and validation because FDA's requirements weren't set in stone," says Barley. "But now, the expectations have been pretty well defined. Companies should know that the agency expects them to perform software V&V."

Kay goes a step further. "There's no question that FDA expects software design houses to implement design control, so nonperformance is not an option," he says. "Performance of design verification and validation is an automatic requirement of all our contracts."

The disadvantage of such a requirement is that it increases companies' upfront development costs. But software experts agree that more work in the early stages of development pays off in the long run. "The costs associated with repairing a released software defect are exponentially greater than the costs of designing the software right the first time," says Bousquet. "The financial liability involved in cutting corners is just too great; with some of these systems, lives are at stake."

In the future, it may become even more critical that companies meet FDA requirements to the letter. The device industry is now awaiting the Supreme Court's decision in the case of Medtronic v. Lohr, which could determine whether FDA approval can be used as part of a legal defense against charges of negligence or lack of oversight. If that defense is upheld, failure to meet FDA requirements could by implication open firms up to even greater product liability.

To address all of these issues, software experts uniformly advise that companies follow best-practice guidelines in their development processes. "Companies should conduct criticality analyses for their own design processes, and should also see that their software vendors do the same," says Brower. "The device company should know and be prepared to show that its software vendor has an adequate software development process. Off-the-shelf software is available to assist in this task."

TECHNOLOGICAL ADVANCES

Over the past decade, advances in microelectronics have enabled designers to dramatically reduce the size of many medical devices. Meanwhile, new software technologies have made it possible for these ever-smaller hardware packages to perform a greater variety of tasks than ever before.

Market pressures have a lot to do with the character of a medical device and its software. Many companies have begun to experience a shrinking market share as a result of the pressures of managed care. In response, some have turned to software as an inexpensive way to enhance product performance and thereby recapture their market. At the same time, says Kay, "investors like bells and whistles. They perceive high value in the ability of a device to perform multiple tasks."

"The direction of technological advance is toward greater sophistication in finished devices, with software as the driver that enables a device's capabilities to be expanded," agrees Brower. "New generations of software are bringing new flexibility--but with this flexibility comes responsibility.

"People need to be reined in, kept within the established specs of the project," he adds. "Software developers are prone to add more bells and whistles, to say 'for just a little more money we can add such-and-such feature.' But some enhancements shouldn't be made."

The next wave of advances could make matters even more complicated for software developers. "The next big area of emphasis will be in information sharing," predicts Noblitt & Rueland's Rubenacker. "In the near future, virtually every device that uses software will also include some kind of communications capacity."

Driven in part by the emergence of unified data collection systems--a result of ongoing consolidation among health-care organizations--many designers are now looking at devices not as stand-alone units, but as parts of a much larger system. Even many simple devices are now being set up for data collection and integration into a larger system. Moreover, these communications hookups are not exclusively one-sided; some devices are also being set up for both uni- and bidirectional communications.

"Connectivity is definitely happening," agrees RELA's Wood, "but that also means that localized software problems now have the potential for becoming systemwide problems. A small problem that starts in one place will be able to migrate throughout an entire network, and pretty soon a whole health-care organization will find itself in big trouble."

One factor that's sure to cause headaches for software developers is the absence of communications standards for use in such health-care data collection systems. "Without universally accepted standards, it will be difficult to get medical devices from different manufacturers to communicate without incident," says George. "Even simple communications can become complex."

The multiplicity of languages currently in use for device software is one of the major culprits causing such communications problems. Nevertheless, even more languages are being pressed into use, and in some cases a single device may use more than one. Wood cites the example of a hemodialysis device in which Visual Basic (VB) was used to create the user interface, while the device drivers were written in C++. Like object-oriented programming, VB uses onscreen icons and metaphors to simplify user operations. "VB is often used as a prototyping language because it can draw quickly on a visual tool set and offers fast user feedback," he notes. "And those same features make it a good choice as the driver for a user interface." Wood believes that the increasing variety of programming languages being used in medical devices obliges companies to have a staff of programmers with multilingual capabilities.

George notes that the digital imaging and communication in medicine standard (DICOM) being developed by the American College of Radiology and the National Electrical Manufacturers Association is a positive step toward resolving such compatibility problems. When a DICOM transmission gets to the receiving end, the system is designed to automatically answer concerns about the quality of the data. However, she adds, "the DICOM standard introduces some compatibility and testing problems of its own."

Whichever solution is to be adopted, it is clear that it will have to be done soon. "Telemedicine is rapidly approaching," says Rubenacker. "And manufacturers who want to capture a share of that market are eager to get on with developing their products. Communications problems represent a stumbling block that can't be allowed to exist for too much longer."

CONCLUSION

With a new FDA policy on the way, device manufacturers may soon have more information about how best to respond to FDA requirements. But other trends in the marketplace will continue to make software development a complex activity. According to industry experts, companies should seek to match their software development process to the risk associated with the project, and this matching should involve consideration of user and patient risk as well as business risk. New technologies don't automatically require high-level software development processes.

Although companies should seek to do only the minimal amount of documentation necessary, they should write a quality plan and audit their development process according to it. That is also what FDA will do, and companies should be prepared to show the agency their software development plan and to demonstrate that they have followed it.

Steven Halasey is executive editor of MD&DI.