In this article you will learn tips and best practices for creating and maintaining your DHF (i.e., Design History File).

What is a DHF?

DHF is an acronym for design history file. The US FDA is the only country that specifically includes this in medical device regulations (i.e., 21 CFR 820.30j). Other countries simply require that you maintain records of design and development. The DHF is a file, virtual or physical, that includes all the records of your efforts to design and develop a medical device. You could create an index for a DHF that includes all of the most recent versions of the documents pertaining to the design of your device, but that is called a Device Master Record or DMR (i.e., 21 CFR 820.181). Another term for the DMR is “technical file” or “medical device file.” The FDA will be adopting the term “medical device file” as part of the Quality Management System Regulation (QMSR), and the definition for a DHF will become obsolete February 2, 2026.

What’s the difference between a DHF, DMR, and DHR?

The US FDA loves acronyms, but overuse of acronyms leads to confusion. The acronyms DHF, DMR, and DHR are the three most commonly confused acronyms in the medical device industry. One of the simplest solutions is to stop using acronyms and to rename each of these documents so that they are no so confusing. Instead of design history file, or DHF, start referring to this file as a record of new product development. That record consists of thousands of pages covering a year or more of design and development activity by your new product development team. Instead of device master record, or DMR, start referring to this as your medical device file or technical file. Clause 4.2.3 of ISO 13485:2016 is specific to this record. It is intended to be a living document that you will update each time you make a design change. Instead of device history record, or DHR, start referring to this as your batch record or lot record. This is a file containing all of the records, or cross-references to records associated with the manufacturing and inspection of a batch or lot of devices. The batch record or lot record will be reviewed for completeness, accuracy, and to ensure all inspection and testing passed. Often a release checklist is used to ensure consistency of this review, and the checklist will be signed and dated by the person that releases the batch or lot for distribution. For sterile products, this is done after sterilization and sterile product is quarantined until release.

Regulatory Requirements for a Design History File (DHF)

The requirements for a design history file (DHF) are found in 21 CFR 820.30(j):

“Each manufacturer shall establish and maintain a DHF for each type of device. 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.”

 There is also a definition for a DHF found in 21 CFR 820.3(e):

“Design history file (DHF ) means a compilation of records which describes the design history of a finished device.”

The FDA provided an official interpretation of this requirement in the preamble when the QSR was published in 1996. That discussion of the requirement indicated that the DHF is intended to be a repository of the records required to demonstrate compliance with your design plan and your design control procedures. The discussion also indicates that the same DHF may be used for minor variations of a device such as size differences. Most manufacturers will organize the DHF in a binder and organize the binder chronologically to match a design project plan, however, most do not create a DHF template. Meeting minutes from each design meeting are typically included as an appendix to the DHF, while reviewed and approved documents such as the design plan, design inputs, design outputs and records of design reviews typically comprise the bulk of the DHF. Manufacturers also typically will conduct an internal auditor of active DHF binders in order to ensure that design projects are following the approved design plans.

Why you should never use a DHF template

The DHF is is intended to provide evidence of following an approved design plan, but the DHF consists of many records–not just one record. A DHF template could be created to follow a standardized design control process, but most manufacturers write a generic design procedure that allows and encourages the design team to customize the design plan to match the needs of each development project. Therefore, design plans may have different numbers of design reviews and very different testing activities prior to the start of the design transfer process and during design verification and validation.

For a device master record (DMR), I recommend creating a DMR Index using a template that is organized in accordance with an international standard to meet the needs of a DMR and a Technical File. The DMR is a living document that only shows the most current design outputs for a device while a DHF may require repeating various verification and validation testing if the initial design fails to meet acceptance criteria and a design change is required prior to the final design review and approval of commercial release. The need for including this variability eliminates the advantages of a template.

What is the purpose of the DHF?

