Design Control Medical Device Academy

Archive for Design Control

DHF Template – Format and Content of Design History File

Posted by Rob Packard on April 14, 2016

The article does not include a DHF template, but recommendations for format and content of a design history file are provided.

A couple of weeks ago I announced that I will be conducting a webinar today (i.e., 10:00am EDT on April 14, 2016) on the topic of the design history file (DHF). One of my blog readers sent me an email in response to this announcement requesting a DHF template.

Regulatory Requirements for a Design History File (DHF)

The requirements for a design history file (DHF) are found in 21 CFR 820.30j: “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 a DHF Template Doesn’t Make Sense

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. However, 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.

Documenting Design Changes in your DHF vs. a DMR Index

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.

Design History File (DHF) Webinar

If you are interested in learning more about design history files, there is still time to register for today’s live training webinar. For a cost of $129 you will receive:

a link to join the live webinar @ 10am EDT
a native slide deck for the new live webinar
a link to download a recording of the live webinar

This live webinar explains what needs to be included in your procedures for design and development, but the webinar explains how and when to create a design history file (DHF). After you create a 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.

After 9:30am EST, you will be able to purchase the webinar as recording only.

CLICK HERE to register for the live DHF webinar or to purchase the recording.

Posted in: Design Control

Implementing Design Controls – 10 Steps

Posted by Rob Packard on September 23, 2013

The article explains ten steps of implementing design controls, including design plans, design inputs, design review, verification protocols, and risk management.

FDA Guidance for Implementing Design Controls

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 controls 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).

Implementing Design Controls: A Complex Process

Even though the requirement for Design Controls has been in place for 16 years, there are still far too many design teams that struggle with understanding these requirements. Medical device regulations are complex, but design controls are the most complex process in any quality system. The reason for this is that each of the seven sub-clauses represents a mini-process that is equivalent in complexity to CAPA root cause analysis. Many companies choose to create separate work instructions for each sub-clause.

Medical Device Academy’s training philosophy is to distill processes down to discrete steps that can be absorbed and implemented quickly. We use independent forms to support each step, and develop training courses with practical examples, instead of writing a detailed procedure(s). The approach we teach removes complexity from your design control procedure. Instead, we rely upon the structure of step-by-step forms completed at each stage of the design process.

10 Ways for Implementing Design Controls

1. Design plans are just a plan. You can and should change that plan. This is stated in both Clause 7.3.1 of the ISO Standards, and Section 21 CFR 820.30b of the FDA QSR. You can make your plan as detailed as you need to, but I recommend starting simple and adding detail. Your first version of a design plan should include the following tasks:

