Design Control Measures That Can Boost Return on Investment

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

An MD&DI May 1998 Column

DESIGN CONTROL

Carefully implemented design control procedures can improve a company's profitability as well as the quality of its devices.

Complying with ISO 13485 and the design control section of the quality system regulation (QSR) is part of doing business for many medical device manufacturers. Some manufacturers view compliance as nothing more than overhead, adding little value to the quality of finished devices. Others realize that thoughtful design control measures represent a good investment that can increase a company's value. In fact, many products involving software fail due to a lack of carefully implemented design control measures.¹ By studying design control compliance requirements, manufacturers can make those investments that will get the right device to the right market at the right time. One goal in implementing design control is to understand which measures represent wise business investments.

MEASURING SUCCESS

Safety is the primary driver for the new QSR. Reducing the number of accidents and deaths attributable to medical devices is one of the regulation's goals. Fewer recalls, defects, and service calls are measured by the number of complaints received, warning letters issued, and FDA-483s received and are quantitative measures of success. Lowering these numbers translates directly into cost savings during the operational and maintenance phases of the device life cycle. These measures of success are objectives of any design control implementation.

But manufacturers also measure success based on the answers to the following questions. What is the return on investment for factors that contribute to design control compliance? Do the decrease in time to market, smaller number of defects, and greater number of satisfied customers justify the investments required? What aspects of a design control solution result in the biggest return on investment? What risks are associated with ignoring such investments? The answers to these questions will vary among companies based on the competitive marketplace, company culture, regulatory environment, technological advances, and previous company investments. However, some design control solutions can increase the chances of success, while ignoring others will result in increased overhead.

Design control implementation involves commitments to processes, methods, and tools. Decisions regarding these commitments influence the success of the product development team. Success from a project management perspective involves cost and scheduling. Over the device's life cycle, however, success is intimately related to device quality, which is reflected in the measures already mentioned. Successful design control investments improve device quality, streamline project management, and increase the company's profitability.

Communication, traceability, and change history are important in design control, and problems can arise if they are ignored or casually implemented. Transition, flexibility, processes, methods and tools, and industry requirements also contribute to the ultimate success or failure of the design control process.

COMMUNICATION

Designing and developing any medical device is a highly iterative and creative process involving many people. Change is the one thing that is certain. The volatility of design inputs, device architectures, and component design affects verification and validation plans. Design changes, review information, document alterations, and corrective-action observations must all be effectively communicated among members of the development team, as well as with professionals from marketing, R&D, testing, manufacturing, and regulatory and quality systems. Keeping all team members up-to-date with the latest changes can be a challenge when teams are geographically dispersed, involve outside suppliers, or are composed of employees from several merged companies. Dynamic forms of communication permit teams to work in an interactive way. For example, a design control solution that allows true multiuser access to electronic documents would support a concurrent engineering environment. Adding the capability to quickly communicate change within the team increases productivity and allows the device to be designed correctly the first time, reducing the time to market. Such capabilities are facilitated by a network-based information system that has the flexibility to support engineers (e.g., using UNIX machines), as well as all other aspects of the design, such as formal reviews and management (e.g., using PCs).

Proven design control techniques and tools have been developed to support such communications via a networked-based information system.While a stand-alone system initially may cost less, it will become more expensive over time because of the processes and tool work-arounds that will have to be established. Manufacturers also should be careful not to develop an overly prescriptive communications process that forces the development team to "check off boxes," which stifles creativity and adds no engineering value. Stringent work-flow processes should be added with caution and perhaps only at critical junctures.

What and how effectively information is communicated throughout the life of a device is important to the bottom line, as well as to successful design control processes. Traceability enables dissemination of the right information to the right people at the right time.

TRACEABILITY

Traceability establishes relationships among design and project management documentation elements. Creating such associations (or links) permits efficient change-impact analyses throughout the device's life cycle. This becomes increasingly more important as the device and the processes used to develop it become more complex. Complexity can arise from the device's intended use, project and hazards risks, technology advances, operational environment, business relationships, and the marketplace. Traceability saves time and money the longer a project continues, the more people and organizations are involved, the more challenging the manufacturing, the longer the expected operational life of the device, and the more complex the device's human-computer interface.

Traceability adds value during the design and manufacturing process because it contributes to controlling and understanding change. With 40% of the expected annual economic impact of design control associated with verification and validation,² traceability of design input changes to test data significantly affects the bottom line. Traceability established during the design phase is an investment-returning value during the operational stage of the device as well. Device modifications such as changes to the human-computer interface that result from in-field reports will most likely be done by a different team of engineers and analysts than those who designed the device. Consequently, traceability at varying degrees of granularity (e.g., at the paragraph, sentence, or numeric-value level) within and across documents allows quick, accurate, and complete root-cause analyses. This represents significant cost savings. Traceability can also assist in derivative product design, thus reducing time to market through reuse supported by detailed traceability and impact-assessment capabilities. Correctly implemented, traceability delivers all that it promises if professionals have control over what levels of detail can be traced and easily identify suspects that are potentially affected if another design element is changed. Electronic implementation across multiple documents permits the viewing of such suspects simultaneously within an interactive environment.

