DESIGN AND DEVELOPMENT

Medical device manufacturers have a bit of latitude in developing a design control system as long as they meet the minimum criteria delineated in the quality system regulation (QSR). The QSR states that procedures must be established for design input, design output, design review, design planning, design verification, design validation, design transfer, and design changes. The specific requirements for each are listed in 21 CFR 820.30. However, the definitions are broad and do not describe methods for implementing controls. For example, consider the following requirements regarding design changes:

820.30(i) Design Changes. Each manufacturer shall establish and maintain procedures for the identification, documentation, validation, or where appropriate verification, review, and approval of design changes before their implementation.

Based on these broad requirements, most companies develop their procedures (known collectively as design controls) in an ad hoc manner, and, as such, they often serve only a few of the company's departments well. Other departments are left to fend for themselves and manage as best they can. For example, the engineers may get the design correct and meet the requirements; however, the production staff is unable to build the design with consistent quality. The engineers had focused only on the product requirements rather than on the requirements and needs of the production line equipment operators, who must be able to build the product consistently. The end result is a set of design control procedures that are inadequately linked, and thus are ineffective for all departments. Eventually, that leads to inadequate execution of design control.

Companies should consider treating the design control development process with the same level of rigor that is used for product design. Doing so will enable device manufacturers to take the company beyond compliance and move toward business excellence.

The creator of the design control procedures is often the quality manager or product development manager who is charged with passing audits. If a deficiency is noted through internal audits or design failures, a quick correction is added to the system to cover that particular weakness.

Alternatively—sometimes because of internal politics—the design control procedures are labeled difficult to comply with, and a round of procedure redesign and simplification removes detail and work instructions. The result of such hasty changes can be design control procedures that no longer meet the regulations.

Design control procedures are necessary for medical device organizations. Effective procedures are crucial to companies' competitiveness in their quest toward business excellence and to their ability to scale for growth. Such procedures can be developed if companies envision the needs of all departments and groups that rely on those procedures. Using recognized good design practices and methodologies can ensure compliance and lead to business excellence and is the key to developing the best possible design control procedures.

The Product Design Approach

One approach to structured product design follows these six steps:

• Identify the user's needs. Examples of users are the product end-users, the service technicians, the trainers, the manufacturing line, the quality inspectors, the marketers, and the company, to name a few.
• Develop requirements, i.e., translate those needs into functional requirements for the product.
• Design the product features. This process entails the designer determining how to meet the requirements by identifying tangible mechanical, hardware, and software technologies or other types of design features to incorporate in the product.
• Design the product structure. Assign those features to a product structure of assemblies, subassemblies, packaging, instructions for use, manufacturing instructions, etc.
• Perform design verification and validation. Verify that the functional needs have been met by testing that the product delivers the required functions, and validate that the product meets the end-users' needs.
• Implement and maintain the product. Incorporate regular product review processes to identify issues and initiate correction where applicable.

These six steps can also be used for developing design control procedures. For example, the design change procedure can be used to show how applying these steps to a design control development process can be effective. The QSR requires a design change procedure. This procedure is used to facilitate changes in the design of a product that has been released to production.

This example does not focus exclusively on the regulatory requirements of the design change procedure; rather, it is primarily concerned with company management and auditors (both internal and external), a subset of users of the design change procedure.

Step 1: Identify User Needs. All users must be identified in an extensive overview. A good rule of thumb is to include any group that interacts at any point with the procedure or the products designed using the procedure. For the design change procedure, a partial list of users is as follows:

• Company management.
• Product development, which includes engineering and regulatory affairs.
• Manufacturing.
• Marketing.
• Document control.
• Operations.
• Shipping.
• Receiving.
• Quality control inspectors.
• Suppliers.
• Regulatory authorities.

The needs of the traditional functions for a design control process can be easily identified. The needs of some users might include the following:

• An operations employee wants any changes implemented to be complete and accurate so that incorporating the change into the production process is relatively problem-free.
• The document control department would like to know when to transfer the documents to the production floor.

As the saying goes, necessity is the mother of invention. Once the functional needs of users have been identified, companies can begin the processes to address them.

It is important to remember that at the heart of these control procedures is a need to be ready for audits. Company management must be able to defend the design as part of the design change process. To do otherwise is to call the design into question and risk the potential for an FDA-483 or, even worse, a recall. Auditors need to be able to determine whether the company is under control from a design change perspective. Areas of concern prompt an auditor to probe deeper into the procedures being implemented.

With this in mind, it is possible to determine the needs of the company management and auditors, as follows:

• Management need: Build auditors' confidence that the organization is under control from a design change perspective. Defend the design; prevent the auditor from becoming an investigator.
• Auditor need: The design change procedure must be easy to audit so that the auditor does not have to probe deeply to make that determination.

To meet these needs, companies should have complete sets of information about the design change procedure at the auditor's fingertips so that the auditor does not need to probe further. This helps establish an auditor's confidence in the company.

Step 2: Develop Requirements and Convert User Needs into Achievable Requirements. Manufacturers must identify functional requirements of the design change procedures that will allow them to meet the user needs. This step is analogous to converting marketing specifications into engineering requirements for a product.
A field change order can illustrate concerns to an auditor (e.g., the field changes that are the result of design changes being implemented).

To ensure that the auditors will feel secure that the design change process is under control when they review field changes, manufacturers' change order must do the following:

• Clearly and precisely describe the change. Provide the part number of the item or subassembly and describe the specific nature of the change.
• Clearly state whether the change is due to a safety concern, and if so, describe in what way. Alternatively, describe why the change was not considered the result of a safety concern.

Also, if the change was the result of any type of problem, the order should describe the nature of the problem and how the change fixes it. Where applicable, identify links to corrective and preventive actions (CAPAs), or other vehicles such as nonconforming materials and complaints, that led to this action. Links to other processes, such as internal audits, CAPA, nonconforming materials, etc., are necessary in case the auditor would like to shift the review to that area.

Finally, the order should describe the implementation plan. Identify whether it will be a full implementation (all of the units in the field) or a partial implementation. If it is a partial implementation, justify the decision from a safety perspective. Describe the timing of the change (e.g., whether it is scheduled for the next preventive maintenance visit or is an immediate update). Again, justify that decision from a safety perspective. Furthermore, describe how the units currently in production will be handled.

If this information is presented in a way that tells the story of the change and defends the design, the auditor is likely to trust that the design changes are under control.

Keep in mind that source information for the field change order will not be with that document. It may be tempting to leave source information out of the picture since the design change documentation will have that data, but listing such data on the document allows the field change order to stand on its own. It also can provide immediate information to an auditor during review. Therefore, including source data on the field change order is a way to meet the company management's need to defend the design and also to meet the auditor's need for the design changes to be transparent during an audit.

Such information should originate on the engineering change order and should be copied verbatim into the field change order. This way, the field change order becomes a door through which the auditor can pass if necessary.

Based on this information, the functional requirement to meet the needs of these users can include the following language: Have complete information available to the auditor that enables the organization to defend the design at the field change order stage.

A functional requirement is one that is required to be delivered by the design (in this case, the design change procedure). In every case, it should stem from a user need, and it is typically the answer to the question, “What functionality is necessary to enable the design to meet the user's needs?” In the case of the design change procedure, the answer is, “The ability of the procedure to have complete information available at the field change order stage.”

Remember that at this step the requirements are broad and will need further detail once the company determines how these requirements will be met.

Step 3: Design the Features. At this stage, the functional requirements are converted into design parameters. Each functional requirement has to be met in a physical way by a design parameter. The process is similar to the design stage in product development, where a designer selects technologies to meet the requirements. In the design of a product, the company must select a technology (how to do it) to meet the requirement (what needs to be done). For example, meeting the requirement “identify a courier package” can be accomplished by using bar coding or even radio-frequency identification (RFID). RFID and bar coding are separate and different technologies that have limitations and constraints that become inherited when selected.

To satisfy functional requirements, the creator of a design change procedure might use data input fields in an MS Word format that prompt the user for specific information that was identified earlier. The fields in the MS Word document should be a design parameter used to fulfill the functional requirements.

In the design change procedures, manufacturers can meet a functional requirement (FR1) with a specified design parameter (DP1):

• FR1: Have complete information available to the auditor that enables the organization to defend the design at the field change order stage.
• DP1: Provide a field change order form that contains information of concern to an auditor.

At this stage, the procedures are still defined broadly and will need more detail at a later stage. Examples of lower-level requirements and design parameters include the following:

• FR1.1: Means to describe the change fully.
• DP1.1: Have a segment of the field change order form for information such as the nature of the change, the scope of the change, and the specific change (e.g., list products and subassemblies affected, with part numbers).
• FR1.2: Means to describe the reason for the change.
• DP1.2: Have a segment of the field change order to describe the reason for the change and clarify whether the change is due to a safety concern.
• FR1.3: Means to link the change to CAPA-type systems that initiated the change for reference.
• DP1.3: Have a segment of the field change order to define the links to other CAPA systems by quoting a reference number for nonconforming material or complaints.
• FR1.4: Means to describe how the change fixes the problem.
• DP1.4: Have a segment of the field change order to identify the problem the change is trying to fix, the root cause of the problem, and how the change corrects the problem.

