DHF Template – Format and Content of Design History File

The article does not include a DHF template, but recommendations for format and content of a design history file are provided.

DHF Content DHF Template   Format and Content of Design History File

A couple of weeks ago I announced that I will be conducting a webinar today (i.e., 10:00am EDT on April 14, 2016) on the topic of the design history file (DHF). One of my blog readers sent me an email in response to this announcement requesting a DHF template.

Regulatory Requirements for a Design History File (DHF)

The requirements for a design history file (DHF) are found in 21 CFR 820.30j: “Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.“ There is also a definition for a DHF found in 21 CFR 820.3(e), “Design history file (DHF ) means a compilation of records which describes the design history of a finished device.” The FDA provided an official interpretation of this requirement in the preamble when the QSR was published in 1996. That discussion of the requirement indicated that the DHF is intended to be a repository of the records required to demonstrate compliance with your design plan and your design control procedures. The discussion also indicates that the same DHF may be used for minor variations of a device such as size differences. Most manufacturers will organize the DHF in a binder and organize the binder chronologically to match a design project plan, however, most do not create a DHF template. Meeting minutes from each design meeting are typically included as an appendix to the DHF, while reviewed and approved documents such as the design plan, design inputs, design outputs and records of design reviews typically comprise the bulk of the DHF. Manufacturers also typically will conduct an internal auditor of active DHF binders in order to ensure that design projects are following the approved design plans.

Why a DHF Template Doesn’t Make Sense

The DHF is is intended to provide evidence of following an approved design plan, but the DHF consists of many records–not just one record. A DHF template could be created to follow a standardized design control process, but most manufacturers write a generic design procedure that allows and encourages the design team to customize the design plan to match the needs of each development project. Therefore, design plans may have different numbers of design reviews and very different testing activities prior to the start of the design transfer process and during design verification and validation.

For a device master record (DMR), I recommend creating a DMR Index using a template that is organized in accordance with an international standard to meet the needs of a DMR and a Technical File. However, the DMR is a living document that only shows the most current design outputs for a device while a DHF may require repeating various verification and validation testing if the initial design fails to meet acceptance criteria and a design change is required prior to the final design review and approval of commercial release. The need for including this variability eliminates the advantages of a template.

Documenting Design Changes in your DHF vs. a DMR Index

Product design changes that occur prior to the final design review and approval of commercial release are required for inclusion in the DHF. However, once a product is released the control over design changes should be tighter and regulatory submission of changes may be required. Therefore, I recommend documenting post-market design changes in the DMR Index for a device as part of the revision history. I treat the DMR Index as a controlled document and any post-market design changes are reflected in the revision history with a reference to the design change approval (e.g., ECN 123 – addition of UDI label to product labeling). The other advantage of this approach is that all post-market design changes that must be documented for a design dossier are summarized in the revision history of the DMR Index and the DMR Index will serve as a Technical File/Design Dossier.

Design History File (DHF) Webinar

If you are interested in learning more about design history files, there is still time to register for today’s live training webinar. For a cost of $129 you will receive:

  • a link to join the live webinar @ 10am EDT
  • a native slide deck for the new live webinar
  • a link to download a recording of the live webinar

This live webinar explains what needs to be included in your procedures for design and development, but the webinar explains how and when to create a design history file (DHF). After you create a procedure, you can show the recording of this webinar to your design and development team to ensure that design and development documentation is compliant and updates are efficiently maintained.

After 9:30am EST, you will be able to purchase the webinar as recording only.

CLICK HERE to register for the live DHF webinar or to purchase the recording.

DHF Template – Format and Content of Design History File Read More »

Class 1 Device Requires Clinical Evaluation Report (CER) too!

Article explains how to write a clinical evaluation report (CER) for CE Marking Class 1 medical devices when there is little or no clinical study literature available. The history behind this European CE Marking regulatory requirement is explained as well.

Clinical study for this  e1446901425122 Class 1 Device Requires Clinical Evaluation Report (CER) too!

In 2010 the European Medical Device Directive was updated to include many tougher regulatory requirements for medical devices of all types. One of this changes is criticized frequently by industry–the change to make essential requirement 14 to a general requirement for all devices. That requirement is now essential requirement 6a in Annex I of the current MDD (93/42/EEC as modified by 2007/47/EC). The general requirements are required for all devices–event products that do not require a Notified Body’s involvement.

Typical Search Strategy for a Class 1 Device

Class 1 devices do not typically have clinical studies performed for three reasons:

  • the products are low in risk and therefore do not require clinical studies for regulatory approval
  • the products have been on the market for a long time and therefore there is little innovation in these products
  • clinical investigators are not interested in researching devices that have been used for a long time