The purpose of the DHF is to provide objective evidence that the design and development team followed design controls in order to develop a medical device. FDA inspectors review the DHF to make sure that the design process is effective by verifying that known hazards were identified, and appropriate design inputs (i.e., test requirements) were approved. The design specifications should demonstrate that risks were reduced as far as possible by implementing design solutions, protective measures, and by providing warnings and precautions of residual risks to users and patients. Verification of design inputs and validation of user needs comprise the bulk of your DHF in the form of testing protocols and reports. Inspectors will review your design transfer activities to ensure that the output of manufacturing consistently meets your design specifications. Design reviews meeting minutes will be sampled to verify that you included an independent reviewer and the design team completed all activities planned in your design plan. FDA inspectors will verify that your design team has adequate training on design controls and the relates processes. Finally, the FDA will look for justifications and updating of design documentation for the design changes your team made during the design process.

Where should you document design changes?

Product design changes that occur prior to the final design review and approval of commercial release are required for inclusion in the DHF. However, once a product is released the control over design changes should be tighter and regulatory submission of changes may be required. Therefore, I recommend documenting post-market design changes in the DMR Index for a device as part of the revision history. I treat the DMR Index as a controlled document and any post-market design changes are reflected in the revision history with a reference to the design change approval (e.g., ECN 123 – addition of UDI label to product labeling). The other advantage of this approach is that all post-market design changes that must be documented for a design dossier are summarized in the revision history of the DMR Index and the DMR Index will serve as a Technical File/Design Dossier.

Training Webinar

If you are interested in learning more about design history files, we recorded a DHF training webinar. The webinar explains how and when to create a design history file (DHF). After you create a design control procedure, you can show the recording of this webinar to your design and development team to ensure that design and development documentation is compliant and updates are efficiently maintained. We are in the process of updating this webinar and it will be hosted live in September.

The Waterfall Diagram was copied by the FDA from Health Canada and ISO 9001:1994, but everyone actually uses an iterative design process.

Iterative Design – What is it?

The FDA first mandated that medical device manufacturers implement design controls in 1996. Unfortunately, in 1996 the design process was described as a linear process. In reality, the development of almost every product, especially medical devices, involves an iterative design process. The V-diagram from IEC 62304 is closer to the real design control process, but even that process is oversimplified.

What is the design control process?

The design control process is the collection of methods used by a team of people and companies to ensure that a new medical device will meet the requirements of customers, regulators, recognized standards, and stakeholders. With so many required inputs, it is highly unlikely that a new medical device could ever be developed in a linear process. The design control process must also integrate risk management and human factors disciplines. ISO 14971:2019, the international risk management standard, requires conducting optional control analysis. Option control analysis requires evaluating multiple risk control options and selecting the best combination of risk controls for implementation. The human factors process involves formative testing where you evaluate different solutions to user interfaces, directions for use, and training. This always requires multiple revisions before the user specifications are ready to be validated in summative usability testing. Process success is verified by conducting verification and validation testing. The process ends when the team agrees that all design transfer activities are completed, and your regulatory approval is received.

Where did design controls come from?

The diagram above is called the “Application of Design Controls to Waterfall Design Process.” The FDA introduced this diagram in 1997 in the design controls guidance document. However, the original source of the diagram was Health Canada.

This diagram is one of the first slides I use for every design control course that I teach because the diagram visually displays the design control process. The design controls process, defined by Health Canada and the US FDA, is equivalent to the design and development section found in ISO 13485 and ISO 9001 (i.e., – Clause 7.3). Seven sub-clauses comprise the requirements of these ISO Standards:

• 7.3.1 – Design Planning
• 7.3.2 – Design Inputs
• 7.3.3 – Design Outputs
• 7.3.4 – Design Reviews
• 7.3.5 – Design Verification
• 7.3.6 – Design Validation
• 7.3.7 – Design Changes

In addition to the seven sub-clauses found in these ISO Standards, the FDA Quality System Regulation (QSR) also includes additional requirements in the following sub-sections of 21 CFR 820.30: a) general, h) design transfer, and J) Design History File (DHF). If you need a procedure(s) to comply with design controls, we offer two procedures:

