Effective Management Skills for Managers

1 Comment / ISO Certification / By / ,

This blog revies some practical and effective management skills that all managers should possess.

Sometimes we hear phrases like: “Well, that’s just an ISO requirement.” This apparent lack of support by top management is what frustrates every Management Representative in the world.

Peer Support

For a Quality Manager or any manager, it is vital to gain support from our peers, as failure to do so can lead to challenges. While the Quality Department plays a crucial role in recommending improvements, providing training, and assisting with implementation, it cannot address all problems on its own. Therefore, I strongly believe in assigning corrective actions to the process owner (i.e., the Manager) responsible for the area where the problems originated. This approach creates an opportunity for QA/RA to collaborate with the area manager and work together as a team towards the shared goal of improvement.

Good managers build people up and improve processes, they don’t point fingers or blame individuals. It is the process, not the person.

sKKP5YsxxUbjMPmSNnZr 4 hrptd 300x300 Effective Management Skills for Managers
Example of ‘not-an-effective-manager’

Persuading Skeptics

If you encounter resistance when trying to persuade skeptics, focus on a crucial project for the individual opposing your ideas. Demonstrate how applying Quality principles can effectively resolve their problems, potentially gaining their support. Converting one person often leads to strong support from them. If the resistant individual holds a senior position such as the CEO, take time to understand the CEO’s initiatives (These shouldn’t be hard to identify as they likely talk about them rather constantly). Illustrate how their actions can align with Quality Objectives, using graphs and presenting well-thought-out solutions to their challenges. Utilize the CAPA (Corrective and Preventive Action) process as a framework to show how the management team can collaboratively address issues.

If nothing seems to be working, you can always try reviewing some FDA MedWatch reports too–just to scare your boss.

Here is a list of tips to deal with unsupportive top management in a quality management system using effective management skills:

Clearly communicate the benefits of the quality management system:

Articulate the advantages that a well-implemented quality management system can bring to the organization, such as improved efficiency, reduced costs, and enhanced customer satisfaction. Don’t just leave the conversation at “The QSR/13485 says that we SHALL have one”.

Address specific concerns and show how quality initiatives overcome challenges:

Listen to the concerns of top management and present how quality initiatives directly address those issues, fostering a more positive outlook towards the system. Just like the old saying,

“An ounce of prevention is worth more than a pound of the cure”

Consider how ISO 13485:2016 has separate sub-clauses for Corrective Actions and Preventive Actions. Explain how something like pushing for preventive actions shows compliance with clause 8.5.3. which auditors, and inspectors will be looking for, but also that every Preventive Action represents a dodged 483 letter or recall.

Or how beefing up incoming inspection is likely to save time and money in reworked product and less scrap dispositions because any non-conforming materials are stopped before they can make their way into finished devices.

Demonstrate how quality aligns with overall business objectives:

Connect the quality management system to the organization’s strategic goals, highlighting how it contributes to long-term success and profitability. Reframe the Quality Policy and Quality Objectives as tools to support a successful business. Not just, “We have to have them for compliance….”

Start with small projects and showcase measurable results:

Begin with pilot projects or smaller initiatives that demonstrate tangible improvements, instilling confidence and support from top management.

Create a compelling business case for the quality management system:

Develop a well-researched and data-driven business case that outlines the return on investment and the long-term benefits of implementing the system. Effective management skills will involve encorporating topics like regulatory compliance. Not only how they align with, but are a part of business goals.

Engage top management in the decision-making process. Seeking their input and making them feel invested in shaping the quality management system. It is important that the entire organization be ‘quality focused’ at all times. Not just when an audit or management review is approaching.

Management Review Webinar and Procedure – Free Downloads

Consider the potential consequences of non-compliance with quality standards:

Emphasize the impact of not adhering to quality standards, such as regulatory penalties or reputational damage. This will underscore the necessity of the system’s implementation. This can be validated externally if need be. Auditors or consultants can assess quality processes and provide independent validation of a systems strengths of weaknesses.

7 Steps to writing an FDA 483 response

Effective Management Skills for Managers Read More »

Four easy ways 510k and De Novo content is different

4 Comments / 510(k), De Novo / By

It’s a common misconception that FDA De Novo content is very different from FDA 510k submission content, but is that true?

What do you think the De Novo content differences are?

Most people think the difference between a 510k and a De Novo is time and money. That conclusion is based upon a very important assumption: a 510k will not require clinical data, and a De Novo will require clinical data. That assumption is not always correct. 10-15% of 510k submissions include clinical data to support the performance claims, and last year our team submitted three De Novo submissions that did not include any clinical data. So what are the differences between a 510k and a De Novo content?

We use the same FDA eSTAR template for both types of FDA submissions, and on the first page of the eSTAR template, we identify if the submission is a 510k or De Novo. If we select De Novo, the eSTAR will be pre-populated with four unique De Novo content requirements that are not found in a 510k. The four unique requirements are:

  1. identifying alternative practices and procedures for the same indications
  2. recommending a classification, providing a justification for that classification, and explaining what efforts were taken to identify a suitable 510k product code
  3. providing a written benefit/risk analysis starting with the clinical benefits of your device
  4. recommendations for special controls for your new product code based upon the risks to health and the mitigation measures for each risk

Alternate practices and procedures 1024x547 Four easy ways 510k and De Novo content is different

What alternative practices and procedures are currently available?

The unique De Novo content requirement is to provide a description of alternative practices and procedures for treatment or diagnosis of the same indications that you are proposing for your subject device. This is a subsection of the device description section in the FDA eSTAR template. Your should description should include other 510k-cleared products, drugs, and even products that have similar indications but are not identical. The description of alternative practices and procedures must also be attached as a document in the section for benefits, risks, and mitigation measures. To maintain consistency throughout your submission, you should create the document for attachment first and copy and paste the content into the text box at the end of the device description section.

You need to recommend a classification in your De Novo

The unique De Novo content requirement is found in a section titled “Classification.” There is a shorter classification section included in 510k submissions, but the 510k version only has four cells. The first three are populated by selecting one of the options from a dropdown menu, and the fourth cell is only used if your subject device includes other product classification codes.

Classification 1024x346 Four easy ways 510k and De Novo content is different

The De Novo version of the eSTAR is identical for the first row of the classification section, but then you must select a proposed product classification (i.e., Class 1 or Class 2) in accordance with FDA Classification Procedures (i.e., 21 CFR 860). The third cell is a text box for you to enter your justification for the proposed classification. Next, the FDA requires you to enter a proposed classification name. Finally, at the end of the classification section, the FDA requires that you provide a classification summary or reference to a previous NSE 510k submission.

A Benefit/Risk Analysis is required in the De Novo Content

For new devices, the FDA uses a benefit/risk analysis to decide if a device should be authorized for marketing in the USA.  This process includes humanitarian device exemptions, De Novo applications, and Premarket Approval submissions. The FDA has a guidance document that provides guidance for FDA reviewers and the industry. The most important aspect is, to begin with, the benefits of the device and to provide a quantitative comparison of benefits and risks. Many De Novo submissions have been rejected because the submitter did not provide objective evidence of clinical benefits for the subject device.

Benefit Risk Analysis 1024x210 Four easy ways 510k and De Novo content is different

The FDA guidance documents are helpful for creating a benefit/risk analysis, but you can also find information in the ISO/TR 24971:2020–the guidance for the application of ISO 14971:2019. Our company also includes a template for a benefit/risk analysis as part of our risk management procedure (i.e., SYS-010).

