Design Control Medical Device Academy

Archive for Design Control

Human factors process, can we make this easy to understand?

Posted by Rob Packard on April 12, 2022

90% of usability testing submitted to the FDA is unacceptable and the root cause is simply a failure to understand the human factors process.

If you submitted no usability testing to the FDA in your 510(k) submission, it would be obvious why the FDA reviewer identified usability as a major deficiency. However, you spent tens of thousands of dollars on usability testing that delayed the 510(k) submission by six months. Despite all of the time and money your company invested in the human factors process, it appears that you need to start over and repeat the entire process again. The CEO is furious, and he wants you to show him where in the 49-page FDA guidance it says that you have to do things differently.

Benefits from the human factors process

Use errors result in serious injuries and death
Easy to use products sell
You will prevent delays in regulatory approval

Why was your rationale for no usability testing rejected?

Unlike CE Marking technical files, the FDA does not require a usability engineering file for all products. Instead, the FDA determines if usability testing is required based upon a comparison of your device’s user interface and a competitor’s user interface (i.e. predicate device user interface). If the user interface is identical, then usability testing may not be required. Instead, your company should be able to write a rationale for not doing usability testing based upon equivalence with the predicate device. If there are differences in your user interface, you will need to provide use-related risk analysis (URRA), identify critical tasks, implement risk controls, and provide verification testing to demonstrate the effectiveness of the risk controls. Even if your device is “easier to use” or “simpler”, you still need to provide the documentation to support this claim in your submission. The FDA also does not allow comparative claims in your marketing for 510(k) cleared devices. Comparative claims require the support of clinical data.

What is the 10-step human factors process?

Define human factors for your device or IVD
Identify use errors
Conduct a URRA
Perform a critical task analysis
Conduct a risk control option analysis
Conduct formative usability testing
Implement risk controls
Conduct summative usability testing
Prepare HFE/UE documentation
Collect post-market surveillance data specific to use errors

There is a YouTube video describing these 10 steps at the bottom of this blog posting.

Why is formative testing needed?

Observational study to identify unforeseen use errors
Observational study to evaluate risk control options
What are the other types of studies?
Development of indications for use
Development of training materials

Why is the human factors process crazy expensive to outsource?

Human factors consultants need time to learn about your device
Consultants are more conservative because they cannot afford to fail
Justifying your choice of risk controls is difficult because you started too late
Your instructions for use (IFU) are inadequate
Consultants need to explain the human factors process to you
Recruiting subjects is marketing (which may not be their expertise)
You are paying for infrastructure (specialized testing facilities)
This is a team effort that requires many consulting hours collectively

Why was your Usability Engineering File refused?

Your company provided an application failure modes and effects analysis (aFMEA) to support your justification that residual risks are acceptable. The FDA guidance suggests using risk analysis tools such as an FMEA or fault-tree analysis, but deficiency letters from FDA reviewers recommend a use-related risk analysis (URRA) format that is totally different.

Example of a URRA Table provided by the FDA for the Human Factors Process

