Blog

Archive for Design Control

NSE letter: A CAPA plan for your 510k process

Cry, complain, call the reviewer…you might feel a little better, but you received an NSE letter, and tomorrow you still can’t sell your device.

NSE Letter NSE letter: A CAPA plan for your 510k process

Instead, try approaching an NSE letter like a CAPA investigation. What is the issue? The FDA determined that your device is not substantially equivalent to the predicate you selected. What is the root cause? There are four (4) possible root causes.

NSE Letter Cause #1: You failed to verify that the predicate is a legally marketed device.

If your predicate device is not legally marketed, you need to select a new predicate and resubmit. However, it is doubtful that your device would pass the refusal to accept the (RTA) screening process if the predicate was not legally marketed. If your predicate was not registered and listed with the FDA (check using this link), then you should have submitted a pre-sub request to determine if the agency has any problem with using the device you chose as a predicate. This is an essential question if the manufacturer is no longer in business, and the product is no longer for sale.

NSE Letter Cause #2: You failed to evaluate the substantial equivalence of your device’s intended use with the predicate.

The intended use of your predicate device is documented for every potential predicate since February 1992 on FDA Form 3881–which you can download along with the 510(k) clearance letter for the predicate. There is also an intended use documented for every device category in the applicable regulation for that device. This intended use is more generic than FDA Form 3881, but both are applicable. The FDA Form 3881 you submit for your device must be equivalent. I recommend a point-by-point comparison with regard to the following elements: 1) OTC vs. prescription use, 2) user, 3) patient population, 4) illness or medical condition, 5) duration of use, 6) environment of use and 7) target part of the body. Any difference can raise new issues of risk and may result in an NSE decision. However, the FDA typically will work with the company to modify the wording of FDA Form 3881 to ensure the intended use is equivalent or to make sure you provide clinical evidence to address the differences. In my pre-submission requests, I include a comparison document for the intended use to ensure that the FDA is aware of any differences in the intended use.

Cause #3: You failed to convince the FDA that technological differences do not raise different questions of safety and effectiveness.

Unless your device is identical in every way to the predicate device, you will have to persuade the FDA that differences do not raise questions of safety and effectiveness. At the beginning of the 510(k) process, it is helpful to document technological differences systematically. Specifically, this should include: 1) materials, 2) design, 3) energy source, and 4) other features. For each difference, you must justify why the difference does not raise different issues, or you must provide data to prove it. It is also possible that you were not aware of questions of safety and performance raised by technological differences. To avoid this problem, you can submit a detailed device description and draft labeling to the FDA in a pre-sub meeting request. If you ask questions about differences in a pre-sub meeting, you can avoid an NSE letter.

Cause #4: You failed to provide data demonstrating equivalence.

For each difference, you should determine an objective method for demonstrating that the difference is equivalent in safety and performance to the predicate. Your test method can be proposed to the FDA in a pre-sub request before testing. The FDA sees more than 3,000 companies propose testing methods to demonstrate equivalence each year. They have more experience than you do. Ask them in a pre-sub before you test anything. There may be a better test method, or you might need to adjust your test method. Sometimes results are unclear, but there might be another test you can perform to demonstrate equivalence, and then you can resubmit your 510(k). Possibly you were unaware of the need to perform a test, and you were unable to complete a test within the 180 days the FDA allowed for submitting additional information. The good news is you now have all the time you need.

What is similar between all four causes of the NSE letter?

In all four root causes identified above, you could benefit greatly from the pre-sub meeting. Now you have an NSE letter, and you know which of the four reasons why your submission did not result in 510(k) clearance. However, the correction to your NSE letter may not be clear. Therefore, you should consider requesting a pre-sub meeting as quickly as you can. Most companies choose not to submit a pre-sub meeting request because they don’t want to wait 60-75 days. However, sometimes pre-sub meetings are scheduled sooner. In addition, 60-75 days is not as costly as receiving a second NSE letter.

Prevent a future NSE letter by requesting a pre-sub meeting

Regardless of your corrections for the current NSE letter, you should prevent future occurrences by planning to submit a pre-sub meeting request for every submission. I try to help clients gather all the information they need without a pre-sub meeting, but each new 510(k) reminds me why a pre-sub meeting is so valuable. You always learn something that helps you with the preparation of your 510(k).

Help with Pre-sub meeting requests