1. Design Controls (SYS-008)
2. Change Control (SYS-006)

The change control process was separated from the design controls process because it is specific to changes that occur after a device is released to the market. We also have a training on Change Control.

Free Download – Overview of the Design & Development Process

What are the phases of the Design Control Process?

Normally, we finish the design control process by launching your device in the USA because this is when you should close your Design History File (DHF). However, if you are going to expand to different markets, there is a specific order we recommend. We recommend the US market first because no quality system certification is required, and the FDA 510(k) process is easier than the CE Marking process due to the implementation of the MDR and the IVDR. The Canadian market is the second market we recommend because the Canadian Device License Application process for Health Canada is even easier than the 510(k) process for Class II devices. The Canadian market is not recommended as the first country to launch because Health Canada requires MDSAP certification for your quality system, and the Canadian market is 10% of the US market size. The European market should probably be your last market because of the high cost and long timeline for obtaining CE Marking. Each of the phases of design and development is outlined in the first column of our free download, “Overview of Regulatory Process, Medical Device Development & Quality System Planning for Start-ups.”

Which regulatory filings are required during each phase of design and development?

The second column of our free download lists the regulatory filings required by the FDA for each phase. Generally, we see companies waiting too long to have their first pre-submission meeting with the FDA or skipping the pre-submission meeting altogether. This is a strategic mistake. Pre-submission meetings are free to submit to the FDA, and the purpose of the meeting is to answer your questions. Even if you are 100% confident of the regulatory pathway, you know precisely which predicate you plan to use, and you know which verification tests you need to complete, you still have intelligent questions that you can ask the FDA. Critical questions fall into three categories: 1) selection of your test articles, 2) sample size justification, and 3) acceptance criteria. Even if you don’t have a complete testing protocol prepared for the FDA to review, you can propose a rationale for your test article (e.g., the smallest size in your product family). You can also provide a paragraph explaining the statistical justification for your sample size. You might also present a paragraph explaining the data analysis method you plan to use.

The following example illustrates how discussing the details of your testing plan with the FDA can help you avoid requests for additional information and retesting. Many of the surgical mask companies that submitted devices during the Covid-19 pandemic found that the FDA had changed the sample size requirements, and they were now requiring three non-consecutive lots with a 4% AQL sample size calculation. If the company made a lot of 50,000 masks, they would be forced to sample a large number of masks, while a lot size of 250 masks allowed the company to sample the minimum sample size of 32 masks.

If the regulatory pathway for your device is unclear, you might start with the submission of a 513(g) submission during the first phase of design and development. After you have written confirmation of the correct regulatory pathway from the FDA, you can submit a pre-submission meeting request to the FDA. If the pathway for your device is a De Novo Classification Request, you might have a preliminary pre-submission meeting to get an agreement with the FDA regarding which recognized standards should be applied as Special Controls for your device. While waiting 70+ days for your pre-submission meeting with the FDA, you can obtain quotes from testing labs and prepare draft testing protocols. After the presubmission meeting, you can submit a pre-submission supplement that includes detailed testing protocols–including your rationale for the selection of test articles, sample size justification, and the acceptance criteria.

What quality assurance documentation is required during each phase?

In addition to testing reports for your verification and validation testing, you will find many other supporting documents you also need to prepare. We refer to these supporting documents generically as “quality assurance documentation” because the documents verify that you meet specific customer and regulatory requirements. However, the documents should be prepared by the person or people responsible for that portion of your design project. For example, every device will need a user manual and draft labeling. Even though you will need someone from quality to complete a regulatory checklist to ensure that all of the required symbols and general label content are included, you will also need an electrical engineer to prepare sections of the manual with EMC labeling requirements from the FDA’s EMC guidance document. In your submission’s non-clinical performance testing section, you must include human factors documentation in addition to your summative usability testing report. For example, you will need a use specification, results of your systematic search of adverse events for use errors, a task analysis, and a Use-Related Risk Analysis (URRA). Software and cybersecurity documentation includes several documents beyond the testing reports as well.