The primary problem with using an FMEA or Fault-Tree risk analysis tool is that these tools involve estimation of the severity of harm and the probability of occurrence of harm, while the FDA does not feel it is appropriate to estimate the probability of occurrence of harm. Instead, the FDA instructs companies to assume that use errors will occur and to implement risk controls to mitigate those risks (see URRA example above). Although “mitigation” is unlikely, and use risks will only be reduced, this is the approach the FDA wants companies to use. In addition, the FDA expects your company to provide traceability of risk control implementation to each use-related risk you identified and the FDA expects documentation of verification testing (i.e. usability testing) that shows your risk controls are effective. Finally, the FDA (and ISO 14971, Clause 10) expects you to collect and perform a trend analysis of use errors. Any use errors that are reported should be evaluated for the need to implement additional corrective actions to prevent future use errors. Blaming “user error” is not an acceptable approach.
You provided risk analysis and human factors testing in your 510(k) submission, but the FDA reviewer said you need to identify critical tasks and provide traceability to each critical task in your summative validation report. – Critical tasks are specifically mentioned in section 3.2 of the FDA guidance on applying human factors and usability engineering–and a total of 49 times throughout the guidance. However, “critical tasks” are not mentioned even once in ISO 14971:2019 or ISO/TR 24971:2020. The term “critical tasks” is not even found in IEC 62366-1:2015. There is mention of “tasks”, and “task” is a formal definition (i.e. Definition 3.14, “Task – one or more USER interactions with a MEDICAL DEVICE to achieve a desired result”). Therefore, companies that are familiar with the ISO Standards and CE Marking process frequently need training on the FDA requirements for the human factors process. After receiving training, then your company will be prepared to modify your usability engineering file documentation to comply with the FDA requirements for human factors.
You completed a summative validation protocol, but the FDA disagrees with your definition of user groups. – Each user has a different level of experience, training, and competency. Therefore, if you define the intended user population too broadly (e.g. healthcare practitioners), the FDA may not accept your summative usability testing. This is the reason that the human factors process begins with defining the human factors for your IVD or device. Radiologists, for example, have the following training pathway:
- graduate from medical school;
- complete an internship;
- pass state licensing exam;
- complete a residency in radiology;
- become board certified; and
- complete an optional fellowship.

Therefore, if you are developing imaging software, you need to make sure your user group includes radiologists that cover the entire range of competencies. In addition, most radiology images are taken by radiology technicians and then reviewed by the radiologist. Therefore, radiology technicians should be considered a completely different user group due to the differences in experience, training, and competency when compared to a radiologist. This simple example doubles the number of users needed because you have two user groups instead of one.

You evaluated 15 users, but the FDA reviewer is asking you to evaluate a larger number of users based upon a special controls guidance document. – The FDA guidance on human factors testing specifies a minimum of 15 users for each user group–not a minimum of 15 users. Therefore, for a device that is for Rx-only and OTC use, you will have at least two user groups that need to be evaluated independently. In addition, some devices have special controls guidance documents that specify usability testing requirements. For example, an OTC blood glucose meter must pass a 350-person lay-user study. Covid-19 self-tests are expected to pass a 30-person lay-user study as another example.
Your usability study was conducted in Australia, but the FDA insists that your usability study must be repeated in the USA. – Most people think of language being the primary difference between two countries, and therefore the author of a study protocol may not perceive any difference between the USA and Australia, Ireland, Canada, or the UK. However, this lack of ability to identify differences between cultural norms shows our own ignorance of cultural differences. International travelers learn quickly about the differences in the interface used for electrical outlets between the USA and other countries. There are also more subtle differences between cultures, such as in which direction do you toggle a light switch to turn on a light, up or down? For devices that are used in a hospital environment, it is critical to understand how your device will interact with other devices and how different hospital protocols might impact human factors.
The FDA reviewer indicated that your usability engineering file does not assess the ability of laypersons to self-select whether your OTC device is appropriate for them. – Devices and IVD devices may have contraindications or indications for use that are specific to an intended patient population or intended user population. In these cases, the user of the device or IVD needs to be able to “self-select” as included or excluded from use. The ability to self-select should be assessed as part of any OTC usability study. The ability to identify suitable and unsuitable patients for treatment is also a common criterion for a usability study involving prescription devices where a physician is the subject of the study.
The FDA reviewer indicated that you did not provide raw data collected by the study moderator. – Data collected during a human factors study is usually subjective in nature, and the FDA may want to conduct their own review and analysis of your data. Therefore, you cannot provide only a testing report that summarizes the results of your study. You must also provide the raw data for the study. It is permitted to provide the data in a tabular format that has been transcribed from paper case report forms or was recorded electronically. You should also consider scanning any paper forms for permanent retention or retaining the paper forms in case there is any question of accuracy in the transcription of the data collected. Finally, it is best practice to record videos of the study participants performing each task and answering interview questions. This will help in filling any gaps in the notes recorded by the moderator, and the recording provides additional objective evidence of the study results.
The FDA reviewer indicated that your study is not valid, because the training provided by moderators was not scripted and training decay was not considered in the design of the study. – Summative usability testing requires that users complete all of the critical tasks identified in your critical task analysis without assistance. It is permitted to provide training to the user prior to conducting the study if the device or IVD is for prescription use and healthcare practitioners are responsible for providing instruction to the user. However, any training provided must be scripted in advance and approved as part of the summative usability testing protocol. This ensures that every subject in the study receives consistent training. Unfortunately, the FDA may still not be satisfied with the design of your study if you do not allow sufficient time to pass between the time that training is provided to the user and when the subject uses the device or IVD for the first time. In general, one hour is the minimum amount of time that should pass between providing user training and when the device or IVD is used for the first time. This is referred to as “training decay” and the duration of time between your scripted training and the user performing critical tasks for the first time should be specified in your summative usability protocol. One solution to address both issues is to provide a video of the instructions to each subject 24-hours in advance of participation in the study.

