Article explains how to determine which FDA Form 483 response you should write a corrective action plan for first and why.
In a perfect world, you would not receive any inspection observations from your next FDA inspection. However, most companies get at least one observation resulting from an FDA inspection and often there are multiple observations on an FDA Form 483. If you
Most Common FDA 483 inspection observation
Companies that have not experienced an FDA inspection before worry too much and prepare too little. Inspections are predictable and certain inspection observations are much more common than others. A couple of years ago I wrote an article analyzing the most common FDA inspection observations. The most common observations are specific to design controls (i.e., 21 CFR 820.30). However, this fact is distorted because many companies receive multiple observations during the same inspection related to design controls. For example, a client of mine recently received three from one inspector: 1) lack of design reviews, 2) lack of design validation, and 3) lack of risk analysis. All three were found during the review of the same design history file and the one corrective action addresses all three observations.
how to determine which FDA Form 483 response you should write a corrective action plan for first
2nd Most Common FDA 483 inspection observation
The second most common observation is specific to corrective and preventive actions (i.e., 21 CFR 820.100). Typically the company has inadequate procedures for verifying and validating effectiveness of corrective actions taken. If this is one of your FDA 483 observations, then you may have a problem with CAPA training or with the design of your CAPA form. If there is no place on the CAPA form to document your effectiveness check, then you might easily forget to perform the verification and validation of effectiveness. Another possibility is that personnel are confused between verification of implementation and the verification of effectiveness.
What if you have multiple FDA 483 observations?
Other common FDA 483 observations include medical device reporting, complaint handling and rework of nonconforming product. If you receive more than one FDA 483 inspection observation, you need to assume there is a chance that the inspection outcome will be “Official Action Indicated” (OAI). In this case, you need to provide a 483 response to your FDA district office within 15 business days. With such a short time to prepare your 483 response, you need to be efficient. Which 483 response should you initiate first and why?
If one of the inspection observations is related to the CAPA process, that 483 response should be your top priority. The reason for this is that the FDA will want to see objective evidence of implementing corrective actions whenever possible. If you use your CAPA procedure and form to document the 483 response, then you can show the FDA how the revised procedure or form will be used in your 483 response. If you write your 483 response for other inspection observations first, then the other 483 responses are using the existing procedure or form that the identified as inadequate.
Your first step should always be to implement corrective actions to address an inadequate CAPA process by revising the procedure or the form. Once the procedure or form is updated, then you can use the new process to document the rest of your 483 responses.
Training Webinar for an FDA 483 response
If you need help preparing an FDA 483 response, click here for our webinar explaining the 7 steps for responding to an FDA Form 483 inspection observation. You can also download a CAPA procedure and CAPA form from our SOP page.
In 2016, the FDA released a final FDA Human Factors Guidance that explains the requirements for human factors testing of medical devices.
FDA Human Factors Guidance
The FDA released a final guidance document on the subject of “Applying Human Factors and Usability Engineering to Medical Devices.” This is a final guidance document that replaces the previous version that was released in 2000 and the draft that was released in 2011. The diagram below is Figure 3 from this new FDA guidance, and it includes references to sections 5 through 9 of the guidance document.
What’s in the new FDA human factors guidance?
The organization of the guidance is similar to an ISO standard. Section 1 is the introduction. Section 2 is the scope of the guidance. Section 3 includes definitions, and Section 4 provides an overview of the human factors process and usability engineering as these concepts apply to medical devices. Sections 5 through 9 of the guidance explain the details of the process for applying these concepts to medical devices and risk management. The guidance document includes six references to national and international standards that include human factors engineering or usability engineering, and there are 19 references to articles about human factors engineering and usability engineering at the end of the guidance document.
Adding human factors to your risk management procedure
The steps in the process for human factors engineering and usability engineering mirror the risk management process as defined in ISO 14971 except this guidance does not specify developing a risk management plan or the need to create a risk management file. Identification of hazards related to use errors is the first step. Risk controls are implemented in order to reduce the risk of harm due to use errors. The risk controls are verified and validated, typically through simulated use studies or clinical studies. Therefore, you should be able to integrate usability engineering into your risk management process by specifying that hazards should include use errors, the environment of use, and the device/user interface. The risk controls section does not need to be revised, but the verification and validation of risk controls need to include simulated use and/or clinical studies in order to verify that risk controls specifically reduce the risk of use errors. It might also be useful to specify that the environment for use should be included in simulated use studies.
Creating a Usability Engineering Report Template
Clients often ask me what they need to do with regard to human factors engineering and usability engineering for documentation in their technical file and design history file. I recommend that they create a usability engineering report based on ANSI/AAMI/IEC 62366. However, companies often do not want to purchase the standard, and they seldom have time to read and understand what the standard is recommending. Now we have a free guidance document that is available from the FDA. Therefore, I recommend that you create a template for your usability engineering report based on this new guidance. If your company makes many types of products with multiple hazard types, then you will need a somewhat generic report template. However, companies with only one or two device families should be able to pre-populate a report template with sections for specific categories of hazards that are applicable to their device family. Once you have a template, this can be used to create a usability engineering report during the design process for any new medical device you are developing.
Updating Your Risk Management File to Include Usability
For products that are already on the market, you should already have human factors engineering and usability engineering incorporated into your risk management file. If you don’t, I recommend updating your risk management file in the following ways:
update your post-market surveillance plan/risk management plan to specifically gather information about use errors related to the use environment, the user, and the device/user interface
update your hazard identification report to include hazards related to use errors
update your risk analysis to include risk controls that you have implemented to reduce the risk of harm related to use errors
perform and document verification and validation of any new risk controls that you may implement related to use errors
update your instructions for use to include warnings and precautions about use errors
develop training tools, such as videos, to demonstrate possible use errors and how to avoid them
The bulk of human factors engineering and usability engineering are documented in the risk management file. Risk management documentation is only required for FDA submissions that include: 1) software of moderate level of concern or higher, 2) De Novo Classification Requests, and 3) PMA submissions. If you have a non-software device for which you are submitting a 510(k), then you do not include a risk analysis with your submission. Therefore, the only way that the usability factors are addressed is by reviewing the simulated use validation of the device and the instructions for use. It is still critical that design teams address usability engineering, however, because identifying use errors and implementing risk controls to eliminate use errors will prevent product complaints and adverse events. If these issues are not addressed during the design of a new product, corrective actions and possibly recalls will be needed after the product launch. FDA inspectors will also identify weaknesses in your risk management activities when they identify complaints that are not addressed in your risk analysis.
Additional Training Resources for Usability Engineering
Our human factors testing webinar was recently updated by Research Collective–a consulting firm specializing in usability engineering. SYS-048, Medical Device Academy’s Usability Procedure, is compliant with IEC/ISO 62366-1 (2015). The procedure includes a template for conducting summative (validation) usability testing. We have also updated our design plan template to include usability testing elements.
This article explains the three (3) critical technical file and 510k submission differences: 1) risk, 2) CER, and 3) PMCF.
Three important technical file and 510k submission differences
There are many differences between a technical file and a 510k submission, including the fact that technical files are audited annually while a 510k submission is reviewed only once. ISO 14971 requires a risk management file, whether you are selling a medical device in the EU or the USA, but the US FDA doesn’t require that you submit a risk management file as part of the 510k submission. If you design and develop a medical device with software, you must submit a risk analysis if the software has a moderate level of concern or higher. However, risk analysis is only a small portion of a risk management file.
Only 10-15% of 510k submissions require clinical studies, but 100% of medical devices with CE Marking require a clinical evaluation report (CER) as an essential requirement in the technical file. The clinical evaluation report (CER) is an essential requirement (ER) 6a in Annex I of the Medical Device Directive (MDD). Even class 1 devices that are non-sterile and have no measuring function require a clinical evaluation report (CER). Yes, even adhesive tape with a CE Mark requires a clinical evaluation report in the technical file.
Annex X, 1.1c of the Medical Device Directive (MDD), requires that medical device manufacturers perform a post-market clinical follow-up (PMCF) study or provide a justification for not conducting a post-market clinical follow-up (PMCF) study. In the past, companies attempted to claim that their device is equivalent to other medical devices, and therefore a post-market clinical follow-up (PMCF) study is not required. However, in January 2012, a guidance document (MEDDEV 2.12/2) was published to provide guidance regarding when a PMCF study needs to be conducted. This guidance makes it clear that PMCF studies are required for many devices–regardless of equivalence to other devices already on the market.
Risk management file for technical file and 510k submission
The FDA only requires documentation of risk management in a 510k submission if the product contains software, and the risk is at least a “moderate concern.” Even though you are required to perform a risk analysis, a knee implant would not require submission of the risk analysis with the 510k. If a product is already 510k cleared, you may be surprised to receive audit nonconformities related to your risk management documentation for CE Marking. The most common deficiencies with a risk management file are:
compliant with ISO 14971:2007 instead of EN ISO 14971:2012
reduction of risks as low as reasonably practicable (ALARP) instead of reducing risks as far as possible (AFAP)
reducing risks by notifying users and patients of residual risks in the IFU
only addressing unacceptable risks with risk controls instead of all risks–including negligible risks
If you are looking for a risk management procedure, please click here. You might also be interested in my previous blog about preparing a risk management file.
Clinical evaluation report (CER) for technical file and 510k submission
The FDA does not require a clinical evaluation report (CER), and up until 2010, only some CE Marked products were required to provide a clinical evaluation report (CER). In 2010 the Medical Device Directive (MDD) was revised, and now a clinical evaluation report (CER) is a general requirement for all medical devices (i.e., Essential Requirement 6a). This requirement can be met by performing a clinical study or by performing a literature review. Since 510k devices only require a clinical study 10-15% of the time, it is unusual for European Class 1, Class IIa, and Class IIb devices to have clinical studies. This also means that very few clinical studies are identified in literature reviews of these low and medium-risk devices.
The most common problem with the clinical evaluation reports (CERs) is that the manufacturer did not use a pre-approved protocol for the literature search. Other common issues include an absence of documented qualifications for the person performing the clinical evaluation and failure to include a copy of the articles reviewed in the clinical evaluation report (CER). These requirements are outlined in MEDDEV 2.7/1, but the amount of work required to perform a clinical evaluation that meets these requirements can take 80 hours to complete.
If you are looking for a procedure and literature search protocol for preparing a clinical evaluation report (CER), please click here. You might also be interested in my previous blog about preparing a clinical evaluation report (CER).
Post-Market Surveillance (PMS) & Post-Market Clinical Follow-up (PMCF) Studies for technical file and 510k submission
Post-market clinical follow-up (PMCF) is only required for the highest risk devices by the FDA. For CE Marking, however, all product families are required to have evidence of post-market clinical follow-up (PMCF) studies or a justification for why post-market clinical follow-up (PMCF) is not required. The biggest mistake I see is that manufacturers refer to their post-market surveillance (PMS) procedure as the post-market surveillance (PMS) plan for their product family, and they say that they do not need to perform a post-market clinical follow-up (PMCF) study because the device is substantially equivalent to several other devices on the market.
Manufacturers need to have post-market surveillance (PMS) plan that is specific to a product or family of products. The post-market surveillance (PMS) procedure needs to be updated to identify the frequency and product-specific nature of post-market surveillance (PMS) for each product family or a separate document that needs to be created for each product family. For devices that are high-risk, implantable, or devices that have innovative characteristics, the manufacturer will need to perform some post-market clinical follow-up (PMCF) studies. Even products with clinical studies might require post-market clinical follow-up (PMCF) because the clinical studies may not cover changes to the device, accessories, and range of sizes. MEDDEV 2.12/2 provides guidance on the requirements for post-market clinical follow-up (PMCF) studies. Still, most companies manufacturing moderate-risk devices do not have experience obtaining patient consent to access medical records to collect post-market clinical follow-up (PMCF) data–such as postoperative imaging.
Procedures & Webinars
If you are looking for a procedure for post-market surveillance (PMS), please click here. If you are interested in learning more about post-market surveillance and post-market clinical follow-up (PMCF) studies, we also have a webinaron this topic.
This article explains how to write a post-market surveillance plan for CE Marking and how to determine if a post-market clinical follow-up (PMCF) study is required.
A post-market surveillance (PMS) plan is only required for the highest risk devices by the FDA (i.e., typically devices that require a PMA or premarket approval). For CE Marking, however, all product families are required to have evidence of post-market clinical follow-up (PMCF) studies or a justification for why PMCF is not required.
Why is a post-market surveillance plan a “hot button” with auditors recently?
Post-Market surveillance is an area of emerging concern around the world. Not just a procedure for PMS, but an actual product-specific plan for gathering post-production data about your product or product family. Product registries, the anticipated launch of Eudamed, and the implementation of UDI regulations are part of this industry-wide movement. The FDA has articulated the US plan for strengthening PMS in a guidance document. At the same time, the European PMS efforts are being debated as a central part of the new European Medical Device Regulations.
The biggest mistake I see
The biggest mistake I see is that manufacturers refer to their PMS procedure as the PMS plan for their product family, and they say that they do not need to perform a PMCF study because the device is similar to several other devices on the market. Manufacturers need to have a PMS plan that is specific to a product or family of products.
How often is post-market surveillance data collected?
Your post-market surveillance procedure needs to be updated to identify the frequency and product-specific nature of post-market surveillance for each product family, or a separate document needs to be created for each product family. For devices that are high-risk, implantable, or devices that have innovative characteristics, the manufacturer will need to perform some PMCF studies. Even products with clinical studies might require PMCF because the clinical studies may not cover changes to the device, accessories, and range of sizes. MEDDEV 2.12/2 provides guidance on the requirements for PMCF studies, but most companies manufacturing moderate-risk devices do not have experience obtaining patient consent to access medical records to collect PMCF data–such as postoperative follow-up data.
Additional Resources
Medical Device Academy has created a post-market surveillance plan template that you can download for free. If you are looking for a procedure for post-market surveillance, please click here. If you are interested in learning more about PMS and PMCF studies, we also have a webinaron this topic.
This article defines software verification and validation for medical devices and provides an overview of CE Marking and 510k requirements. We also provide a link to our free download of a webinar on 510k software documentation.
Software Verification and validation is an essential tool for ensuring medical device software is safe. Software is not a piece of metal that can be put into a strain gauge to see if the code is strong enough not to break. That’s because software is intangible. You can’t see if it is in the process of failing until it fails. The FDA is concerned about software safety since many medical devices now include software. Software failure can result in serious injury or even death to a patient. This places significant liability on the device manufacturer to ensure their software is safe. One way to ensure software safety is to perform software verification and validation (V&V).
What is software verification and validation (V&V)?
Definitions of software verification and validation confuse most people. Which tasks are software verification? And which tasks are software validation? Sometimes the terms are used interchangeably. Even the FDA does not clearly define the meaning of these two terms for software. For example, in the FDA’s design control guidance documentthe following definitions are used:
“Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.”
“Validation means confirmation by examination and provision of objective evidence that the particular requirements for specific intended use can be consistently fulfilled.”
Specific intended use requirement…specified requirements…what is the difference? To understand the difference between the two terms, the key is understanding “Intended Use.” It is asking the question: “What is the software’s intended use?”
“Intended Use” is not just about a bunch of engineers sitting around a table coming up with really fresh ideas. “Intended Use” refers specifically to the patient/customer of the software and how it fulfills their needs (i.e., “User Needs”). Systematic identification of user needs is required, and the software must address the user needs. Identification of user needs is done through customer focus groups, rigorous usability studies, and consultation with subject matter experts such as doctors and clinicians providing expert insight.
“Intended Use” also ensures the safety of the process through the process of “Hazard Analysis,” whereby any hazard that could potentially cause harm to the patient/customer is identified. For each identified hazard, software requirements, software design, and other risk controls are used to make sure the hazard does not result in harm, or if it does, the severity of the harm is reduced as far as possible.
So if “Validation” ensures user needs are met, what is “Verification” and how does it apply to the software development process. “Verification” ensures that the software is built correctly based on the software requirements (i.e., design inputs), with regard to each task the software must perform (i.e., unit testing), during communication between software modules (i.e., integration testing) and within the overall system architecture (i.e., system-level testing). This is accomplished by rigorous and thorough software testing using prospectively approved software verification protocols.
CE Marking requirements for software verification and validation (V&V)
European CE Marking applications include the submission of a technical file that summarizes the technical documentation for the medical device. To be approved for CE Marking by a Notified Body, the device must meet the essential requirements defined in the applicable EU directive. The technical file must also include performance testing of the medical device in accordance with the “State of the Art.” For software, IEC/EN 62304:2006, medical device software – software life cycle processes, is considered “State of the Art” for the development and maintenance of software for medical devices. This standard applies to stand-alone software and embedded software alike. The standard also identifies specific areas of concern, such as software of unknown pedigree (SOUP). As with most medical device standards, the standard provides a risk-based approach for the evaluation of SOUP acceptability and defines testing requirements for SOUP.
FDA requirements for software verification and validation (V&V)
For 510k submissions to the US FDA, section 16 of the 510k submission describes the software verification and validation (V&V) activities that have been conducted to ensure the software is safe and effective. There are 11 documents that are typically included in this section of the submission for software with a moderate level of concern:
Level of Concern
Software Description
Device Hazard Analysis
Software Requirement Specification (SRS)
Architecture Design Chart
Software Design Specification (SDS)
Traceability Analysis
Software Development Environment Description
Verification and Validation Documentation
Revision Level History
Unresolved Anomalies (Bugs or Defects)
The FDA does not require compliance with IEC 62304 as the European Regulations do, but IEC 62304 is a recognized standard, and manufacturers must comply with all applicable parts of IEC 62304 if they claim to follow IEC 62304. The FDA also provides a guidance document for the general principles of software validation. The above requirements for software verification and validation documentation also apply to software as a medical device (SaMD).
Additional Resources
If you are interested in learning more about the documentation requirements for a 510k submission of a software medical device, please click here to download a free recording of our 510k software documentation webinar.
Medical Device Academy also has a new live webinar scheduled for Tuesday, January 5, 2016, @ Noon (EST). The topic is “Planning Your 2016 Annual Audit Schedule“. We are also offering this live webinar as a bundle with our auditor toolkit.
About the Author
Nancy Knettell is the newest member of the Medical Device Academy’s consulting team, and this is her first blog contribution to our website. Nancy is an IEC 62304 subject matter expert. To learn more about Nancy, please click here. If you have suggestions for future blogs or webinars on the topic of medical device software, please submit your requests to our updated suggestion portal.
Handle FDA inspector egos and incompetencies during an audit of your facility–including requests for exempt quality system records.
This is not how to handle FDA inspectors or auditors!
This topic was submitted to my suggestion portal from a colleague in Australia. Originally I posted this as an announcement for my LinkedIn Group, but the post was limited to ISO certification body auditors and excluded FDA inspectors. The basic approach is the same, but there are some important nuances regarding how to handle FDA inspector incompetencies and ego that I include in this article.
Handle FDA Inspector Distrust
In general, anyone that works for the FDA is genuinely concerned about public health and welfare. They also have a very low tolerance for unethical behavior. This has not always been the case at the FDA, and the agency has fought hard over the past twenty years to eliminate anyone from their ranks that is not ethical. Therefore, if an FDA inspector thinks that you have something to hide, the best approach to handle FDA inspector concerns is to give them anything they ask for–and quickly.
Unlike ISO auditors, FDA inspectors are not allowed to review three types of records:
Management Review Meeting Minutes
Internal Audit Reports
Supplier Audit Reports
The FDA can learn almost everything they want to know by reviewing CAPAs that resulted from Management Reviews, internal audits, and supplier audits. However, some FDA inspectors will still ask to see records that are part of the quality system record exceptions (i.e., 21 CFR 820.180c). Some quality system managers design cover sheets for these three records to specifically show FDA inspectors only the information that they are entitled to. If I am faced with this situation, I handle FDA inspector requests for restricted quality system records in the following way.
“Here is a copy of the quality system record you requested. This is one of the records that are exempt from the requirements in 21 CFR 820.180. However, we have nothing to hide. Therefore, you can take as many notes as you like about the content of this record, but you may not take a copy of the record with you.”
The above approach is intended to convince an FDA inspector that you have nothing to hide. Still, it also requires that you review and edit your records before approval and archiving to make sure that statements made in the records are appropriate–regardless of the audience reading the record.
Handle FDA Inspector and auditor personality
100% of auditors are a little weird (yep, takes one to know one). You travel for a living and tell people what’s wrong with their quality system. If you don’t start drinking scotch, you probably will eventually. However, a little patience, understanding, and communication helps. For example, provide directions (that are accurate). Recommend a hotel (middle of the road, not the Ritz or a fleabag). Tell them about the corporate discount. Ask them in advance if they have food allergies (I’m gluten-free, and not by choice), and then try to remember not to serve only the things they are allergic to (yes, Panera Bread is a crappy choice, but a gluten-free pizza is heaven). If Uber makes sense, recommend it because nobody wants to negotiate with Payless Rent-A-Car at 11:59 pm.
FDA inspectors are in the same situation as auditors with regard to being travel weary. However, FDA inspectors will probably not take your recommendation for a hotel. Instead, they will follow FDA guidelines and stay at a hotel chain where they prefer to accumulate membership points, and they can get a government employee discount. In addition, FDA inspectors will not eat at your facility. It seems as though a few companies entertained FDA inspectors at clubs and fancy restaurants in the past. In order to eliminate any possible perception of unethical behavior, FDA inspectors are now instructed to leave your facility for lunch and return to complete the day. They probably won’t even accept a cup of coffee unless you place a carafe on the table for everyone to drink. You can also count on the FDA inspectors driving a rental car if they do not live locally.
Handle FDA Inspector and Auditor Ego
Everyone has an ego. Auditors typically have a big one, and a few FDA inspectors do too. I’m not shy, I’m smart, and I love a good debate. If I’m you’re auditor; you’re lucky because I’ll admit when I’m wrong or make a mistake. Most auditors will not admit mistakes. In fact, the stronger they argue a point, the more likely that they are insecure on the topic or that they have a personal preference that is a result of a bad experience. Unfortunately, FDA inspectors seem to be even more likely to argue a point when they know very little experience.
Don’t ask FDA inspectors and auditors to prove something is in the regulations or the standard. Instead, try reading Habit 5 by Covey (7 Habits of Highly Effective People). You need to be an empathic listener. The FDA inspector or auditor doesn’t hate you. They might even be trying to help you. They also might be wrong, but try restating what the person is saying in your own words and try explaining why it’s important. This shows them that you were listening, you understand what they said, and you understand how they feel about the issue. Pause. Then tell them how you were trying to address this issue.
One of the areas where the above approach is especially important is when an FDA inspector is reviewing complaint records and medical device reports (MDRs). You want to convince the FDA inspector that you are doing everything you can do to investigate the complaint or adverse event, and you want to prevent a recurrence. Remember that someone was hurt by your device or misuse of your device, and FDA inspectors take public safety very seriously. You will not be able to handle an FDA inspector that believes you are doing less than you could be.
Handle FDA Inspector and Auditor Incompetencies
FDA inspectors rarely have industry experience, but they know the regulations. Therefore, arguing the regulations with an FDA inspector is a huge mistake. The only frame of reference for “industry best practice” is what the FDA inspector has seen at other device manufacturers they audit. Therefore, it is very import to know how experienced your FDA inspector is. If they don’t have a lot of experience, they will be defensive, and you might need to “educate” them.
During ISO audits, you have less time to retrain your auditor. Don’t even try. I do this for a living, and we’re a stubborn bunch of orifices. Instead, try the empathic listening first. 99% of the time, one or both of you are not communicating clearly. Either they can’t find what they are looking for, or they misunderstood what you were telling them. It could be a difference of interpretation, but it’s probably not. If it is, then say, “We were interpreting that requirement as…”. Say this once. If they argue, let it drop for now.
Resolution of 483 Observations and Audit Findings
You shouldn’t just take incorrect findings lying down. Do your homework. Send me an email. Get help. If you’re right, then contest it at the closing meeting in a factual and persuasive way. If the auditor holds their ground, ask what the policy is for resolving disputes. This is supposed to be covered as part of the closing meeting of every audit. If your auditor is just lazy, sloppy and incompetent–request a new auditor. You might even disagree in writing, address the finding anyway, and then request the new auditor. That shows the management of the certification body that you’re not lazy, sloppy, or incompetent.
FDA inspection 483 observations are a little different. If you and the inspector disagree, you should state this in the closing meeting when they give you the 483 observation, and you should be clear that you disagree prior to the end of the inspection when they start preparing FDA Form 483. Once a 483 observation is issued, however, your only recourse is to persuade the district office that the 483 observation is undeserved. The FDA district office will have copies of all your procedures and records and a copy of the FDA inspector’s notes. Be careful with complaints to the district office, though. FDA inspectors are far more likely to retaliate than ISO auditors.
Caution
If you make a habit of disputing everything, your auditor or FDA inspector will come prepared for war. You also will have little credibility with the managers at the certification body or the FDA district office. Dispute only justified things and provide a written, factual justification that is devoid of all emotion.
Responding to FDA 483 Observations
If you do receive FDA 483 observations, it is important that you respond with well-conceived corrective action plans. If you need help with responding to an FDA 483 inspection observation, you might be interested in my webinar on this topic.
This article explains how to write a quality system plan template to revise and update your quality system for compliance with ISO 13485:2016. If you want to download our free template, there is a form to complete at the end of this article.
Templates are the key to writing a quality system plan
Plan, do check, and act (PDCA) is the mantra of the Deming disciples, but does anyone know what should be in your quality system plan template. Everyone focuses on the steps–the “What’s.” Unfortunately, people forget to include the other important pieces of an all-inclusive quality system plan. Why? When? Who? And How much?
The table in the template is an example of “What?” steps to perform, but it is specific to my procedures. You will need to revise the table to reference your procedures, and the changes you make will be specific to your quality system plan. The other sections of the template tell you what needs to be included in that section, but I did not provide examples for those sections.
Why should you create a quality system plan template?
The purpose section of the quality system plan answers the question of “Why?” You need to specify if the purpose of your quality system plan is compliance with new and revised regulatory requirements, preventing recurrence of quality issues, or maybe a faster development cycle. The purpose section of the plan also provides guidance with regard to the monitoring and measurement section of your quality system plan template.
When should you create a plan for quality system changes?
Most changes have deadlines. In the case of ISO 13485:2016, there will be a 3-year transition period. Still, most companies establish internal goals for early implementation by the end of the fiscal year or the end of a financial quarter. Some of the changes can be made in parallel, while other changes need to be sequential. Therefore, there may be specific milestones within your quality system plan that must be completed by specific dates. These dates define “When?” the steps in the quality system plan must be implemented.
Who should write your quality plan?
As my quality system plan template indicates, I recommend defining both individual process owners and teams of process owners where processes can be grouped together. For example, I typically group the following four processes together as part of “Good Documentation Practices (GDPs)”: 1) control of documents (SYS-001), 2) control of records (SYS-002), 3) training (SYS-004), and 4) change control (SYS-006). I cover all four processes in a webinar called “GDP 101.”
It is important to have one person that is accountable and has the authority to implement changes for each process, but only one person should be in control of each process. If you have four related procedures, then the team of four people will need to coordinate their efforts so that changes are implemented swiftly and accurately. For the overall quality system plan template, I recommend assigning a team leader for the team of four process owners described above. One of those people should be responsible for team leadership and writing the quality system plan template.
Monitoring implementation of your quality plan?
Monitoring the progress of your plan ensures the successful implementation of the plan. Sometimes things don’t work as planned, and corrections need to be made. Additional resources might be needed. The plan may have been too optimistic with regard to the implementation time required. I recommend assigning one person the task of retrieving team status reports from each of the teams and consolidating the team reports into an overall progress report.
Free download of ISO 13485:2016 quality system plan template
The sign-up form below will allow you to receive an email with the ISO 13485:2016 quality system plan template attached. This is a two-step process that will require you to confirm the sign-up.
If you have a suggestion for a different type of quality plan, please let us know.
This article is a case study that explains how to implement a new ISO 13485 quality system plan at an accelerated schedule of just four months. The quality system will also be compliant with 21 CFR 820.
ISO 13485 quality system plan
Typically, I recommend implementing a new ISO 13485 quality system plan over a period of 6 months. The reason for this is that people can only read procedures and complete training at an individual pace. Since there are approximately 30 procedures required for a full-quality system, an implementation pace of one procedure per week allows a company to complete 90% of the reading and training in six months.
In October, a new client asked me for a proposal to implement a new ISO 13485 quality system plan. The proposed quality system plan indicated that the project would start in October and finish in March. The client accepted my proposal, but they asked me to help them implement the quality system plan in four months, as indicated in the table above. We just started the implementation of the quality system plan last week, and I have discovered some secrets that dramatically simplify the process. This blog shares some of the lessons learned that help implement the quality system plan at this faster pace.
Outsourcing ISO 13485 quality system development
Not everyone has the skill and experience to write a quality system procedure. Still, if you have a goodtemplate, you understand quality systems–then you can write quality system procedures. Depending upon the length of the procedure, it may take four to eight hours of writing for each procedure. Therefore, an in-house quality manager needs to allocate one day per week if they plan to write all the procedures for their quality system in six months. For a four-month implementation of an ISO 13485 quality system plan, you need to allocate two days per week to writing.
Alternatively, you can outsource the writing of your quality system. However, someone must be responsible for “customizing” generic procedures to fit your company, or the procedures need to be written from scratch. A third and final option is to have a hybrid of in-house procedures and outsourced procedures. If your quality manager has limited time resources, then you can supplement the managers’ time with procedures that are purchased and customized to fit your template. If there are specific procedures that the quality manager needs help with, such asrisk management, then you can also purchase just those procedures.
Continuous Improvement
One of the basic principles of quality management systems is “continuous improvement.” The continuous improvement cycle is also known as the “Deming Cycle.” There are four parts to the cycle:
Plan
Do
Check
Act
When you are developing an ISO 13485 quality system, the first step is to develop the quality system plan. I recommend the following guidelines for a quality system plan. First, plan to implement the quality system at a steady pace. Second, organize the implementation into small groups of related procedures.
In this case study, I have 29 procedures that we are implementing, and there are 11 recorded training webinars. During each of the four months, approximately the same number of procedures are implemented. Then I organized the small groups of procedures around the scheduled webinar training. For example, the month of November will have a total of 24 documents (i.e., eight procedures and 16 associated forms and lists) implemented, and there are four webinar trainings scheduled. Therefore, four procedures related to “Good Documentation Practices 101“ will be implemented as a group under document change notice (DCN) 15-001. Two procedures associated with “Are your Suppliers Qualified? Prove it!“will be implemented as a group under DCN 15-002. The remaining two procedures, design controls, and risk management, will be implemented as a group under DCN 15-003 with two related webinars on design controls andISO 14971.
Document Change Notice (DCN)
The next step in the Deming Cycle is to “Do.” For the implementation of an ISO 13485 quality system plan, “doing” involves the creation of procedures, forms, and lists, but “doing” also involves the review and approval of these documents. The form we use to review and approve procedures is called a document change notice or DCN.
It’s been almost 20 years since I completed my first DCN. For anyone unfamiliar with the review and approval of new and revised documents, most quality systems document the review and approval of procedures and forms on a separate form. The reason for this is that when you make one change, it often affects several other documents and forms. Therefore, it is more efficient to list all the documents and forms that are affected by the change on one form. This results in fewer signatures for reviewers and approvers. Several of the companies that I have helped to implement an ISO 13485 quality system plan for failure to review and approve the documents and forms in a timely manner. I think there are two reasons for this:
they haven’t been responsible for document control before, and
they don’t want to have to create and maintain quality system records any sooner than required.
The first reason can be addressed quickly with training. The second reason, however, is flawed. It is essential to implement the procedures as soon as possible to begin creating quality system records that can be audited by an ISO 13485 certification auditor or by FDA inspectors for compliance with 21 CFR 820. I have struggled with this hesitation in the past, but for this project, I am completing DCNs for the initial release of all the procedures and forms. This ensures that all the procedures and forms will be reviewed and approved shortly after the webinar training is completed. Also, this gives my client multiple examples of DCNs to follow as they make revisions to the procedures and forms over time.
Quality Objectives & Data Analysis
The third step in the Deming Cycle is to “check.” I recommend using quantitative metrics to track progress toward your goal of completing the quality system implementation. For example, if you have 50 documents to review and approve, you can track the % complete by just multiplying each document that is approved by 2%. You can also track the implementation of documents separately by type. Every DCN you route for approval will take a certain number of days to complete. You might consider tracking the duration of DCN approval. As a benchmark, an efficient paper-based DCN process should average about four days from initiation to completion. I have seen average durations measured in months, but hopefully, your average duration of DCN approval will be measured in days. Another metric to consider is the % of required training that has been completed for the company, for each department, and for each employee. Regardless of which metrics you choose to evaluate your quality system implementation, you should pick some of these metrics as quality objectives (i.e., a requirement of ISO 13485, Clause 5.4.1). You should also analyze this data for positive and negative trends as required by ISO 13485, Clause 8.4.
Your first CAPAs
The fourth and final step in the Deming Cycle is to “act.” Acting involves taking corrective action(s) when your data analysis identifies processes that are not functioning as well as they should be. To achieve ISO 13485 certification, you will need some examples of corrective and preventive actions (CAPAs) that you have implemented. The steps you take in response to observed trends during data analysis are all potentialCAPAs.
Download an ISO 13485 quality system plan
Later this week, I will be posting afollow-up blogthat explains how to write an ISO 13485 quality system plan for establishing a new quality system. There will also be a link for downloading a free ISO 13485 quality system plan.
This article explains details of implementing a CAPA preventive action and corrective action for packaging issues. Specifically, containment measures, corrections, corrective actions, and preventive actions to address the root cause identified in part 1 of this case study.
Comparing Incoming Inspection Results as a CAPA Preventive Action
CAPA Step 1: Containment of Product with Defective Packaging
When you learn of a packaging complaint related to a specific lot, you also need to determine if another product associated with the lot is safe to ship to customers. You should not attempt a correction and removal of the product unless you have a reasonably high level of confidence that there is a packaging issue with the lot or a portion of a lot, but you might consider placing product from the same lot in your inventory on hold until your investigation is completed. If you confirm that you have an issue with a specific lot, lots, or portion of a lot, then you should initiate correction and removal of product to prevent potentially, a non-sterile product from being used. This type of problem could result in a Class 1 recall (i.e., the most severe of the three categories). Therefore, you need to act quickly and according to established procedures for corrections and removals.
CAPA Step 2: Correction(s) of Defective Packaging
If you find a problem, there is little you can do to fix the existing defective packaging other than to repackage the product. If the product has only been sterilized once, and you have revalidated the product for resterilization, then you can repackage, relabel and resterilize. To ensure traceability to the lot that has been reworked, you may need to revise the labeling (e.g., add an “R” to the lot number). If you have not revalidated the resterilization of the product, you may want to use this lot for validation of resterilization instead of throwing it out. However, sometimes your best option is to scrap the product.
Additional corrections may involve correcting the calibration of a testing device or performing a repair to sealing equipment. You might modify a specification on a drawing. You might correct a work instruction that did not have the correct, validated sealing parameters. All of these could be corrections.
CAPA Step 4: Corrective Action(s) for Packaging Issues
Investigation of root cause (CAPA Step 3) occurs in parallel with containment (CAPA Step 1) and correction (CAPA Step 2). Corrective actions (CAPA Step 4) prevent the packaging issues from recurring, and they occur after the first three steps because you can only implement corrective actions once you understand the root cause of the quality issue. The best tool for evaluating your current process controls and evaluating the implementation of new corrective actions is a process risk control plan. In order to do this, you need a process flow diagram and a process risk analysis. Each step of the process, from the raw material fabrication of film to the released product, needs to have potential hazards identified, risks evaluated, and risk controls implemented. You should use your process validation to verify the effectiveness of process risk controls quantitatively. If the process capability is greater than 95% for each parameter, and you have addressed every possible source of problems, then you probably won’t gain much from additional risk controls. However, many companies reduce their sampling or rely on certificates of conformity to ensure that the process is controlled adequately.
CAPA Step 5: CAPA Preventive Action for Packaging Issues
You already had a packaging issue with one lot of products, but you could have another issue with a different product or lot for the same reason or a different reason. If the product is the same, and the reason is the same, then the actions taken are corrective actions. If you take action to prevent the occurrence of this issue with a different product, or you prevent other potential causes of packaging issues by initiating more robust monitoring and process controls, then your actions are preventive. Often you will want to implement both types of actions.
In the box plot example provided in this article, Lot D was detected at incoming inspection as having peel test results that were outside the alert limit but acceptable when compared to the specification limit for peel testing. The alert limit was established during validation of the pouches and comparison of lots A, B, C, and D, demonstrate that Lot D is slightly lower in peel strength. The manufacturer may choose to use the lot, but the sampling plan for in-process peel testing may be altered, or the manufacturer may choose to place the new lot in quarantine while an investigation is performed. This is a CAPA preventive action.
Below I have listed six additional potential CAPA preventive actions to consider for your packaging process:
Perform peel testing and/or bubble leak testing of packaging raw materials as part of the receiving inspection process and perform data analysis of the incoming inspection samples to determine if lower or higher alert and action limits should be established for the new lot of raw materials. The limits should be based upon the manufacturer’s seals as well as your seal.
Retain remnants of in-process peel testing, include the remnants with the sterilization load, and then store the remnants for real-time aging.
Consider implementing visual inspection tools that are able to detect sealing imperfections non-destructively.
Increase the number of samples you test (e.g., 1 to 3 or 3 to 5) for each lot of product sealed to increase your confidence that the seals will be within specifications.
Perform statistical analysis of in-process data for seal peel strength in order to identify potential lots with packaging issues prior to release.
Evaluate the performance of the packaging at temperature and humidity extremes that may be higher or lower than the conservative estimates for ambient conditions (e.g., 30C vs. 25C).
Additional Resources
In addition to the previous article that was part 1 of this case study, I have posted ten other blogs specifically on the topic of CAPA. There is also a CAPA procedure you can download from this website.
Risk-based CAPA Webinar
If you are interested in learning more about a risk-based approach to CAPAs, then please click here.
How to use risk management traceability for CE Marking to cross-reference hazards, risks, and risk controls throughout your technical file.
This approach will more efficiently integrate risk management tools into your Design History File (DHF), post-market surveillance documentation, and clinical evaluation reports (CERs). The table above provides a simple template for the nomenclature of risk management elements that you need to cross-reference and provides risk management traceability throughout your technical documentation.
The table does not include a cross-reference code for verification and validation reports because there could and typically are multiple risk controls that are validated and verified for each risk. Many times they are applied across multiple product lines. Therefore, it is more efficient to simply reference the controlled document number for the verification report that is applicable to that risk control.
The basic concept of traceability
The concept of risk traceability is more than being able to identify the verification and validation study that was performed to verify the effectiveness of risk controls in your FMEA because it is in the same row of your table. The best practice is to number your hazards, risks, and risk controls so that you can cross-reference more easily throughout all your technical documentation [i.e., design requirements matrix, risk management file, clinical evaluation report, post-market surveillance plan/reports, and post-market clinical follow-up (PMCF) report].
Design Requirements Traceability Matrix (DRTM)
The design requirements traceability matrix (DRTM) is a combination of two documents that have been used for the past two decades by medical device manufacturers: 1) the design requirements matrix or IOVV (i.e., inputs, outputs, verification, and validation), and 2) the risk traceability matrix. The second document is less commonly used, but an example of one is provided in Figure 3 of the GHTF risk management guidance document SG3 N15R8.
The risk management summary table that is presented in Figure 3 of the guidance also provides cross-references to specific tests, and each test has an identification number for traceability. This approach is also used frequently in risk control plans–an excellent tool for production process controls and planning product realization before process validation.
Risk management traceability to post-market surveillance
I recommend that companies create a post-market surveillance plan for devices or device families during the design transfer process. This is NOT the post-market surveillance procedure. Your procedure should indicate the process you use for post-market surveillance. Still, your plan should be process-specific and identify specific risks that you intend to gather post-production data for. The post-market surveillance plan should provide traceability back to each risk in your risk management file (e.g., R1, R2, R3). You should include a post-market clinical follow-up (PMCF) protocol and report that also cross-reference to these risks and associated risk controls–or provide a justification for not conducting a PMCF study. In 2016, the new European Medical Device Regulations (EMDR) will require that both the protocol and the report be included in your post-market surveillance plan as a required section (see Annex II of the proposed regulations) of the technical file or design dossier. Finally, I recommend that you revise and update your risk management plan for post-production data collection at the time of design transfer. When you make this revision, I recommend moving the risk management plan from the design plan to your post-market surveillance plan as an integral part of the plan (i.e., one of the primary sections of the plan).
Risk Management Traceability for Your Clinical Evaluation Report (CER)
In your clinical evaluation report (CER), if you simply said that “the clinical data reviewed addresses all of the residual risks identified in the risk management summary report,” you are not specific enough. Your clinical evaluation report (CER) should explain how the clinical study data you reviewed addresses each of the risks that you identified in your risk analysis. Personally, I like to have subsections in the discussion section of the clinical evaluation report (CER) for each of the risks identified in the risk management file. I also do this when I write my post-market surveillance plan. When I do this, I include a cross-reference to the applicable hazard in my design requirements matrix, risk analysis, and hazard identification summary report (e.g., “HZ1”, “HZ1” and “HZ3”).
Traceability to warnings & precautions
Disclosing residual risks to users of your device is required in the EU MDR and it is a risk control. However, you cannot claim to reduce the risks of your product by disclosing these residual risks because warnings and precautions are not effective. You should still validate the effectiveness of the instructions for use, technique guide, and training through simulated use studies before product release. Do not claim a quantitative risk reduction in your risk analysis. Of course, there can be a reduction in overall risks when you train users, but you can’t claim it, and the prevalence of use errors demonstrates the limited effectiveness of IFUs and training.
Additional risk management references
Please click here if you are looking for risk management training. There are a number of additional risk management articles on our website that were created in preparation for an international conference in Brussels.
Procedures & templates for risk management
If you are looking for a risk management procedure (SOP), SYS-010 meets the requirements of ISO 14971:2019 and Regulation (EU) 2017/745 for CE Marking.