Which procedures do you need to implement during each development phase?

The last column of our free download lists the procedures we recommend implementing during each phase of the design process. In Canada and Europe, you must complete the implementation of your entire quality system before submitting a Canadian License Application or CE Marking application. In the USA, however, you can finish implementing your quality system during the FDA review of your 510k submission or even after 510k clearance is received. The quality system requirement is that your quality system is fully implemented when you register your establishment with the FDA and begin distribution.

This article describes best practices in managing your design change control process, including a list of the ten most common mistakes.

During every visit by FDA inspectors, and CE Marking auditors, the changes you have made will be reviewed. The focus by inspectors and auditors is: 1) to verify that your design verification and validation was adequate for the changes, and 2) to verify that necessary regulatory approval of the changes was obtained. Due to this scrutiny, your design change control process is one of the most important processes to manage well.

Ten most common mistakes in managing design change control

1. Failure to carefully update drawings and specifications. Often these errors are typos, but it is essential to perform a thorough review of all your drawing dimensions, tolerances, notes, etc.
2. Failure to update procedures and work instructions, especially inspection instructions. As a quality system becomes more mature, it becomes harder to identify all the places where a reference is found. If you have a 100% electronic quality system, with the ability to include cross-references, finding the related documents is easier. MasterControl uses “info cards.” It is possible to do this in any system by adding tags to your master document list. The “tags” can be standards, regulations, other procedures, and forms.
3. Failure to validate inspection methods. Often a new inspection tool or method may appear to be better, but it is important to re-validate inspection methods whether you are changing: 1) design, 2) inspection tools, or 3) inspection methods. A Gauge R&R study is an example of one method for the validation of inspection methods.
4. Failure to re-verify and re-validate your design. In general, whenever you make a design or process change, you need to repeat your verification and validation that was initially performed. You may be able to abbreviate the verification and validation testing. Still, if you cannot provide a justification for the abbreviated method, then you should use the same method and the same acceptance criteria. This presents an enormous burden for any device that required a clinical study to demonstrate safety and effectiveness. This is also why it is so expensive to implement changes in CE Marking for Class III devices, and FDA approved Class III PMA devices. In both cases, there is typically a large supplement required for regulatory approval.
5. Failure to update your risk management documentation and post-market surveillance plans. Risk management files and post-market surveillance plans are meant to be “living documents.” Therefore, whenever you make changes, even minor ones, you should document your evaluation of the need to update the risk management file or your PMS plan. If the changes planned are related to a CAPA or recall, it is critical to verify the effectiveness of the changes made. This verification is both verification of the design change and the effectiveness of your risk controls. It will also be critical to document the change in the PMS plan by identifying potential confusion and use errors associated with your change.
6. Failure to change UDI. Most companies created their change control procedure in the early stages of their quality system, and very few revisions and updates are made to the change control procedure and associated forms. Your UDI process and procedure are probably much more recent, and many companies forget to add UDI requirements to their change control process. It is important to update your device identifier, not only for regulatory compliance but also as a tool to help your company better track which quality issues are related to the previous version of your device and which quality issues are limited to the new version.
7. Since the EU MDR requires that DI portion of your UDI is included in your Declaration of Conformity, this is another document to make sure you update when you make a design change. I recommend identifying the date (or lot) of first CE Marking and last CE Marking for your previous version in an updated Declaration of Conformity. Then you will also need the date of first CE Marking for the new version of your product. This can create a very long and complicated declaration. Still, it is important to control these transitions in anticipation of potential complaint investigations during the period of time when both versions are in distribution/use.
8. Failure to update your technical file and device master record (DMR). Every time you change a drawing, specification, tolerance, testing method, etc. you need to update your technical documentation and DMR. This is why using a Technical File Index, and DMR Index are considered best practices. These tools just list all the related controlled documents and the current revision. The best indices will also identify how revisions were controlled (e.g., change notification or design change order). You might even identify which CE Certificate or 510(k) clearance is associated with each item in the index. This is especially helpful when you have multiple accessories involved. FDA inspectors will verify that you updated your DMR, and they will review the MDR for design changes that were not adequately validated. Your Notified Body will also review changes made to your Technical File to make sure you have notified them of changes or obtained prior approval to commercial release.
9. Failure to document your rationale for no new regulatory approval. Whenever you make a change, you need to document your rationale for whether a new regulatory submission is required. You should have a systematic method that is documented. The FDA has published two guidance documents with decision trees to assist with this decision for 510(k) cleared products: 1) Deciding When to Submit a 510(k) for a Change to an Existing Device, and 2) Deciding When to Submit a 510(k) for a Software Change to an Existing Device. For CE Marking and Canadian Licensing, there are guidance documents on determining when a submission is required for significant changes. Regardless of your decision, you need to document the decision, and the form you use to document this decision should be a controlled form within your change control process.
10. Failure to notify suppliers of your changes. Whenever you make a change, it is critical to notify your suppliers of the change. However, you also need to determine if the change may impact any open purchase orders. Will you need to rework or scrap any work in progress? Will you need to coordinate the use of components so that all components are used up before the change? There may even be obsolete inventory that you need to disposition as “use-as-is” or “rework.”