What are your recommended Special Controls?

In FDA De Novo Classification Decision Summaries, there is a table provided that identifies the identified risks to health and the recommended mitigation measures for each risk category. In the FDA eSTAR, you are required to add a similar table for De Novo content. The only difference between the table in summary and the eSTAR is that the eSTAR table has a third column where the FDA wants you to reference the supporting data provided for each mitigation measure–including the document and page within the document. The FDA also provided an example table in the eSTAR, copied below.

Risk Mitigation Table Four easy ways 510k and De Novo content is different

The above table for the risks to health and mitigations needs to be translated into a list of recommended Special Controls for Class II devices. Since most De Novo applications are for Class II devices, you will need to convert each of your mitigations into a corresponding Special Control and type these controls into the text box provided in the FDA eSTAR.

Special Controls Four easy ways 510k and De Novo content is different

What else is different from a 510k?

There are no additional mandatory elements that you need to include in a De Novo application, but there are several elements of a 510k submission that are not included in a De Novo. The most obvious of these sections is the Substantial Equivalence Comparison Table in the section labeled “Predicates and Substantial Equivalence.” Another difference is that you are more likely to need clinical data to support a De Novo application than for a 510k submission. It is also possible that subsequent 510k submissions for the same product code may not need to provide clinical data because the 510k process only requires a demonstration of substantial equivalence rather than clinical benefits outweighing risks to health. The FDA review time for a Traditional 510(k) varied between 190 and 210 days in 2022, while the De Novo review timeline averaged 390 days in  2022. Finally, the FDA user fees for 510k submissions are far less than those for a De Novo application.

Four easy ways 510k and De Novo content is different Read More »

Why modernize 21 CFR 820 to ISO 13485?

Leave a Comment / FDA, Human Factors, ISO 13485:2016, Post-Market Surveillance, Quality Management System, Software Verification and Validation / By

The FDA patches the regulations with guidance documents, but there is a desperate need to modernize 21 CFR 820 to ISO 13485.

FDA Proposed Amendment to 21 CFR 820

On February 23, 2022, the FDA published a proposed rule for medical device quality system regulation amendments. The FDA planned to implement amended regulations within 12 months, but the consensus of the device industry is that a transition of several years would be necessary. In the proposed rule, the FDA justifies the need for amended regulations based on the “redundancy of effort to comply with two substantially similar requirements,” creating inefficiencies. In public presentations, the FDA’s supporting arguments for the proposed quality system rule change rely heavily upon comparing similarities between 21 CFR 820 and ISO 13485. However, the comparison table provided is quite vague (see the table from page 2 of the FDA’s presentation reproduced below). The FDA also provided estimates of projected cost savings resulting from the proposed rule. What is completely absent from the discussion of the proposed rule is any mention of the need to modernize 21 CFR 820.

Overview of Similarities and Differences between QSR and ISO 13485 1006x1024 Why modernize 21 CFR 820 to ISO 13485?

Are the requirements “substantively similar”?

The above table provided by the FDA claims that the requirements of 21 CFR 820 are substantively similar to the requirements of ISO 13485. However, there are some aspects of ISO 13485 that will modernize 21 CFR 820. The areas of impact are 1) software, 2) risk management, 3) human factors or usability engineering, and 4) post-market surveillance. The paragraphs below identify the applicable clauses of ISO 13485 where each of the four areas are covered.

Modernize 21 CFR 820 to include software and software security

Despite the limited proliferation of software in medical devices during the 1990s, 21 CFR 820 includes seven references to software. However, there are some Clauses of ISO 13485 that reference software that are not covered in the QSR. Modernizing 21 CFR 820 to reference ISO 13485 will incorporate these additional areas of applicability. Clause 4.1.6 includes a requirement for the validation of quality system software. Clause 7.6 includes a requirement for the validation of software used to manage calibrated devices used for monitoring and measurement. Clause 7.3 includes a requirement for validation of software embedded in devices, but that requirement was already included in 21 CFR 820.30. The FDA can modernize 21 CFR 820 further by defining Software as a Medical Device (SaMD), referencing IEC 62304 for management of the software development lifecycle, referencing IEC/TR 80002-1 for hazard analysis of software, referencing AAMI TIR57 for cybersecurity, and referencing ISO 27001 for network security. Currently, the FDA strategy is to implement guidance documents for cybersecurity and software validation requirements, but ISO 13485 only references IEC 62304. The only aspect of 21 CFR 820 that appears to be adequate with regard to software is the validation of software used for automation in 21 CFR 820.75. This requirement is similar to Clause 7.5.6 (i.e., validation of processes for production and service provisions).

Does 21 CFR 820 adequately cover risk management?

The FDA already recognizes ISO 14971:2019 as the standard for the risk management of medical devices. However, the risk is only mentioned once in 21 CFR 820. In order to modernize 21 CFR 820, it will be necessary for the FDA to identify how risk should be integrated throughout the quality system requirements. The FDA recently conducted two webinars related to the risk management of medical devices, but implementing a risk-based approach to quality systems is a struggle for companies that already have ISO 13485 certification. Therefore, a guidance document with examples of how to implement a risk-based approach to quality system implementation would be very helpful to the medical device industry. 

Modernize 21 CFR 820 to include Human Factors and Usability Engineering

ISO 13485 references IEC 62366-1 as the applicable standard for usability engineering requirements, but there is no similar requirement found in 21 CFR 820. Therefore, human factors are an area where 21 CFR 820 needs to be modernized. The FDA has released guidance documents for the human factors content to be included in a 510k pre-market notification, but the guidance was released in 2016 and the guidance does not reflect the FDA’s current thoughts on human factors/usability engineering best practices. The FDA recently released a draft guidance for the format and content of human factors testing in a pre-market 510k submission, but that document is not a final guidance document and there is no mention of human factors, usability engineering, or even use errors in 21 CFR 820. Device manufacturers should be creating work instructions for use-related risk analysis (URRA) and fault-tree analysis to estimate the risks associated with use errors as identified in the draft guidance. These work instructions will also need to be linked with the design and development process and the post-market surveillance process.

Modernize 21 CFR 820 to include Post-Market Surveillance

ISO/TR 20416:2020 is a new standard specific to post-market surveillance, but it is not recognized by the FDA. There is also no section of 21 CFR 820 that includes a post-market surveillance requirement. The FDA QSR focuses on reactive elements such as:

  • 21 CFR 820.100 – CAPA
  • 21 CFR 820.198 – Complaint Handling
  • 21 CFR 803 – Medical Device Reporting
  • 21 CFR 820.200 – Servicing
  • 21 CFR 820.250 – Statistical Techniques

The FDA does occasionally require 522 Post-Market Surveillance Studies for devices that demonstrate risks that require post-market safety studies. In addition, most Class 3 devices are required to conduct post-approval studies (PAS). For Class 3 devices, the FDA requires the submitter to provide a plan for a post-market study. Once the study plan is accepted by the FDA, the manufacturer must report on the progress of the study. Upon completion of the study, most manufacturers are not required to continue PMS.

How will the FDA enforce compliance with ISO 13485?

It is not clear how the FDA would enforce compliance with Clause 8.2.1 in ISO 13485 because there is no substantively equivalent requirement in the current 21 CFR 820 regulations. The QSR is 26 years old, and the regulation does not mention cybersecurity, human factors, or post-market surveillance. Risk is only mentioned once by the regulation, and software is only mentioned seven times. The FDA has “patched” the regulations through guidance documents, but there is a desperate need for new regulations that include critical elements. The transition of quality system requirements for the USA from 21 CFR 820 to ISO 13485:2016 will force regulators to establish policies for compliance with all of the quality system elements that are not in 21 CFR 820.

