Software in Medical Devices

Design Service Life

Open, sharable and validated software can be thought of as investment grade software. This means that it has been produced in a way that gives it a very long service life, is reusable and has undergone an extremely rigorous testing regime. The end result is much lower costs over the lifetime of the product.

This is an important benefit in the medical device industry because products often have (manufacturing) service life spans on the order of 6 - 40 years. However, proprietary software generally has a service life of only about 2 - 3 years.

This drives up the cost of product maintenance because it increases the time and labor necessary to make changes. These are a necessary part of any product design because it must continuously adapt to incorporate new features, improve performance, fix bugs and add other enhancements. Many devices have software upgrades on a quarterly basis.

These changes are much more difficult when a proprietary software vendor discontinues a product line or goes out of business. This means that support of the product is discontinued, and so the medical device maker must find new solutions. This is a very long and costly process which should be avoided whenever possible.

Maintenance costs fall dramatically when open and sharable software is used. That’s because all of the source code for the operating system, tools and application are available whenever changes are made. This is especially true in cases when a minor change to the design precipitates large changes to the software V&V. This can happen if a minor bug is fixed after there has been a revision to a proprietary operating system or other component. In this case all of the changes must undergo a new software V&V.

Software Development and Validation Tools

Software development and validation tools are another important aspect in the V&V process. These also need to be validated and archived along with other software source codes. Compiler, synthesis and routing tools are a just a few examples.

Again, the problem here is that most development tools are proprietary, and cannot be openly shared throughout the V&V process.

Special Solutions in Integrated Circuit Software

Integrated circuits pose special problems and solutions when it comes to software V&V. That’s because they are designed with special hardware description languages such as VHDL or Verilog. This means that chips must undergo the same V&V process as any other type of software. However, this creates two very difficult problems: (1) how to handle off-the-shelf chip designs that have not been validated and (2) how to validate the supply (manufacturing) chain.

This problem is magnified because of the high costs and lead-times in integrated circuit design and manufacture. In order to be cost effective, chips for medical devices are usually purchased through established supply (distribution) chains. Unfortunately, chip manufacturing is so expensive that the entire process is spread across many companies and countries. For example, a device might be designed in Texas, fabricated in Taiwan, packaged in Korea, tested in Mainland China and inventoried in Chicago.

Since the design of these devices can be altered at any of these locations it means that each stage in the manufacturing pipeline must be validated as well. For example, if an integrated circuit has a specification for low leakage current (a common requirement in medical devices), then the manufacturers’ test equipment must be calibrated to insure that the requirement is met. This means that each facility that handles the chips must be validated as well. This is an almost impossible undertaking given the audit trail requirements of the regulations.

One attractive solution to this problem is to change the product design so that it uses programmable logic chips. These chips, which are generally called Field Programmable Gate Arrays (FPGAs), can be built and tested anywhere in the world. Once delivered to the medical device manufacturer they are programmed with validated software. This process sidesteps the need to validate the manufacturing facilities.

These procedural changes are needed because of many recent changes in the semiconductor industry. Today the world is awash in information technology. This has been caused by new, lower cost development tools along with a major industry recession during the period of 2001 - 2003. The semiconductor world -- which was traditionally driven by performance and features -- is now driven by cost cutting.

This trend can be seen in a number of ways. Venture capital for semiconductor technologies has tapered off, and the industry has relocated its manufacturing to areas of the world with lower labor costs and less severe environmental regulations.

The Software Verification and Validation (V&V) Process

The software verification and validation process (V&V) is best understood when viewed as an organizational relationship between three parties. As shown in Figure 1 (last month), these include a software acquirer (the ‘buyer’), a development team and a V&V team. This organization is well described in Annex F of IEEE Std 1012-1998: IEEE Standard for Software Verification and Validation.

The organizational process presented in the IEEE standard describes a tightly knit, contractual relationship between the three parties. Unfortunately, it’s also an expensive way to do business because the various parts of the process can’t be broken up into smaller, competitive units.

An Overview of the V&V Process for Medical Devices