Identification of the regulatory pathway-based upon the device risk classification and applicable harmonized standards.
Development of a risk management plan
Approval of your design plan (1^st design review)
Initial hazard identification
Documentation and approval of design inputs (2^nd design review)
Risk control option analysis
Reiterative development of the product design
Risk analysis
Documentation and approval of design outputs (3^rd design review)
Design verification and validation and risk control verification
Clinical evaluation and risk/benefit analysis
Development of post-market surveillance plan with a post-market risk management plan
Development of a draft Device Master Record(DMR) /TF Index
Commercial release (4^th and final design review)
Regulatory approval and closure of the Design History File (DHF
Review lessons learned and initiate actions to improve the design process

2. Design inputs need to be requirements verified through the use of a verification protocol. If you identify external standards for each design input, you will have an easier time completing the verification activities, because verification tests will be easier to identify. Medical Device Academy has written more on this topic in a previous blog posting.

3. Design outputs are drawings and specifications. Ensure you keep them updated and control the changes. When you finally approve the design, this is the “design freeze.”

4. Design reviews should have defined deliverables. I recommend designing a form for documenting the design review, which identifies the deliverables for each design review. The form should also define the minimum required attendees by function. Other design review attendees should be identified as optional—rather than required reviewers and approvers. If your design review process requires too many people, this will have a long-term impact upon review and approval of design changes.

5. Design verification protocols should be standardized instead of being project-specific. Information regarding traceability to lots of calibrated equipment ID and test methods should be included as a variable that is entered manually into a blank space when the protocol is executed. The philosophy behind this approach is to create a protocol once and repeat it forever. This results in a verification process that is consistent and predictable, but it also eliminates the need for review and approval of the protocol for each new project.

6. Design validation should be more than bench testing. Ensure that animal models, simulated anatomical models, finite element analysis, and human clinical studies are considered.

7. Design transfer is not a single event in time. Transfer begins with the release of your first drawing or specification to purchasing and ends with the commercial release of the product.

8. Do not keep the DHF open after commercial release. All changes after that point should be under production controls, and changes should be documented in the (DMR)/Technical File (TF).

9. Your DMR Index should perform a dual function of also meeting technical documentation requirements for other counties, such as Canada and Europe.

10. Audit your design control process to identify opportunities for improvement and preventive actions. Audits should include a review of the design process metrics, and you may consider establishing quality objectives for the improvement of the design process. This last step, and the standardization of design verification protocols in step five (5), are discussed in further detail in another blog by Medical Device Academy.

More Information Regarding Implementing Design Controls

If you are interested in design control training, Rob Packard will be teaching a Design Controls Training Webinar on November 2, 2018.

Tags: Design controls, design controls implementation

Posted in: Design Control

Auditing Design Controls – 7 Step Process

Posted by Rob Packard on June 23, 2012

This blog reviews seven steps for effectively auditing design controls utilizing the ISO 13485 standard and process approach to auditing.

turtle diagram for design controls Auditing Design Controls 7 Step Process

Third-party auditors (i.e., – a Notified Body Auditor) don’t always practice what we preach. I know this may come as a huge shock to everyone, but sometimes we don’t use the process approach. Auditing design controls is a good example of my own failure to follow was it true and pure. Instead, I use NB-MED 2.5.1/rec 5 as a checklist, and I sample Technical Files to identify any weaknesses. The reason I do this is that I want to provide as much value to the auditing client as possible without falling behind in my audit schedule.

Often, I would sample a new Technical File for a new product family that had not been sampled by the Technical Reviewer yet. My reason for doing this is that I could often find elements that are missing from the Technical File before the Technical Reviewer saw the file. This gives the client an opportunity to fix the deficiency before submission and potentially shortens the approval process. Since NB-MED documents are guidance documents, I could not write the client up for a nonconformity, unless they were missing a required element of the M5 version of the MDD (93/42/EEC as modified by 2007/47/EC). This is skirting the edge of consulting for a third- party reviewer, but I found it was a 100% objective way to review Technical Files. I also found I could review an entire Technical File in about an hour.

What’s wrong with this approach to auditing design controls?

This approach only tells you if the elements of a Technical File are present, but it doesn’t evaluate the design process. Therefore, I supplemented my element approach with a process audit of the design change process by picking a few recent design changes that I felt were high-risk issues. During the process audit of the design change process, I sampled the review of risk management documentation, any associated process validation documentation, and the actual design change approval records. If I had time, I looked for the following types of changes: 1) vendor change, 2) specification change, and 3) process change. By doing this, I covered the following clauses in ISO 13485:2016: 7.4 (purchasing), 7.3.9 (design changes), 7.5.6 (process validation), 7.1 (risk management), and 4.2.5 (control of records).

So what is my bastardized process approach to auditing design controls missing? Clauses 7.3.1 through 7.3.10 of ISO 13485:2016 are missing. These clauses are the core of the design and development process. To address this, I would like to suggest the following process approach:

Step 1 – Define the Design Process

Identify the process owner and interview them. Do this in their office–not in the conference room. Get your answers for steps 2-7 directly from them. Ask lots of open-ended questions to prevent “yes/no” responses.

Step 2 – Process Inputs

Identify how design projects are initiated. Look for a record of a meeting where various design projects were vetted and approved for internal funding. These are inputs into the design process. There should be evidence of customer focus, and some examples of corrective actions taken based upon complaints or service trend analysis.

Step 3 – Process Outputs

Identify where Design History Files (DHF) are stored physically or electronically, and determine how the DHF is updated as the design projects progress.

Step 4 – What Resources

This is typically the step of a process audit where their auditor needs to identify “what resources” are used in the process. However, only companies that have software systems for design controls have resources dedicated to Design and Development. I have indicated this in the “Turtle Diagram” presented above.

Step 5 – With Whom, Auditing Training Records

Identify which people are assigned to the design team for a design project. Sometimes companies assign great teams. In this case, the auditor should focus on the team members that must review and approve design inputs (see Clause 7.3.2) and design outputs (see Clause 7.3.3). All of these team members should have training records for Design Control procedures and Risk Management procedures.

Step 6 – Auditing Design Controls Procedures and Forms

Identify the design control procedures and forms. Do not read and review these procedures. Auditors never have the time to do this. Instead, ask the process owner to identify specific procedures or clauses within procedures where clauses in the ISO Standard are addressed. If the process owner knows exactly where to find what you are looking for, they’re training was effective, or they may have written the procedure(s). If the process owner has trouble locating the clauses you are requesting, spend more time sampling training records.

Step 7 – Process Metrics

Ask the process owner to identify some metrics or quality objectives they are using to monitor and improve the design and development process. This is a struggle for many process owners–not just design. If any metrics are not performing up to expectations, there should be evidence of actions being taken to address this. If no metrics are being tracked by the process owner, you might review schedule compliance.