Companies that do not already have ISO 13485 certification should be proactive by 1) updating their quality system to comply with the ISO 13485 standard and 2) adopting the best practices outlined in the following related standards:

  • AAMI/TIR57:2016 – Principles For Medical Device Security – Risk Management
  • IEC 62366-1:2015 – Medical devices — Part 1: Application of usability engineering to medical devices
  • ISO/TR 20416:2020 – Medical devices — Post-market surveillance for manufacturers
  • ISO 14971:2019 – Medical Devices – Application Of Risk Management To Medical Devices
  • IEC 62304:2015 – Medical Device Software – Software Life Cycle Processes
  • ISO/TR 80002-1:2009 – Medical device software — Part 1: Guidance on the application of ISO 14971 to medical device software
  • ISO/TR 80002-2:2017 – Medical device software — Part 2: Validation of software for medical device quality systems

What is the potential impact of the US FDA requiring software, risk management, cybersecurity, human factors, and post-market surveillance as part of a medical device company’s quality system?

Why modernize 21 CFR 820 to ISO 13485? Read More »

Best human factors questions?

1 Comment / 510(k), FDA, Human Factors, Usability / By /

Best human factors questions to ask the FDA during a pre-submission meeting, and what information content do you need in a 510k?

Human factors questions to ask the FDA?

The FDA did not start enforcing the requirement to apply human factors and usability engineering to medical device design until 2017 because the final version of the human factors guidance document was not released until February 3, 2016. Approximately ninety percent of the human factors testing reports submitted to the FDA in 510k pre-market submissions are deficient because the 510k submission content only includes the final summative testing report. The FDA needs a complete usability engineering file, and the human factors information needs to comply with FDA guidelines for the format and content of a 510k pre-market submission–not just IEC 62366-1:2015.

Follow the FDA guidance 1024x180 Best human factors questions?

What human factors information does the FDA want?

For several years, FDA submission deficiency letters indicated that you should not include the frequency of occurrence in your estimation of use-related risks. Still, the FDA never provided this information in a guidance document. On December 9, 2022, the FDA finally released a draft human factors guidance regarding the format and content of a 510k pre-market submission. The new draft guidance includes a use-related risk analysis (URRA) requirement in table 2 (copied below).

Table 2 example of tabular format for the URRA 1024x354 Best human factors questions?

In this new draft FDA guidance, the FDA identifies three different human factors submission categories. For the first category, only a conclusion and high-level summary are needed. For the second category, a user specification is also needed. For the third category, you need a comprehensive human factors engineering report with the following elements described in Section IV of the draft FDA guidance:

Submission Category 1, 2, and 3

  • Conclusion and high-level summary

Submission Category 2 and 3

  • Descriptions of intended device users, uses, use environments and training
  • Description of the device-user interface
  • Summary of known use problems

Submission Category 3 only

  • Summary of preliminary analyses and evaluations
  • Use-related risk analysis to analyze hazards and risks associated with the use of the device
  • Identification and description of critical tasks
  • Details of validation testing of the final design

Before spending tens of thousands or hundreds of thousands of dollars on human factors testing, you want to ensure the FDA agrees with your human factors testing plan. Otherwise, you will pay for the testing twice: once for your initial submission and a second time in your response to the FDA request for additional information to address deficiencies. Testing can cost more than your electrical safety testing. The facility needs the right equipment and space for the testing; you need support personnel to set up the equipment; you need to recruit participants; you need to compensate participants; and you need device samples.

When can you ask the FDA human factors questions?

The FDA cannot provide consulting advice on a submission, and the agency will not review data during pre-submission meetings. The FDA can provide feedback on protocols, specifications, and scientific justifications. Therefore, you should submit questions to the FDA in a pre-submission when you have a draft protocol, a draft specification, or a draft justification for why a task is not critical. Pre-submissions are “non-binding.” You can change your design and approach to human factors. Therefore, don’t wait until your information is 100% finalized. Share your documentation at the draft stage during the development phase and before your design freeze. You need these answers when you are planning a study and obtaining quotes. 

What are the best human factors questions to ask in a pre-sub?

In the FDA guidance for pre-submission meetings, the FDA provides suggested questions to ask:

  • Does the Agency have comments on our proposed human factors engineering process?
  • Is the attached use-related risk analysis plan adequate? Does the Agency agree that we have identified all the critical tasks?
  • Does the Agency agree with our proposed test participant recruitment plan for the human factors validation testing?

The above examples are only suggestions, but the best approach is to provide a brief example of what the human factors information will look like and ask the FDA to comment on the examples. The FDA does not have time to review data during a pre-sub meeting, but the FDA can review a few rows extracted from your URRA and comment on your proposed approach to the human factors process.

Human factors questions that are not appropriate

The FDA pre-submission guidance cautions you only to ask 3-4 questions for each meeting request because the FDA has difficulty answering more questions in a 60-minute teleconference. Therefore, you should not ask questions already answered in the FDA guidance. The new draft guidance includes examples of when a device modification can leverage existing human factors information and when new information is needed to support a premarket submission. Instead of asking a question specific to leveraging existing human factors information, provide your rationale for leveraging existing data and ask if the FDA has any concerns with your overall approach to human factors.

Recommended human factors action items

Create a procedure for your human factors process that includes detailed instructions for creating the information required in a usability engineering report and templates for each document.

Best human factors questions? Read More »

Software validation documentation for a medical device

Leave a Comment / 510(k), FDA, Software Verification and Validation / By / , , , , , , , ,

Learn why you need to start with software validation documentation before you jump into software development.

When do you create software validation documentation for a medical device or IVD?

At least once a week, I speak with the founder of a new MedTech company that developed a new software application as a medical device (SaMD). The founder will ask me to explain the process for obtaining a 510(k), and they want help with software validation documentation. Many people I speak with have never even heard of IEC 62304.

Even though they already have a working application, usually, validation documentation has not even been started. Although you can create all of your software validation documentation after you create a working application, certain tasks are important to perform before you develop software code. Jumping into software development without the foundational documentation will not get your device to market faster. Instead, you will struggle to create documentation retroactively, and the process will be slower. In the end, the result will be a frustrating delay in the launch of your device.

What are the 11 software validation documents required by the FDA?

In 2005 the FDA released a guidance document outlining software validation documentation content required for a premarket submission. There were 11 documents identified in that guidance:

software validation documentation 1024x385 Software validation documentation for a medical device

What the FDA guidance fails to explain is that some of these documents need to be created before software development begins, or your software validation documentation will be missing critical design elements. Therefore, it is important to create a software development plan that schedules activities that result in those documents at the right time. In contrast, four of the eleven documents can wait until your software development is complete.

Which of the software validation documents can wait until the end?

The level of concern only determines what documents the FDA wants to review in a submission rather than what documents are needed for a design history file. In fact, the level of concern (LOC) document is no longer required as a separate document in premarket submissions using the FDA eSTAR template because the template already incorporates the questions that document your LOC. The revision level history document is simply a summary of revisions made to the software during the development process, and that document can be created manually or automatically at the end of the process, or the revision level history can be a living document that is created as changes are made. The traceability matrix can also be a living document created as changes are made, but its only purpose is to act as a tool to provide traceability from hazards to software requirements, to design specifications, and finally to verification and validation reports. Other software tools, such as Application Lifecycle Management (ALM) Software, are designed to ensure the traceability of every hazard and requirement throughout the entire development process. Finally, unresolved anomalies should only be documented at the time of submission. The list may be incomplete until all verification and validation testing is completed, and the list should be the shortest at the time of submission.