Additional resources for the human factors process and usability testing

Tags: Design controls, Human Factors Process, IEC 62366-1, Usability

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

Software as a medical device (SaMD)

Posted by Rob Packard on June 1, 2021

Can you combine the software development lifecycle with design controls when you are developing software as a medical device (SaMD)?

Don’t forget to subscribe to our YouTube channel for more medical device quality and regulatory training. There has been a remarkable increase in the number of medical devices developed in the past few years that consist of only software. The medical device industry refers to these products as software as a medical device (SaMD). Along with the increase in the number of SaMDs on the market, there has also been an increase in the number of companies that are developing these SaMDs without any prior medical device industry experience. Medical Device Academy specializes in helping start-up medical device companies, and we see common characteristics shared by these MedTech start-ups. First, they are usually successful in demonstrating proof of concept for their software device within months. Second, the development team is typically virtual (i.e. everyone lives in a different state or even in different countries). Third, the development team does not include anyone with quality or regulatory responsibility. Fourth, the company has not implemented software design controls or started a design history file (DHF). Fifth, the company is not even aware of the existence of IEC 62304 (less expensive than other websites) –the international standard that defines the life cycle requirements for medical device software.

The above situation is quite common, but it is not a serious problem. These Medtech start-ups just need guidance on how to comply with medical device regulations without creating an overly burdensome quality system and excessive documentation. At the same time, these companies need to stay small, agile, and thrifty. Most people believe that the quality system and software documentation process slows down the development process, but the intent is to prevent mistakes and to help you plan the design and development of your SaMD so that the resulting software is safe and performs as you intended (i.e. efficacious). In order to create a quality system and software documentation process that is lean and efficient, there are some common pitfalls you should avoid.

When do you need to implement a quality system for software as a medical device (SaMD)?

When a quality system is required depends upon which market you are launching your product in first. If you are launching your product in Canada, you need a special kind of quality system certificate before you can apply for a Canadian Medical Device License (i.e. MDSAP Certificate for ISO 13485:2016). MDSAP stands for “medical device single audit program,” and there are only 16 organizations that can issue this type of certificate. If you are launching your product in Europe, you will go through your ISO 13485 quality system certification in parallel with obtaining the CE Certification of your SaMD. If you are launching your product in the USA, you do not need your quality system to be complete until after you obtain 510(k) clearance and you are ready to register and list with the FDA. You also do not need ISO certification for the US market. If your SaMD is a Class 1 device in any of these three markets, you may have fewer quality systems and regulatory requirements.

Regardless of which market you are planning to launch your product in, you should not invest in a complete quality system and then develop your SaMD. You should either develop both in parallel, or you should develop your SaMD first. The only processes that are really important to implement at the beginning of product development are 1) design controls, 2) software development, 3) risk management, and 4) usability engineering or human factors testing. You can wait to implement the other 20+ procedures until you are entering the design transfer phase of your design and development project.

Do you need separate procedures for design controls, change control, and software development?

If you are developing a complex system that includes hardware and software you should probably have three separate procedures. The reason for this is that there are different quality systems and regulatory requirements for changes to hardware and software. If you are only developing SaMD, then you can easily combine these three processes into one procedure. The video at the beginning of this blog describes how to combine these three into one procedure, but the following outlines the software documentation that should be covered in each stage of your design process:

Phase 1 – Design planning requires identification of the software risk classification (i.e. A, B, or C) in accordance with IEC 62304, and the Level of Concern (LoC) for your software in accordance with the FDA guidance for software documentation. Regardless of what the LoC is for your SaMD, you will still need to develop the documentation required for the risk classification in IEC 62304–even if the FDA does not want to review all of that documentation in your 510(k) submission. You will also need to identify the regulatory pathway for your SaMD. Your design plan will identify the team members and each person’s role and responsibility. This phase is when you should document your software development environment, create a draft software description, and create a draft software architecture diagram.
Phase 2 – Design inputs must be documented and approved in the second phase. These inputs are testing requirements. Therefore, you need to develop a testing plan for your product based upon the regulatory pathway for that product, recognized international standards or common specifications, and any guidance documents that are specific to your type of SaMD. Typically, it is recommended to review your testing plan with a regulator in a pre-submission meeting prior to conducting your verification and validation testing–especially if animal preclinical studies or human clinical studies are required. This phase is when you should conduct a hazard analysis and approve your software requirements specification (SRS). The hazard analysis should include use-related risk analysis (URRA) and cybersecurity risk analysis.
Phase 3 – Design outputs are iteratively developed during the third phase. This is typically the longest phase of your development process, and the “Waterfall Diagram” is not an accurate depiction of most software development processes. The “V-Diagram” presented in IEC 62304 is a better representation of the software development process because you continuously repeat steps as you debug your code and add functionality to your software. Only the simplest firmware is written in a linear fashion without multiple debug and retest cycles, and lean product development methods (i.e. Agile programming) are intended to be iterative. This phase of development is complete when you conduct a “design freeze” and begin your verification and validation testing. Typically, companies that are developing SaMD can complete most of their unit testing and integration testing prior to the design freeze, but system validation may not be conducted until phase 4. Unfortunately, the unit testing and integration testing can only proceed so far if you have an embedded system (i.e. software embedded in hardware). If the SaMD requires human clinical studies, that software validation is performed during Phase 4. Phase 3 is when you should be documenting your software design specifications (SDS), unit testing, and integration testing. Any formative testing required for the user interface would be done during this phase. Formative testing may include: 1) evaluating very software functions, 2) developing directions for use, and 3) developing a training program for users. You should write testing protocols for system validation and summative usability testing during this phase as well. It is important to identify all of the critical tasks related to use-related risks during this phase and document them. These critical tasks determine the summative usability testing required. It is also an excellent idea to start drafting a traceability matrix during this phase to ensure that each hazard and SRS item is being addressed in your verification and validation plan.
Phase 4 – Design verification and validation of your SaMD are completed during this phase. At the end of this phase, you should have a complete traceability matrix, you should create a summary report of your unit testing and integration testing, and you should create a system validation report–including any benchtop, animal, or human performance testing is conducted. You should also create a revision history document and a bug report identifying any known bugs in the software with a justification for why the software is safe to release with these bugs. This phase is also when you should complete your risk management file and your summative usability testing report. Finally, you need to complete a final draft of your user manual for the software that includes directions for use and the indications for use. When all of this documentation is completed, you are ready for your regulatory submission.
Phase 5 – Product release is the last phase of design and development. Once you receive 510k clearance for your SaMD, then you can begin the final release of your product. You will need to update your “splash” or “about” screen for the software to include a Unique Device Identifier (UDI). The information will need to be uploaded to the FDA’s GUDID. You can assign the DI for the UDI anytime, but the GUDID data elements cannot be finalized until you have 510k clearance from the FDA. You will also need to manage revisions of your software for this minor change and revalidate the code. This type of change will not require a new 510k, because it is a minor device modification. However, you will need to review the FDA guidance on software changes for other types of software revisions you make in the future.

Should you outsource software documentation for software as a medical device (SaMD)?