Many design projects are behind schedule, and therefore this is an important metric for most companies. Now that you have completed your “Turtle Diagram,” if you have more time to audit the design process, you can interview team members to review their role in the design process. You could also sample-specific Technical Files as I indicated above. If you are performing a thorough internal audit, I recommend doing both. To learn more about using the process approach to auditing, you can register for our webinar on the topic.

Tags: auditing, Design controls, ISO 13485

Posted in: Design Control, ISO Auditing

How to Write Design Control Procedures

Posted by Rob Packard on May 27, 2012

The author has reviewed 100+ design control processes in his career, and this blog provides five steps to write design control procedures.

In my previous blog posting, I indicated six things that medical device companies can do to improve design controls. While the last posting focused on better design team leaders (WANTED: Design Team Needs Über-Leader), this posting focuses on writing stronger procedures. I shared some of my thoughts on how to write design control procedures just a few weeks ago, but my polls and LinkedIn Group discussions generated great feedback regarding how to write design control procedures.

No Need to Write Design Control Procedures

One of the people that responded to my poll commented that there was no option in the poll for “zero.” Design controls do not typically apply to contract manufacturers. These companies make what other companies design. Therefore, their Quality Manual will indicate that Clause 7.3 of the ISO 13485:2016 Standard is excluded. If this describes your company, sit back and enjoy the music.

1 Procedure Only

Another popular vote was “one.” If you only have one procedure for design controls, this meets the requirements. It might even be quite effective.

When I followed up with poll respondents, asking how many pages their procedures were, a few people suggested “one page.” These people are subscribing to the concept of using flow charts instead of text to define the design control process. I use the following diagram to describe the design process: The Waterfall Diagram!

waterfall diagram How to Write Design Control Procedures

From the US FDA Website.

I first saw this diagram in the first course I took on Design Controls. This is on the FDA website too. To make this diagram effective as a procedure, we might need to include some references, such as work instructions, forms, the US FDA guidance document for Design Controls, and Clause 7.3 of the ISO 13485:2016 Standard.

Many Design Control Procedures

The bulk of the remaining respondents indicated that their company has eight or more procedures related to design controls. If each of these procedures is short and specific to a single step in the Waterfall Diagram, this type of documentation structure works well. Unfortunately, many of these procedures are a bit longer.

If your company designs software, active implantable devices, or a variety of device types—it may be necessary to have more than one procedure just to address these more complex design challenges. If your company has eight lengthy procedures to design Class 1 devices that are all in the same device family, then the design process could lose some fat.

In a perfect world, everyone on the design team would be well-trained and experienced. Unfortunately, we all have to learn somehow. Therefore, to improve the effectiveness of the team, we write design control procedures for the team to follow. As an auditor and consultant, I have reviewed 100+ design control processes. One observation is that longer procedures are not followed consistently. Therefore, keep it short. Another observed is that well-designed forms help teams with compliance.

Therefore, if you want to re-write design control procedures, try the following steps:

Use a flow chart or diagram to illustrate the overall process
Keep work instructions and procedures short
Spend more time revising and updating forms, instead of procedures
Train the entire team on design controls and risk management
Monitor and measure team effectiveness and implement corrective actions when needed

The following is a link to the guidance document on design controls from the US FDA website. In addition to the comments I made in this blog, please refer back to my earlier blog on how to write a procedure. You can also purchase Medical Device Academy’s design control procedure and forms.

Tags: Design Control, Design control SOP, SOP

Posted in: Design Control

Design Team – Needs a Superwoman Leader

Posted by Rob Packard on May 16, 2012

“Mona Superwoman” by Teddy Royannez (France)

This blog discusses the reasons for a female design team leader and the qualities and skills that she should possess to get maximum results out of her team.

Last November, Eucomed published a position paper titled, “A new EU regulatory framework for medical devices: Six steps guaranteeing rapid access to safe medical technology while safeguarding innovation.” While I have serious doubts that any government will ever be able to “guarantee” anything other than its own continued existence, I have an idea of how the industry can help.

The position paper identified six steps. Each of these steps has a comparable action that could be taken in every medical device company. My list of six steps is:

Only the best leaders have:

Only one approach to design controls
Stronger internal procedures
Cross-pollination by independent reviewers
Clear communication of project status to management
Better project management skills

The most critical element to success is developing stronger design team leaders. Design teams are cross-functional teams that must comply with complex international regulations while simultaneously be creative and develop new products. This type of group is the most challenging type to manage. To be successful, design team leaders must be “Über-Leaders.”

Critical Design Team Leader Skills

The most critical skills are not technical skills but team leadership skills. The role of a design team leader is to ensure that everyone is contributing, without tromping on smaller personalities in the group. Unfortunately, there are more men in this role than women.

Why is this unfortunate? Because men have difficulty when it comes to listening (takes one to know one).