What documentation will be created near the end of development?

The software design specification (SDS) is typically a living document until your development process is completed, and you may need to update the SDS after the initial software release to add new features, maintain interoperability with software accessories, or change security controls. The SDS can not begin, however, until you have software requirements and the basic architecture defined. The verification and validation activities are discrete documents created after each revision of the SDS and must therefore be one of the last documents created–especially when provided to the FDA as a summary of the verification and validation efforts.

Which validation documents do you need first?

At the beginning of software development, you need a procedure(s) that defines your software development process. That procedure should have a section that explains the software development environment–including how patches and upgrades will be controlled and released. If you don’t have a quality system procedure that defines your development process, then each developer may document their coding and validation activities differently. That does not mean that you can’t improve or change the procedure once development has begun, but we recommend limiting the implementation of a revised procedure when making major software changes and discussing how revisions will be implemented for any work that remains in progress or has already been completed.

When do the remaining software validation documents get created?

The remaining four software validation documents required for a premarket submission to the FDA are:

  1. Software description
  2. Software hazard analysis
  3. Software requirements specification (SRS)
  4. Architecture design chart

Your development process will be iterative, and therefore, you should be building and refining these four documents iteratively in parallel with your software code. At the beginning of your project, your design plan will need a brief software description. Your initial software description needs to include the indications for use, a list of the software’s functional elements, and the elements of your user specification (i.e., intended patient population, intended users, and user interface). If you are using lean startup methodology, the first version of your device description will be limited to a minimal viable product (MVP). The target performance of the MVP should be documented as an initial software requirements specification (SRS). This initial SRS might only consist of one requirement, but the SRS will expand quickly. Next, you need to perform an initial software hazard analysis to identify the possible hazards. It is important to remember that software hazards are typically hazardous situations and are not limited to direct physical harm. For each potential hazard you identify in your hazard analysis, you will need a software requirement to address each hazard, and each requirement needs to be added to your SRS. As your software becomes more complex by adding software features, your device description needs to be updated. As you add functions and requirements to your software application, your SRS will need updates too. Finally, your development team will need a tool to track data flow and calculations from one software function to the next. That tool is your architecture design chart, and you will want to organize your SRS to match the various software modules identified in your architecture diagram. This phase is iterative and non-linear, you will always have failures, and typically a team of developers will collaborate virtually. Maintaining a current version of the four software documents is critical to keeping your development team on track.

How do you perform a software hazard analysis?

One of the most important pre-requisite tasks for software developers is conducting a hazard analysis. You can develop an algorithm before you write any code, but if you start developing your application to execute an algorithm before you perform a software hazard analysis, you will be missing critical software requirements. Software hazard analysis is different from traditional device hazard analysis because software hazards are unique to software. A traditional device hazard analysis consists of three steps: 1) answering the 37 questions in Annex A of ISO/TR 24971:2020, 2) systematically identifying hazards by using Table C1 in Annex C of ISO 14971:2019, and 3) reviewing the risks associated with previous versions of the device and similar competitor devices. A software hazard analysis will have very few hazards identified from steps 1 and 2 above. Instead, the best resource for software hazard analysis is IEC/TR 80002-1:2009. You should still use the other two standards, especially if you are developing software in a medical device (SiMD) or firmware, but IEC/TR 80002-1 has a wealth of tables that can be used to populate your initial hazards analysis and to update your hazard analysis when you add new features.

How do you document your hazard analysis?

Another key difference between a traditional hazard analysis and a software hazard analysis is how you document the hazards. Most devices use a design FMEA (dFMEA) to document hazards. The dFMEA is a bottom-up method for documenting your risk analysis by starting with device failure modes. Another tool for documenting hazards is a fault tree diagram.

Fault Tree Example from AAMI TIR 80002 1 2009 300x239 Software validation documentation for a medical device
Copied from Section 6.2.1.5 from AAMI / IEC TIR 80002-1:2009

A fault tree is a top-down method for documenting your risk analysis, where you identify all of the potential causes that contribute to a specific failure mode. Fault tree diagrams lend themselves to complaint investigations because complaint investigations begin with the identification of the failure (i.e., complaint) at the top of the diagram. For software, the FDA will not allow you to use the probability of occurrence to estimate risks. Instead, software risk estimation should be limited to the severity of the potential harm. Therefore, a fault tree diagram is generally a better tool for documenting software risk analysis and organizing your list of hazards. You might even consider creating a separate fault tree diagram for each module of your software identified in the architecture diagram. This approach will also help you identify the potential impact of any software hazard by looking at the failure at the top of the fault tree. The higher the potential severity of the software failure, the more resources the software team needs to apply to developing software risk controls and verifying risk control effectiveness for the associated fault tree.

Software validation documentation for a medical device Read More »

Auditing Risk Management Files

3 Comments / Auditing, CE Marking, ISO 14971:2019 (Risk Management), ISO Auditing, Remote Auditing / By / ,

What do you look at and look for when you are auditing risk management files to ISO 14971 and the new Regulation (EU) 2017/745?

Your cart is empty

Next week, November 15th @ Noon EST, you will have the opportunity to watch a live webinar teaching you what to look at and what to look for when you are auditing risk management files to Regulation (EU) 2017/745 and ISO 14971. Risk Management Files are one of the essential requirements of technical documentation required for CE Marking of medical devices. Most quality system auditors are trained on how to audit to ISO 13485:2016 (or an earlier version of that standard), but very few quality system auditors have the training necessary to audit risk management files.

Why you are not qualified to audit risk management files

Being a qualified lead auditor is not enough to audit the risk management process. When you are auditing a risk management file, you need risk management training and lead auditor training. To audit the risk management process, you will also need training on applicable guidance documents (i.e., ISO/TR 24971:2020) and applicable regulations (i.e., Regulation 2017/745 and/or Regulation 2017/746). There may also be device-specific guidance documents that specify known risks and risk controls that are considered state-of-the-art.

Creating an audit agenda

Once you have scheduled an audit of risk management files, and assigned a lead auditor, then the lead auditor needs to create an audit agenda. The audit can be a desktop audit that is performed remotely, or it can be an on-site audit. Regardless of the approach, the audit should include interviewing participants in the risk management process documented in the risk management file. As a rule of thumb, I expect a minimum of 30 minutes to be spent interviewing the process owner and one or more other participants. Then I spend an additional 60 minutes of auditing time reviewing documents and records.

Your audit agenda should specify the following items at a minimum:

  1. the method of auditing to be used,
  2. date(s) of the audit,
  3. the duration of the audit,
  4. the location of the audit, and
  5. the auditing criteria.

The auditor(s) and the auditee participants should be identified in the audit agenda. Finally, you should specify which documents and records are required for audit preparation. These documents will be used to help identify audit checklist questions and to determine a sampling plan for the audit. At a minimum, you will need a copy of the risk management procedure and a list of the risk management files that are available to audit. You may also want to request the audit plan for each of those risk management files.

What did you look at and look for during your risk management audit?

