Blog

Archive for Design Control

DHF Required for a Class I Device? At least 67%…

Is a DHF required appears to be a simple yes/no question? If you reword the question, however, you get a very different answer.

Is a DHF required DHF Required for a Class I Device? At least 67%...

If you ask “how much less documentation is required for the design of a Class 1 device compared with a Class 2 device?” you get a very different answer. Instead of 0% (Yes a DHF is required) of 100% (No DHF required), the answer is that you need 33% less documentation for the design of a Class 1 device.

The FDA shared a presentation on design controls in 2015.

In that presentation, the agency identified six, Class 1 product classifications that require design controls, while thousands of Class 1 product classifications do not require design controls. Despite the lack of design controls, manufacturers must still maintain a procedure for design transfer, maintain an approved device master file with all the approved design specifications (i.e., design outputs) and design changes may still require revalidation prior to implementation.

Why is a DHF Required for Class 2, but Not for Class 1?

Class 1 devices are simple devices that are already on the market and have a history of clinical safety. Class 2 devices are generally more complex and present a moderate risk. Therefore, changes in the technological characteristics often present a greater risk for Class 2 devices. When you design a Class 1 device, you still have to determine what your design specifications will be, but you don’t need: 1) to review and approve design inputs, 2) a procedure to document your design process, 3) to document formal design reviews, and 4) to create a design plan.

In the 1997 guidance document for design controls, the FDA states that a design transfer procedure should include at least three basic elements:

  1. design and development procedures should include a qualitative assessment of the completeness and adequacy of the production specifications;
  2. procedures should ensure that all documents and articles which constitute the production specifications are reviewed and approved; and
  3. procedures should ensure that only approved specifications are used to manufacture production devices.

The first of these basic elements is not required for Class 1 devices, because product specifications for most Class 1 devices are simple. The other two requirements are basic principles of document control and configuration management. Therefore, you still need a design transfer procedure for Class 1 devices but you don’t need to include the first element that relies upon design and development procedures.

If you have a Class 1 device, you must still comply with labeling requirements (i.e., 21 CFR 820.120). If your device is sterile, you must still validate and re-validate the process in accordance with 21 CFR 820.75. Class 1 products also require, a device master record (DMR) in accordance with 21 CFR 820.181.

What is Not DHF required?

Needed for Class I (67%)

  1. Approved Design Outputs
  2. Labeling Procedure
  3. Approved Labeling
  4. Sterilization Validation Procedure
  5. Sterilization Validation Protocol and Report
  6. Design Transfer Procedure
  7. Approved DMR
  8. Design Change Procedure

Needed for Class II and Class I requiring Design Controls (100%)

  1. Design Control Procedure
  2. Design Plan
  3. Approved Design Inputs
  4. Approved Design Outputs
  5. Labeling Procedure
  6. Approved Labeling
  7. Sterilization Validation Procedure
  8. Sterilization Validation Protocol and Report
  9. Design Transfer Procedure
  10. Evidence of at least 1 Design Review
  11. Approved DMR
  12. Design Change Procedure

Therefore, although you do not technically have to have a DHF for a Class 1 products, the difference between the two categories is the following elements:

  1. Design Control Procedure
  2. Design Plan
  3. Approved Design Inputs
  4. Evidence of at least 1 Design Review

When an FDA inspection occurs, the investigator will review your design control procedure and then audit your DHF in accordance with your design plan.

When you have a Class 1 device, you are not typically inspected unless there is a problem and when ORA inspectors perform an inspection for Class 1 devices the inspector looks for evidence of items in first list.

If you are interested in learning more about design history files (DHF), please check out our DHF webinar.

Posted in: Design Control

Leave a Comment (0) →

DHF Template – Format and Content of Design History File

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

DHF Content DHF Template   Format and Content of Design History File

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. 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 the DHF vs. the 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

Leave a Comment (0) →

10 Steps to Implementing Design Controls

waterfall fda 10 Steps to Implementing Design Controls

The author describes 10 steps to implementing design controls, including design plans, design inputs, design review, verification protocols and risk management.