You can outsource all of your software documentation for a SaMD, but the person(s) creating that documentation will still need the documents mentioned in phase 2. If you do not provide any documentation of hazards, a software description, or a crude sketch of your software’s architecture, it will be nearly impossible for anyone to create your software documentation. It is also extremely expensive to outsource software documentation. Even if you do outsource this task, you still will need to review and approve that documentation. Most people outsource tasks because they don’t know how to do it, but it is critical for medical device companies to learn how to document their software development because they will need to maintain that documentation when the software is updated to fix a software bug or to patch cybersecurity weaknesses. Everyone that is developing software for a SaMD should receive basic training on the requirements of IEC 62304 early in your project. Your team does not need to be an expert in IEC 62304, but you need to create draft documents that you can present to experts for feedback. Your team should also review all four of the guidance documents that the FDA released for software documentation:

Creating your documentation is the hard part that your team should be doing while reviewing and editing your documentation is a great task to hire an expert consultant for your first SaMD project. This will ensure your team is writing the software documentation to the correct level of detail, and that you are not missing anything critical. Expert consultants can also provide you with templates for your software documentation.

Does software as a medical device (SaMD) require an electronic quality management system (eQMS)?

There are two types of quality systems: 1) paper-based, and 2) electronic. Most start-up companies chose the paper-based option because they don’t want the extra hassle of having to validate an electronic system. However, if your company is smart enough to validate SaMD, you are smart enough to validate software for your quality system too. The applicable standard for validation of software tools is ISO/TR 80002-2:2017. You can also purchase templates for software tool validation from Medical Device Academy. Companies are always asking for a referral of which eQMS system to purchase. The problem is that every year software has more functionality and costs less. Therefore, my general advice is to never pay more than $10,000 for eQMS as a start-up and consider starting with free database software to organize all of the documentation that is in your traceability matrix. You can migrate the data into an eQMS later by mapping your free database to the new eQMS software database.

Who should be responsible for QA and RA for software as a medical device (SaMD)?

Quality and regulatory are two different functions, and it doesn’t always make sense to have one person be responsible for both requirements. The two primary standards that are applicable to the quality assurance of SaMD are 1) IEC 62304, and 2) ISO 13485. Anyone you are considering for the position of quality manager should be familiar with both standards, and they should be making sure that your development team is documenting the software verification and validation as you proceed through the iterative software development process that is typical of Agile software development teams. The person doesn’t need to be able to code software, but they should be able to help review software documentation and suggest changes. This person’s role is extremely important to make sure that software revisions are managed properly, your software is only released when all of the validation and revalidation are complete. This person should also be able to determine if a new 510(k) is required for software modifications.

The regulatory process is the preparation of the 510k submission and communications with the FDA. This is an activity that you will probably need to perform once every two years. The FDA requirements for a 510k change more frequently than once every two years, and it is extremely difficult to become proficient when you are filling out government forms so rarely. For these reasons, it is recommended to work with an expert regulatory consultant with SaMD experience until your company has enough software products and revisions that you need to file multiple 510k submissions each year. Therefore, a less experienced quality manager can gradually learn the regulatory requirements over time and they will need less help from a regulatory consultant each year.

How do you measure quality for SaMD?

A lot of software developers struggle with identifying quality metrics if they are developing software as a medical device (SaMD). There are many aspects of software development that you can measure. Here’s a list of examples:

customer feedback
the velocity of Agile sprints
coding errors
what is the development lead time?
how fast does the software load?
technical support requests
software configuration errors
duration of software validation
software validation documentation burden
post-market surveillance of use errors
How many software bug remain?

Do you need a corporate office?

Many MedTech companies are virtual companies, but the FDA will require a physical address to visit for an FDA inspection. FDA inspectors have visited the home of the company founder at other companies, but you probably will be more comfortable with an office space for the FDA inspector to visit. The FDA is unlikely to visit your company during the first year after you initially register your product. An inspection is more likely in the second year after initial registration and listing. Therefore, you might consider renting a co-working space where you can reserve a conference room if an FDA inspector visits. If you don’t have the funds to afford rent until after you launch your product, don’t worry. FDA inspectors are unlikely to visit so soon, and if they do–just relax and be honest about the situation. You are not alone.

