The United States Food and Drug Administration recognizes that with devices, the majority of serious problems are introduced during the design / change phases of development of new or changed products. Changes to existing products are addressed under Change Control, Engineering Change Orders, and similar required cGMP procedures. In the mid 1990s, it was recognized that the design of new product or major changes / line extensions to existing products was not well controlled. Recognizing this issue led to a solution: Design Control.
Formal Design Control and Design History File (DHF) requirements (both a part of GMPs) were instituted by the FDA in 1996-1997. Not only are these requirements "must dos" because of regulations but they serve companies in the retention of their IP (intellectual property) via the proper documentation of development and changes and via the creation of false starts records, blind alleys and similar development "dead ends." If done properly, it can provide a valuable training tool for engineering, manufacturing, QA and marketing personnel.
This article is related to the White Paper:
Reducing the Documentation Burden in FDA Design Control Process.
To get the full details, please download your free white paper.
Design Control mandates a formal, defined "Start Date." A repeatable system for many companies is usually to designate the "start" of formal design control as the time when senior management makes a medical device research effort a formal project and begins to budget for and/or make major expenditures to commercialize it (either internally or with the idea of selling off the technology).
The key elements of Device Design Control involve the following elemets, which are heavily based on the above cited FDA source:
Design plans are to be initiated and maintained, and should also describe or reference design and development activities and define responsibility for implementation. This may consist of Gantt Charts, defined milestones, tasks, timelines and responsibilities. Plans should also be updated periodically.
Product developers ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user / clinician and patient, the use environment, as well as meeting the requirements of any applicable standards mandated in the market(s) in which the product will be sold.
The developer is also responsible to establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements. Design output procedures shall contain or make reference to acceptance criteria and identifies those design outputs that are essential for the proper functioning of the device. These are then confirmed by verification and validation activities.
Formal documented reviews of the design results are to be planned and conducted at appropriate stages of the device's development. Participants at each design review are to include representatives who can consult and review when they have expertise or input regarding the various stages of design (e.g, one representative may only review one stage, another would consult during a second stage, etc). Also required is an individual(s), who does not have direct responsibility for the design stage, and can provide an independent "voice." Participants in such review teams may change as development progresses.
Verifying, testing, and/or inspecting the device design to confirm that the design output meets the design input requirements (see Validation, below) must be performed on product as close to production as possible. Even actual production samples can be used. Verification steps may involve biocompatibility, sterility, functional testing, packaging / shaking / dropping / shipping and accelerated ageing studies. Electronic products have their own series of tests required by various standards for safety, electromagnetic compatibility (emitting and receiving) and similar.
Design validation is to be performed under defined operating conditions on initial production units, lots, batches or any of their equivalents (use of early stage prototypes are to be avoided since this weakens the validation purpose). The purpose of design validation activities is to ensure that devices conform to defined user needs, intended uses and applicable standards. Such validation will include testing of production units under actual or simulated use conditions, with such products having been built in a production environment using production / test equipment, and production personnel. Carelessness in these requirements has often resulted in future product recalls.
Design validation shall include software validation where appropriate and device risk analysis (re: ISO 14971:2007 and ICH Q9). 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 transfer used to be a major source of quality problems but as companies have moved from "throwing a design over the wall" to cross-functional teams involving R&D, Engineering, Manufacturing, QA/RA and Marketing, such issues have been basically eliminated. Whatever development system is used, the manufacturer ensures that the device design is correctly translated into production specifications. Production specifications then ensure that manufactured devices are repeatedly and reliably produced within product and process capabilities. The process of encapsulating knowledge about the device into written production specifications to which product is periodically tested / inspected / verified against, is critical to device quality.
The system must support the identification, documentation, verification / validation, review, and approval of design changes before their implementation. In "design control" there are the two principal administrative elements / activities of document control and change control involved in the controlling of design changes:
All these activities described above are documented in the product's Design History File.
The DHF is compiled for each type of device. The DHF contains or references the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of the FDA's design control, as described above. Such development documentation also needs to be properly witnessed where appropriate and thus may also serve in supporting patent claims.
Design and development contracts should explicitly specify the manufacturer's right to design information, as well as define and establish standards for the form and content of design documentation. This would include custom software as well. Finally, certain basic design information may be maintained in a single project file in a specified location or a basic DHF document with pointers to other supporting documents not directly/physically included in the DHF (including dates / revision numbers).
The completed product DHF may include the following:
The DHF is mandated by the U.S. FDA, and describes a product through its development cycle, under Design Control, with its output being the DMR (Device Master Record) which defines the product as currently marketed. However, the EU (European Union) under the Medical Device Directive (MDD; EU Council Directive 93/42/EEC) and for CE-Marking, requires a file describing the product at a point in time, i.e., as currently marketed in EU / Common Market countries, similar to the DMR, with elements of the DHF, such as risk management documents, and clinical data. Generally the Technical File (TF) addresses product that is MDD Class I and Class IIa or IIb, while the (Design Dossier) DD addresses product that is MDD Class III. These files consist of the following basic sections to support the Medical Device Directive (MDD), Essential Requirements (for that product), and the company's "Declaration of Conformity" for that product:
Newer EU regulatory guidance documents are moving the TF/DD more in the direction of the DHF. However, a review of both descriptions above shows much commonality already, allowing the development of both files (DHF and TF/DD) almost concurrently, while supplementing the DHF with the DMR for a current TF/DD.
John Lincoln is principal of J. E. Lincoln and Associates, a consulting company with over 28 years experience including 16 years as a full time consultant, serving U.S. FDA-regulated industries. John has worked with companies from start-ups to Fortune 100 in the U.S., Mexico, Canada, France, Germany, China, and Taiwan. He specializes in medical device CGMPs / systems / SOPs, product to market, defect and cycle time reduction, equipment / process / product / software documentation / validation, quality/regulatory management, product risk / ISO 14971, product clearance and regulatory issues resolution. He's held assignments as VP R&D, Director of QA/RA, senior QA engineer, senior manufacturing engineer, working for such companies as Abbott Laboratories and Mallinckrodt Medical. Additional experience has been in government (civil and military), aerospace and electronics industries. He has published numerous peer-reviewed articles on culture change, training, biohazards, quality, regulatory affairs, CAPA, and validation. He conducts webinars, workshops and training worldwide. He has a BA from UCLA. Contact him at http://www.jelincoln.com, by email: firstname.lastname@example.org or by phone: 435.882.4655
Watch Related Videos