The FDA published a guidance document for pre-sub meeting requests. If you need additional help, there is a webinar on this topic.

Posted in: 510(k), CAPA, Design Control

Leave a Comment (0) →

Design change control – best practices in managing changes?

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

Tire Change Image for Change Control Blog Design change control   best practices in managing changes?

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

Posted in: Design Control

Leave a Comment (0) →

Integrating usability testing into your design process

This article explains how you should be integrating usability testing into your design control process–especially formative usability testing.

Integrating Usability Engineering and Risk Management into your Design Control Process Integrating usability testing into your design process

Why you should be integrating usability testing into the design

We recently recorded an updated usability webinar and released a usability procedure (SYS-048) with help from Research Collective–a firm specializing in human factors testing. After listening carefully to the webinar, and reading through the new usability procedure, I felt we needed to update our combined design/risk management plan to specify formative testing during phase 3 and summative (validation) testing during phase 4 of the design process. This is necessary to ensure your usability testing is interwoven with your risk management process. Integrating usability testing into all phases of your design process is critical–especially design planning (phase 1), feasibility (phase 2), and development (phase 3).

Identifying Usability Issues During Planning & Feasibility Phases

During the usability training webinar, Research Collective provided a diagram showing the various steps in the usability engineering process. The first five steps should be included in Phases 1 and 2 of your design process. Phase 1 of the design process is planning. In that phase, you should identify all of the usability engineering tasks that need to be performed during the design process and estimate when each activity will be performed. The first of these usability activities is the identification of usability factors related to your device. Identifying usability factors is performed during Phase 2 of your design process before hazard identification.

Indentifying Usability Issues 300x209 Integrating usability testing into your design process

Before performing hazard identification, which should include identifying potential use errors, you need to identify five key usability elements associated with your device:

  1. prospective device users during all stages of use must be defined
  2. use environments must be identified
  3. user interfaces must be identified
  4. known use errors with similar devices and previous generations of your device must be researched
  5. critical tasks must be described in detail and analyzed for potential use errors

Defining users must include the following characteristics: physical condition, education, literacy, dexterity, experience, etc. Use environment considerations may consist of low lighting, extreme temperatures or humidity, or excessive uncontrolled motion (e.g., ambulatory devices). User interfaces may include keyboards, knobs, buttons, switches, remote controllers, or even a touch screen display.

Often the best reason for developing a new device is to address an everyday use error that is inherent to the design of your current device model or a competitor’s product. Therefore, a thorough review of adverse event databases and literature searches for potential use errors is an important task to perform before hazard identification. This review of adverse event data and literature searches of clinical literature are key elements of performing post-market surveillance, and now ISO 13485:2016 requires that post-market surveillance shall be an input to your design process.

Finally, the step-by-step process of using your device should be analyzed carefully to identify each critical user task. User tasks are defined as “critical” for “a user task which, if performed incorrectly or not performed at all, would or could cause serious harm to the patient or user, where harm is defined to include compromised medical care.” Not every task is critical, all critical tasks must be identified, and ultimately you need to verify that each critical task is performed correctly during your summative (validation) usability testing.

Evaluating Risk Control Options – Phase 3 (Development)

Once your design team has conducted hazard identification and identified your design inputs (i.e., design phase 2), you will begin to evaluate risks and compare various risk control options. Risk control option analysis requires testing multiple prototype versions to assess which design has the optimum benefit/risk ratio. This is an iterative process that involves screening tests. For any use risks you identify, formative usability testing should be performed. Sometimes the risk controls you implement will create new use errors or new risks of other types. In this case, you must compare the risks before implementing a risk control with risks created by the risk control.

Formative Usability Testing Process 220x300 Integrating usability testing into your design process

Ideally, each design iteration will reduce the risks further until all risks have been eliminated. The international risk management standard (ISO 14971) states that risks shall be reduced as low as reasonably practicable (ALARP). However, the European medical devices regulations require risks to be reduced as far as possible, considering the state-of-the-art. For example, all small-bore connectors in the USA are now required to have unique connectors that are incompatible with IV tubing Luer lock connections to prevent potential use errors. That requirement is considered “state-of-the-art.” If your device is marketed in both the USA and Europe, you will need to reduce errors as far as possible–before writing warnings and precautions in your instructions for use.