The V&V process ensures that software code is complete, correct, maintainable, error free and complies with all required standards. The actual method for doing this is through an inspection process called a code walkthrough.There a set of input, output and testing criteria are defined in a document called the Software V&V Plan (SVVP). The details of the SVVP depend on the end application of the software, and so they are determined on a project-by-project basis. Some applications are more critical than others, and therefore must exhibit a higher level of integrity. For example, a heart defibulator is a life-sustaining device, so the softToday’s 34ware is judged more critically then, say, in an electric toothbrush.

The organization of the various parties in the V&V effort depends on the size and scope of the software project. In large projects each party may have large staffs to accomplish the work, but in small projects they may have only one or two people. However, each process must be done by at least one, unique individual (i.e. one person can’t do more than one job). This prevents bias (or conflict of interest) on the part of any one person, which would diminish the overall quality of the end product.

Together the three parties in the V&V process form a triarchy, or judgment by three rulers. The three parties work together over the course of the entire project with one common goal in mind: to ensure the best possible solution to the problem. However, there are always competing requirements that Combe resolved in software development projects. These can usually be boiled down to cost, performance and time-to-market. The V&V triarchy forms a three-way negotiation process ensures one, best overall solution to the problem.

It should also be noted that only the essential steps of the development V&V process are presented in this article. Actual implementations are much more complex, and may be applied in other ways such as in code maintenance or system integration.

V&V Responsibilities

Each of the parties in the open V&V process has the following responsibilities:

• Acquirer program management. The software acquirer can also be thought of as the buyer. In some cases they may actually be the buyer (i.e. they pay for the development and V&V processes), but in other cases it means that they’re the ones who accept and take ultimate responsibility for the final product.
• Product (software) development. The development team can be thought of as the software seller. In some cases they may actually be the seller (from a financial sense), but in other cases it means that they designed and wrote the software.
• Verification and validation. The V&V team can be thought of as an independent inspector of the final product. In reality, a good product development team also acts as its own inspector, but the V&V team provides an independent ‘second opinion’ for the software acquirer to insure the quality of the final product. The V&V team must operate autonomously from the product development team...from both a financial and a managerial standpoint.
• Secure code storage. The final, validated and verified (V&V) code must be warehoused in a secure environment using industry standard procedures. This usually means that the code is maintained under a revision control system, and is housed and distributed in a secure way to prevent accidental or malicious tampering.

Open Technical Standards

The open V&V marketplace described here uses existing software technical standards and procedures whenever possible. For example, an open V&V operating system marketplace might use the GNU/Linux kernel and operating system components. Similarly, a V&V System- on-Chip (SoC) marketplace might use open software technologies such as WISHBONE or the Open Core Protocol (OCP-IP).

In some cases new, open standards would need to be developed. For example, specific V&V test procedures for various types of medical devices would be created using the principles of established, open standards processes. Combepiler, synthesis and other development tools would need to be validated and provided to the V&V community at-large. Standard practices for secure code distribution would be helpful as well.

Product Liability and Warranty

At first glance it might appear that the open V&V markets described in this article may have special product liability or warrantee problems. However, both of these issues can be handled with practices that are currently used within the industry.

In most cases, the owner of the software application (i.e. the medical device) accepts the risk and ultimate burden of product liability. This is standard industry practice in both the medical device and software industries because software can often be used for a variety of purposes. For example, it would be inherently unfair to burden a toothbrush maker with the risk and cost of heart defibulator software. As a result, the owner of the final application generally owns the product liability as well.

While the owner of the software assumes the risk of product liability, it does not necessarily mean that other parties in the process (development, V&V and code storage) would be immune from all risk. To the contrary, each would be expected to offer warrantees that would fix or replace any software that was found to be defective.

Conclusions

As stated at the outset of this two-part article, an open marketplace for the verification and validation (V&V) of software solves a serious problem for medical device manufacturers. That is, how to create the software, tools and other infrastructure necessary for the manufacture of safe and effective medical devices, while meeting the requirements of government regulators around the world.

The competitive, open marketplaces described here would reduce many of the development costs in new medical devices and technologies. This need is especially critical in the United States, where the demographics of the baby boom means that two tax working taxpayers will soon be supporting every retired person.

These solutions could be initiated with minimal impact on current industry infrastructure. The major pieces already exist; it would mostly be a matter of leadership and logistics to pull the pieces together. This could be readily accomplished using established trade associations, standards organizations and trade press. TMD