The relationship between functional requirements and design parameters is made using the concept of zigzagging. Zigzagging is very naturally used during product design. When designers identify a high-level user requirement, they also identify a high-level design parameter (or technology) that will fulfill the requirement. For example, a functional requirement of “control the operation of an electromechanical device” could be fulfilled by the design parameter of “an industrial PC” or “a microcontroller.” Each selection will have its own implications and limitations when implementing lower-level control requirements such as the number of sensor inputs, monitoring frequency, etc.

Accordingly, the high-level technology must also be considered when identifying lower-level requirements and when ensuring that those requirements are met. This process is the strength of the zigzagging concept. Once the high-level requirement and the high-level technology to be used to fulfill the requirements are defined, create lower-level functional requirements and then identify how they individually will be fulfilled (keeping in mind the microcontroller or industrial PC). If at any point the lower-level requirements cannot be met because of limitations of the higher-level technology selection, then a new technology will need to be selected. Only by keeping that high-level design parameter in mind can designers successfully identify lower-level functional requirements.

Once DP1 for the design change process (as described earlier) is established as a form that contains information, it becomes easier to visualize the lower-level functional requirements and design parameters as fields in a form that meets different functions. Lower-level requirements will then define the specific fields that need to be included in the form.

As part of Step 3, analyze the design against a good design rule. After the design parameters are defined, it is important to look for situations in which more than one functional requirement is satisfied by a single design parameter. If a single parameter is used, the company may want to review those requirements and consider meeting them using different independent design parameters. Having two requirements coupled to one design parameter imposes limitations on the ability to make changes to one of the two requirements and the design parameter. If a change is made, it is unlikely that the second requirement would be able to remain satisfied if the requirements were coupled.

Step 4: Design the Product Structure and Link Design Parameters to a Physical Structure. Once the user needs have been translated into functional requirements and design parameters for the design change procedures, the parameters are mapped to physical elements of the design change procedures. This is analogous to assigning features to parts or subassemblies when creating products. The physical elements of design change procedures include workflows, forms, procedures, and databases.

The sidebar on page 68 and Figure 1 both illustrate how the structure of a design change has been defined. Each box in the graphic represents a form. For a description of the purpose for each form, see Table I.

Step 5: Perform Design Verification and Validation and Verify that Procedures Meet Users' Needs. Once the design parameters have been linked to a product structure, it is easy to collect all of the requirements and parameters for a specific element such as a form used in the design change procedure. A requirements management software tool can be used to achieve this. For example, the Acclaro DFSS software from Axiomatic Design Solutions Inc. of Brighton, MA, easily exports a traceability matrix into an MS Word document and uses that as a design validation guide.

The validation guide lists the product structure element (the form) as the heading and then summarizes all the design parameters that must reside in that form. Once this is done, the procedure designer must verify that the form contains all the design parameters. If not, then the form must be corrected to fulfill the requirements by adding any missing features to the form. This verification phase is critical because it is the last chance to review the details of the requirements and ensure that all the detailed design parameters are met within the procedures.

Step 6: Implement and Maintain the Product. The net result of the verification and validation phase is that all customer needs are met. Furthermore, this method provides the documentation that identifies all of the users' needs and traces how they have been met. If in the future the company wishes to make a change to the process, it is easy to determine the reasons that the process was constructed in such a way. It also provides insight as to whether the proposed change would cause any problems.

Furthermore, by providing validation documentation that links the regulations and the procedures, this method enables the company to demonstrate to external auditors specifically how regulations have been met at the company.

Conclusion

Design control procedures development can be approached much like product design. The procedures are needed to meet the QSR regulation but also to address business needs. The use of a structured design methodology allows the procedure designer to easily identify user needs and convert them into functional requirements and design parameters. Once this is done, it is possible to validate the system after the design parameters have been linked to the product structure. Once validations are complete, the company will have a new set of procedures—developed with functional needs in mind—that meet the needs of all users. In addition, process documentation will support the company's procedures during an audit.

Taras Worona, P Eng, is manager of product development and project leader for Vasogen Inc. (Mississauga, ON, Canada). He can be contacted at [email protected].

Copyright ©2006 Medical Device & Diagnostic Industry