Reaching the point where use errors cannot be reduced any further may require many design iterations, and each iteration should be subsequently evaluated with formative usability testing. Formative testing can be performed with prototypes, rather than production equivalents, but the formative testing conditions should also address factors such as the use environment and users with different levels of education and/or experience. Ultimately, if the formative testing is done well, summative (validation) testing will be a formality.

Risk Control Effectiveness During Phase 4 – Verification Testing

Once your team freezes the design, you will need to conduct verification testing. This includes integrating usability testing into the verification testing process. Summative (validation) testing must be performed once your design is “frozen.” If you are developing an electrical medical device, then you will need to provide evidence of usability testing as part of your documentation for submission to an electrical safety testing lab for IEC 60601-1 testing. There is a collateral standard for usability (i.e., IEC 60601-1-6). For software as a medical device (SaMD), you will also be expected to conduct usability testing to demonstrate that the user interface does not create any user errors.

Summative Usability Testing Process 174x300 Integrating usability testing into your design process

When you conduct summative (validation) testing, it is critical to make sure that you are using samples that are production equivalents rather than prototypes. Also, it is crucial to have your instructions for use (IFU) finalized. Any residual risks for use errors should be identified in the precautions section of your IFU, and the use of video is encouraged as a training aid to ensure use errors are identified, and the user understands any potential harm. When the summative testing is performed, there should be no deviations and no use errors. Inadequate identification of usability factors during Phase 2, or inadequate formative testing during Phase 3, is usually the root cause of failed summative testing. If your team prepared sufficiently in Phase 2 and 3, the Phase 4 results would be unsurprisingly successful.  

Additional Training Resources for Usability Engineering

Our human factors testing webinar was recently updated by Research Collective–a consulting firm specializing in usability engineering. SYS-048, Medical Device Academy’s Usability Procedure, is compliant with IEC/ISO 62366-1 (2015). The procedure includes a template for conducting summative (validation) usability testing. We have also updated our design plan template to include usability testing elements.

Posted in: Design Control, Usability

Leave a Comment (0) →

Accelerating design projects – one secret you haven’t heard

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

A secret Accelerating design projects   one secret you havent heard

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…

Our testing plan is my life t shirt 1 298x300 Accelerating design projects   one secret you havent heard

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 1 Accelerating design projects   one secret you havent heard
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

Your cart is empty

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.

Posted in: Design Control

Leave a Comment (0) →

Design Plan Template – with Risk Management

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

Design Plan Template Graphic 1024x194 Design Plan Template   with Risk Management

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 new 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. 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:2012 requires a risk management plan in Clause 3.4, but there are some subtle changes needed for compliance with the new draft ISO/DIS 14971. In addition, there are new 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:

Other Webinars About Design Controls

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

Posted in: Design Control

Leave a Comment (0) →

Risk Management Requirements – 510k vs DHF

This article compares the risk management requirements for a 510k submission with the risk management requirements for your design history file (DHF).

Design Controls and Risk Management Risk Management Requirements   510k vs DHF

Risk Management Requirements and Design Control Requirements

Last week I presented a free webinar on how to combine risk management with design controls when planning to submit a 510k. Many questions were asking what the design control and risk management requirements are for a 510k.

What are the Design Control Requirements in a 510k?

There is no specific part of the regulations stating what the 510k design control requirements are. However, some aspects of the DHF are required as 510k design control documentation, but not necessarily in the exact form as maintained in the DHF. For example, Design Inputs and Design Outputs are presented as applicable recognized standards and design specifications, while others will remain precisely the same (i.e., verification and validation test reports).

What are the Risk Management Requirements in a 510k?

For 510k submissions, the only risk management requirements are the inclusion of risk documentation for devices containing software of at least moderate level risk. There are some exceptions to this as well, though, based on a few special control guidance documents—especially when the submission type is an abbreviated 510k. This is article identifies which of the DHF and RMF elements are 510k design control requirements and 510k risk management requirements.

510k Design Control Requirements

Design Controls are identified in 21 CFR 820.30. Every manufacturer of any class II or class III devices and certain Class I devices (class I devices with software, tracheobronchial suction catheters, surgeon gloves, protective restraints, radionuclide applicators, radionuclide teletherapy devices) need to control design per this regulation. The requirement for a Design History File is item j) and states:

“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 following the approved design plan and the requirements of this part.”

The “requirements of this part” refer to the other bullets in 21 CFR 820.30 which can be summarized as:

a) Establish and maintain procedures to control the design of a device.

b) Design and Development Planning – Each manufacturer shall establish a plan that describes the design and development activities, and defines responsibilities for implementation.

c) Design Inputs – Manufacturers need to ensure design requirements relating to a device are appropriate and address the intended use of the device.

d) Design Outputs – Design outputs need to be documented in terms that allow an adequate evaluation of conformance to design input requirements. Design outputs that are essential for the proper functioning of the device should be identified.

e) Design Review – Formal documented reviews of design results should be planned and conducted at appropriate stages of device development.

f) Design Verification – Design verification confirms that the design output meets the design input requirements.

g) Design Validation – Design validation shall be performed under defined operating conditions on initial production units or their equivalents. It shall ensure that devices conform to defined user needs and meet the intended use of the device.

h) Design Transfer – Design transfer documentation shall ensure that the device design is correctly translated into production specifications.

i) Design Changes – changes should be identified, documented, validated/verified, reviewed, and approved before their implementation.

The Design History File is intended to be a repository of the records required to demonstrate compliance with your design plan and design control procedures. While companies are required to create and maintain this documentation according to the FDA regulation, not all of the documentation will be reviewed as part of the 510k. The following table compares the elements that comprise a DHF with the 510k design control requirements.

DHF Element 510k Design Control Requirements
Design Plan Not Required
User Needs Not Required
Design Inputs

Cover Sheet (Section 1) and

Declaration of Conformity (Section 9)

Some design inputs will appear in the form of standards in FDA Form 3514 (Cover Sheet) and the Declaration of Conformity FDA Form 3654 (Standards Data Report)

Design Outputs

Device Description (Section 11)

The Device Description lists the specifications of the device, and your Design Outputs document will help populate the Device Description. This can include drawings, pictures, or written specifications that describe your device.

Labeling

Proposed Labeling (Section 13)

The labeling is usually considered part of the Design Outputs within the DHF and is included specifically in the labeling section of the 510(k) submission. This includes both the Instructions for Use and any Package Labeling.

Verification and Validation Protocols

Not Required

You do not have to include the protocols, but the reviewer may ask to see them if they have any questions when reviewing the reports.

Verification and Validation Reports

Sterilization (Section 14)

Biocompatibility (Section 15)

Software (Section 16)

Electrical Safety and EMC (Section 17)

Bench Performance Testing (Section 18)

Animal Performance Testing (Section 19)

Clinical Performance Testing (Section 20)

Of course, not all of these sections will be applicable to every device. Still, you should include all relevant validation test reports within your submission in the appropriate part of the 510k. Typically, each of these sections will have a cover sheet that outlines the reports that are included within the section, and then you can just include the report from the DHF in its entirety behind the cover sheet in that section.

Process Validation Only required for sterilization validation typically, but there are exceptions for novel materials and coatings
Work Instructions Not Required for 510k
Design Review Meeting Minutes Not Required for 510k
Design Trace Matrix Only required for software
Risk Management File Sometimes – See Risk Management File Table Below
Post-Market Surveillance Plan Not Required, but a few exceptions for high-risk devices
Clinical Data Summary Required only if used to demonstrate safety and efficacy
Regulatory Approval It Will result from 510k Clearance, so nothing to be included in 510k submission.

510k Risk Management Requirements

Regarding the FDA regulations for risk management, there is a requirement under the Design Validation section of 21 CFR 820.30 that states:

“Design validation shall include software validation and risk analysis, where appropriate.”

For FDA compliance and CE Marking, both recognize ISO 14971 as the standard for risk management. FDA recognizes ISO 14971:2007 whereas EN ISO 14971:2012 is the European National version for CE Marking. Rob Packard wrote an article describing the contents of the risk management file as well as the specific differences in the requirements between the FDA and CE Marking with regard to ISO 14971.

For your 510k submission, the FDA only requires risk management documentation to be included if the product contains software, and the risk is at least a level of “moderate concern”. There are some other cases when risk management is required by special controls guidance documents, but even when it is required, you only have to submit your risk analysis. The table below describes the risk management requirements in greater detail.

RMF Element 510k Risk Management Requirement
Risk Management Plan Not Required
Hazard Identification

510ks with Software Only (Section 16)

Hazard Identification is only required for devices that have a software component. It is not required for most other devices.

Risk Assessment

510(k)s with Software (Section 16)