When you audit the risk management process, you could take any of the following approaches or a combination of more than one. You could audit the process according to the risk management procedure. You could audit the process according to the risk management plan(s) for each risk management file. You could audit using the process approach to auditing. Finally, you could audit in accordance with specific requirements in the ISO 14971:2019 standard and applicable regulations (i.e., Regulation 2017/745). Regardless of which approach you take, your audit notes and the audit report should identify which documents and records you sampled and what you looked for in each document. Providing only a list of the documents is not enough detail.

Creating an auditing checklist for risk management files

Auditors with limited experience are taught to create an audit checklist by creating a table that includes each of the requirements of the audit criteria. For a risk management file, this would include a list of each of the requirements in ISO 14971 for a risk management file (i.e., Clause 9???). However, this approach is more like the approach that you should be using for a gap analysis. The better approach for creating an audit checklist for risk management files is to start by creating a turtle diagram. In the “process inputs” section (i.e., step 2 of 7), you would add questions derived from your review of the risk management plan(s). In the “process outputs” section (i.e., step 3 of 7), you would add questions specific to the risk management report and other records required in a risk management file. In the “with whom” section (i.e., step 5 of 7), you would add questions related to training and competency. You might also identify additional people involved in the risk management process, other than the process owner, to interview as a follow-up trail. In the “how done” section (i.e., step 6 of 7), you would add questions specific to the procedure and forms used for the risk management process. Finally, in the “metrics” section (i.e., 7 of 7), you would verify that the company is conducting risk management reviews and updating risk management documentation in accordance with the risk management procedure and individual risk management plan(s).

Audits are just samples

Just because you can generate a lot of questions for an audit checklist does not mean that you are required to address every question. Audits are intended to be a “spot check” to verify the effectiveness of a process. You should allocate your auditing resources based on the importance of a process and the results of previous audits. I recommend approximately three days for a full quality system audit, and approximately 90-minutes should be devoted to a process unless it is the design control process (i.e., Clause 7.3 of ISO 13485) which typically requires three to four hours due to the importance and complexity of the design controls process. Therefore, you should schedule approximately 30 minutes to interview people for the risk management process and approximately 60 minutes should be reserved for reviewing documents and records. With this limited amount of time, you will not be able to review every record or interview everyone that was involved in the risk management process. This is why auditors always remind auditees that an audit is just a sampling.

Which records are required in a risk management file?

The contents of a risk management file is specified in ISO 14971:2019, Clause 4.5. There are only four bullets in that section, but the preceding sentence says, “In addition to the requirements of other clauses of this document.” Therefore, your risk management file should address all of the requirements in ISO 14971:2019. What I recommend is a virtual risk management folder for each risk management file. As the auditor, you should also request a copy of the risk management policy and procedure. An example of what this would look like is provided below. The numbers in front of each subfolder correspond to the sub-clause or clause for that requirement in ISO 14971:2019.

Risk Management File Example Auditing Risk Management FilesWhich records are most valuable when auditing risk management files?

As an auditor, I typically focus on three types of targets when auditing any process. First, I will sample any corrective actions implemented in response to previous audit findings. Second, will sample documents and records associated with any changes made to the process. Changes would also include any changes that were made to individual risk management files or the creation of a new risk management file. Finally, my third target for audit sampling is any item that I feel is at risk for safety or performance failures. The severity of the safety or performance failure is also considered when prioritizing audit sampling. In the context of a risk management file, I always verify that production and post-production activities are being conducted as planned. I try to verify that risk analysis documentation was reviewed for the need to update the documentation in response to complaints and adverse events.

More auditor training on risk management files

We are recording a live webinar intended to teach internal auditors and consultants how to perform a thorough audit of risk management files against the requirements of the new European Regulation (EU) 2017/745 and ISO 14971.

PXL 20221101 183748328 Auditing Risk Management Files
Auditing Risk Management Files
In this new webinar, you will learn how to conduct a process audit of risk management files. You will learn what to look at and what to look for in order to verify compliance with Regulation (EU) 2017/745 and ISO 14971:2019. The webinar will be approximately one hour in duration. Attendees will be invited to participate in the live webinar and receive a copy of the native slide deck. Anyone purchasing after the live event will receive a link to download the recording of the live event and the native slide deck.
Price: $64.50

In addition to this webinar on auditing risk management files, we also have other risk management training webinars available. The webinar on auditing risk management files will be hosted live on November 15, 2022 @ Noon EST (incorrect in the live video announcement).

Auditing Risk Management Files Read More »

What is the De Novo review timeline?

4 Comments / De Novo / By

The new FDA goal is to reduce the De Novo review timeline to 150 days for 70% of De Novo submissions, but how long does it take now?

What is an FDA De Novo submission?

An FDA De Novo submission is an application submitted to the FDA for creating a new device product classification. There are three classifications of devices by the FDA: Class 1, Class 2, and Class 3. Class 1 devices are the lowest-risk devices, and they only require general controls. Class 2 devices are moderate-risk devices that require “Special Controls,” and Class 3 are high-risk devices that require Pre-Market Approval (i.e., PMA). De Novo applications can only be submitted for Class 1 and Class 2 devices, and most of the De Novo submissions require clinical data to demonstrate that the clinical benefits of the new device classification outweigh the risks of the device to patients and users. It’s the need for clinical data that is partly responsible for the longer De Novo review timeline.

What is the De Novo review timeline?

Initially, the FDA required that Class 2 devices must be first submitted as a 510k submission. If the device did not meet the criteria for a 510k, then the company could re-submit a De Novo Classification Request to the FDA. On July 9, 2012, the regulations were revised to allow companies to submit De Novo Classification Requests directly. This makes sense because some devices have novel indications for use, and submission of a 510k would be a complete waste of time in money. For example, the first SARS-COV-2 test had to be submitted as a De Novo by Biofire to obtain permanent approval for the test instead of emergency use authorization (EUA). This change in 2012 dramatically reduced the De Novo review timeline.

On October 4, 2021, the FDA published a final rule for De Novo Classification Requests. This new regulation identified the De Novo review timeline as 120 calendar days. Even though 120 days is 30 days longer than the FDA review clock for a 510k, the actual timeline to review De Novo submissions was much longer.

Every five years, when Congress reauthorizes user fee funding of the FDA, new MDUFA goals are established. The draft MDUFA performance goals (which impact FDA funding) were published recently. The specific performance goal to review De Novo submissions is:

FDA will issue a MDUFA decision within 150 FDA Days for 70% of De Novo requests.

There are two problems with this goal. First, the term “FDA Days” is based on calendar days minus the number of days the submission was placed on hold, and we don’t have any visibility into the number of days submissions are placed on hold. In the past, submissions could be placed on hold multiple times during the Refusal to Accept (RTA) screening process, and the “FDA Days” is reset to zero days each time the company receives an RTA hold letter. In addition, even after the submission is finally accepted, the FDA places the submission on hold when they request additional information (i.e., AI Hold). RTA and AI Hold periods can last up to 180 days, and during the Covid-19 pandemic, companies were allowed to extend this up to 360 days.

The second problem with the MDUFA goal is that we only have visibility into the outcome of De Novo submissions that were granted. More than 60 De Novo submissions are submitted each year, but the number of De Novo Classification Requests granted ranged between 21 and 30 over the past three years. Therefore, the 50%+ of De Novo applications denied could skew the % of submissions that meet the MDUFA goal for the De Novo review timeline.

What is the FDA track record in reviewing a De Novo?

