Medical Device Validation: How Vendors Can Assist their Customers

The current Good Manufacturing Practices – Quality System Regulation 21 CFR 820 and ANSI/AAMI/ISO 13485:2003 – require medical device manufacturers, contract manufacturers, and specification developers to validate any software used in their devices or in the development or manufacture of a device. Suppliers of instruments or subsystems used by medical device manufacturers can create a market advantage for themselves by directing the validation efforts and assisting their customers with the regulatory requirements.

 

The Challenge

 

Manufacturers that use manufacturing and/or test instruments that rely on software as part of production or the quality system may be required by regulation to validate that software. This may include software embedded as part of the instrument or external software (including off-the-shelf software) that interacts with the instrument. This article relates only to software used by manufacturers in the design, development, manufacture, or control of quality of the device; it does not address software that is embedded in a medical device.

 

Often, little information is available from the manufacturers to assist users in validating the instruments for their intended use. However, installation and operational qualification templates and/or information are readily available from these suppliers. The performance qualification is commonly the responsibility of the end user after successful installation and operational qualifications. This creates an opportunity for system and instrumentation manufacturers to stand out in their competitive markets by assisting their users with their validation needs.

 

Validation costs can easily exceed the purchase cost of the instrument or software. Whatever the suppliers of software-controlled instruments can do to reduce their customers’ cost of validation therefore reduces the overall cost of use of the system. This can be used as a marketing advantage and will eventually become a necessity to stay competitive in the medical device market.

 

Regulatory Background

 

Manufacturers are bound by a specific federal regulation on software found in manufacturing and quality systems. This regulation, found in the Federal Code (21 CFR 820.70(i)) section on medical device production and process controls, states: 

 

“(i) Automated processes. When computers or automated data processing systems are used as part of the production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.” 

 

FDA published General Principles of Software Validation; Final Guidance for Industry and FDA Staff – commonly referred to as the GPSV – in 2002 to expand on FDA’s interpretation of all legislated software validation requirements relation to medical devices.

 

Defining What is Regulated

 

Manufacturers are encouraged – via master validation plan driven by cross-functional policy – to inventory the software used in a production, research, engineering, sales, or service facility. That inventory should include the “intended use” for each software item and delineate whether validation is necessary. If the software item is used to monitor or control part of the manufacturing process, design and development process, or any part of the quality system, it falls within the regulation. This includes software that is used in: 

 

• The design and development of medical devices, such as computer-aided design (CAD) systems, compilers, test software, simulators, or code generators. 
• The manufacture of medical devices, such as embedded machine tool software, machine vision quality control, robotics, or statistical process control software.
• The creation, maintenance, and control of quality data about medical devices, such as complaint handling systems, lot-tracking systems, training systems, quality control (QC) systems, or patient-tracking systems. 
• The creation, maintenance, reporting, validation, and storage of electronic records and electronic signatures.

 

Unregulated software can fall under the requirements of 820.70(i) by its association with other regulated software. A software item normally considered unregulated under these guidelines might produce data that are used by regulated software. The validation requirements of 820.70(i) may then apply to that formerly unregulated software item. The validation requirements in this case could be focused on the functionality of the (formerly unregulated) software item related to the creation, storage, manipulation, and security of that data used by the regulated software.

 

The Customer’s Validation Obligations

 

Manufacturers have certain obligations for validating any applicable software used as part of production or the quality system. It is a popular misconception that validation is synonymous with testing. It is not. Software validation, as described by the GPSV includes many activities in addition to testing. Validation as recommended by FDA’s GPSV includes the following components:

 

• Determination of the software lifecycle 
• Document intended use 
• Risk analysis and risk management 
• Configuration-management and version control 
• Planning Technical evaluations and management reviews 
• Testing Traceability

 

Validation Ideas for Instrument Manufacturers

 

Manufacturers need to plan how the validation guidelines apply to each software item. Since validation is to be proportional to the risk and complexity of the software’s intended use, risk management is needed for all software items. Manufacturers need to address each of the components of validation. However, for embedded software that is acquired from an instrument vendor, the manufacturer has little control over or visibility into the software development process. Validating such software takes some creativity on the part of manufacturers.

 

Make product validation profitable. 

 

Validating manufacturing and quality-system software is burdensome for manufacturers. They typical manufacturer user responsible for validation is not a software engineer, and is not familiar with software validation activities. Vendors of software-controlled instruments might profit by selling validation packages to their manufacturer customers. These packages might include partial validation documentation, training, and/ or consulting with manufacturer users on validating for their intended use.

 

Providing validated or partially validated software can provide real marketing advantages for suppliers of software to the medical device industry. By reducing a manufacturer’s validation overhead in acquiring a piece of software or software-controlled instrumentation, the overall cost of ownership is reduced.

 

Implement design controls and validation practices

 

Instrument manufacturers can alleviate much of their customers’ validation obligation if they document that they have followed good software engineering practices, such as design controls, maintaining the equivalent of a design history file, and providing the components of validation under their control. The details of this are beyond the scope of this article, but are well documented in FDA guidelines.

 

Verification Testing

 

Good software engineering development practices depend on detailed requirements and functional specifications. Verifying the implementation of the software involves testing each requirement in the specifications for its existence and proper function. This testing should be documented in detailed test protocols. The instrument supplier cannot validate for the manufacturer user’s intended use, but it can verify that the software correctly implements the requirements.

 

Encourage audits

 