Certain Special Controls Guidance

The Risk Assessment is only required to be included in your device contains software, or if a special controls guidance document specifically requires a risk assessment. It is not required for other 510ks.

Risk Control Option Analysis Software and Certain Special Controls Guidance
Risk Control Verification and Validation

Sterilization (Section 14)

Biocompatibility (Section 15)

Software (Section 16)

Electrical Safety and EMC (Section 17)

Bench Performance Testing (Section 18)

Animal Performance Testing (Section 19)

Clinical Performance Testing (Section 20)

This will not be any additional or special documentation specific to Risk Management and was already included in the DHF breakdown above. Still, the verification and validation also relate to risk management in ensuring that the risks have been adequately mitigated.

Risk-Benefit Analysis

Not Required for 510(k)

Risk-Benefit analyses are only required for De Novo applications, Humanitarian Device Exemptions, and PMAs.

Informing Users and Patients of Risks

Labeling (Section 13)

Part of the risk management will appear in the Labeling section of the 510k as warnings, contraindications, and precautions within the Instructions for Use and Package Labeling.

Risk Management Report Not Required

Special Controls Guidance Documents with Risk Management Requirements

Your first step in preparing your 510k submission is to search the FDA Guidance Document Database to determine if there is an applicable guidance document for your device. You can read another blog we wrote to explain Special Controls Guidance documents, and how to determine if one applies to your device. The following list provides examples of Class II Special Controls Guidance documents that require risk analysis to be included within the 510k:

When there are 510k risk management requirements, the special controls guidance document will typically state, “We recommend that the summary report contain:

An identification of the Risk Analysis method(s) used to assess the risk profile in general as well as the specific device’s design and the results of this analysis. (Refer to Section 6 for the risks to health generally associated with the use of this device that FDA has identified.)

Discussion of the device characteristics that address the risks identified in this class II special controls guidance document, as well as any additional risks identified in your risk analysis.”

The special controls guidance will also identify risks to health that have been identified for products of that type, which you should be sure to include in your risk analysis as appropriate.

More Information on Design Control and Risk Management Requirements

Hopefully, you are now able to determine which elements of your DHF are 510k design control requirements and which elements of your RMF are 510k risk management requirements. If you would like more information about how to implement design controls and risk management within your product development process, please consider registering for one of our training webinars:

If you need any further information or specific assistance with your 510k submission, please feel free to send me an email at mary@fdaecopy.com or schedule a call with our principal consultant, Rob Packard. He can answer any of your medical device regulatory questions.


Click here to schedule a 15 minute call 300x62 Risk Management Requirements   510k vs DHF

Posted in: 510(k), Design Control, ISO 14971:2019 (Risk Management)

Leave a Comment (0) →

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 need 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 before 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 higher risk for Class 2 devices. When you design a Class 1 device, you still have to determine what your design specifications will be. Again, 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 consist of 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 fundamental 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. When ORA inspectors perform an inspection for Class 1 devices, the inspector looks for evidence of items in the 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 (4) →

Color change is only device modification. Is a new 510k required?

This article explains the process for determining if a color change and other material changes require a new 510k before implementing the change.

color change Color change is only device modification. Is a new 510k required?

I recently taught a frequently asked questions (FAQs) webinar, where I asked attendees to provide questions in advance of the webinar, and I answered the questions during the webinar. One of the attendees asked how to know if a new 510k is required if the only modification to a device is a color change.

New FDA guidance for device modifications

On August 8, 2016, the FDA released a new draft guidance document for device manufacturers regarding device modifications and when a new 510k is required. The current final guidance is titled “Deciding when to submit a 510(k) for a change to an existing device,” and that guidance is dated January 10, 1997. A draft guidance document on this topic was released several years ago, but that draft guidance was withdrawn in response to feedback from the industry. The new draft guidance document includes modified decision trees to help manufacturers decide which types of changes will require a new submission, but there are also examples provided in Appendix A. The most helpful part of the guidance, however, is Appendix B. Appendix B explains how to document changes properly—regardless of whether a change requires submission or not.

Decision Trees from the Guidance

There are five decision trees or flow charts provided in the new draft guidance. The purpose of each decision tree is identified below:

  • Main flow chart
  • Decision Tree A = labeling changes
  • Decision Tree B = technology, engineering and performance changes
  • Decision Tree C = material changes
  • Decision Tree D = IVD product changes