Create controlled templates for verification and validation testing

For every verification and validation test that you perform, you should have some kind of documented testing plan or formal protocol. Plans are more appropriate when the testing will be outsourced to a lab that has their testing protocols. If you are performing the testing in-house, you should have a formal protocol that references any internal testing work instructions that may be relevant and any testing standards that apply. The protocols should also be designed for “fill-in-the-blank” use to facilitate reuse of the protocol for multiple devices. Protocols should also identify the following required elements: 1) facilities needed for testing, 2) calibrated devices needed for measurement, 3) any controlled documents or standard referenced in the protocol, 4) sample requirements, 5) acceptance criteria, and 6) statistical rationale for sample sizes. The FDA also released a guidance document defining the format and content for testing reports. Whenever a standard is revised, it will also be important to assess the impact on current regulatory approval. CE Marked products will need to be retested to the new standards, or at least a scientific justification must be provided. By maintaining these plans and protocols as controlled documents, you will be able to execute testing plans and protocols much more quickly and consistently. You may also want to consider maintaining an appendix for testing plans that identifies any vendors and contacts for obtaining quotations for new testing.

Organizing design change control approval forms

One of the biggest mistakes people make is to try and streamline questions down to checkboxes or yes/no questions. For example, don’t ask the question, “Is 510(k) clearance required for this change?” Instead, require the person always to fill out a form to document the decision for whether a 510(k) is required or not–which should also be a controlled form. Don’t ask the person if there is an inventory that is affected by the change. Instead, ask the person to identify how many units are at each stage of the process (i.e., pending purchase orders, inspection quarantine, and finished good inventory). Then ask the person to identify the disposition for the product at each stage. This would typically be documented with a nonconforming material record (i.e., NCMR). You should also define which roles and responsibilities complete each part of your form unless you have a small company where key individuals are responsible for multiple roles.

Who should approve design changes?

There is no specific requirement for who must review and approve changes, but each document that is revised and updated will need to be reviewed and approved by the same functions that approved the previous version. Therefore, it would make sense that the same functions that reviewed and approved the design in a final design review should also be involved in the review and approval of a design change for the same device. There is no requirement for an independent reviewer for design change review and approval. Still, I have observed so many mistakes, and I think an independent reviewer and approver are extremely valuable for design changes.

What if you are facing a deadline