We need a leader that will be strong, but we also need someone that is in touch with the feelings of others and will use that skill to bring out the best of everyone on the team. This superwoman also needs to earn the respect of the male egos around the table. She needs to be an expert in ISO 14971, ISO 13485, Design Controls, Project Management, and managing meetings. Our beautiful heroine must also be a teacher because some of our team members will not know everything—even if they pretend to.

The Über-Leader will always remind the team that Safety & Efficacy are paramount. As team leaders, we must take the “high road” and do what’s right—even when it delays a project or fails to meet our boss’s unrealistic timetable. Superwoman must demand proof in the form of verification and validation data. It is never acceptable to go with an opinion.

She will remind us that compromise is the enemy, and we must be more creative to solve problems without taking shortcuts that jeopardize safety and efficacy. She will work harder on the project than anyone else on the team. She will keep us on schedule. She will whisper to get our attention, but she won’t be afraid to yell and kick our ass.

As Jim Croce says, “You don’t tug on Superman’s cape.” Superwoman is the only exception to this rule.

Tags: Design Control

Posted in: Design Control

Design Input Requirements: 3 Common Errors

Posted by Rob Packard on May 12, 2012

The author reviews three common errors related to design input requirements and uses examples to illustrate compliance.

I have been directly involved in dozens of design projects throughout my career, and during the past three years, I have audited 50+ Design Dossiers for CE Marking of Medical Devices. Throughout most of these design projects, I have noticed one common thread—a misunderstanding of design inputs.

ISO 13485 identifies design input requirements. These requirements are:

Functional (7.3.2a)
Performance (7.3.2a)
Safety (7.3.2a)
Statutory/Regulatory (7.3.2b)
Previous and Similar Designs (7.3.2c)
Essential Requirements (7.3.2d)
Outputs of Risk Management (7.3.2e)
Customer Requirements (7.2.1)
Organizational Requirements (7.2.1)

Design Input Requirements: 3 Common Errors Reviewed

The most common error seems to be the failure to include the outputs of risk management. For those of you that have used design FMEA’s—that’s what the right-hand columns are for. When you identify suggested actions to mitigate risks with the current design, these actions should be translated into inputs for the “new and improved” model.

The second most common error seems to be a failure to consider regulatory requirements. There are two ways this mistake is frequently made: 1) Canadian MDR’s were not considered as design inputs for a device intended for Canadian medical device licensing, and 2) an applicable ISO Standard was not considered (i.e., – “State of the Art” is Essential Requirement 2 of the Medical Device Directive (MDD)).

The third most common error, and the one that drives me crazy, is a confusion of design outputs and design inputs. For example, an outer diameter of 2.3 +/- 0.05 mm is not a design input for a 7 French arterial catheter. This is a design output. The user need might be that the catheter must be small enough to fit inside the femoral artery and allow interventional radiologists to navigate to a specific location to administer therapy. Validation that the new design can do this is relatively straight forward to evaluate in a pre-clinical animal model or a clinical study. The question is, “What is the design input?”

Design Input Examples

Design inputs are supposed to be objective criteria for verification that the design outputs are adequate. One example of a design input is that the catheter outer diameter must be no larger than a previous design that is an 8 French catheter. Another possible design input is that the catheter outer diameter must be less than a competitor product. In both examples, a simple measurement of the OD is all that is required to complete the verification. This also gives a design team much more freedom to develop novel products than a narrow specification of 23 +/- 0.05 mm allows for.

If you are developing a Class II medical device for a 510(k) submission to the FDA, special controls guidance documents will include design inputs. If you are developing a Class IIa, Class IIb, or Class III medical device for CE marking, there is probably an ISO Standard that lists functional, performance, and safety requirements for the device. Regulatory guidance documents and ISO Standards usually reference test methods and indicate acceptance criteria. When you have a test method and acceptance criteria defined, it is easier to write a verification protocol. Therefore, design teams should always strive to document design inputs that reference a test method and acceptance criteria. If this is not done, verification protocols are much more difficult to write.

In my earlier example, the outer diameter of 2.3 +/- 0.05 mm is a specification. Unfortunately, many companies would document this as an input and use the final drawing as the output. By making this mistake, “verification” is simply to measure the outer diameter to verify that it matches the drawing. This adds no value, and if the specifications are incorrect, the design team will not know about it.,

A true verification would include a protocol that identifies the “worst-case scenario,” and verifies that this still meets the design input requirements. Therefore, if the drawing indicates a dimensional tolerance of 2.3 +/- 0.05, the “worst-case” is 2.35 mm. The verification process is to measure either a previous version of the product or a competitor’s catheter. The smallest previous version or competitor catheter tested must be larger than the upper limit of the design output for the outer diameter of the new catheter.

Tags: Design Input, design input requirements

Posted in: Design Control