How to apply Decision Tree C to a color change

Typically adding a colorant, or changing a colorant, does not negatively impact the strength of a device, but this is the first cautionary statement made at the beginning of the section for material changes. Therefore, if your device has a performance testing requirements that involve a component that is involved in a proposed color change, then you need to repeat the performance testing to verify that the color change has not negatively impacted the strength. Sometimes large concentrations of colorant result in weakening of plastics. Therefore, repeating some of the performance testing or providing data that supports the need for no further testing is expected. In the decision tree, this is addressed by question C5, “Could the change affect performance specifications?” If no, then you document the change, but a new 510k is not required. If yes, then you refer to decision tree question B5.

The next concern addressed by Decision Tree C is the biocompatibility of your modified device. If the material change of the device or device component comes into direct contact with the body, blood, or tissues, then biocompatibility risks must be assessed. If the change does create new or increased issues related to biocompatibility, then question C4.1 asks, “Has the manufacturer used the same material in a similar legally marketed device?” If the changed material has not been used previously for a similar application, then a new 510k is required—typically a Special 510k if only the material is changed and only biocompatibility needs to be assessed by the FDA.

Reference to FDA biocompatibility guidance

Within the guidance document, the FDA explains that you may want to refer to “Use of International Standard ISO 10993-1, ‘Biological Evaluation of Medical Devices Part 1: Evaluation and Testing,’” when you are answering question C4. This new final guidance was released on June 16, 2016, and the Office of Device Evaluation (ODE) appears to be focusing much more closely on biocompatibility since this new guidance released.

Examples of material changes from FDA guidance

There are six examples of material changes presented in the new draft guidance:

  1. A slight change in polymer composition for a catheter = letter to file
  2. Change in polymer for a catheter
    1. Change in a polymer for a catheter to a polymer already used by another manufacturer for a 510k cleared device with the same indications = new 510k submission
    2. Change in a polymer for a catheter to a polymer already used by your company for another 510k cleared catheter of the same type and duration of contact = letter to file
    3. Change in a polymer for a catheter to a polymer already used by your company for another 510k cleared catheter of the same type but shorter duration of contact = new 510k submission
    4. Change in a polymer for a catheter to a polymer already used by your company for another 510k cleared catheter of the same type but longer duration of contact = letter to file
  3. Change in the manufacturing method of catheter tubing (i.e., molding to extrusion) = new 510k submission
  4. Change in material for a catheter
    1. The new polymer is already used by your company for another 510k cleared catheter of the same type and same duration, but the sterilization method changes (i.e., gamma to EO) = new 510k submission
    2. The new polymer is already used by your company for another 510k cleared catheter of the same type, duration, method of manufacturing (i.e., molding) and method of sterilization (i.e., EO) = letter to file
    3. The new polymer is already used by your company for another 510k cleared catheter of the same type, duration, method of manufacturing and sterilization, but the performance specifications are slightly different = letter to file (depends upon the impact of difference)
  5. Change in the dental implant from the untreated surface to acid-etched = new 510k submission (may also be considered a design change)
  6. The implantable device is marked temporarily with tape proven not to leave a residue = letter to file

Do you have other questions about biocompatibility?

On Thursday, December 1, @ 11:00 am EST, I will be hosting a new live webinar on the topic of biocompatibility. The webinar will address both requirements for 510k submissions and for CE Marking technical files. If you are interested in registering for that webinar, please click on the following link:

Click Here for Biocompatibility Webinar 300x64 Color change is only device modification. Is a new 510k required?

Do you have a question about your 510k submission?

If you have a question related to your 510k submission, you can submit your question to me and download the webinar recording for free by clicking on the following link:

Click Here for 510k FAQs Webinar 300x64 Color change is only device modification. Is a new 510k required?

I will respond to your question by email, but most questions make great future blog topics—like this one.

You might also be interested in our 510k course series:

Click Here for 510k Course 300x64 Color change is only device modification. Is a new 510k required?

You gain unlimited access to 24 webinars related to 510k submission.

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

Leave a Comment (0) →

Implementing Design Controls – 10 Steps

The article explains ten steps of implementing design controls, including design plans, design inputs, design review, verification protocols, and risk management.
waterfall fda Implementing Design Controls   10 Steps

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

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.

Posted in: Design Control

Leave a Comment (6) →
Page 1 of 2 12