There is always pressure from peers and superiors to release design changes to the market as soon as possible. In theory, everything new is better, but this is often untrue. Forcing everyone to follow your change control process is intended to prevent the release of a product that is not ready for release. Therefore, you should fill out as much of your design change approval form at the beginning of a design change as possible. This will help everyone identify the documentation updates at the beginning. All the documentation and testing that is required should be planned, target dates for completion of each update should be documented, and the person responsible for each updated document should be identified. By documenting your plan and maintaining that plan, everyone will know what needs to be completed before a modified device can be released. By controlling the changes in this way, it becomes the responsibility of the whole team to make sure the responsible person and on-time complete each document. If you adopt this strategy, more device changes will be released on-time. You will also find that fewer mistakes will be made, and the team will share the burden of meeting launch deadlines.

Are “full” design controls required?

For minor design changes, you don’t want to apply “full” design controls and create a new design history file (DHF). However, you may want to create a shorter version of a design plan to document what level of control is required and how the project will be managed. This could be as short as a page, but it is likely to be several pages. The following is a list providing examples of things you might document in the abbreviated plan for control of design changes:

1. Previous regulatory approvals [e.g., 510(k) number]
2. Applicable Technical File or DMR Index that will be updated
3. Any new risks identified
4. Any new applicable standards
5. Approved Design Inputs (indicate if changes are needed)
6. Design Outputs that need to be updated (consider highlighting in your DMR index)
7. Changes to your supply chain (e.g., process changes, supplier changes, supplier quality agreements, and process changes)
8. Process validation and Revalidation required
9. Labeling and UDI changes
10. Obsolescence of inventory and reverse/forward compatibility of components
11. Impact on service procedures and/or providers
12. Changes and changeover of internal calibrated tooling and testing stations

What if you are making a design change before a product is commercialized?

The quality system requirement for control of design changes also applies to changes made before the release of a product. During the design process, changes made before “design freeze” will be frequent. For these changes, you want to make the process as simple as possible. Once you begin purchasing capital equipment and performing verification or validation testing, now the design changes are costly. This is when you really must have tight control of changes. Many companies designate that drawings and specifications have begun design transfer when the revision changes from a number (e.g., 1, 2, 3) to a letter (e.g., A, B, C). This helps identify any documentation that will now require tighter design change control. If the design is being conducted internally, then a representative of top management may need to approve changes. If a contract design firm is conducting the design, then approval by the customer may be required for any changes during design transfer.

Additional design change control resources

If your firm needs a procedure for design change control, please visit our webpage for our Change Control Procedure (SYS-006). If you are interested in Design Controls, before the release of a product from the design process, please visit our webpage for the Design Change Procedure (SYS-008).

This article identifies one overlooked secret to accelerating design projects that you can implement immediately, and it will work on every project.

You would love to cut a few weeks off the launch schedule for your device. If you had a magic wand, what would you wish for? The trick to accelerating design projects is not an unlimited budget, hiring ten more engineers, or paying a Nationally Recognized Testing Laboratory (NRTL) to only work for you.

I know a secret for accelerating design projects that will work, but first, you need to understand why projects take as long as they do. Yes, I worked on a few design teams, but I learned the most from watching companies make mistakes that created delays and cost them time. Sterility tests can not be made shorter, guinea pig maximization tests (GPMT) can’t be completed in four weeks, and your electrical safety testing report will not be delivered when the lab promised it would be.

Accelerating design projects by preventing testing delays

The primary source of delay is not that testing is delayed, but rather the testing is not started as early as it could be. Some managers believe that the solution is to use a Gantt chart. Unfortunately, Gantt charts are not a solution. Gantt charts are just tools for monitoring projects. There is much more to project management. If you forget to do just one test, your entire project will be delayed until that test is finished. Therefore, making sure you identify every required test is an essential early project task–even before you start designing your device. You also need to update the plan when things change.

Start with a generic template for your testing plan

Our firm has a template for a device testing plan that we use for every pre-submission request. Getting help in creating your testing plan is one of the most important reasons to hire our firm to help you with a pre-submission request. Surprisingly, our template is more comprehensive than most design plans. What makes our plan surprising is that it’s a generic testing plan that I created in 30 minutes. If you would like it, just email me at rob@13485cert.com. We also have an updated template for combined design and risk management plans.

