Medical device design controls are the regulations that govern the development of medical devices. The FDA established design controls in 1997 because they found that manufacturing controls alone were not sufficient. The FDA recognized that many patient injuries and deaths were the result of medical devices with fundamental design flaws (i.e. no matter how carefully they were manufactured, the devices would still be dangerous). That was 25 years ago, so design controls must be very well understood by the medical device industry now, right? Well, unfortunately no. In this blog post and the next, I’ll try to dispel some major misconceptions about design controls and point out specific ways they can be misapplied to undermine good product development.
FDA design controls (21 CFR 820.30) consist of the following eight elements:
- Design and Development Planning – setting up the project for success
- Design Input – what does the product need to do?
- Design Output – what the product is
- Design Review – are we on the right path?
- Design Verification – does the output conform to the input?
- Design Validation – does the product meet user needs?
- Design Transfer – getting the new product into manufacturing
- Design Changes – improving the product
The documented results of following these design controls are all recorded in the Design History File (DHF), which describes how we ended up with the final product (and constitutes proof we did all of the above). Note that there are comparable design control requirements in the ISO 13485 international standard for quality management (section 7.3) with some differences.
Although the formal terminology of design controls may appear odd to many people, these are really just good product development practices. Properly implemented, design controls provide a rigorous framework to integrate the work of multiple disciplines to produce safe and effective new medical devices. And interpreting them from the viewpoint of creating high-quality medical devices will help you avoid some of the worst mistakes in design controls.
People who have never developed a product under design controls may not realize how detailed they are and how challenging it is to comply with them, especially when developing medical devices with software. And people who do have experience with design controls may nevertheless not understand their purpose. To them, complying with design controls may seem like just a big distraction from the real, more familiar work of product development.
Misconceptions About Design Controls
First, design controls are not just a bunch of documents! (that the Quality department insists you produce at various stage-gates during development) Design controls are a set of interdependent activities (processes) we use to ensure the development of safe and effective medical devices. The documents that result from those activities provide the objective evidence to show compliance and to submit to the FDA and other regulatory bodies for product approval. Design controls are processes we use to ensure safe and effective medical devices. The activities defined in those processes all produce documentation, for an audit trail, which is the most visible part of design controls but is not the core.
Second, design controls are not the same as a product development process; the design control regulations were never intended to be interpreted literally as a recipe for developing medical devices. Design controls are mandated for the development of every Class II and Class III medical device but how they are implemented can vary considerably from company to company. Each medical device company needs to first determine the optimal product development process for their organization and products then fit the design controls to that overall process. For example, the implementation of design controls at a company developing sterile disposable medical devices will be different than for another company developing an ultrasound imaging system or for a small medical startup versus a very large company with thousands of employees across multiple locations. Design control procedures need to be implemented to fit each organization and the types of medical devices it produces. And design controls need to evolve as the organization, its products, and applicable regulations and standards change. As a consultant, I’ve worked on the development of a wide variety of medical devices. I can tell right away when a company has inappropriately copied design control procedures from another company (a different organization with different products) instead of tailoring them to their own needs.
Figure 1: Outline of the Elements of Design Controls
(Note: this is NOT a product development process!)
Third, design controls are fundamentally about good knowledge management during the development of a new medical device. By the end of development, the resulting Design History File (DHF) should become a detailed knowledge base about the product design and its clinical application. This knowledge base can serve as a valuable resource for managing the product throughout its lifetime. Some people still seem to think that design controls are only for compliance–that they don’t have anything to do with “real” product development. Unfortunately, this can result in many hours spent writing documents devoid of crucial knowledge about the medical device. Most auditors can tell right away if your DHF documentation is for real or just a facade of compliance, so you’ll probably fail an audit and have wasted lots of time on useless documents.
My recommendation is to view it this way: DHF = compliance + knowledge base
In other words, a completed DHF is necessary for regulatory compliance but is also valuable as a systematic way to archive complex product data, risk analysis insights, usability results, test methods, and other crucial knowledge.
Terminology Mistakes: DHF vs. DMR vs. DHR
An unfortunate quirk of medical device regulations is that we’ve ended up with 3 acronyms that sound almost the same but have very different meanings. This table summarizes the differences between DHF, DMR, and DHR. Understanding the differences is important to understand design control regulations (and has the added benefit that you can sound more knowledgeable at the next meeting when you correct your colleague’s terminology).
Name | Design History File (DHF) | Device Master Record (DMR) | Device History Record (DHR) |
Purpose | How we ended up with this design | What it is and how to manufacture it | How each one was built (per the DMR) |
Example Content | Product Requirements, Hazard Analysis, electronics schematics, mechanical drawings, V&V testing documents, Design Review records | Assembly instructions, purchasing specs, component specs, manufacturing equipment design, process validation, facilities specs | Date of manufacture, Device identification and control numbers, manufacturing inspection and test results |
Managed By | Engineering and Quality | Manufacturing and Quality | Manufacturing and Quality |
Additional Notes | The Design Outputs in the DHF form the basis for the DMR | The DMR contains all the information to enable transferring manufacturing from one facility to another | For products that are managed by lot, this becomes the Lot History Record (LHR) |
There is one DHF per product or family of products. There is one DMR per product. This means that you can have a single DHF driving multiple DMRs (e.g., for multiple versions of a product), but you should never have multiple DHFs driving a DMR. And there is one DHR per individual device manufactured (or one LHR per lot of devices). For capital equipment such as a CT scanner which is maintained and upgraded over its lifetime, the DHR also records the maintenance and upgrades.
Navigating Design Space (Big Picture of Design Controls)
The development of an innovative new medical device can be viewed as an exploration of “design space” where the product team evaluates multiple design options and refinements before settling on the final design to bring to market. In this context, design controls govern key aspects of development and the Design History File (DHF) records the “voyage” of the product team, especially changes in direction. By the time of product launch the DHF will not only describe “how we ended up with this design” but it should also become a valuable knowledge base that can be used in making informed decisions about the product throughout its lifetime.
Figure 2: Navigating Design Space
Changes in “design direction” are crucial to record in the DHF. However, some companies I work with seem to record every little change to documents ( = many hours spent redlining in Microsoft Word) without recording the most important product design changes! And then they wonder why the DHF is missing the “why” for the product design (and often struggle to explain this to an auditor). That’s why I recommend thinking about medical device development as a journey and the DHF as a way to map out the journey, and not just the final design.
So what if the product team only documents the final design (the endpoint in this diagram)? Well, initially it would appear to be sufficient to start manufacturing the new medical device. However, as soon as any design changes need to be made (e.g., because of a change in suppliers, feedback from customers, or to streamline the manufacturing process), there isn’t any background information to guide the changes. Will the revised product still be safe and effective? It’s hard to know without fully understanding how the original development ended up with the original product design. And of course, this is assuming the team does a perfect job of creating all the documentation at the end of development, which is highly unlikely (translation: repeatedly failing future audits).
Properly implemented and understood, design controls can provide a robust framework for your product team to develop an excellent new medical device. In the next blog post I’ll describe multiple ways that improperly implemented design controls can delay and frustrate your product team.
Additional Information
For more information on the basics of medical device design controls I recommend the following:
Ultimate Guide to Design Controls – an excellent overview, written in plain English with lots of practical advice by Jon Speer from Greenlight Guru
Design Control for Medical Devices – a short video tutorial on the basics by Peter Sebellius of MedicalDeviceHQ, with additional info about European regulatory compliance