Since there is typically no requirement for a clinical study for a Class 1 device, companies will perform a literature search in order to meet the requirements of Essential Requirement 6a. That search will typically result in articles that mention the device or a competitor device, but the device is typically just part of a clinical study that was performed for another device (i.e., the device of interest is merely an accessory). If there are clinical studies, the studies may be quite old and it may be more helpful to search for review articles first. In the end, you may end up finding no clinical studies for the type of device you are designing, but a clinical evaluation report is still required for CE Marking for Class 1 devices.

It may be painful for you and your company to conduct a clinical evaluation, even using the literature route, when there are no new clinical studies to find. However, the CE Marking regulations are written to address all devices and material innovations alone are driving the need for companies to reconsider the “state of the art” for even Class 1 devices. It is also important to consider emerging issues such as infection control with antibiotic resistant strains and the trend toward using disposable instruments such as drill bits.

Reference Articles for Clinical Evaluation Reports and PMS

I have published 3 previous blogs specifically on the topic of clinical studies and post-market surveillance over the past couple of years. Please click here if you are looking for more information on this topic.

Procedure/Template for Class 1 Device Clinical Evaluation Report (CER)

If you are looking for a procedure (SOP) and associated literature search protocol template for a clinical evaluation report (CER) please click here. The purpose of this 6-page procedure is to define the process for performing a clinical evaluation of literature in accordance with MEDDEV 2.7/1. There is also template provided for performing a literature search (i.e., TMP-004).

Class 1 Device Requires Clinical Evaluation Report (CER) too! Read More »

483 Response: Which corrective action plan should you write first?

Article explains how to determine which FDA Form 483 response you should write a corrective action plan for first and why.

chicken and egg 483 Response: Which corrective action plan should you write first?

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.

483 Response: Which corrective action plan should you write first? Read More »

FDA Human Factors Guidance

In 2016, the FDA released a final FDA Human Factors Guidance that explains the requirements for human factors testing of medical devices.

Screenshot 2016 02 04 at 1.24.04 PM FDA Human Factors Guidance

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:

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

  2. update your hazard identification report to include hazards related to use errors

  3. update your risk analysis to include risk controls that you have implemented to reduce the risk of harm related to use errors

  4. perform and document verification and validation of any new risk controls that you may implement related to use errors

  5. update your instructions for use to include warnings and precautions about use errors

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

FDA Human Factors Guidance Read More »

Three (3) important technical file and 510k submission differences

This article explains the three (3) critical technical file and 510k submission differences: 1) risk, 2) CER, and 3) PMCF.

3 different apples Three (3) important technical file and 510k submission differences
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:

  1. compliant with ISO 14971:2007 instead of EN ISO 14971:2012
  2. reduction of risks as low as reasonably practicable (ALARP) instead of reducing risks as far as possible (AFAP)
  3. reducing risks by notifying users and patients of residual risks in the IFU
  4. 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 webinar on this topic.

Three (3) important technical file and 510k submission differences Read More »

Post-market surveillance plans: How to write one for CE Marking.

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.

Screenshot 2015 12 15 at 6.18.57 AM Post market surveillance plans: How to write one for CE Marking.

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 webinar on this topic.

Post-market surveillance plans: How to write one for CE Marking. Read More »

What are the software verification and validation (V&V) requirements?

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 Validation and Verification 1 What are the software verification and validation (V&V) requirements?

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 document the 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:

  1. Level of Concern
  2. Software Description
  3. Device Hazard Analysis
  4. Software Requirement Specification (SRS)
  5. Architecture Design Chart
  6. Software Design Specification (SDS)
  7. Traceability Analysis
  8. Software Development Environment Description
  9. Verification and Validation Documentation
  10. Revision Level History
  11. 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 box.

What are the software verification and validation (V&V) requirements? Read More »

How to handle FDA inspector with incompetencies and ego

Handle FDA inspector egos and incompetencies during an audit of your facility–including requests for exempt quality system records.

p31653 p v7 aa e1449491882329 298x300 How to handle FDA inspector with incompetencies and ego
This is not how to handle FDA inspectors or auditors!

This topic was submitted to my suggestion box 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:

  1. Management Review Meeting Minutes
  2. Internal Audit Reports
  3. 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.

How to handle FDA inspector with incompetencies and ego Read More »

How to write a quality system plan template (free download)

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.

Screenshot 2015 11 19 at 5.52.44 PM How to write a quality system plan template (free download)

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.

How to write a quality system plan template (free download) Read More »

How to implement a new ISO 13485 quality system plan in 2016

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.

QMS Implementation Plan How to implement a new ISO 13485 quality system plan in 2016

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 good template, 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 as risk 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:

  1. Plan
  2. Do
  3. Check
  4. 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 and ISO 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:

  1. they haven’t been responsible for document control before, and
  2. 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 potential CAPAs.

Download an ISO 13485 quality system plan

Later this week, I will be posting a follow-up blog that 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.

How to implement a new ISO 13485 quality system plan in 2016 Read More »

Scroll to Top