3. Design Controls
DESIGN AND DEVELOPMENT PLANNING
Structure of Plans
Preparation For Reviews
Why Design Reviews
Types Of Design Review Meetings
Design Review Requirements
End Of Initial Design
Documenting Design Output
Design Output Approval
DESIGN VERIFICATION AND VALIDATION
Design Evaluation versus Specifications
DESIGN HISTORY FILE
Design Input Requirements Procedure
The Safe Medical Devices Act of 1990 added design validation requirements to the GMP requirements in section 520(f) of The Act. Section 820.30 of the Quality System (QS) regulation lists the design control requirements that manufacturers should satisfy to be in compliance. This chapter describes design controls and provides guidance to assist manufacturers in complying with design control requirements.
"Design Control Guidance for Medical Device Manufacturers" is another document that may assist manufacturers in understanding the intent of the design control requirements. This manual interprets the language of the QS regulation and explains the underlying concepts in practical terms. "Do It By Design: An Introduction to Human Factors in Medical Devices" is a document that contains background information about human factors as a discipline, describes and illustrates device problems and discusses human factors principles and methods as a part of the design control system. Both of these manuals are possible resources for manufacturers who are either developing or improving their design control system. These manuals are also available through DSMA.
The design controls section 820.30 of the QS regulation applies to the design of products, and processes and changes to existing designs and processes. Changes to existing designs should be made in accordance with design control requirement even if the original design was not subject to these requirements. Design controls are not retroactive to completed portions of ongoing design programs.
Each manufacturer of any class III or class II device, and class I devices automated with computer software and those listed below shall establish and maintain procedures to control the design of the device in order to make certain that specified design requirements are met. Manufacturers of other Class I devices should develop and document their devices under their own design control system because the documentation is needed to help meet the device master record requirements in 820.181 and marketing submission requirements. Thus, manufacturers of exempt Class I devices are encouraged to use 820.30, Design Controls, as guidance.
|Classification Section||Class I Devices Subject to Design Controls Listed in Paragraph 820.30(a)(2)|
|868.6810||Catheter, Tracheobronchial Suction|
|892.5650||System, Applicator, Radionuclide, Manual|
|892.5740||Source, Radionuclide Teletherapy|
|All Sect.||Devices automated with computer software|
The design requirements for the device are primarily specified by the manufacturer; however, FDA has a few design requirements in the 21 CFR Part 801 labeling regulations and in Parts 1000-1050 which cover radiological and electronic products. A few of the FDA design requirements are in standards. For example, some parameters for medical gloves are in standards by the American Society for Testing and Materials (ASTM). (That is, medical gloves are required to meet these standards in order to be substantially equivalent to gloves already in commercial distribution.)
Each manufacturer is required to establish and maintain a quality system that is appropriate for the specific medical device(s) designed or manufactured [820.5 and 820.1(a)(3)], and that meets the requirements of Part 820. Therefore, the details of design control systems will vary depending on the complexity of the product or process being designed. However, all non-exempt manufacturers including very small manufacturers and manufacturers that design less complex devices or processes are expected to define, document and implement design control procedures and other quality system procedures as called for in the regulation. One of these, a sample design input procedure, is exhibited at the end of this chapter.
Manufacturers may establish one design control procedure to cover the various design control sections in 820.30; or, they may use one or more procedures for each topic. Multiple procedures may be easier to develop, update and implement. Medium to large manufacturers may have several additional procedures to support their main design control procedures. Design control procedures may be part of the quality system records (QSR) noted in section 820.186.
Personnel training in 820.25 is one of the quality system requirements, which applies to employees that perform any activity covered by the QS regulation including all design activities.
Manufacturers are required to establish procedures for identifying training needs and making certain that all personnel are trained to adequately perform their assigned responsibilities. Design personnel shall be made aware of device defects which may occur from the improper performance of their specific jobs. In particular, personnel who perform verification and validation activities shall be made aware of defects and errors that may be encountered as part of their job functions.
Most technical employees need various degrees of training, as appropriate, in the medical device regulations, safety, labeling, human factors, verification, validation, design review techniques, etc.
Developing a new device and introducing it into production are very complex tasks. For many new devices and associated manufacturing processes that use software, these tasks are further complicated because of the importance of software, and the possibility of subtle software errors. Without thorough planning, program control, and design reviews, these tasks are virtually impossible to accomplish without errors or leaving important aspects undone. The planning exercise and execution of the plans are complex because of the many areas and activities that should be covered. Some of the key activities are:
- determining and meeting the user/patients requirements;
- meeting regulations and standards;
- developing specifications for the device;
- developing, selecting and evaluating components and suppliers;
- developing and approving labels and user instructions;
- developing packaging;
- developing specifications for manufacturing processes;
- verifying safety and performance of prototype and final devices;
- verifying compatibility with the environment and other devices;
- developing manufacturing facilities and utilities;
- developing and validating manufacturing processes;
- training employees;
- documenting the details of the device design and processes; and,
- if applicable, developing a service program.
To support thorough planning, the QS regulation requires each manufacturer to establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation.
The plans should be consistent with the remainder of the design controls. For example, the design controls section of the quality system requires a design history file (DHF) [820.30(j)] that contains or references the records necessary to demonstrate that the design was developed in accordance with the:
1. approved design plan, and
2. regulatory requirements.
Thus, the design control plans should agree with, and require meeting, the quality system design control requirements. One of the first elements in each design plan should be how you plan to meet each of the design control requirements for the specific design you plan to develop; that is, the design plans should support all of the required design control activities. Such plans may reference the quality system procedures for design controls in order to reduce the amount of writing and to assure agreement.
Design And Development Planning section 820.30(b) states:
"The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process..."
If a specific design requires support by contractors such as developing molds, performing a special verification test, clinical trials, etc., then such activities should be included or referenced in the plan and proactively implemented in order to meet the interface and general quality system requirements. Of course, the interface and general requirements also apply to needed interaction with manufacturing, marketing, quality assurance, servicing or other internal functions.
Proactive interface is a important aspect of concurrent engineering. Concurrent engineering is the process of concurrently, to the maximum feasible extent, developing the product and the manufacturing processes. This valuable technique for reducing problems, cost reduction and time saving cannot work without proactive interface between all involved parties throughout all stages of the development and initial production program.
Structure of Plans
Each design control plan should be broad and complete rather than detailed and complete. The plan should include all major activities and assignments such as responsibility for developing and verifying the power supplies rather than detailing responsibility for selecting the power cords, fuseholders and transformers. Broad plans are:
- easier to follow;
- contain less errors;
- have better agreement with the actual activities; and
- will require less updating than detailed plans.
Over the years, several manufacturers have failed to follow this advice and opted for writing detailed design control procedures. They reported being unable to finish writing the over-detailed procedures and were unable to implement them.
Regardless of the effort in developing plans, they usually need updating as the development activities dictate. Thus, the QS regulation requires in 820.30(a) that the plans shall be reviewed, updated, and approved as the design and development evolves. The details of updating are left to the manufacturer; however, the design review meetings are a good time and place to consider, discuss and review changes that may need to be made in the design development plan.
Design input means the physical and performance requirements of a device that are used as a basis for device design [820.3(f)].
Section 820.30(c) Design Input, requires that each manufacturer shall establish and maintain procedures to make certain that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. Also, a design requirement in 820.130 requires that each manufacturer shall make certain that device packaging and shipping containers are designed and constructed to protect the device from alteration or damage during the customary conditions of processing, storage, handling, and distribution. The intent of 820.130 is to add the broad conditions that are considered for a package design. Packaging design activities should be done according to design controls. Likewise, the design of the content and physical parameters of labeling are covered by design controls. Manufacturers that are exempt from design controls shall labeling and packaging specifications in the DMR (820.181) and are encouraged to use the QS design controls as guidance.
The input procedures shall address incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
Under a design control system, manufacturers should identify device requirements during the design input phase or beginning of the design activity. Design input includes determining customer needs, expectations and requirements plus determining regulatory, standards, and other appropriate requirements. These various requirements are documented by the manufacturer in a set of device requirements. A set of design input requirements, when converted to engineering terminology, finalized and accepted as part of the device master record is called a device or product specification.
The design input phase usually is a continuum because intensive and formal input requirements activities usually occur near the beginning of the feasibility phase and continue to the early physical design activities. After the initial design input phase there are also intensive and formal activities to reduce the input requirements to engineering-type input specifications -- usually called a product or device specification.
At the opposite end of the design program, the last event is initial production which may be pilot production or the beginning of routine production. Whether a manufacturer starts with pilot or routine production depends on the nature of the new device and associated production. Pilot devices may be distributed after design validation of initial units is completed if they meet all of the device master record and other GMP requirements. Some manufacturers, however, use the pilot models in training programs for technical writers, production and service personnel, etc. Pilot models are also commonly used in early marketing displays.
After the concept of the new device design is established, the following basic design input questions should have been answered:
1. What is the real need for the new device?
2. Where will the new device be used?
3. Who will use the new device?
4. How will the new device be used?
5. With what devices will the new device be used?
6. How long will the new device be used? and
7. Other questions related to the specific device to be developed.
Designing a device and verifying that it meets customer requirements are expensive and time consuming activities. Therefore, to control these activities and increase the probability of achieving desired safety and performance characteristics, device, software, and process requirements and specifications should be thoroughly reviewed and approved before physical design and development begins. As the design evolves, the hardware, software, packaging, labeling, etc., shall be verified [820.30(f)] and reviewed [820.30(e)] versus their latest specifications to verify that design input requirements have been met.
Device requirements should identify all of the desired performance, physical, safety and compatibility characteristics of the proposed device and, ultimately, the finished device. Design input also includes requirements for labeling, packaging, manufacturing, installation, maintenance and servicing. The final device specifications should cover ALL of the device characteristics. The device specifications may incorporate other specifications by reference such as reference to the manufacturer's list of specifications for a type of device, to specific paragraphs in standards, or to all of a standard, etc. with respect to a referenced specification. It should be very clear exactly what is going to be met. A failure to properly address characteristics or factors such as immunity from transients in the power source, thermal stress, electromagnetic compatibility (EMC), packaging protection, shipping stability, proper maintenance, etc., can have disastrous consequences.
It is possible to diligently develop device requirements and still forget one or more elements in the final specification. Hopefully, no key factors will be left out. To reduce the probability of a requirement or characteristic being left out, a specification checklist(s) may be used during the design input phase. A checklist should be developed that is broad based but also germane to the product line of the manufacturer. If used, a checklist should be part of a standard operating procedure such as a Design Input Specification Procedure.
The input requirements should cover any standards that the manufacturer plans for the device to meet. In the United States, information about essentially all national and international standards may be obtained from the American National Standards Association (ANSI), 11 West 42nd Street, New York, New York, 10036, phone 212-642-4900. ANSI is a private organization, which monitors most of the standards activity in the United States and foreign activity in which U.S. citizens "officially" participate. Thus, ANSI can supply addresses and other information about all well established standards writing groups. Also, ANSI has for sale many different types of standards including quality system standards. For example, the International Electrotech Commission has a draft design review standard, "Guide on Formal Design Review" (plus a supplement), which should be helpful to product assurance/design control personnel.
The QS regulation requires that the input procedures shall address incomplete, ambiguous, or conflicting requirements. Thus, every reasonable effort should made to collect all of the requirements from which the designers can generate detailed design specifications that are clear, correct and complete.
At the end of the major aspects of the design input stage, the design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
A documented device specification or set of specifications derived from the input requirements should exist at the beginning of the physical design project. The device and other related specifications should be kept current as the design of the device, packaging, labeling and manufacturing processes evolve during the development program. As the physical design evolves, the specifications usually become more specific and more detailed.
The device specification will undergo changes and reviews as the device design evolves. However, one goal of market research and initial design reviews is to establish complete device requirements and specifications that will minimize subsequent changes.
Old versions of the input requirements and later the input specifications are put in the design history file (DHF) or indexed in the computer as part of the DHF to help show that the design plan was followed.
Design review [820.30(e)] is one of the key design control elements in a quality system. The objectives of design review are stated in the definition of design review in 820.3(h) as follows:
Design review means a documented, comprehensive, systematic examination of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems.
To meet the systematic design review requirement, device design and design reviews should progress through defined and planned phases starting with the design input phase and continuing through validation of initial production units or lots. Subsequent activities are usually design changes.
To meet the design review comprehensive requirement, assessments should include a formal review of the main device and subsystems, including accessories, components, software, labeling, and packaging; production and resource needs; and installation and service, if needed. The scope includes performance, physical safety, compatibility with other devices, overall device system requirements, human factors, and environmental compatibility.
Even though users or medical practitioners will be aware of direct medical requirements, they may not be fully aware of physical safety, compatibility, system, human factors, and environmental requirements. Thus, the reviews of the design input and the design should extend beyond merely satisfying user-stated requirements in order to assure that safety and effectiveness goals are met.
As the development program progresses, the reviews should cover producibility and production documentation such as assembly drawings, manufacturing instructions, test specifications, test procedures, etc.
The extent and frequency of design reviews depends on the complexity and significance of the device being evaluated.
When the design program is a redesign of an existing device, a special effort should be made to assure that data obtained from previous failures, complaints, and service records are made available and reviewed by those responsible for design, design input and design review.
Marketing submissions to FDA for drug delivery, drug coated, etc., devices are required to have appropriate data that supports combination claims. The verification of combination devices requires interaction between device, drug or other manufacturers. Records of this interaction, such as design review meeting minutes, are required in order to meet the interface requirements of 820.30(b), Design and Development Planning. The labeling and particularly the cross-labeling of combination devices should be carefully analyzed during verification and validation activities, and design review meetings.
Preparation For Reviews
The designated moderator or other designated employee should announce the formal review meetings with appropriate lead time and include an agenda.
Persons who are making presentations should prepare and distribute information to help clarify review issues and help expedite the review. However, the intent of the quality system is not that presentations be so formal and elaborate that designers are spending excessive time on presentations rather than on designing a safe and effective device.
Persons who plan to attend a review meeting should come prepared to discuss the key issues on the agenda and issues related to the current design phase. Design review meetings are a great educational forum. However, design review meetings should not be used as a primary tool to educate or bring new employees or unprepared employees up-to-speed. To do so detracts from the intent of the meeting and detracts from the intent of the GMP requirements. Obviously, design review is also an excellent educational tool. However, new, or new-to-the-project employees should be primarily oriented by other means that do not detract from the primary function of design review meetings.
Why Design Reviews
Design reviews are conducted for design definition, selection and adequacy; communication; and resolution of problems and issues. For example, the design review of the design input requirements and subsequent design input specifications for the device, labeling, packaging and accessories is performed to help select the best and/or needed characteristics and requirements, usually from among many available and sometimes conflicting inputs.
The design review of the initial requirements allows input from all parties. Various people may participate and "buy in" or "become part of the program." As the design input and review activities progress, any conflicts are resolved and the preliminary specifications for the device, accessories, labeling, and packaging are established. Herein, the device, accessories, labeling and packaging is called the device system. Because of the establishment of these input requirements and subsequent specifications, plus interface and communication during the reviews, all personnel are directed toward the goal of developing the "exact" same device system.
As the development progresses and the design and production processes evolve, design reviews reduce errors, help avoid problems, help find existing problems, help propose solutions, increase producibility and reduce production transfer problems. The relentless inquiry during design reviews will expose needed design input requirements and/or design corrections that otherwise may have been overlooked.
Throughout the design program and particularly toward the end of the development cycle, design reviews help assure that the final design of the device system meets the current design requirements and specifications.
Types Of Design Review Meetings
Design review meetings may be grouped into two levels such as:
- total or major program review meetings, and
- sub-program or team review meetings.
Some of the review meetings need to be total or major program review meetings because this is the only type of review meeting that will satisfy all of the GMP review requirements, particularly the interface requirement for interaction between or among different organizational groups. However, sub-program, team and contractor review meetings are design review meetings, are subject to quality system design controls, and should be conducted in a manner that meets the GMP requirements. Sub-program or team meetings are encouraged as these can be very effective and efficient in reviewing and resolving sub-program issues.
The records of total program and team meetings are part of the device design history file. The team review records or a summary of team records and the current design documentation are to be available, as appropriate, at total program review meetings.
Design review meetings are called under two scenarios:
- first are the meetings that are preplanned and called at least on a per design phase;
- second are ad hoc meetings that are covered in the broad plans and are called to review or resolve a specific problem or issue.
The preplanned design review meetings and ad hoc meetings are part of the planning and interaction that are required in 820.30(b), Design and Development Planning. That is, the manufacturer should expect, plan for, and encourage appropriate ad hoc meetings as well as the major design review meetings. Reasonable notes and copies of significant engineering documents discussed during total device system, ad hoc, contractor, and other review meetings are part of the device design history file.
Design Review Requirements
The objectives of design review are stated in the definition noted above. How these objectives are to be achieved are presented in the design review requirements. The main design review requirements are in 820.30(e) of the QS regulation as follows:
Each manufacturer shall establish and maintain procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device's design development. The procedures shall ensure that participants at each design review include representatives of all functions concerned with the design stage being reviewed and an individual(s) who does not have direct responsibility for the design stage being reviewed, as well as any specialists needed. The results of a design review, including identification of the design, the date, and the individual(s) performing the review, shall be documented in the design history file.
There are four requirements related to design reviews:
1. The meetings should be formal. That is, key attendees are designated and the meetings are conducted at least once per stage/phase, are planned, are announced or are periodic, have an appropriate agenda, notes are recorded, etc., according to the manufacturer procedure for design reviews.
The design review procedure should be broad and complete in that it contains information about all of the requirements. However, the procedure should not be so detailed that it cannot be followed. Over the years, several manufacturers have failed to follow this advice, tried to write detailed design QA procedures, and have reported that they were unable to finish writing the over-detailed procedures and were unable to implement them.
2. To meet the definition of design review in 820.3(h), the review should include persons who are intimately knowledgeable about the technical characteristics of the design such as performance, safety, compatibility, etc. In many manufacturers this can only be done by those persons responsible for the design. However, reviews are to be objective, unbiased examinations by appropriately trained personnel which should include an individual(s) not responsible for the design. The moderator of the review meeting may be one of the persons not responsible for the design.
To meet interface and other review requirements, the review meetings should, as appropriate, include representatives of R&D, Engineering, Technical Support Services, Production Engineering, Manufacturing, Quality Assurance, Marketing, Installation and Servicing, Purchasing and contractors. Design review should, as applicable and at the appropriate phase, include those responsible for coordinating or managing preclinical and clinical studies.
3. Pre- and post-review meeting significant responsibilities and assignments should be documented [820.30(b)]. These assignments are not unusual -- they are simply ordinary work required to develop a new product or modify an existing product. The progress and/or results of such assignments would typically be reported at the next review meeting. Documentation is not required for detailed day-to-day development activities that are part of the designers routine job.
4. The design review meeting results are made a part of the device design history file. The results should include minutes and should include notes, or annotated draft drawings and annotated draft procedures that played a significant role during the design review. Such documents help show that plans were followed, verification/validation was reviewed, and, to some extent, how the design evolved.
The QS regulation does not require that every document mentioned, referenced or used during a design review be placed in the design history file.
The device design review meeting minutes should include information such as:
- moderator and attendees,
- date and design phase/stage,
- plans and/or agenda,
- problems and/or issues to identify and solve,
- minutes and reports, and
- follow-up report(s) of solutions and/or the next review covers the solutions and remaining issues.
Manufacturers may use a form to capture some of this information for minutes such the device, date, moderator, attendees, major phase, problems, assignments, etc. The device design review minutes are a key and required part of the design history file. The minutes also help consolidate development information and the current minutes are also a brief record of some of the immediate development tasks to be done.
End Of Initial Design
The design control requirements, particularly design validation, give clear insight into when the initial
design effort is completed. The end of the total design effort has not been reached until it is known that the initial production devices, when transferred to production and produced per the device master record, meet all of the current design specifications. This fact can only be determined by performing design validation on one or more samples of the finished production units as required by 820.30(g). Initial production and subsequent validation are well defined stages; and, therefore, design review(s) shall be performed as required by 820.30(e), Design Review.
Thus the design validation of initial production should be followed by a "final" design review to meet the design review requirement. If the validation of the final design and subsequent design review(s) reveal design problems, then design changes are required to correct these problems. Design changes require another design verification and, where appropriate, validation and review of all parts or the affected parts of the device system.
Design output per 820.3(g) means the results of a design effort at each design phase and at the end of the total design effort. The finished design output is the basis for the device master record. The total finished design output consists of the device, its packaging and labeling, and the device master record.
Device master record (DMR) means a compilation of records containing the procedures and specifications for a finished device.
The design output at each phase are documents and physical design elements that are either complete or are used to move the design effort into the next phase. For example, the first design output will usually be the design requirements document. From the requirements and their engineering knowledge, the designers will derive the preliminary design specifications. Then the physical design begins. For example, the designers may begin the selection of known routine components that are part of the design and begin documenting their purchasing and acceptance requirements documented to meet 820.50 Purchasing Controls, (b) Purchasing Data which requires that each manufacturer shall establish and maintain data that clearly describe or reference the specified requirements, including quality requirements, for purchased or otherwise received product and services.
Other components will be selected as the design evolves. The design output for some special or new components, or components in unusual applications, will include verification protocols, purchasing and acceptance requirements.
Many of the design output documents are documents that directly form part of the DMR. The remaining DMR documents are created by quality assurance, production engineering, process engineering, technical writing, installation and servicing, etc., using design output data and information. For example, the finished device final-test methods and some installation and/or servicing test methods and data forms may be derived from the design verification protocol(s). When all of these design and documentation activities are completed, the DMR is complete. When the DMR is complete and initial production units, including packaging, meets all specifications, the total finished design output exists.
To generate the design output per the QS regulation in 820.30(d), three activities are required. Each of these is listed and discussed below.
1. Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements.
2. Design output procedures shall contain or make reference to acceptance criteria and ensure that those design outputs that are essential for the proper functioning of the device are identified.
3. Design output shall be documented, reviewed, and approved before release. The approval, including the date and signature of the individual(s) approving the output, shall be documented.
Documenting Design Output (1)
Documenting design output in terms that allow an adequate evaluation of conformance to design input requirements is a significant requirement and design activity. A common technique for achieving this conformance is listed below.
- Convert the general input requirements to specific design engineering specifications and give each item a line/paragraph number.
- Develop the design to meet all of the parameters and characteristics in the design engineering specification.
- Generate a verification requirement document(s) and test method(s) for the design and give each requirement/parameter/characteristic the same line/paragraph number that it has in the design engineering specification.
- Generate a verification data form that lists each requirement/parameter/characteristic and give each requirement/parameter/characteristic the same line/paragraph number that it has in the design engineering specification.
Each of these documents has a different drawing number but the line/paragraph numbers are the same. The first of these documents may be used as the beginning format for the next one. Therefore, it is almost impossible to leave out an element. Thereafter, when the verification is performed and documented, conformance or lack of conformance from input to output is known.
Acceptance Criteria (2)
The verification documents and data contain more information than is typically needed for production evaluation and acceptance of components, in-process items and finished devices. Therefore, it is easy to copy and modify verification documents to meet the quality system requirement that: design output procedures shall contain or make reference to acceptance criteria and ensure that those design outputs that are essential for the proper functioning of the device are identified. In fact, this technique of deriving test procedures from the verification protocols also yields the test method(s) and data form(s) needed to meet the DMR requirements for QA procedures and acceptance criteria in 820.181(c).
Design Output Approval (3)
The third and final output requirement is that: design output shall be documented, reviewed, and approved before release. The approval, including the date and signature of the individual(s) approving the output, shall be documented. This means that:
- Manufacturers may choose to have a group review certain documents and have individuals review other documents.
- Output documents that are directly part of the DMR are reviewed, dated and signed by the author which is current practice; and reviewed, dated and approved by individual(s) designated by the manufacturer. As appropriate, these reviews should cover technical issues as well as adequacy for use in production, purchasing, servicing, etc. DMR documents that are generated and approved under 820.30 automatically meet the approval requirements of 820.40, Document Controls and do not have to be re-approved under 820.40.
- Design output reports, data and any other document that will be used to create documents in the DMR are reviewed, dated and signed by the author which is current practice; and reviewed, dated and approved by individual(s) designated by the manufacturer.
Design output also includes the physical design which, of course, is not intended to be signed, and dated. The approval for the physical design is the validation that is done on initial production units.
Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification [820.30(f)] shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.
Validation [820.30(g)] means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.
Process validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications.
Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).
Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.
Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.
Design verification is always done versus specifications. Therefore, to control the specifications and increase the probability of achieving desired safety and performance characteristics, device, software, labeling, packaging and any other specifications should be complete and thoroughly reviewed before development commences. As the hardware and software designs evolve, they should be evaluated versus their current specifications.
Verification and validation should be done with test equipment calibrated and controlled according to quality system requirements. Otherwise, there is limited confidence in the data.
Verification and validation should also be done according to a written protocol(s). The protocol(s) should include defined conditions for the testing. The protocol(s) should be approved before being used. Test protocol(s) are not perfect for a design, particularly a new design. Therefore, the designers and other verification personnel carefully annotate any ongoing changes to a protocol. Likewise, the verification personnel should record technical comments about any deviations or other events that occurred during the testing. The slightest problem should not be ignored. During design reviews, the comments, notes and deviations may be as important as test data from the formal protocol(s).
Design Evaluation versus Specifications
The original design of devices and any subsequent changes should be verified by appropriate and formal laboratory, animal, and in vitro testing. Risk analysis should be conducted to identify possible hazards associated with the design. Failure Mode Effects Analysis and Fault Tree Analysis are examples of risk analysis techniques.
Appropriate laboratory and animal testing followed by analysis of the results should be carefully performed before clinical testing or commercial distribution of the devices. The manufacturer should be assured that the design is safe and effective to the extent that can be determined by various scientific tests and analysis before clinical testing on humans or use by humans. For example, the electrical, thermal, mechanical, chemical, radiation, etc., safety of devices usually can be determined by laboratory tests.
Clinical testing is not needed for many substantially equivalent devices (See 21 CFR Part 807 Subpart E Premarket Notification Procedure). Where it is needed, such as for complex substantially equivalent devices or new devices, clinical testing on humans should meet the applicable requirements in the Investigational Device Exemption (IDE) regulations (21 CFR Parts 812 and 813).
The general IDE regulation (21 CFR Part 812) exempts a manufacturer during the "premarketing phase" from the following provisions of the FD&C Act:
- Registration of the Establishment,
- Premarket Notification [510(k)],
- FDA Performance Standards,
- Premarket Approval,
- Production sections ONLY of the Good Manufacturing Practices,
- Color Additives,
- Banned Devices, and
- Restricted Devices.
Don't be misled by this list of exemptions -- being exempted from these provisions does not mean that a manufacturer may develop a new device under uncontrolled conditions and then test it on humans. Devices being clinically tested are not exempt from section 501(c) of the FD&C Act, which states that a device is adulterated if it does not meet a manufacturer's quality claims. Devices being manufactured for use in clinical studies under an IDE are exempt ONLY from the production section of the QS regulation. They are not exempt from design controls listed in 820.30. In addition, the IDE regulation has labeling requirements in 812.5 and quality assurance requirements in 812.20(b)(3) that shall be met. Further, manufacturers should remember that human subjects are also protected through the courts via product liability laws and actions. In summation, protection of manufacturer interests, human test subjects, practitioners, and patients requires that all medical devices be developed, evaluated, and manufactured under a total quality system.
Laboratory testing to force a failure takes considerable time and the "culprit" may not fail during the testing. Another evaluation technique is Failure Mode and Effects Analysis (FMEA) in which failures are assumed to occur. FMEA is useful for evaluating reliability, safety, and general quality where, for example, the evaluator assumes that:
- each component fails,
- each subsystem or subassembly fails,
- the operator makes errors, and
- the power source is interrupted and immediately restarted.
The probability of each failure actually occurring and, if it does, the resulting effect are analyzed. Then, where needed and feasible, hazards and faulty performance are designed out of the device or reduced; or compensated or prevented/reduced by interlocks, warning signs, explicit instructions, alarms, etc. Risks, of course, cannot always be removed from medical devices, but they should be known and controlled to the extent feasible with existing technology.
Failure Mode and Effects Analysis (FMEA) is a very powerful and costeffective technique. Note that it takes very little time to assume that a component or subsystem is going to fail versus the time required to test to failure. The idea is not to promote one method above the other because a reasonable amount of both actual testing and failure mode and effects analysis should be done before a device is clinically tested and/or placed into production.
Besides using FMEA there are also other human factor and validation process techniques that can be used in developing an overall risk analysis. These techniques include: timelines, workload analysis, failure analysis, alternative calculations, testing including animal testing, auditing the design output, design reviews, demonstrations, and comparing a new design to a proven design etc. The users should be considered components when developing a fault tree and failure mode effects analysis.
All evaluation results should be reviewed by product development personnel who compare the tests and FMEA results with specifications, including safety and performance standards, to make certain that the desired level of intrinsic quality has been designed into the device. Also, the appropriate design of manufacturing processes, including validation where appropriate, is needed to assure that production can achieve the level of quality designed into the device.
Software is evaluated and reviewed versus the software specifications during the ongoing development of the device design. When a "final" prototype(s) is available, the software and hardware are validated to make certain manufacturer specifications for the device and process are met. Some aspects of hardware evaluation were discussed above. Aspects specific to software are covered below.
Before testing the software in actual use, the detailed code should be visually reviewed versus flow charts and specifications. All cases, especially decision points and error/limit handling, should be reviewed and the results documented.
In all cases, algorithms should be checked for accuracy. Recalls have occurred because algorithms were incorrectly copied from a source and, in other cases, because the source algorithm was incorrect. During the development phase, complex algorithms may need to be checked by using a test subroutine program written in a highorder language, if the operational program is written in a lowlevel language.
The validation program is planned and executed such that all relevant elements of the software and hardware are exercised and evaluated. The testing of software usually involves the use of an emulator and should include testing of the software in the finished device.
The testing includes normal operation of the complete device; and this phase of the validation program may be completed first to make certain that the device meets the fundamental performance, safety and labeling specifications. Concurrently or afterward, the combined system of hardware and software should be challengedwith abnormal inputs and conditions. As appropriate, these inputs and conditions include such items as:
- operator errors;
- induced failure of sensors and cables or other interconnects;
- induced failure of output equipment;
- exposure to static electricity;
- power loss and restart;
- simultaneous inputs or interrupts; and,
- as appropriate, deliberate application of none, low, high, positive, negative, and extremely high input values.
The results of the software and combined device system validation are included in the design reviews.
During verification, the complete device is exercised such that all labeling, displays, and outputs are generated, reviewed, and the results documented. During the verification, all displayed prompts and instructions are checked versus the manufacturer's and FDA's labeling requirements and versus the operator manual.
Printed labeling and screen displays should be checked to see if they are directed to the user and not to the system designers, which is a common fault found in labeling. Displayed text should be short and to the point. Because displays are brief, keywords should be carefully selected to match system characteristics, yet transfer the maximum information to the user. The text of references to controls or other parts of the system should match the labeling on the device. Data, identifications, or other key information displayed should be current, complete, unambiguous, and accurate.
During verification, all prompts and instructions should be followed exactly by the device test or other operators and such action should result in correct operation of the device. Prompts and instructions should appropriately match the instructions in the operator's manual. The evaluation should include verification that any screen or other displays meet the requirements of, and have been approved per, the manufacturer's policy/procedure for design of labeling.
Patient and procedure data on printouts should be correct; therefore, printouts should undergo a verification similar to that performed for the screen or other displays. In addition, the printouts should be evaluated with respect to their "cold" information transfer characteristics. Will the printouts be quickly and clearly understood a few weeks later when the reader is not reading the displays, operating the device, or looking at the patient? All printouts should also meet the manufacturer's design control policy/procedure requirements for labeling. Likewise, patient data or other key information transmitted to a remote location should be correct; therefore, it should be checked for accuracy, completeness, and identification. Annotated copies of verified labeling, printouts, etc. and associated notes and any checklists should be placed in the design history file.
The overall device specifications usually have requirements that cover user/operator error prevention and control. Along with operator training, such errors are controlled by:
- adequate instruction manuals,
- adequate device labels,
- display of adequate prompts and correct instructions,
- status (history) reports,
- exclusion of certain erroneous inputs or actions, and
- adequate human factors design.
Also, for some devices, it may be important to control the order in which data can be entered by the operator. In emergency situations or because of distractions, it may be important to present the operator with a brief history or status report of recent actions. During the verification, the listed items should be evaluated versus the specifications, and checked for completeness and appropriateness. A checklist or matrix may be used to aid in the review of labeling.
The design controls require that each manufacturer shall establish and maintain procedures to ensure that the device design is correctly translated into production specifications.
It is common practice for sections of a design to be transferred before the entire design is completed. The QS regulation does not prevent such split or multiple transfers. Transfer is to be performed only for completed elements of the design -- multiple transfers may not be used to bypass any design, labeling or other GMP requirements.
A significant part of the transfer requirement is met when the design output is being created. That is, some of the design output documents are part of the DMR and are used directly for production. The remaining DMR documents are based on design output information. A procedure is needed to cover the generation of the remaining device master record documents based on information in the design output documents.
Design transfer should assure that the section of the design being transferred:
- meets input requirements;
- contains acceptance criteria, where needed;
- contains design parameters which have been appropriately verified;
- is complete and approved for use;
- is fully documented in the DMR or contains sufficient design output information to support the generation of remaining DMR documents; and
- is placed under change control if not already done.
Design transfer may include training of production, installation and service employees and such training should be covered by or referenced by the transfer procedure.
Changes to a design element are controlled per 820.30(i) Design Changes which states that: 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.
The original design activities and subsequent change control activities for the design are both done under the full set of the quality system design controls. A manufacturer may not use a design change control procedure to bypass part of the design controls. Thus, it is difficult to describe change control before design transfer because both activities are done under design controls.
Most of the details of the change control system are left to the manufacturer to develop, document and implement. As the design activity progresses toward the final stage, it is expected that the degree of change control will increase.
Those elements of the design that have been verified and accepted obviously should be under change control. A design that has been submitted to FDA for marketing clearance should be under change control. A design undergoing clinical trials should be under change control or the clinical data may not be accepted by FDA. A design that is released for production should be under design and general change control.
After design activities are begun and the physical design evolves into an accepted entity, subsequent changes to the device specification(s) are proposed, evaluated, reviewed, approved, and documented per all of 820.30. The revised specification(s) becomes the current design goal in accordance with the manufacturer procedures for: design control, design change control, and document control.
- A design change control procedure should at least cover:
- under what conditions change control is required;
- documenting the reason for the change;
- any differences in the change control process when outside parties are involved;
- analysis of the design to identify other elements that are impacted by the change; and
- for significant changes which includes any change requiring verification and/or validation, placing the reason for the change in the design history file along with the required design verification, validation and review documentation.
Design history file (DHF) means a compilation of records which describes the design history of a finished device [820.3(e)].
The DHF covers the design activities used to develop the device, accessories, major components, labeling, packaging and production processes.
The design controls in 820.30(j) require that each manufacturer shall establish and maintain a DHF for each type of device. Each type of device means a device or family of devices that are manufactured according to one DMR. That is, if the variations in the family of devices are simple enough that they can be handled by minor variations on the drawings, then only one DMR exists. It is common practice to identify device variations on drawings by dash numbers. For this case, only one DHF could exist because only one set of related design documentation exists. Documents are never created just to go into the DHF.
The QS regulation also requires that the DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part. As noted, this requirement cannot be met unless the manufacturer develops and maintains plans that meet the design control requirements. The plans and subsequent updates should be part of the DHF. In addition, the QS regulation specifically requires that:
the results of a design review, including identification of the design, the date, and the individual(s) performing the review, shall be documented in the DHF.
design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.
Typical documents that may be in, or referenced in, a DHF are listed below:
- design plans;
- design review meeting information;
- engineering notebooks;
- component qualification information;
- biocompatibility (verification) protocols and data;
- design review notes;
- verification protocols and data for evaluating prototypes;
- validation protocols and data for initial finished devices;
- contractor / consultants information;
- parts of design output/DMR documents that show plans were followed; and
- parts of design output/DMR documents that show specifications were met.
The DHF contains documents such as the design plans and input requirements, preliminary input specs, validation data and preliminary versions of key DMR documents. These are needed to show that plans were created, followed and specifications were met.
The DHF is not required to contain all design documents or to contain the DMR, however, it will contain historical versions of key DMR documents that show how the design evolved.
Does the DHF have value for the manufacturer? Yes, when problems occur during redesign and for new designs, the DHF has the "institutional" memory of previous design activities. The DHF also contains valuable verification and validation protocols that are not in DMR. This information may be very valuable in helping to solve a problem; pointing to the correct direction to solve a problem; or, most important, preventing the manufacturer from repeating an already tried and foundtobeuseless design.
Design Input Requirements Procedure
A sample Design Input Requirements procedure is presented which covers basic activities for obtaining data on requirements that is needed for employees to develop device specifications. This procedure uses the multiple specification approach; however, a single combined specification would use a very similar procedure. This procedure should be modified to meet specific needs before being adopted by a manufacturer.
C O M P A N Y L O G O
Title: Design Input Requirements Procedure SOP #: ___________ Page:__1_of_2_____
Prepared by:__________________________________ App: ____________ Date:____________
Prep. Date: __________________________________Rev: ____________ Date:____________
POLICY - Design specifications covering all design requirements shall be established for all proposed devices before any significant physical design activities are started.
SCOPE - This policy applies to all devices and accessories developed by the manufacturer or developed by a contractor for us. For purchase of completed designs, refer to SOP ####. The device specification(s) must exist or be generated regardless of the source of the design.
CONFIDENTIALITY - Device development plans and activities are always confidential. Market research reports and documents such as specifications with parameter data shall be marked confidential.
Design control procedures, standard SOPs, blank forms, and required design review and design verification/validation records may be shown to, and may be copied by, FDA investigators as required by the QS regulation. Design parameters are not covered by the QS regulation. Therefore, confidential specification characteristics and parameters in the copies of these documents shall be blacked out unless the document is being collected during an inspection related to a marketing submission.
Marketing and Engineering have the primary responsibility for determining safety and performance requirements and developing input specifications; however, all departments are expected to support the development of input requirements and subsequent specifications.
MARKETING - Marketing shall plan and conduct all customer contacts to obtain information on customer desires, needs, expected pricing, opinions about existing devices, etc.
To the maximum extent feasible, market research shall be conducted in a manner to reduce leaking of manufacturer confidential information and plans.
Design review meetings shall normally precede and follow all significant outside market research activities. Initial market research activities shall be previewed with top management.
Market research results are to be documented and marked confidential.
PRODUCTION - Production has primary responsibility for assuring producibility and establishing manufacturing requirements. Some of these requirements may be general during the early design stages.
ENGINEERING - Engineering is expected to supply design input information on most requirements. Such inputs may parallel data obtained by market research.
Engineering has primary responsibility for specifying what technology to use.
Engineering shall analyze input data on requirements and reduce it to preliminary specifications.
Engineering has primary responsibility for addressing incomplete, ambiguous, or conflicting requirements and shall see that such issues are appropriately discussed at design reviews.
Page 2 of 2
RA & QA - RA and QA managers or their designees shall attend all design input or specification review meetings to provide input on, and to assure that, regulatory, manufacturer, quality, safety, performance, etc., procedures are followed and that requirements are met.
STRUCTURE - Multiple specifications shall be used except for very simple devices. A separate specification shall be developed for accessories, labeling, packaging, etc. An overall device specification shall be developed and shall include an index that points to supporting specifications. The specifications, among other factors, shall address:
1. Performance and Efficacy;
2. Human Factors;
3. Chemical Safety;
4. Electrical Safety;
5. Mechanical Safety;
6. Radiation Safety;
7. Thermal Safety;
9. Device Compatibility;
10. System Compatibility;
11. Environmental Compatibility;
12. Packaging (in a separate specification document);
13. Any FDA design requirements in the Part 801 and Part 1000-1050 regulations; and
14. Labeling in a separate document and, as appropriate, in the device primary specification.
CHECKLISTS - Checklists of requirements germane to our product line may be used to develop and support specifications. If used, such checklists become part of this procedure and part of the design documentation.
DESIGN REVIEW - Each specification shall undergo design review before it is approved for physical design activities or is used as a background document to support further market research. Such reviews shall be documented.
APPROVAL - The Marketing manager and Engineering manager shall approve all input specifications after these have been subjected to design review.
DOCUMENTATION - The approved specifications shall be given document numbers and become part of the device master record for the new device.
CHANGE CONTROL - The Engineering manager shall decide when design activities have progressed to the stage that the various specifications shall be subject to our Design Change Control Procedure. However, for our organization, design change control can start NO later than the FIRST of the following events:
- clearance of a 510(k), or
- start of a clinical investigation.