The diagram above is called the “Application of Design Controls to Waterfall Design Process.” This diagram was introduced by the FDA in 1997 in a design controls guidance document (http://bit.ly/DesignControlGuidance). However, the original source of the diagram was Health Canada.

This diagram is one of the first slides I use for every design controls course that I teach, because the diagram visually displays the design controls process (http://bit.ly/DesignControls). 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). There are seven sub-clauses that 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).

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. In fact, many companies choose to create a separate work instruction 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 (http://bit.ly/DesignSOP) removes complexity from your procedure. Instead, we rely upon the structure of step-by-step forms completed at each stage of the design process.

10 Ways to Implement Design Controls

Design plans are just a plan. You can and should change that plan. In fact, this is stated in both Clause 7.3.1 of the ISO Standards, and in 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 16 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 (1st design review) 

Initial hazard identification

Documentation and approval of design inputs (2nd design review) 

Risk control option analysis

Reiterative development of the product design

Risk analysis 

Documentation and approval of design outputs (3rd design review) 

Design verification and validation, and risk control verification 

Clinical evaluation and risk/benefit analysis

Development of post-market surveillance plan with post-market risk management plan

Development of a draft Device Master Record(DMR) /TF Index

Commercial release (4th 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 (http://bit.ly/DesignInputs). 

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 clearly 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, 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 predicable, 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 release of your first drawing, or specification to purchasing, and ends with 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 (http://bit.ly/AuditDesign) 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 improvement of the design process. This last step, and the standardization of design verification protocols in step five (5), are discuss in further detail in another blog by Medical Device Academy (http://bit.ly/DesignCAPA). 

If you are interested in design control training, Rob Packard will be teaching an audio seminar hosted by FX Conferences on October 15, 2013 (http://bit.ly/Oct15FX).

  1. Please Join us on Social Medialinkedin 1 10 Steps to Implementing Design Controlsgoogleplus 10 Steps to Implementing Design Controlstwitter 10 Steps to Implementing Design Controls

Posted in: Design Control

Leave a Comment (5) →

7 Steps to Auditing Design Controls Using the ISO 13485 Standard

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

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.

So what’s wrong with this approach?

This approach only tells you if the elements of a Technical File are present, but it doesn’t really 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: 7.4 (purchasing), 7.3.7 (design changes), 7.5.2 (process validation), 7.1 (risk management) and 4.2.4 (control of records).

So what is my bastardized process approach to auditing design controls missing? Clauses 7.3.1 through 7.3.6 of ISO 13485 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: 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: 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: 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: This is typically the step of a process audit where there 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 following “Turtle Diagram.”

%name 7 Steps to Auditing Design Controls Using the ISO 13485 Standard

“With What Resources” is typically not applicable, because most companies do not have electronic design history files.

Step 5: Identify which people are assigned to the design team for a design project. Sometimes companies assign very large 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: Identify procedures and forms that define the Design and Development process. 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: 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 there are any metrics that are not performing up to expectations, there should be evidence of actions being taken to address this. If there are no metrics 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.

Posted in: Design Control

Leave a Comment (0) →

Design Control Procedure: The Ultimate SOP

The author has reviewed 100+ design control processes in his career, and this blog provides 5 steps for rewriting your design control procedure.

Disclaimer: There is no need to create the Ultimate Design Control SOP. We need medical devices that are safer and more effective.

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 writing design control procedures just a few weeks ago, but my polls and LinkedIn Group discussions generated great feedback regarding 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 Standard is excluded. If this describes your company, sit back and enjoy the music.

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. In fact, I use the following diagram to describe the design process: The Waterfall Diagram!

waterfall diagram Design Control Procedure: The Ultimate SOP

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 Standard.

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 create design 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-desiged forms help teams with compliance.

Therefore, if you want to rewrite your design control SOP try the following steps:

  1. Use a flow chart or diagram to illustrate the overall process
  2. Keep work instructions and procedures short
  3. Spend more time revising and updating forms, instead of procedures
  4. Train the entire team on design controls and risk management
  5. 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.

Refer to my LinkedIn polls and discussions for more ideas related to design control procedures:

  1. Medical Devices Group
  2. Elsmar Cove Quality Forum Members Group

In addition to the comments I made in this blog, please refer back to my earlier blog on how to write a procedure.

Posted in: Design Control

Leave a Comment (0) →

Design Team Needs Superwoman Leader

mona superwoman Design Team Needs Superwoman Leader

“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 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:

  1. Only one approach to design controls
  2. Stronger internal procedures
  3. Cross-pollination by independent reviewers
  4. Clear communication of project status to management
  5. 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 team is the most challenging type to manage. In order 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’ 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.

 

Posted in: Design Control

Leave a Comment (3) →

Design Input Requirements: 3 Common Errors

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, 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:

  1. Functional (7.3.2a)
  2. Performance (7.3.2a)
  3. Safety (7.3.2a)
  4. Statutory/Regulatory (7.3.2b)
  5. Previous and Similar Designs (7.3.2c)
  6. Essential Requirements (7.3.2d)
  7. Outputs of Risk Management (7.3.2e)
  8. Customer Requirements (7.2.1)
  9. 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 failure to consider regulatory requirements. There are actually 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 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, “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 outer diameter of the new catheter.

Posted in: Design Control

Leave a Comment (2) →
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers:

Simple Share Buttons
Simple Share Buttons