Every CEO I speak with asks the same question: “How long does the FDA review take?” In preparation for a webinar I taught about De Novo Classification Requests in 2019, I researched the latest De Novo review timelines. I expected the review timelines to be close to 150 calendar days because the FDA decision goal was 150 FDA days. The 150-day goal was set in 2018 when Congress approved MDUFA IV. The 2019 data held two surprises:

  1. only 21 De Novo requests were granted in 2019, and
  2. the average review timeline was 307 calendar days (i.e., the range was 108 days to 619 days).

FDA days are not the same as calendar days. Only 23.8% of De Novo submissions were reviewed within 150 calendar days. The FDA doesn’t calculate the number of FDA days as calendar days, but there is no way to know how much time each De Novo spent on hold publicly. Upon seeing the announcement of a new decision goal for MDUFA V on October 5, 2022, I decided to revisit my previous analysis.

De Novo review timeline What is the De Novo review timeline?

*Only 9+ months of data for 2022, because data was collected on October 17, 2022.

We can blame the Covid-19 pandemic for the slower De Novo review timeline during the past few years, but you would expect a longer average duration in 2020 if that was the root cause of the FDA’s failure to achieve the MDUFA IV target of 150 calendar days. You would also expect 2021 to have the longest review timelines. Instead, the review timelines are the slowest for 2022. The number of De Novo submissions remains small, and therefore it is hard to be conclusive regarding the root cause of the failure to reach the 150-day decision goal. In addition, the percentage of De Novo applications granted within 150 calendar days was lowest in 2021, as you would expect if the reason for delays is primarily due to the Covid-19 pandemic.

Is there any good news?

The FDA is allowing the new eSTAR templates to be used for De Novo Classification Requests. These new electronic submission templates standardize the format of all 510k and De Novo submissions for FDA reviewers. The eSTAR also forces companies to answer all questions in the FDA reviewer’s checklist to ensure the submission is complete and accurate before the new submission is submitted to the FDA.

The new eSTAR templates were first used in 2021, and our firm has observed shorter overall review timelines and fewer deficiencies identified by FDA reviewers when they submit an “Additional Information Hold” (AI Hold) to companies.

How can the FDA improve De Novo timelines?

The FDA, industry, and Congress seem to be taking the same approach pursued five years ago to improve the review timeline for De Novo submission. MDUFA V authorized additional user fees for De Novo submissions (i.e., 17.8% increase), and the FDA will be authorized to hire additional employees each year during MDUFA V if the performance goals are met. However, there are three other options that the FDA and industry should have seriously considered during the FDA-industry negotiations.

The first option that should have been considered is to allow third-party reviewers to review the elements of a De Novo that are identical to a 510k submission:

  1. sterilization validation
  2. shelf-life testing
  3. biocompatibility testing
  4. software validation
  5. electrical safety testing
  6. EMC testing
  7. wireless testing
  8. interoperability testing
  9. benchtop performance testing
  10. animal performance testing
  11. human factors engineering

The above approach would require blended pricing where the FDA charges a smaller user fee than a Standard De Novo user fee, and the third-party reviewer charges a smaller fee than a 510k. The combined cost would be higher than the FDA Review of a De Novo, but this would reduce the number of hours the FDA needs to complete their review of a De Novo, and it would allow for pricing that is much lower than the De Novo standard user fee for qualified small businesses.

A second approach would be to pilot a modular review approach. A modular review would be similar to modular reviews for PMA submissions. In a modular review, the FDA can review most submission sections and provide feedback before the human clinical performance data is available. This would not help the few De Novo submissions that do not include human clinical performance data, but this would have a profound positive impact on most De Novo projects. First, the FDA would be able to complete the review of all sections in the submission except the human clinical performance data without delaying the final De Novo decision. Second, a successful review of non-clinical data by the FDA would give investors more confidence to fund pivotal clinical studies required to complete the De Novo submission.

A third approach would be for the FDA to force manufacturers to submit testing plans and protocols as pre-submissions to the FDA. This approach would give the FDA more familiarity with each device and the testing plan before reviewing the data. This approach would also reduce the hours FDA reviewers spend reviewing data that doesn’t meet the requirements and writing deficiencies. This approach would also give investors more confidence to fund De Novo projects for all V&V testing.

What is the De Novo review timeline? Read More »

FDA CCP now accepts FDA eSTAR & eCopy

6 Comments / 510(k), De Novo / By / , ,

Finally, we can use the new FDA CCP to eliminate FedEx shipments, and 100% of your submissions will be electronic through the portal.

July 2022 Update for the FDA eCopy process

The FDA created a Customer Collaboration Portal (CCP) for medical device manufacturers. Initially, the portal’s purpose was to provide a place where submitters could track the status of their submissions and verify the deadlines for each stage of the submission review process. Last week, on July 19, the FDA emailed all active FDA CCP account holders that they can upload both FDA eCopy and FDA eSTAR files to the portal 100% electronically. The FDA released an eSTAR draft guidance as well. Since our consulting team sends out submissions daily, everyone on the team was able to test the new process. If you have a CCP account, you no longer need to ship submissions via FedEx to the Document Control Center (DCC).

FDA CCP step-by-step uploading process

When you are uploading an FDA eCopy for medical device submission to the Document Control Center (DCC), using the new FDA CCP, the following steps are involved:

  1. Confirm your eCopy complies with FDA’s eCopy guidance.
  2. Compress your eCopy into a “.zip” file.
  3. Sign in to the portal on the login page
  4. Click on the “+” symbol on the left panel of the webpage (if you hover over the “+” symbol, you will see “Send a submission”)
  5. Select your desired upload format (pre-submissions, meeting minutes, breakthrough device designations, and withdrawal letters must be submitted as an eCopy)Format Selection 1024x515 FDA CCP now accepts FDA eSTAR & eCopy
  6. Click on the “Next” button that appears below the selection formats once a format is selected
  7. Drag & drop your single “.zip” file here, or browse for it.
  8. Click on “Send” button to complete the uploading process.Send Step 1024x528 FDA CCP now accepts FDA eSTAR & eCopy
  9. Verify that the FDA CCP site gives you a confirmation for the successful uploading of your submission.Confirmation that eCopy was sent 1024x556 FDA CCP now accepts FDA eSTAR & eCopy

FDA Q&A about the new FDA CCP Submission Uploading Process

  1. Medical Device Academy Question: Who will be permitted to use the FDA CCP to upload submissions for the DCC? FDA Response: We will first offer this feature in batches to people like you who already use CCP so we can study its performance. We will then refine it and make it available to all premarket submitters.
  2. Medical Device Academy Question: What do you need to use the FDA CCP? FDA Response: You don’t need to do anything to participate since you already use CCP. We will email you again when you can start sending your next submissions online.
  3. Medical Device Academy Question: Suppose another consultant asks me to submit an eSTAR or eCopy for them, or I do this for a member of my consulting team. Is there any reason I cannot upload the submission using my account even though the other person is the official submission correspondent and their name is listed on the cover letter? FDA Response: The applicant and correspondent information of the submission is still used when logging the submission in. The submitter (i.e., the person uploading the submission) is not used in any part of the log-in process. The submission portal is essentially replacing snail mail only; once the DCC loads the submission, whether it be from a CD or an online source, the subsequent process is identical to what it used to be, for now.
  4. Medical Device Academy Question: Is there any type of eCopy that would not be appropriate for this electronic submission process (e.g., withdrawal letters, MAF, or breakthrough device designations)? FDA Response: You can use the eCopy option to submit anything that goes to the DCC, so all your examples are fair game, though interactive review responses would still be emailed to the reviewer.
  5. Medical Device Academy Question: How can I get help from the FDA? FDA Response: If you have questions, contact us at CCP@fda.hhs.gov.