About the Author

Robert Packard is a regulatory consultant with 25+ years of experience in the medical device, pharmaceutical, and biotechnology industries. He is a graduate of UConn in Chemical Engineering. Robert was a senior manager at several medical device companies—including the President/CEO of a laparoscopic imaging company. His Quality Management System expertise covers all aspects of developing, training, implementing, and maintaining ISO 13485 and ISO 14971 certifications. From 2009 to 2012, he was a lead auditor and instructor for one of the largest Notified Bodies. Robert’s specialty is regulatory submissions for high-risk medical devices, such as implants and drug/device combination products for CE marking applications, Canadian medical device applications, and 510(k) submissions. The most favorite part of his job is training others. He can be reached via phone at 802.258.1881 or by email. You can also follow him on Google+, LinkedIn, or Twitter.

Posted in: Design Control, Software Verification and Validation

NSE letter: A CAPA plan for your 510k process

Posted by Rob Packard on April 28, 2020

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 510k 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 510k. 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 510k reminds me why a pre-sub meeting is so valuable. You always learn something that helps you with the preparation of your 510k.

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?

Posted by Rob Packard on February 12, 2020

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

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

Ten most common mistakes in managing design change control

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

Previous regulatory approvals [e.g., 510(k) number]
Applicable Technical File or DMR Index that will be updated
Any new risks identified
Any new applicable standards
Approved Design Inputs (indicate if changes are needed)
Design Outputs that need to be updated (consider highlighting in your DMR index)
Changes to your supply chain (e.g., process changes, supplier changes, supplier quality agreements, and process changes)
Process validation and Revalidation required
Labeling and UDI changes
Obsolescence of inventory and reverse/forward compatibility of components
Impact on service procedures and/or providers
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

Posted by Rob Packard on October 9, 2019

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

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

Integrating usability testing into your design plan helps identify issues earlier

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:

prospective device users during all stages of use must be defined
use environments must be identified
user interfaces must be identified
known use errors with similar devices and previous generations of your device must be researched
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 – Formative Usability Testing in 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 – Summative Usability Testing during Verification

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

The following additional training resources for usability engineering may be helpful to you:

Posted in: Design Control, Usability

Accelerating design projects – one secret you haven’t heard

Posted by Rob Packard on July 25, 2019

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:

First, do every test in parallel that you can.
Second, identify any tests that must be done sequentially.
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

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

Posted by Rob Packard on November 18, 2018

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:

Hazard identification
Risk estimation
Risk evaluation
Risk control option analysis
Risk control verification of effectiveness
Benefit/Risk analysis
Evaluation of overall residual risk
Risk management review
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

Risk Management Requirements – 510k vs DHF

Posted by Mary Vater on August 22, 2017

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.

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%…

Posted by Rob Packard on March 22, 2017

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

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:

design and development procedures should consist of a qualitative assessment of the completeness and adequacy of the production specifications;
procedures should ensure that all documents and articles which constitute the production specifications are reviewed and approved; and
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%)

Approved Design Outputs
Labeling Procedure
Approved Labeling
Sterilization Validation Procedure
Sterilization Validation Protocol and Report
Design Transfer Procedure
Approved DMR
Design Change Procedure

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

Design Control Procedure
Design Plan
Approved Design Inputs
Approved Design Outputs
Labeling Procedure
Approved Labeling
Sterilization Validation Procedure
Sterilization Validation Protocol and Report
Design Transfer Procedure
Evidence of at least 1 Design Review
Approved DMR
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:

Design Control Procedure
Design Plan
Approved Design Inputs
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

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

Posted by Rob Packard on November 28, 2016

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

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:

A slight change in polymer composition for a catheter = letter to file
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
Change in the manufacturing method of catheter tubing (i.e., molding to extrusion) = new 510k submission
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)
Change in the dental implant from the untreated surface to acid-etched = new 510k submission (may also be considered a design change)
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:

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:

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