The requirements for traceability during the design stage are very different from those during manufacturing. Document-level traceability works well during manufacturing because the number of engineering change orders is dramatically smaller than the number of changes seen during development. However, applying only document-level traceability during the design phase can quickly lead to professionals wasting a great deal of time performing root-cause analyses and/or continuous process improvements over the life of the device. During design, the whole process is too volatile, while in the operational stage, analyses are not done by developers, which means much time can be wasted hunting through records, with traceability only from document to document.

Design control does not require traceability for all technical aspects; however, prudent application of traceability for key design elements (e.g., those linked with intended use or 510(k) submissions) will pay off over the life of the device. This benefit is magnified if product derivatives are also planned. Verification and validation costs can be dramatically reduced by applying traceability early in the design stage. The obvious advantage here is ensuring that the right tests are being applied to changing user needs and design inputs.

Flexibility is key to cost-effective traceability implementation. In some cases, large sections of documents can be linked, while in others, individual performance numbers or cells within a table must be traced. With safety-critical requirements, it is desirable to enforce a one-to-one traceability to ensure encapsulation of all such elements. Hazards-analysis traceability is another obvious place where the capability to trace at any level of detail is highly desirable. Another critical application of traceability involves making the decision not to implement a stated requirement, thus terminating that portion of the project. This is a design control requirement that also lends insight into future derivative product development.

The risk associated with complete traceability flexibility is that everything can be linked, creating unwanted overhead. Two risk-mitigation techniques can be applied here—information models and traceability matrices.

Information models are used to determine ahead of time which design elements should be linked together. One example of a high-level information model is design control compliance linkages across stages. Such models can be repeated at lower levels within and across design control stages to help developers understand what should be linked to support the project management and quality system processes within the company. The information models help reduce unnecessary overhead caused by implementing traceability just because it is possible.

Traceability matrices are techniques that are often supported by software tools. If a matrix view is used and the amount of checked cells becomes too dense, there is the risk of linking because it could be linked, not because it should be linked. A complex design could also be the cause of such a matrix, which may warrant other actions beyond traceability control. Tools that permit viewing and analyzing of information that would normally be found in multiple matrices are also available. Use of these tools allows for more cost-effective and time-saving analyses over the life of the device.

Just as traceability aids in the focusing of communications and enables engineers to work more productively, change histories or audit trails help management understand what happened and why during the design stage, especially long after the device is in production.

CHANGE HISTORY

A change history is used by management to understand what, why, when, by whom, and how things happened during the design stage. Questions regarding continuous process improvement, corrective actions and preventions, and product derivative development can all be answered by reading the change history. Key issues regarding the value of capturing and storing a change history deal with the level of detail required to provide a benefit and the amount of extra work required by the design team in offering such documentation.

Both formal and informal methods for capturing change are needed. During the FDA design control midcourse correction meeting (February 2, 1998, Bethesda, MD), it was pointed out that manufacturers were applying formal engineering change order processes to capture change history during the design stage, resulting in large overheads for the developers with little perceived value. Such a formal established process is only required once a document or design element is undergoing formal review and/or management approval. In this case, several approval authorities may be reviewing the document, so that careful recording and analysis of all proposed changes (including traceability links) must be tracked to their conclusion (closed-loop analysis). Applying this process during the highly volatile periods of design stifles the process and frustrates the developers.

An informal history of change should require no extra work by the developer. Implemented correctly, such change histories automatically record the change made, who made it, and when it was made, and include a mechanism for alerting everyone to the change. These records can also be stored and cleared once a more formal change history process is required and can be available for review in a variety of value-added ways (e.g., by author or date). The perceived overhead to those making the changes should be zero.

Having only one method for capturing change creates risks. Using only an informal change process encourages chaos, complicating the review and management-approval processes because of the inability to formally track, organize, and present changes. Having only a formal change history stifles the design team by creating extra work that adds no value during the initial parts of any design stage. A design change process must be established that incorporates, and thoughtfully uses, both informal and formal change history mechanisms. Software tools are available that support both mechanisms.

Version and baseline controls are related to this concept. Version controls permit rapid informal changes to be tracked and captured but not necessarily carried throughout the process once a document or design element becomes more stable. Baseline controls are used to capture the finished results of a formal review process or management approval where final specifications, as part of design outputs, might be the end product. Elements of the design history file and the device master record would normally be subject to version and baseline controls.

CONTRIBUTING FACTORS

Other key factors that should be considered when implementing a design control solution that reflects a good return on investment are:

CONCLUSION

Design control and ISO 13485 compliance is a complex issue. Balance and thoughtfulness are required to be successful the first time. Manufacturers can improve their profitability by examining the investment value of any process, method, or tool rather than simply the initial cost. At the same time, ensuring design control requirements are met has the side benefit of doing business wisely within the design phase of a device.

REFERENCES

1. Chaos Report, The Standish Group, 1995, www.standishgroup.com/index.html.

2. Medical Devices Current Good Manufacturing Practices Final Rule, Quality System Regulation, 61 FR:52601—52662.

Brian McCay, PhD, is marketing manager for vertical markets at Quality Systems & Software (Mt. Arlington, NJ).

Copyright ©1998 Medical Device & Diagnostic Industry