FDA CCP now accepts FDA eSTAR & eCopy Read More »

Risk management policy – Do you have one?

1 Comment / ISO 14971:2019 (Risk Management) / By

ISO 14971:2019 includes a requirement for top management to define and document a risk management policy, but do you have one?

Screen capture for POL 005 1024x542 Risk management policy Do you have one?

Your risk management procedure is not your risk management policy

ISO 14971:2019 includes a requirement for a risk management policy and a risk management procedure. The word procedure is defined (Clause 3.13), a “specified way to carry out an activity or a process,” but there is no definition for policy. Both of these words begin with the letter “p,” but they are not the same.  There is no guidance for a risk management policy in either of the European device regulations for CE Marking and there is no guidance in the US FDA’s regulations. In fact, there is not even a specific cause of the international risk management standard that is specific to the requirement for a risk management policy. The word “policy” only appears in ISO 14971 seven times, but the last occurrence provides the best explanation:

  • Appendix A2.4.2 states that “because [ISO 14971] does not define acceptable risk levels, top management is required to establish a policy on how acceptable risks will be determined.”

If someone responsible for risk management activities does not understand this distinction, this shows that risk management training may not be adequate.

Can you have a different policy for each product family?

The purpose of the policy is to establish how the acceptability of risks will be determined. However, not all devices have the same benefit-risk ratio. Therefore, if you have product families with high and low risks, then you should address this in your policy with specific criteria for each device family or create a separate risk management policy for each product family. For example, if your company is focused on designing and developing products for diabetics, you will not have the same benefit-risk profile for a Class 2 glucose reader and lancet for Type 2 diabetics that you have for an automated Class 3 insulin pumps for Type 1 diabetics. In general, separate criteria within one policy are preferred over separate policies to reduce the number of documents that must be managed.

Is there a required format for a risk management policy?

The ISO 14971:2019 standard does not include a specific format or content requirement for your risk management policy. Instead, information about the format and content of a risk management policy is provided in Annex C of ISO/TR 24971:2020. This is a guidance document, and therefore you can choose an alternate approach if you provide a justification for its equivalence. If you choose the approach recommended in Annex C, the following elements should be included:

  • purpose;
  • scope;
  • factors and considerations for determining acceptable risk;
  • approaches to risk control;
  • requirements for approval and review.

You can download Medical Device Academy’s template for a risk management policy (POL-005) by completing the form below.

What are the factors for determining acceptable risk?

There are four possible factors to consider when determining your risk management policy:
  1. Applicable regulatory requirements;
  2. Relevant international standards;
  3. State-of-the-Art;
  4. And stakeholder concerns.

An example of regulatory requirements being applied to the determination of acceptable risks is the special controls defined in 21 CFR 880.5730 for insulin pumps. The special controls requirements outlined by the FDA specify design inputs as well as verification and validation requirements. The requirements are also organized into systems that comprise an insulin pump. For the digital interface requirements, the regulation specifies:

  • secure pairing to external devices;
  • secure data communication between the pump and connected devices;
  • sharing of state information between devices;
  • ensuring the pump continues to operate safely when receiving data that is outside of the boundary limits that are specified as inputs;
  • a detailed process and procedure for sharing pump interface specifications with connected devices.

The hazard implied by the fourth requirement above is that the pump will stop without warning or deliver the incorrect amount of insulin if the data from a continuous glucose sensor is outside of the input specifications. This design input is then addressed by a software design specification established by your company. To verify that your software risk controls are adequate, you will need to execute a verification protocol that automatically inputs a series of values that are outside of the boundary limits specified. Every time a change is made to the software, these boundary limits will need to be re-verified as part of your automated regression analysis to make sure software changes did not have an unintended effect on the device.

For software and use-related hazards, you will not be able to estimate the probability of occurrence of harm. Therefore, you shall assess the acceptability of risks based upon the severity of harm alone. Risk acceptability criteria shall be recorded in your risk management plan and the criteria shall align with your risk management policy. Ideally, these criteria are based upon international standards. For the example of an interoperable insulin pump, the following international standards are applicable:

  • ISO 14971, application of risk management to medical devices
  • IEC 62366-1, application of usability engineering to medical devices
  • IEC 62304, medical device software – software lifecycle processes

For the state-of-the-art, there are three examples provided in the ISO/TR 24971 guidance for how to this relates to your risk management policy:

  1. “Leakage currents of the medical device are state of the art, demonstrated by compliance to the limits and tests regarding leakage current of IEC 60601-1.
  2. Dose accuracy of the delivery device are state of the art, as demonstrated by compliance to the limits and tests regarding dose accuracy of ISO 11608-1.
  3. Protection against mechanical failure caused by impact is on the same level as or better than a similar medical device, as demonstrated by comparative test such as drop test.”

Stake holder concerns is the fourth factor to consider when creating your risk management policy. Stakeholder concerns may be identified in clinical literature. However, the current trend is an emphasis on patient-reported outcome (PRO) data and post-market surveillance. Post-market surveillance is a requirement in ISO 13485, Clause 8.2.1. However, the new European MDR and IVDR have new requirements for post-market surveillance data in the technical documentation. Health Canada updated the medical device regulations to include post-market surveillance summary reports, and even the FDA is trying to develop methods for using real-world data and real-world evidence to make regulatory decisions.

Approaches to risk acceptability

The European device regulations require that a benefit/risk analysis be conducted for all risks and the overall residual risk of your device. The EU regulations also do not permit risk acceptability to consider economic impact. The EU regulations also require that risks are reduced as far as possible. Therefore, if your company is seeking CE Marking, there is only one acceptable approach suggested in ISO/TR 24971, Annex C.2: “reducing risk as far as possible without adversely affecting the benefit-risk ratio.” This is also the approach specified in our risk management procedure (SYS-010).

Requirements for review and approval of the risk policy

Requirements for approval and review of the risk management policy should be specified in the policy itself. This should specify who needs to approve that the policy is acceptable and how often the policy needs to be reviewed. Section 4.2.2 of ISO 14971 also requires that top management review the risk management process for its effectiveness. In general, we recommend that this review of the risk management process be incorporated into the management review process. Therefore, we also believe that this would be the ideal time to review the risk management policy. Generally, this is more frequently than is typically required, but if your risk management process is being reviewed for effectiveness then you have all of the necessary inputs available to review the policy as well.

Risk management policy – Do you have one? Read More »

What is a CAPA Board? and Do you need one?

1 Comment / CAPA / By

A CAPA Board is a team responsible for making sure that all CAPAs are completed on time and the actions taken are effective.

Many of the medical device companies we work with have to open a CAPA for their CAPA process because they fail to implement all the actions that were planned, they fail to implement corrective actions as scheduled, or the actions implemented fail to be effective. When we investigate any process, we typically see one of five common root causes:

  1. top management is not committed to the CAPA process (we can’t fix this)
  2. procedures and/or forms are inadequate
  3. people responsible do not have sufficient training
  4. management oversight of the process is neglected
  5. there are not enough resources to do the work

Creating a CAPA Board can address four of these potential root causes, but the CAPA Board needs to understand how to work effectively.

Creating a CAPA Board shows a commitment to quality

Sometimes top management only pays lip service to quality. Top management’s actions demonstrate that quality is a cost-center, and they do not view quality as contributing to the revenue of the company. Instead, quality is viewed as a “necessary evil” like death and taxes. If this describes your company, sharpen your resume and find a new job. Quality is essential to selling medical devices and quality is the responsibility of everyone in the company. The Management Representative is responsible for “ensuring promotion and awareness” (see Clause 5.5.2c of ISO 13485) of regulatory and quality system requirements. This person should be training others on how to implement best practices in quality system management. One person or one department should never be expected to do most of the work related to the quality system.