I’m not suggesting that our plan template already includes every single safety and performance test. Our testing plan does not include everything. However, we spend several hours looking for applicable guidance documents and researching the testing requirements for your device. Then we add the requirements we find to your customized testing plan in the pre-submission request.

Basics of shortening the critical path

If your testing plan includes 100% of the safety and performance tests that you need, your project will still be unnecessarily delayed. The reason for the unnecessary delay is that you are not taking advantage of the three most important timing factors:

1. First, do every test in parallel that you can.
2. Second, identify any tests that must be done sequentially.
3. Third, protect your critical path from further delays.

If the three “tricks” I listed above are new to you, you might consider reading more about a single-minute exchange of die (SMED) techniques, and applying the theory of constraints to project management:

In summary, I gave you several clues to the one secret. But the one secret is simple and practical. You need someone on your team who only focuses on the testing plan. Usually, every person on a design team is multitasking, but none of us can focus when we are multitasking. As the design project manager, it would be impossible for you to focus on one task. You are a project manager of a design team, and managing a project team is inherently all about multitasking. Therefore, you need to give one person on your team the task of focusing on the testing plan throughout the entire project. It doesn’t have to be the same person during every phase of the project. In fact, by rotating who that person is, each person assigned this responsibility only needs to be dedicated for a short duration. This is a critical concept. One person must be focused on your testing plan, and that person must be dedicated to that task as long as they are responsible for focusing on your testing plan. You might even consider making a big deal out of it…

Managers are always looking for creative ways to motivate teams. Custom t-shirts are fun, you can quickly design a different t-shirt for each role on the team, everyone can wear their t-shirt to team meetings, and the testing plan t-shirt will identify who has the responsibility for focusing on the secret to completing the project on schedule. You can order one of these t-shirts from us for $15. I dare you to compare the cost of a few custom t-shirts with the other solutions you were considering.

Our Testing Plan is my life T-Shirt

Please click the button to confirm that you'd like to receive the t-shirt shown in the picture. Please let us know what size you would like (M, L, XL, 2XL, 3XL). Only white t-shirts available with black graphics. We also need your shipping address. Shipping via US Postal Service is FREE. If you want the t-shirt expedited, we can ship it via FedEx to you. We will invoice you for the cost of our FedEx shipping to your location.

Price: $15.00

If you liked this article, please share it. If you are interested in design control or risk management training, consider purchasing one of our webinars on those topics for your company.

This article defines the requirements for design and risk management planning that were used to create our new design plan template.

Why combine Design and Risk Management Plans into a Design Plan Template?

There are two primary reasons for combining your risk management plan with your design plan. The first reason is to reduce the number of documents you must maintain and control. The second reason is that there are different requirements for risk management during the design process and after the commercial release of a new product. Therefore, you will need one risk management during the design phase, and a second risk management plan after your product is released. You can achieve this by incorporating your risk management plan with your design plan and your post-market surveillance plan. Therefore, you only need to maintain two documents instead of four.

Six requirements for your design plan?

There are no specific design planning requirements in the European MDR, but the requirements for design planning are specified in ISO 13485:2016, Clause 7.3.2. In the previous version of ISO 13485, the requirement for a design procedure and a design plan were combined into one clause (i.e., Clause 7.3.1). Now, these two requirements have been split into independent clauses. The requirement to manage the interfaces between various groups involved in the design project was removed from the requirements for design planning in the new version of the standard, but three additional requirements were added. The following sub-clauses did not change (although numbering changed):

• 7.3.2a) document the design and development stages
• 7.3.2c) document verification, validation and transfer activities required at each stage
• 7.3.2d) document responsibilities and authorities

The first new requirement in your design plan template