Instrument manufacturers usually consider detailed requirements, specifications, test protocols and results, evaluations, and review minutes dictated by a controlled design environment to be considered proprietary information. Encourage your manufacturer customers to audit your design process, making the validation and design control documentation available to them for viewing. This will satisfy some of your manufacturer customers’ obligations for validation. Such audits might also fit well with any ISO 9000 or ISO 13485 audits that the manufacturer’s purchasing group may require.

 

Make known defect lists available

 

Even a well tested instrument or software item is likely to have a list of residual defects at release whose resolution was deferred for future releases. After release to the field, the software users might discover additional defects. These defect lists should be made available to users and prospective users so that they can assess the risk of the defect in their intended use environment.

 

Coach your customer

 

Instrument suppliers cannot take full responsibility for the validation of their embedded software used by manufacturers. Only the user of the instrument can define his or her intended use. The risk associated with the instrument’s use will depend on the intended use, so that too must be the responsibility of the manufacturer user.

 

The instrument supplier has experience with the instrument and possibly experience with how manufacturers are using it. Instrument suppliers can coach their manufacturer users in identifying and documenting intended uses. Furthermore, instrument suppliers can leverage their knowledge of instrument failure modes to assist their manufacturer users in risk analysis and in identifying risk-control measures to manage the risk to acceptable levels.

 

Partner with validation experts

 

Manufacturer users of software-driven instruments often are not software professionals and have no experience with software validation. Instrumentation suppliers may not have knowledge of the regulated medical device industry and may not have enough business in the medical device industry to develop in-house expertise. An outsourced validation expert can consult with the instrument supplier on improving internal software development processes to survive customer audits. Additionally, the validation expert can work with customers to assist them in final validation for their intended use. The instrument supplier benefits because validation no longer seems like an obstacle in the acquisition of the instrument.

 

A Case in Point

 

Take, for example, an intelligent motor that communicates with an external computer and is used to control part of the manufacturing process for a medical device. The motor itself has an embedded processor and software that takes electronic commands and converts them to motor movements. 

 

A manufacturer of an implantable medical device wants to use the motors to automate the winding of a coil with a non-constant winding density along the axis of the coil. The winding profile is critical to the correct operation of the medical device into which the coil is embedded.

 

The motor manufacturer should: 

 

• As part of good engineering practice and design control, document product requirements, performance requirements, and limitations; specify the communications protocols between the motor and the external computer; and specify requirements of the software for the onboard microprocessor. 
• Design verification-test protocols for the motor, specifically testing each requirement for the software. Tests should be executed and results formally documented.
• Prepare a known defect list from the results of the verification testing for any defects in the released product. 
• Make all of the above results available to the customer. Proprietary information can be made available in audits. 
• Conduct formal reviews of the design and implementation process and make the results of those proceedings available to customers. Any information that is considered to be proprietary can be provided during onsite audits only.

 

All of the above items may be kept in a design history file that can be reviewed by customers and prospective customers.

 

The medical device manufacturer should:

 

• Identify the intended use of the motor in the coil winding system. The intended use should be specific enough to know what performance requirements are expected of the motor.
• Consider how changes to the software embedded in the motor will be controlled. For example, what happens if a motor with Version 1.0 embedded software fails and is replaced with a new motor with Version 2.0 software? Is there a way to know? Who will be responsible for revalidating the new motor with the new software in the manufacturing system?
• Conduct risk analysis for using the motors in the coil winder. Consider how the motor might fail in a way that the coil will be affected. Assign severity levels to the anticipated coil defects relative to the ultimate safety impact to the patient.
• Provide risk management for the more severe and/or probable risks. Determine how the failure modes could be detected or corrected as part of the overall manufacturing system.
• Conduct validation testing to provide a level of assurance that risky failure modes do not exist, that critical performance specifications can be met, and that any risk-control measures that are identified are in place and reduce the risk to an acceptable level.

 

The above is an abbreviated itemization of tasks for the supplier of a software-controlled motor and the manufacturer user of the instrument. A competitive motor supplier that does not perform the validation tasks suggested above puts additional validation burdens on the manufacturer customer. Conversely, a competitive motor supplier that does perform the validation tasks suggested above and assists with some of the user’s responsibilities by coaching, training, or consulting creates added value and a marketing advantage for its motor.

 

In some cases, the manufacturer may be using an instrument for a non-critical purpose in the manufacturing process, or may be using it in a way in the process that 100% of all product is inspected and verified downstream in the process. In these situations a case can be made for reducing validation requirements. A supplier who can assist the user in this type of analysis and documentation can save the user considerable costs in unnecessary analysis and testing.

 

Summing Up

 

The points discussed in this article are specific to software used in the design or manufacture of medical devices that are used as part of production or the quality system. The main point is that manufacturers are legally obligated to validate any software that is used as part of production or the quality system.

 

Suppliers can aid their manufacturer customers by getting their own software development processes under control and leaving a documented trail of activities (i.e., a design history). Proprietary information does not need to be published; it can be made available in an audit setting. Suppliers, however, cannot do it all for the manufacturers. Only the medical device manufacturer knows the intended use of the software, and the specific requirements they will demand of the software. The device manufacturer is the only one in the position to evaluate the risks associated with the use of the software and to know what controls they may exercise over that risk. A “validation package” is best when it covers activities from both the supplier and medical device manufacturing customer.

 

Suppliers can make it easier and more cost effective for manufacturers to perform validation. Their efforts constitute both a value-added service and a marketing advantage for the supplier. Increasingly, manufacturers will insist that their suppliers take steps that will make life easier for them. An ounce of prevention on the supplier side will save a pound of effort for the manufacturer.