A CAPA Board should be a cross-functional team of managers that help each other maintain an effective CAPA process. This means: 1) corrections are completed on time, 2) corrective and preventive actions are completed on time, and 3) each CAPA is effective. In order to do this consistently, the CAPA Board needs to work together as a team on the CAPA process. The CAPA Board doesn’t look for someone to blame. Instead, the CAPA Board rotates their responsibilities regularly, everyone is cross-trained on the roles within the CAPA Board, and the team passes tasks from one person or department that is overloaded to another person or department that has the resources to complete the tasks effectively and on time. A professional team must anticipate holes in task coverage, and someone on the team needs to communicate to the rest of the team which hole they are addressing. You can’t wait until the coverage gap is obvious and then have everyone jump into action. If you do this, your effectiveness will resemble a soccer team of 9-year-olds. 

Is your CAPA procedure the root cause?

In most companies, the problem is not the CAPA procedure. Clauses 8.5.2 and 8.5.3 of ISO 13485 are quite specific about each step of the CAPA process, and therefore it is easy to write a procedure that includes all of the required elements. The CAPA procedure is also one of the first procedures that auditors and inspectors review, and therefore any deficiencies in your procedure are usually addressed after one or two audits. If you feel that your CAPA procedure needs improvement, the above link explains how to write a better CAPA procedure. You might also consider asking everyone that is responsible for the CAPA process to provide suggestions on how to improve your procedure to streamline the process and clarify the instructions. The best approach is to have a small group (i.e. 3 to 5 people) of middle-level managers, from different departments, assigned to a CAPA Board with the responsibility of improving the CAPA process and procedure. If you have a large company, you might consider rotating people through the CAPA Board each quarter instead of having a larger group.

Does your CAPA Board have sufficient training?

Everyone can benefit from more training–even instructors will periodically engage in refresher training. Before someone is assigned to work on a CAPA, that person needs to be trained. Nobody should be assigned to a CAPA Board unless they are prepared to become an expert in the CAPA process. Some companies will only require people to sign a training record that states they read and understood the CAPA procedure. However, you must also demonstrate that your training was effective and the person is competent at the task assigned. Therefore, we recommend training people on CAPAs by training them with a CAPA training webinar and evaluating the effectiveness of the training by having each person complete a quiz. The use of a training webinar will ensure that each employee receives the same training, and the quiz will provide objective evidence that they understood the training (i.e. it was effective). If you have a CAPA Board, each person on the board should be involved in your CAPA training, and it is their responsibility to make sure people in their department have been trained effectively.

Competency is the hardest thing to demonstrate for any task. You can do this by verifying that the person has performed this task in one or more prior jobs (e.g. resume). If the person does not have evidence of working on CAPAs in their previous employment, then you will need someone that is already competent in the CAPA process to observe each person completing CAPAs and providing feedback. Once each person has demonstrated successful completion of multiple CAPAs, then the expert can attest to their competency in a training record with references to each of the successful CAPAs that were completed. If you are the person assigning a CAPA or individual tasks to people, do not assign the role of investigation, or writing the CAPA, to anyone that has not already demonstrated competency unless you are assessing them for competency. Everyone on the CAPA Board should either already be competent in the CAPA process or another expert on the CAPA Board should be in the process of training them to become a CAPA expert.

Average CAPA Aging Graph What is a CAPA Board? and Do you need one?

CAPA Boards are responsible for management oversight of the CAPA process

The most common method for management oversight of the CAPA process is to discuss the status of CAPAs at a Management Review. This information can be presented by the Management Representative, but assigning the presentation of CAPA status to another person on your CAPA Board will delegate some of the Management Review tasks and gives other people practice at presenting to a group. Some companies only conduct a Management Review once per year, but this makes it impossible to review CAPAs that were initiated immediately after a Management Review unless the CAPA takes more than a year to implement. Even if your company conducts quarterly Management Reviews, the review of CAPA status during a Management Review should focus on the most important issues rather than discuss every CAPA in detail. The impact on safety, the impact on product performance, and the economic impact of a specific CAPA are all criteria for deciding which CAPAs to discuss during a Management Review.

The CAPA Board needs a metric or metrics for monitoring the effectiveness of the CAPA process. The simplest metric is to monitor the average aging of CAPAs. If that average is steadily rising week after week, then new CAPAs are not being initiated, and existing CAPAs are not being closed. You can also measure the time to write a CAPA plan and the time to perform an investigation or monitor the on-time completion of tasks. The most important thing is for someone to take action when these metrics are not aligned with your quality objectives for the CAPA process. Taking action after 90 days of neglect is not good enough. You need to be monitoring the CAPA process weekly, and you need to take action proactively. Therefore, your CAPA Board needs to meet weekly and you need to show evidence in your CAPA records of what actions were taken by the CAPA Board.

Who should be assigned to the CAPA Board?

Top management does not need to be directly involved in the CAPA Board. Top management already reviews the status of CAPAs during Management Reviews. In a small company (i.e. < 20 people) you might have no choice but to have the same people that are assigned to your CAPA Board also be members of top management. As your company gets larger, you should assign middle-level managers and people that are new to management as members of the CAPA Board. Participating in the CAPA Board will teach those managers to work together as a team to achieve shared company goals and to persuade their peers to help them. The experience of working on a CAPA Board will also expose less experienced managers to other departments outside of their expertise. Ideally, participation in the CAPA Board will build friendships between peers that might not speak to one another. Each CAPA represents a team-building opportunity. The team needs to find a way to pool its resources to complete CAPAs on time and effectively. It is also important to rotate the assignment to the CAPA Board so that eventually all of your middle-level managers are trained in the CAPA process and each of them has been evaluated on their demonstration of team leadership and effectiveness in working with peers cooperatively. In large companies, it is common to assign one member of top management to the CAPA Board to show that top management is supportive of the CAPA process and to provide authorization for additional resources and funding for actions when needed. The top management representative should also be rotated to make sure that all of the top management remains competent in the CAPA process.

How does the CAPA Board manage the CAPA process?

The CAPA Board should never be blaming an individual or department for the lack of CAPA success. The CAPA Board should be anticipating when a CAPA is falling behind schedule or might not be as effective as it should be. Nobody on the team should be afraid to voice their opinion or to make a suggestion. Each member of the team has the responsibility of asking for help when they need it and asking for help as early as possible. The CAPA assignments should be shared between the team members, and one person should be responsible for chairing the meetings. If everyone is experienced in participating in CAPA Boards, then the role of the chairperson can be rotated each week. If one or more team members are inexperienced, the person on the CAPA Board assigned to training them should be teaching them how to participate in the meetings and prepare them for acting as chairperson.

Every CAPA Board meeting should have a planned agenda and meeting minutes. Every open CAPA should be discussed during the meeting, but the amount of time devoted to each CAPA should be adjusted for the risk of the CAPA failing to be completed on time or failing to be effective. If a CAPA is going smoothly, the discussion might only last seconds. Any discussion or actions planned that are specific to a CAPA should be documented in the individual CAPA record as well as the meeting minutes. This will ensure that the CAPA records are maintained as required by the ISO 13485 standard and the regulations.

What is a CAPA Board? and Do you need one? Read More »

Scroll to Top