©2014 Maetrics, All Rights Reserved +
WHITEPAPER: DESIGN HISTORY FILE – FROM INSPIRATION TO REALITY
White paper produced by Maetrics For more information, please contact global sales +1 610 458 9312 +1 877 623 8742 [email protected] With offices around the world www.maetrics.com
2
Introduction Designers and developers working in New Product Development are often busy trying to iron out irksome niggles and glitches to meet launch deadlines. This is particularly the case for small start-ups and/or new spin-out companies. The very concept of fully documenting a Design History File is so far off the radar that it is rarely even considered at all. The importance of a robust Design and Development procedure however, cannot be underestimated. European regulatory authorities require some sort of design history and it does not have to be a hugely cumbersome document or technical article, nor should it be an epic piece of prose. This paper looks to provide a practical guide on the key benefits and processes medical device companies should consider for the implementation of an effective Design and Development procedure that adds value to business operations and meets regulatory needs.
The Process The development of a Design History File (DHF) consists of planning, design inputs, design outputs, defined roles and responsibilities, stage-gate design reviews culminating in validation and verification (see figure 3, page 6). The time spent and the level of detail required should be proportionate to the risk associated with the device. Broadly the device classification from Class I through IIa, IIb and Class III gives a good indication as to where your device will be seen as fitting, with the higher class demanding a greater level of detail. Begin by documenting the inspiration for the initial concept, the driver or the bright idea - literally from the pub conversation you may have had! Work through the initial designs, even sketches if you held onto them, your reasoning for material selection, through to your various prototypes and testing. Do not forget to include the failures; this is an important part of the product’s development story. There is no shame in doing so and they are vital in mapping the design changes that you made as a result of a ‘technical glitch’. Document any bench testing and any other pre-clinical work that may have been conducted.
“Success does not consist in never making mistakes but in never making the same one a second time.”
- George Bernard Shaw
3
Finally, record your validation and verification activities. While often confused and merged into one, these are in fact separate processes. Design verification is the process of ensuring that the design and development outputs conform to the specified design and development inputs. Design validation is intended to ensure that the medical device meets the user requirements and the specified intended use in the hands of the intended user as a finished medical device. Once that is completed, all Design Changes must be controlled and documented in accordance with a robust change control process as part of your Quality System. The earlier medical device innovators develop their DHF, the more likely the process will be a smoother and hassle free journey. Documents should be added to the DHF as and when design developments occur to ensure that facts are recorded accurately. Efficiency savings are also gained as time is not wasted in trying to find information retrospectively. Moreover, for device developers that need an ISO 13485 quality management system, this can be done right from the outset and in conjunction with all the other regulatory procedures, rather than as a separate task at the end of the product development and registration process. By taking a best practice approach (see figure 2) medical device developers can make significant time and labour savings in terms of compliance. The flow charts below highlight the major stages – from the initial idea to registration – and contrast the different approaches to implementing key regulatory and quality procedures. Figure 1. Typical Process – the reality of late DHF development
Idea Development Product Develop Story for DHF Initiate PTF Registration
ISO 13485 for all future products
4
Figure 2. Best Practice procedure – efficiency savings achieved
The Contents A design history file should contain the following information: a. A description of the design history fi le (for instance, that it is a file of quality documents related to a certain device design) and names of the types of documents that it will contain. The DHF must describe the complete history of the design of a particular device or component assembly of a device. The DHF should cover the development of the device, accessories, major components, labelling, packaging and the manufacturing process. Even though every step in the design phase of the device may not be documented, the whole design history should be apparent from the contents of the DHF. The DHF must reference or contain enough records to prove that the design was developed in accordance with a design and development plan and other regulatory and design control requirements. The final design output from the design phase should be present in the DHF either as filed documents or by reference. The documents in the DHF serve as the basis for the device master record. If a company has more than one device design under development, more than one DHF will need to be prepared. Each device family needs its own DHF. If similar devices are simple variants of a single familial design, then a single DHF may be warranted. Each distinct design type should have its own DHF.
Idea • Implement
ISO13485
Development • Log in DHF &
PTF
Product • Log in DHF &
PTF Registration
ISO 13485 for initial & all
future products
5
b. The DHF should contain the design and development plan, results of design reviews, design validation and verification results and any other data needed to show compliance with design requirements. The DHF should contain or reference all of the documents that will demonstrate compliance with the design plan. The design control procedures should also be included in the DHF. c. The DHF serves as a long term memory for the company so that successive generations of workers may understand the history of how the device was developed, what decisions were made and for what reason. It will contain the verification and validation studies and also the safety and failure mode studies that may be referenced in the event that problems develop. The file should be named for the design that it will contain and also be labelled with any product or design codes for the device. Figure 3. Design & Development Process
6
Useful definitions • Design and development planning Design plans are to be initiated and maintained and should describe design and development activities and define responsibilities for implementation. • Design input To 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 in the market(s) in which the product will be marketed. • Design output Documented evaluation of conformance to design input requirements. Needs to contain or make reference to acceptance criteria and identify the outputs that are essential to the proper functioning of the device. These are then confirmed by verification and validation activities. • Design reviews Formal documented reviews of the design results to be planned and conducted at appropriate stages of the devices development. • Design verification Confirmation that the design output meets the design input requirements. • Design validation To ensure that devices conform to defined user needs, intended uses and applicable standards. • Design transfer Ensures device design is correctly translated into production specifications.
7
Conclusion The process of developing a new product is an exciting one. Being caught up in the innovation bubble however can potentially lead to compliance featuring further down the priority list. Taking the best practice approach of the early Design History File and – where needed – quality management system implementation this can result in significant time and cost savings. New and existing medical device developers need to be aware that good regulatory and quality practice can make a real difference to their business. Wherever you are in the product development cycle, being aware of the requirements can ease the headache of compliance later on. There are a number of training courses designed to educate those involved on the requirements for compiling a technical file and what best practice looks like. Making this sort of investment in training early on or working with a third party specialist will ultimately ensure that you give your device the best possible chance for market success.
8
©2014 Maetrics, All Rights Reserved +
Global Acumen From A Single Source
White paper produced by Maetrics
For more information, please contact global sales +1 610 458 9312 +1 877 623 8742 [email protected]
With offices around the world www.maetrics.com
- EU Authorized Representative - Quality Remediation - Global Regulatory Issues, 483s, Warning Letters - CAPA - Regulatory Compliance - Regulatory Submissions - Quality – Audits & Assessments - Quality – System Implementation & Process Improvement - Validation – Strategies, Planning, & Execution - For all types -process, software, test method, etc. - Complaints, Adverse Events & Recalls
- Sterilization/contamination control - UDI - Supply chain management - Make/buy, distribution, test/quality, functions & delivery - Supply Chain Risk Assessment - Supplier Quality – Auditing, Qualification & Management - Commissioning Of Facilities & Utilities - Manufacturing engineering services - Post-market surveillance - Mock FDA Inspections - Implementation & Validation Of Software Systems - Organizational change management - Maetrics U – Quality Training
