Blog

Archive for Design Control

Auditing Design Controls – 7 Step Process

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.

Posted in: Design Control, ISO Auditing

Leave a Comment (1) →

How to Write Design Control Procedures

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:

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

Posted in: Design Control

Leave a Comment (0) →

Design Team – Needs a Superwoman Leader

mona superwoman Design Team   Needs a 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 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:

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

 

Posted in: Design Control

Leave a Comment (4) →

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

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

Posted in: Design Control

Leave a Comment (3) →
Page 2 of 2 12