The first new requirement is in Clause 7.3.2b). You are required to document the design reviews required at each stage. This does not mean that a review is required at every stage, but your plan should specify at which stages you will conduct a review. At a minimum, a final design review is required for the commercial release of the device. My recommendation is to have a review at every stage for every project. If your design inputs have not changed from the previous version of the device, then the stage leading up to the approval of design inputs will be very short, and that design review meeting can be 30 minutes or less. If you make changes to your design control procedure in the middle of a project, I recommend that you maintain compliance with the existing procedure until the next design review. The design review gives you an excellent opportunity to document changes to the design procedure, design plan, and any other adjustments to the documentation that may require the completion of a new version of a form.

The second new requirement in your design plan template

The second new requirement is in Clause 7.3.2e). You are required to document methods of traceability between design inputs and outputs–including your risk controls. This is a requirement that most companies do poorly. In theory, you can use a spreadsheet to list all the design inputs, and the adjacent column can list the corresponding design outputs. Many companies use an input / output / verification / validation (IOVV) diagram. You can also add the user’s needs to this diagram. The challenge with the method of documentation is that it is labor-intensive to make updates. You must update the references to inputs every time a standard is updated. The outputs must be updated every time a drawing or specification is changed. Every time you update a verification or validation testing report, the diagram must be updated too.

The third new requirement in your design plan template

The third new requirement is in Clause 7.3.2f). You are required to document the resources needed at each stage–including the necessary competence of personnel. In general, companies experiencing difficulties in documenting competency for personnel, but this requires that you document competency for each person on a design project for each stage. My recommendation is to keep it simple. Tables are usually the simplest way to document this type of information. For example, you can use a three-column table: 1) role, 2) responsibility, 3) competency requirements. In general, I recommend that anyone on your design team has training in design controls and risk management. However, training and competency are not equivalent. To demonstrate competency, you must have prior experience documented in that area.

What is required in a Risk Management Plan?

EN ISO 14971:2019 requires a risk management plan in Clause 4.4. In addition, there are requirements in Regulation (EU) 2017/745. Specifically, in Essential Requirement 3:

• (a) establish and document a risk management plan for each device;
• (b) identify and analyze the known and foreseeable hazards associated with each device;
• (c) estimate and evaluate the risks associated with, and occurring during, the intended use and during reasonably foreseeable misuse;
• (d) eliminate or control the risks referred to in point (c) in accordance with the requirements of Section 4;
• (e) evaluate the impact of information from the production phase and, in particular, from the post-market surveillance system, on hazards and the frequency of occurrence thereof, on estimates of their associated risks, as well as on the overall risk, benefit-risk ratio, and risk acceptability; and
• (f) based on the evaluation of the impact of the information referred to in point (e), if necessary, amend control measures in line with the requirements of Section 4.

In our previous blog on changes to the risk management process, we identified nine activities that should be included in your risk management plan:

1. Hazard identification
2. Risk estimation
3. Risk evaluation
4. Risk control option analysis
5. Risk control verification of effectiveness
6. Benefit/Risk analysis
7. Evaluation of overall residual risk
8. Risk management review
9. Production and post-production activities

How to purchase our new Design Plan Template

Medical Device Academy’s new design plan template is an associated form sold with the purchase of either of the following procedures: 1) Design Control Procedure (SYS-008), 2) Risk Management Procedure (SYS-010). You can also learn more about design control requirements by registering for our updated design controls training webinar.

Other Blogs About Design Controls

Medical Device Academy wrote the following blogs on the topic of design controls:

• Implementing Design Controls – 10 Steps
• Auditing Design Controls – 7 Step Process
• How to Write Design Controls Procedures
• Product Launch Design Planning for a 510(k) Submission in 300 Days or Less
• DHF Template – Format and Content of Design History File

Other Webinars About Design Controls

The following webinars are available on the topic of design controls:

• 510(k) Best Practices – Design Controls & Risk Management
• Design Changes Webinar
• Design History File (DHF) – Training Webinar
• Combining Product Risk Management with Design Controls