FDA Inspections-Complaint Investigation Requirements-Part I

“FDA Inspections-Complaint Investigation Requirements-Part I” is a two-part series that provides an overview of 21 CFR 820.198 requirements.

Last week, I received a message from someone asking for advice on how to perform a complaint investigation. She has a complaint handling procedure that explains how to determine if complaints are reportable (http://bit.ly/Medical-Device-Reporting), and she is the complaint coordinator. Her procedure includes a list of pre-determined cause codes for the most common complaints the company has received in previous years. Her system does not require a complaint investigation if an existing cause code is identified. She would like to know how to perform an investigation if she receives a complaint that does not fit one of the existing cause codes.

Is It a Complaint?

Most discussions about complaint handling begin with the definition of a complaint [i.e., 21 CFR 820.3(b); http://bit.ly/21CFR820-3]. However, if a complaint is received during an investigation of a device rather than the use of the device, the FDA will still consider this as being “after releasing for distribution.” The reason is that release for distribution occurs at final inspection. If the device breaks during installation, the device was still distributed.

One last question. Is it correct to consider a complaint only when the device is live and not during the settings and installation process of the device? (The definition states “after it is released for distribution,” what do they mean by this?).

What is Required?

The FDA QSR section specific to complaint handling is 21 CFR 820.198 (http://bit.ly/820-198). There are seven subsections (i.e., “A” through “H”) that comprise the regulation.

Manufacturers shall maintain complaint files and establish procedures for complaint handling.
Manufacturers must review and evaluate if an investigation is needed.
Manufacturers must perform an investigation automatically for any complaint involving a device malfunction–unless an investigation has already been performed for a similar complaint.
Separate files shall be maintained for complaints that involve adverse events that are reportable under 21 CFR 803 (http://bit.ly/21-CFR-803).
The content of a complaint investigation record is specified in this subsection.
When the complaint handling unit is located at another facility, the records of investigations shall be reasonably accessible to the manufacturing establishment.
When the complaint handling unit is located outside the USA, then the records must be reasonably accessible at a U.S. manufacturer or the location of an initial distributor.

What Does the FDA Expect to See?

FDA inspectors are guaranteed to sample complaint records and CAPA records during every routine inspection. The complaint records sampled will typically be limited to a specific product family that has been selected as the focus of the investigation. Most companies have an electronic log of the complaints, and the investigator may request a sorted list that only includes complaints specific to that one product family. The investigator will already be aware of all of your reported adverse events associated with the product family, and there may be one or two records they specifically want to investigate. The investigator will also review the complaint log to see if there are any complaints with a description that sounds like it might be reportable–even though the complaint was not reported.

The investigator will verify that each complaint record includes the content specified in subsection “E”:

name of the device;
the date the complaint was received;
any device identification(s) and control number(s) used;
the name, address and phone number of the complainant;
the nature and details of the complaint;
the dates and results of the investigation;
any corrective action is taken; and
any reply to the complainant.

In my response to the question that I received, I also included advice on how to conduct an investigation. In general, the investigation is no different than an investigation for any CAPA. The first step is to perform a root cause analysis. The second part of this article will explain the investigation process in more detail.

Register to receive email notification of new blog postings (http://bit.ly/MDA-Blog), so you can read the second part of this article next week. If you are interested in learning more about complaint handling, you might be interested in downloading the webinar that Medical Device Academy recorded last year for complaint handling and vigilance reporting (http://bit.ly/Complaint-Webinar-Landing). We can also help you one-on-one with a current complaint investigation you are conducting. Please don’t hesitate to contact me and ask for help: Mobile: 802.281.4381 or rob@13485cert.com.

FDA Inspections-Complaint Investigation Requirements-Part I Read More »

Jan 13 2015

Obtaining a Health Canada Medical Device License (Case Study)

7 Comments / Health Canada / By Robert Packard / canadian medical device license, health canada medical device license, obtaining a canadian medical device license, obtaining a Health Canada medical device license

This article explains the process for obtaining a Health Canada Medical Device License through a hypothetical case study. Canadian Medical Device Licensing is generally a more straightforward process than the 510(k) submission process for the US FDA and the European CE Marking Process. Therefore, launching a new product in Canada is one of the fastest ways for start-up medical device companies to achieve initial cash flow.

For this case study, I chose the maker of Krazy Glue^® as a hypothetical new client. The company wants to start selling their products as medical devices. Fortunately for them, companies have been selling cyanoacrylate (e.g., – Krazy Glue^®) as a medical device for years. Therefore, my client needs to decide if they want to sell the product as 1) a liquid bandage, 2) a topical adhesive to replace sutures, or 3) a vascular repair device for use inside the body during surgery. The client indicates that they want to sell cyanoacrylate as a medical device all over the world. Therefore, after a little homework, the client decided that a “topical adhesive” application will give the company higher margins of a medical device for prescription use. Still, it will also avoid the costly Pre-Market Approval (PMA) process at the FDA. I recommend that the client try a pilot launch in Canada first to evaluate their new packaging ideas on a smaller market than the USA or Europe.

Even though I have submitted multiple-device license applications to Canada, my first job in Regulatory Affairs taught me the most valuable lesson of all: “Always check the source.” Therefore, I went to the “helpful links” (http://bit.ly/RA-Resources) page of my website to find the Canadian Medical Device Regulations (CMDR), but for those of you that just don’t want to work that hard, here’s the direct link: http://bit.ly/SOR-98-282. The CMDR was most recently updated on December 8, 2014, but there have been no amendments to the regulations since December 16, 2011. If you want to know what the difference is between the current version and the previous version, I wrote an entire blog posting on just that topic (http://bit.ly/CMDRChange). The posting is 701 words long, but the two-word answer is: “Not much.”

Once I find the most recent version of the CMDR, I skip ahead to the bottom of page 54. Rule 4 states that “all non-invasive devices that are intended to come into contact with injured skin are classified as Class 2.” This is the applicable rule for a topical adhesive, but with device classifications, I always verify the Classification by looking up the license for a competitor product. The competitor product I selected was “Surgiseal.” I wasn’t sure who the manufacturer was for Surgiseal™, so I used Health Canada’s Medical Device Active License Database and searched by “Device Name.” In this case, I quickly found the license information I needed. Still, sometimes I use the US FDA website’s Registration and Listing Database (http://bit.ly/CDRH-Registration-Listing-Database) to identify device names and the name of manufacturers. The Canadian Device License information for Surgiseal™ is shown below:

After verifying, this is a Class 2 device in Canada, I reviewed the Canadian Licensing Process for Class 2 devices. Starting on page 16 of the CMDR, Section 32, I reviewed the process of applying for a Medical Device License. I also reviewed the Guidance Document for “How to complete a new medical device license application.” The location of that Health Canada Guidance Document is http://bit.ly/Canadian-Device-License. Fortunately, this is a Class 2 device, and the requirements are primarily to complete the application form for a new Class 2 device license (http://bit.ly/Canadian-Device-License-Form), sign attestations regarding compliance with the safety and effectiveness requirements (Section 10-20 of the CMDR) and compliance with the labeling requirements (Section 21-23 of the CMDR). The application form has a new section requiring information about the phthalate content of the device in the application. However, this tissue adhesive would only have phthalates if it was contained in the packaging.

Obtaining a Health Canada Medical Device License: The Process

After reviewing all the requirements for a device license application, I meet with the client to explain the next steps of the process:

The client needs to upgrade its existing ISO 9001:2008 Quality Management Certificate to an ISO 13485:2003 Certificate with CMDCAS. “CMDCAS” is the Canadian Medical Device Conformity Assessment System (http://bit.ly/CMDCAS-Certification-Part2). The Quality System Auditor from the registrar will look for additional requirements specific to the CMDR, but all of these requirements are identified in GD210—another guidance document from Health Canada. This will only require a one-day external audit to upgrade the scope of the current certification.
The labeling needs to be revised to meet the requirements for Sections 21-23 of the CMDR. Since this product will be used by Medical Professionals, rather than an over-the-counter product, the labeling requirements are similar to Europe and the U.S. The most important thing to do will be to implement the use of appropriate symbols found in ISO 15223:2012—an Internal Standard for Labeling and Symbols.
The client will need to conduct an internal audit to the CMDR requirements before the certification upgrade audit. If I make revisions to the client’s quality system, then another auditor on my team will conduct the internal audit remotely. If the client makes the changes to the quality system themselves, then I can conduct the internal audit myself.
Finally, once the new CMDCAS Quality System Certificate is received, we can complete the medical device license application and submit the application with a copy of the new certificate.

In my proposal to the client, I estimate that the entire process will require less than 60 days. When the client gets an upgrade quotation from their registrar, the earliest date available is in 10 weeks, but their annual surveillance audit is already scheduled for 13 weeks. Therefore, the client decided to combine the upgrade audit and the annual surveillance audit to save money on the travel costs and to give themselves more time to prepare for the upgrade to CMDCAS certification.

Not all applications are this easy. For higher-risk devices (i.e., Class 3 and 4), Summary Technical Documentation (STED) must be submitted in both paper and electronically. Health Canada provides guidance documents for this, and there is a Global Harmonization Task Force (GHTF) document that explains how to prepare these documents. Depending upon the Classification and complexity of the device being submitted, this documentation can take weeks or months to prepare.

The STED documents described above meet the European CE Marking requirements for the content of a Technical File, and most of the STED documents can be modified to meet 510(k) submission requirements of the US FDA. Preparation of STED documents, including STEDs for biocompatibility testing and sterilization validation, can be prepared in parallel with obtaining ISO 13485:2003 certification. The only item that should require additional time is the clinical summary–if clinical studies are required.

If your company needs help with Canadian Medical Device Licensing, please contact Rob Packard.

Obtaining a Health Canada Medical Device License (Case Study) Read More »

Jan 7 2015

11 Steps to Obtaining CMDCAS Certification-Part 2

2 Comments / Health Canada / By Robert Packard / 11 Steps to Obtaining CMDCAS Certification-Part 2, CMDCAS, CMDCAS certification

“11 Steps to Obtaining CMDCAS Certification-Part 2” focuses on the process of updating the quality system and preparing for your certification audit. The first three steps focus on classification and selecting a registrar.

Steps 4: Writing a Licensing Procedure

Nowhere in the Canadian Medical Devices Regulations (CMDR), or ISO 13485, does it require that you have a procedure for licensing or writing your technical documentation. However, most of the registrar auditors I have observed expect to see a procedure for this. You can reference Health Canada’s guidance documents (http://bit.ly/CanadianGuidance) and the CMDR (http://bit.ly/CanadianMDR), but that’s not enough. Typical audit questions I see on regulatory checklists include:

Is the company required to notify Health Canada of changes to the certificate within 30 days?
Is the classification rationale documented?
What is the procedure for maintaining technical documentation for Health Canada?
Is there a procedure for identifying significant changes that require notification of Health Canada (http://bit.ly/Canada-Significant-Change)?

Step 5: Mandatory Problem Reporting (MPR)

Some companies choose to have one procedure for adverse event reporting that covers all the countries that they distribute the product(s) in. However, I recommend having a separate procedure for each country that is shorter and will require updates less often. It’s a personal preference, but I find people are intimidated by a longer, combined procedure. The following are the key elements for the MPR procedure:

decision tree for when to report
timescale for reporting deadlines
form references
address for reporting
reminder to report the event to the US FDA if the product is also sold in the USA

Step 6: Recall Procedure

Unlike the MPR procedure, I recommend having only one recall/advisory notice procedure to comply with Health Canada’s requirements and the rest of the worlds’ regulatory requirements. I typically choose this approach, because the recall/advisory notice procedure is less complex than the adverse event reporting procedures. The key element I look for in this procedure is the address for notifying Health Canada of a recall because there is a different address in each region of Canada.

Step 7: Finding a Distributor

A Canadian Medical Device License is a license to distribute medical devices. Only Class I devices require an establishment license. Therefore, your company will be able to sell directly to physicians prescribing your device if you have a Class II, III, or IV Medical Device License. If you choose to use a distributor in Canada, the distributor must meet the requirements for record-keeping, and demonstrate the ability to conduct a recall, if necessary. Often, this is done by having a quality agreement in place, which stipulates the retention of distribution records. Also, your company should conduct a mock recall once distribution has begun. This will ensure that the distributor is compliant with the requirements for maintaining distribution records. The instructions for conducting a mock recall will be included in the revisions to the recall/advisory notice procedure described in Step 6.

Step 8: Training

The most common root cause of audit findings related to the CMDR is a lack of understanding with regard to the regulatory requirements. A better procedure can help, but there is no substitution for training on the CMDR. The CMDR is relatively easy to understand when compared to European Regulations, and the CMDR is shorter in length than US FDA regulations. However, most people have a lot of difficultly understanding the jargon of medical device regulations unless they are a regulatory expert. Therefore, it is essential to develop training that summarizes the CMDR for anyone in your company that will be involved with complaint handling, adverse event reporting, recalls and regulatory submissions–including design changes.

Medical Device Academy has a recorded webinar designed explicitly for company-wide training when companies are preparing for CMDCAS certification: http://bit.ly/CMDCAS-webinar. The cost of the webinar is $129, and there is a 10-question exam to verify the effectiveness of training. The exam costs $49 to grade, correct answers are explained for each question, and a certificate is issued for a passing grade of 70% or more.

Step 9: Internal Auditing

Your registrar will verify that you conducted an internal audit of the quality system for compliance with applicable sections of the CMDR. This can be performed by one of your internal auditors or a consultant. The audit can be completed on-site, but sometimes a remote desktop audit will suffice. Since there will be no records of distribution, licensing, complaints, or recalls before the CMDCAS certification–there is little value in conducting an on-site audit before certification. The duration of the internal audit should not exceed a day. It typically can be completed in four hours by an experienced auditor–plus a couple of hours of audit report writing.

Step 10: Conducting the CMDCAS Certification Audit

Your registrar conducts this step. Any audit findings will require a corrective action plan that is accepted by the auditor before the new certificate can be issued. The new CMDCAS certificate will look very similar to the existing certificate, but there is typically an additional logo indicating compliance with CMDCAS. This is not the same as the SCC logo indicating accreditation by the Standards Council of Canada. Once the initial extension to the scope is completed, the continued certification is evaluated as part of the normal surveillance audits and re-certification audits.

Step 11: License Application Submission

For a Class 2 device license application, you need to complete a form, send a check, and include a copy of your new ISO 13485 Certificate with CMDCAS. The response from Health Canada is typically within 15 days or less–depending upon the current workload. Class III and IV device license applications are more complex and require technical documentation–including a clinical evaluation.

The timelines for approval of a Class III or IV device license is closer to the timeline for a 510(k) clearance letter from the US FDA. Health Canada’s Device Licensing Division is quite responsive to email inquiries, and they will respond to voicemail messages. Once a license is issued, it is typically faxed to the company, and a hardcopy is mailed. I recommend a dedicated fax number for your regulatory affairs department.

Medical Device Academy, Inc. has a complete set of generic quality system procedures–including Canadian Medical Device Licensing and Mandatory Problem Reporting. Since the requirements for reporting adverse events is quite different in each country, it is not recommended to combine these procedures with other procedures. The cost of purchasing generic procedures from Medical Device Academy in a native MS Word Format is $300/procedure. Purchase grants your company a non-exclusive license to the content of the procedure for internal use. Please email Rob Packard if you are interested.

11 Steps to Obtaining CMDCAS Certification-Part 2 Read More »

Jan 2 2015

11 Steps to Obtaining CMDCAS Certification: Part I

4 Comments / Health Canada / By Robert Packard

“11 Steps to Obtaining CMDCAS Certification-Part I” focuses on the process of verifying the classification, selecting a registrar, and more.

Step 1: Verify Classification

There are four device risk classifications in Canada: I, II, III, and IV. If your device is Class I, then you can work with a distributor in Canada that has an establishment license. However, if your device is Class II, III, or IV, then ISO 13485 certification with CMDCAS is required as a prerequisite for a Canadian Medical Device License Application. Therefore, before you waste time and money on upgrading your ISO 13485 certification to include CMDCAS, you should ensure that your device is Class II-IV.

Each country has slightly different regulations. Often the risk classification is different between the two countries. However, in the following example, the classification is identical. If a device is an active, therapeutic device, then the device is typically classified as Class 2, as per Rule 9 of the CMDR. The rule and the rationale are identical to the EU classification of Class IIa, per rule 9 in Annex IX of the MDD. A manufacturer can confirm this classification by sending an email to the Device Licensing Division, asking them to confirm the classification rationale. Including a copy of the draft, IFU is recommended, so that Health Canada is aware of the intended use when they are verifying your classification rationale. Verification typically is completed within ten days, and there is no charge. If you need help determining the classification, please contact Rob Packard.

Step 2: Health Canada recognizes a verified Registrar

The process for becoming a CMDCAS auditor is one of the most challenging examinations that I have ever taken (http://bit.ly/Instructor-Effectiveness). However, the process of becoming a recognized registrar for CMDCAS is even more challenging. Health Canada acknowledges only 15 registrars. Therefore, ensure that your registrar is on the list first http://bit.ly/RecognizedRegistrars.

If you are selecting a critical subcontractor (i.e., “subcontractors in charge of processes which are essential for ensuring compliance with legal requirements”), you should verify that the company has a registrar that is recognized by Health Canada, as well. If not, this may result in the need for additional scrutiny of the critical subcontractor by the registrar–including the potential for an audit. If you need help selecting a registrar from the 15 recognized registrars, you should read our blog on this topic: http://bit.ly/SelectingRegistrar.

If your registrar is not one of these 15, then you will either need a second registrar, or you will need to transfer to a new registrar. The transfer process is a little different from each registrar. Still, generally, the new registrar must review previous audit reports, your certificate, and any corrective actions that are associated with the previous regulatory audit. This is typically completed in a one day audit that may be on-site or remotely conducted. The next step is to obtain a quote.

Step 3: Obtaining a Quote for CMDCAS Certification

Every registrar I know has a long application form that needs to be completed before they can provide a quote for CMDCAS certification. You will need company information about the various locations for each site covered by the quality system certificate–including the number of people, shifts, and types of activities conducted at each location. If you already have ISO 13485 certification, the quotation will be for an extension to the scope of the original quality system certification. An extension to scope audit is typically one day in duration. Upon successful completion of the audit, your company is recommended for CMDCAS certification, and the existing ISO 13485 certificate is replaced with a CMDCAS Certificate. For some companies, the scope of activities requires that you maintain your original certificate and the new CMDCAS certificate.

Once you obtain your quote(s) for upgrading to CMDCAS, then you must schedule your audit. Typically, auditors are booked at least 90 days in advance. Since the process of making upgrades to your quality system takes no more than 90 days, I don’t recommend waiting to make changes. Just go ahead and schedule the audit, and now you have a real deadline for everyone to work toward.

Part 2 of this article will explain the changes you need to make to the quality system to prepare for your CMDCAS audit.

11 Steps to Obtaining CMDCAS Certification: Part I Read More »

Dec 9 2014

How to reconcile the conflict between ISO 13485 and ISO 9001

3 Comments / ISO 13485:2016, ISO 9001:2015, ISO Certification / By Robert Packard / ISO 13485, ISO 13485 standard, ISO 9001, ISO 9001 standard, upcoming ISO 13485 and 9001 standards

This blog explains how to reconcile the conflict between ISO 13485 and ISO 9001, and discusses whether you should maintain dual certification.

What is the conflict between ISO 13485 and ISO 9001?

The previous version of ISO 13485 was released in 2003. That standard was written following the same format and structure as the overall quality system standard at the time (i.e., ISO 9001:2000). In 2008, there was an update to the ISO 9001 standard, but the changes were minor, only clarified a few points, and the periodic review of ISO 13485 in 2008 determined there was not a need to update 13485 at that time. Unfortunately, the proposed structure of the ISO 9001 standard was radically different, and this forces companies with dual certification to reconcile the conflict between ISO 13485 and ISO 9001.

On December 1-5, 2014, the working group for the revision of ISO 13485 (i.e., TC 210 WG1), met at AAMI’s Standards week to review the comments and prepare a first Draft International Standard (DIS). We should have some updates on the progress of the DIS later in December, but hopefully, the news will not be delayed in publication until 2016. The following is a summary of the status before last that meeting.

Updated ISO 13485 and ISO 9001 Standards Being Released

In 2015, there will be a new international version of ISO 9001 released. This new version will have dramatic changes to the standard–including the addition of a new section on risk management and the adoption of the new High-Level Structure (HLS) changing from 9 sections to 11. The ISO 13485 standard is also anticipated to have a new international version released in 2015, but the ISO 13485 standard will maintain the current HLS with nine sections. The timing of the ISO 9001:2015 release and the ISO 13485:2015 release will likely be around the same time (Correction: the ISO 13485:2016 standard was released in February 2016). Both standards are expected to have a three-year transition period for implementation. The combination of the three-year transition and lessened requirements in the new version of ISO 9001 for a structured quality manual should allow most manufacturers to wait until the ISO 13485 release before they begin drafting a quality plan for compliance with the new standards. Some of my clients have already indicated that they may drop their ISO 9001 certification when it expires, instead of changing their quality system to comply with the ISO 9001:2015 requirements. However, my clients will not have the ability to allow their ISO 13485 certification to lapse. Will Health Canada be updating GD210 and continue to require ISO 13485 certification for medical device licensing? What should companies do?

Update on the reconciliation of ISO 13485:2016 and ISO 9001:2015 on May 29, 2020:

GD210 was never updated, and instead, it was replaced by MDSAP
ISO 13485:2016 certification, under the MDSAP program, is required for Canadian Medical Device Licensing
Many device companies have dropped the ISO 9001 certification.

Recommendations

From the experience of preparing for the ISO 13485:2016 and ISO 9001:2015 releases, I learned that obtaining draft versions of the standards before publication is invaluable. I was able to use the drafts to help prepare quality plans for the transition. Second, companies need to train their management teams and auditors on the differences between the current and the new standards to enable a gap analysis to be completed. Any manager that is responsible for a procedure required by the current version of a standard should receive training specific to the changes to understand how they will meet the requirements for documented information. Most companies will need to improve their risk management competency (which was updated again in December 2019). I recommend that companies begin drafting their quality plans and enter discussions with their certification body for quality system changes as early as possible. I also recommend that medical device companies maintain a quality manual structure that follows the ISO 13485:2016 standard rather than the ISO 9001:2015 standard. Following ISO 13485:2016 will help everyone locate information faster.

There is also specific text in the introduction of ISO 9001:2015 that states it is not the intent of the standard to imply the need to align your quality management system to the clause structure of the standard. Companies that maintain ISO 9001 certification should consider including cross-references between the two standards in their quality manual.

Historical Note

There are also European National (EN) versions of each standard (e.g., EN ISO 13485:2012). The EN versions are harmonized with the EU directives, but the content of the body or normative sections of the standards are identical. Historically, the differences were explained in Annex ZA, which was the last Annex in the EN version of the standard. In 2009 the harmonization annex for ISO 14971 (i.e., the medical device risk management standard) was split into three parts to match up with the three directives for medical devices (i.e., the MDD, AIMD, and IVDD). The new annexes (i.e., ZA, ZB, and ZC) were moved to the front of the EN version of the standard. The changes to ISO 14971 consisted of a correction and the change to Annex ZA. In 2012, there were new harmonization annexes created for ISO 13485 to follow the same format that was used for the EN ISO 14971 annexes. It is expected that these “zed” annexes will be released with a new EN version of the standard shortly after the international standard is published.

How to reconcile the conflict between ISO 13485 and ISO 9001 Read More »

Oct 22 2014

Medical Device Validation Document Resources

1 Comment / Validation / By Robert Packard / medical device validation, medical device validation document resources

This blog provides a list of medical device validation resources and explains how to create your resource list.

The first step to understanding how to conduct successful validations are always to read and re-read the requirements of the documents below:

21 CFR 820.30(g)
21 CFR 820.75
ISO 13485, Clause 7.3
ISO 13485, Clause 7.5.2

Unfortunately, we sometimes need to consult a reference guide that explains aspects of the requirements.

Max Sherman (http://bit.ly/MaxSherman) is finishing a new handbook on design and process validation that will be published through RAPS. The following is a list of resources for the process and design validation that I am submitting for publication in the book. Many of these resources are free, and these are the resources I use to learn and teach principles of validation.

GHTF/SG3/N99-10:2004 – Process Validation Guidance (http://bit.ly/N99-10)
ISO 14969 – ISO Guidance document for ISO 13485 (http://bit.ly/iso14969)
13485 Plus – CSA Guidance document for ISO 13485 (http://bit.ly/13485Plus)
AAMI The Quality System Compendium: Bundled Set of Textbook & CD (http://bit.ly/AAMI-Store)
The preamble to the QSR (http://bit.ly/QSR-preamble)
ICH Q2: Validation of Analytical Procedures: Text and Methodology (http://bit.ly/Q2-Analytical-Validation)
FDA Guidance for Part 11: Electronic Records (http://bit.ly/Part11Guidance)
FDA Guidance for Software Validation (http://bit.ly/FDA-Software-Validation)
FAQs about Implementation of IEC 62304:2006 (http://bit.ly/Team-NB-IEC62304)

In addition to these resources, you may also need additional resources for design validation. Here are some examples of design validation resources I use in my design controls training “tool kit:”

As regulatory affairs professional, it is critical to maintain a list of the most current standards and an organized list of links to those standards. I used to keep a list of favorites in my web browser for this purpose, but my database now exceeds the utility of “favorites.” Now, I use my webpage for this purpose. You can do this yourself by creating a free WordPress blog, and having one of the webpages to the blog be specifically to maintain a list of applicable Standards. Here’s a link to my webpage that I share: http://bit.ly/RA-Resources

Medical Device Validation Document Resources Read More »

Oct 3 2014

Software Design Validation – FDA Requirements

3 Comments / FDA / By Robert Packard / Design Validation, FDA, FDA QSIT inspection, FDA QSIT medical device inspection, medical device design validation, QSIT

What are the FDA software design validation requirements for software as a medical device (SaMD) and software in a medical device (SiMD).

If your product has software, then the investigator is instructed by the FDA QSIT Inspection Manual to consider reviewing software validation. Since inadequate software validation causes many quality problems with devices, you should be shocked if an investigator doesn’t review the software validation of a device containing software. Software-containing devices are also the only devices that manufacturers are required to submit a risk analysis for when submitting premarket notifications (i.e., 510k submissions).

Software Design Validation

Validation confirms that a device meets the user needs. Software validation is no different. Unfortunately, “software design validation” is also the term that we use to mean software design and development–which includes software verification activities and software validation activities. The software verification activities consist of unit testing, integration testing, and system testing. In software verification, we are verifying that each requirement of the software design specification (SDS) meets the requirements of the software requirements specification (SRS). In contrast, software validation involves simulated use or actual use testing of the software to confirm that it meets the user needs of the software. The “device” is the final complete software program in the operating environment in which it is intended to be used (i.e., operating system and hardware), and the “user needs” may be defined as system-level requirements in the SRS or as the intended purpose of the software in the software description.

To facilitate the validation of software, a traceability matrix is typically used to facilitate the construction of validation protocols. The traceability matrix will identify each requirement in the left-hand column of the matrix. The columns to the right of the requirements should include the following:

hazard identification
the potential severity of harm
P1 – the probability of occurrence
P2 – the probability of occurrence resulting in harm
risk controls
design outputs or references to the code modules that are responsible for each requirement
references to verification and validation testing for each risk control
estimation of residual risks
risk/benefit analysis of each risk and overall risk
traceability to information disclosed to users and patients or residual risks

Since the failure of each module can easily result in multiple failure modes, the above approach to documenting design requirements and risk analysis is generally more effective than using an FMEA. This approach also has the benefit of lending itself to assessing risk each time new complaints, service reports, and other post-market surveillance information is gathered.

The use of a traceability matrix also lends itself to the early stages of debugging software modules and unit validation. Each software design requirement will typically have a section of code (i.e., a software module) that is associated with it. That module will be validated initially as a standalone unit operation to verify that it performs the intended function. In addition to verifying the correct function, the software validation protocol should also verify that the embedded risk controls catch incorrect inputs to the module for that module. The correct error code should be generated, and applicable alarms should be triggered.

Finally, after each requirement has been verified, the entire software program must be validated as well. When changes are made, the module and program as a whole must be re-validated. Inspectors and auditors will specifically review changes made in recent versions to verify that revalidation of the entire program was performed–not just unit testing. You must also comply with IEC 62304, medical device software – software lifecycle processes. This is required for CE Marking as a harmonized standard and recognized by the US FDA. One of the implications of applying IEC 62304 is that you must consider the risk of using software of unknown pedigree or provenance (SOUP).

Software Risk Analysis

Each requirement of the software design validation requirements document will typically have a risk associated with it if the software fails to perform that requirement. These risks are quantified concerning the severity of harm and the probability of occurrence of harm. The likelihood of occurrence of harm has two factors: P1 and P2, as defined in Annex E of ISO 14971:2007 (see our updated risk management training).

P1 is the probability of occurrence, and for software, we have two factors. First, the situation must occur that will trigger a failure of the software. Second, does the software have a design risk control that prevents harm or provides a warning of the potential for harm? P2 is the probability that occurrence will result in harm; P2 has one factor. P2 is determined by evaluating the likelihood that failure will result in harm if the risk control is not 100% effective.

An investigator reviewing the risk assessment should verify that risk has been estimated for each software design requirement. There should be harm identified for each software design requirement, or the traceability matrix should indicate that no harm can result from failure to meet the software design requirement. Next, the risk assessment should indicate what the risk controls are for each requirement identified with the potential for harm. In accordance with ISO 14971, design risk controls should be implemented first to eliminate the possibility of harm. Wherever it is impossible to eliminate the possibility of harm, a protective measure (i.e., an alarm) should be used.

Each risk control must be verified for effectiveness as part of the software validation. Also, the residual risk for each potential harm is subject to a risk/benefit analysis in accordance with EN ISO 14971:2012, Annex ZA Deviation #4. The international version, ISO 14971:2007 (which is recognized by the US FDA and Health Canada), allows companies to limit a risk/benefit analysis to only unacceptable risks. Therefore, the European requirement (i.e., EN ISO 14971:2012) is more stringent. Companies that intend to CE Mark medical devices should comply with the EN version of the risk management standard instead of the international version for risk management.

Software Design Validation – FDA Requirements Read More »

Sep 23 2014

FDA QSIT Inspection of Design Validation: Part I-Non-Software

1 Comment / FDA / By Robert Packard / Design Validation, FDA medical device regulatory compliance, FDA QSIT, medical device QSIT, medical device validation

This article reviews FDA QSIT inspection requirements of design validation and is specific to devices that do not contain software.

In the FDA QSIT Manual (http://bit.ly/QSITManual), the word “validation” appears in the QSR 78 times. This exceeds the frequency of the name “verification,” “production,” “corrective” and the acronym “CAPA.” The word “validation” is almost as frequent as the word “management”–which appears 80 times in the QSIT Manual. The section of the QSIT Manual specific to design validation is pages 35-40.

The FDA selects only one product or product family when they are inspecting design controls. Therefore, if you keep track of which products have already been inspected by the agency, you can often predict the most likely product for the investigator to select during the next inspection. The number of MDRs and recalls reported will have an impact on the investigator’s selection. Class, I devices are not selected.

The QSIT Manual instructs inspectors to verify that acceptance criteria were specified before conducting design validation activities and that the validation meets the user needs and intended uses. There should also be no remaining discrepancies from the design validation. Inspectors must verify that all validation activities were performed using initial production devices or production equivalents. The last item to verify is that design changes were controlled–including performing design validation of the changes.

Risk Analysis

Risk analysis is seldom reviewed in great detail–except software risk analysis. However, when a nonconforming product is reworked, it is required to review the adverse effects of rework. QSIT inspectors will expect you to document this review of risks. Investigators will also expect risks to be reviewed and updated in accordance with trend analysis of complaints, service reports, and nonconformities. Finally, when companies assess the need to report recalls, the FDA expects to see a health hazard evaluation to be completed (http://bit.ly/HHE-Form). A detailed review of risk analysis is uncommon in QSIT inspections but receives greater emphasis in the review of CE marking applications.

Predetermined Acceptance Criteria

Investigators reviewing your design validation protocols will specifically look at the acceptance criteria for testing you perform. Investigators are looking for two things. First, were the acceptance criteria met without deviation? Second, was the protocol approved before knowing the results (i.e., was this a prospective design validation protocol?). In certain areas, there are also known risks associated with products that the investigators will look for. For example, in sterilization validation, the investigator will verify that the validation was performed to the most current version of the standard and that the validation has addressed the most common pitfalls of sterilization. For example:

Have the most challenging devices been identified?
Has performance been validated at the maximum sterilization dose?

User Needs & Intended Uses are Met

In the area of user needs and intended uses, there are few problems with the initial launch of devices for the intended use. Problems typically arise when companies expand the intended use to new patient populations and new intended uses. When this occurs, there may be unique user needs and risks that need to be evaluated. Therefore, the FDA periodically reviews claims made by companies in marketing communications to ensure that claims do not stray beyond the cleared intended use of the device. This will sometimes be identified as a 483 inspection observation. In some instances, the FDA will issue a warning letter to a company that continues to market a device for uncleared indications.

Initial Production Devices or Production Equivalents

When investigators review validation protocols and reports, the documentation must include traceability to the production lot(s) of the device. Investigators may even request a copy of the Device History Record (DHR) for the production lot used for validation. If a production lot is not used, then the design validation documentation must disclose how the product differs from production lots, and why the results are acceptable. The samples used should be subjected to the final test/inspection requirements. If final test/inspection requirements are not yet established, samples should be retained, so that they can be inspected at a later date. Without this traceability, you may have to repeat your design validation with a production lot.

Validation of Design Changes

Far too many hours are wasted writing justifications for why re-validation is not required. I recommend that re-validation of design be performed for any design change if all three of the following criterion are not met:

a sound scientific rationale can be provided with references
the logic does not require a subject matter expert to understand it
quantitative analysis is possible to analyze the risk impact

Many design validations require simulated use with a physician. Companies should obtain as much user feedback as possible before launching a device. Therefore, any re-validation that requires simulated use and user feedback should be a priority over writing a rationale for not conducting re-validation.

FDA QSIT Inspection of Design Validation: Part I-Non-Software Read More »

Sep 5 2014

The Three Biggest Changes in the Latest 510k Guidance

Leave a Comment / 510(k) / By Robert Packard

This blog describes the three most prominent changes in the latest 510k guidance document released on July 28, 2014.

This recently issued guidance (http://bit.ly/Substantial-Equiv-Guidance) for evaluating Substantial Equivalence (SE) is well written and informative, with well-chosen and written examples. For newbies to 510ks, this is the place to start. The guidance includes background information about the 510k process and links to other documents. If you are an experienced professional, this is a must-read insight into the FDA’s current approach. Use it to guide your strategy for your next submission, and make it as easy as possible for the reviewer to reach a decision of SE for your device.

Change #1: 510k Flowchart

The 1986 flowchart guiding the decision of SE was updated and re-formatted to improve clarity. A substantial part of the guidance explains the thinking process that guides a reviewer at each decision step. If you are in the middle of preparing a submission, as I am, then the guidance provides an opportunity to review your work against current FDA thinking and training and adjust your submission to align with the FDA.

Change #2: Predicate Selection

Much has already been written about how this document may alter your selection of a predicate device. The FDA clarifies that split predicates (one for intended use equivalence, another for technological equivalence) have been ruled out. The FDA also recently released another guidance document to assist with performing a benefit/risk analysis (http://bit.ly/SE-Benefit-RIsk) when you are developing a device with a different technology than the predicate. The checklist below is intended to help you review your submission when you have already chosen an appropriate predicate.

If you are using multiple predicates, have you stated which one is your primary predicate, the one that is most similar to your device? The FDA must find your device substantially equivalent to one other device.
Are you using secondary predicates only when you are combining features, have more than one intended use, or have additional indications for use?
Is the intended use the same as that for the predicates? Carefully compare your Intended use and the Indications for use with those of the predicates. If they are worded differently, have you explained how they are nevertheless the same?
Have you provided a rationale for your choice of predicates in a way that aligns with the guidance?
Is your SE table organized such that the secondary predicates only support the additional indications for use?
Has your predicate been involved in a design-related recall?
Double-check the Indications for Use statement in your labeling. Regulations state that the determination of the same intended use must be made against the labeling, not against what you say in the submission. Of course, what is in the submission should match the labeling.
Have you included a copy of the labeling for the predicate device, e.g., the user manual?
Does your Description section have sufficient information about the technical characteristics? The FDA is quite specific about what they want to see. Check your Description against the lists on page 19, and at (http://bit.ly/510k-Content) and in any device-specific guidance.
Does your SE table identify similarities and differences in technological characteristics in a structured way?
Do you make it clear why each of the differences does not pose a significant safety or effectiveness concern?
Clinical performance data. Do the examples in the guidance suggest that you might need clinical evidence after all?
If you are using an animal study, does it comply with applicable parts of GLP regulation (http://bit.ly/21-CFR-58)? This was already flagged in the RTA checklist (http://bit.ly/FDA-RTA-Policy). If the RTA reviewer can’t tick those boxes for question 39, then your submission won’t make it through the review.

Change #3: 510k Summary Template

Eleven pages, a quarter of the guidance document, are devoted to the 510k Summary, which will be posted on the FDA website. The guidance states that “FDA intends to verify the accuracy and completeness of the information included in a 510(k) Summary.” Your reviewer will have been so instructed. There is no change to the regulatory requirements for the Summary, but anyone who has combed through these while searching for a predicate will know that many Statements are incomplete.

The FDA states that their focus on the Summary is in the interests of transparency, and they are making their point quite clearly in this guidance. As well as explaining each requirement, an example is provided. Therefore, I will be using Appendix C as a template for my 510k Summary.

The Three Biggest Changes in the Latest 510k Guidance Read More »

Sep 2 2014

Technical File Conversion – 5 gaps to avoid

1 Comment / 510(k) / By Robert Packard / medical device 510k, medical device 510k documentation, medical device technical file

Technical File conversion from a 510k submission is easy, but five elements are missing from a 510k that you will need to add.

This blog, Technical File Conversion, offers practical courses of action to consider related to this topic. Below are five parts of a technical file you are likely to be missing in your 510k documents:

Technical File Conversion Requires Clinical Evidence – The FDA states that clinical data is unnecessary for most devices cleared by the 510k process. The MD Regulation (Annex II) requires a clinical evaluation to be performed and the evaluation report to be part of the technical file. Once formulated, the report becomes “clinical evidence” of the safety and performance of the medical device for demonstrating conformity with the relevant General Safety and Performance Requirements (GSPRs).

Here’s how to fill this gap using five steps offered by MEDDEV 2.7.1 Rev. 3:

Identify the GSPRs requiring clinical support. (e.g., the device “shall not compromise the clinical condition or the safety of patients, or the safety and health of users” and “any risks which may be associated with their use constitute acceptable risks when weighed against the benefits to the patient.”
Identify and “data pool” existing clinical data relevant to the device and its intended use. This should include any available post-marketing data on the same or similar device. But it may also comprise data from clinical trials or clinical use of a previous generation or even a substantially similar device. Finally, if you are utilizing standard methodologies in your device, it may be possible to use data showing conformity to recognized standards.
Evaluate the data to determine if it’s suitable for establishing the safety and performance of your device. Even some generally unusable studies may produce relevant data. It is vital to perform this evaluation systematically. You might draw a chart listing the relevant ERs on the left and indicate the data source supporting or contradicting it to the right. The evaluation must objectively consider both positive and negative data.
Generate any clinical data still needed. Consider methods other than a clinical trial for generating this missing data, e.g., “Data Pull” existing field data of the same or similar devices that may not yet have been ‘pulled’ through your PMS/RM Post-Production Infosystems. If data is unavailable, you may have no choice in generating it through a small-scale clinical trial. If so, keep it small, focused on the questions at hand, and statistically significant.
“Bring all the clinical data together” to reach conclusions about your device’s clinical safety and performance. Essentially, conduct a benefit-risk analysis. Involve qualified team members: e.g., experts in medical conditions and device technology.

Now sum it up in a report.

General Safety and Performance Requirements Checklist – This central component of the technical file is based on Annex I of the MDR and IVD, respectively. There is no such review in a 510k.

Develop a checklist based on the principles in GHTF N68:2012 containing all of the following columns for each ER:

Applicable? – y/n; Is the requirement applicable? If not, why.
The method used to demonstrate conformity –harmonized standard, Common Specification (CS), etc…?
Specific Standards or CS applied.
Evidence of conformity
The controlled document/s demonstrating fulfillment of the ER.

Technical File Conversion Requirest Post-Market Surveillance– The FDA requires PMS activities only if it is mandated due to safety concerns and for Class III or devices with Humanitarian Device Exemptions (HDEs). A PMS plan must then be submitted. Manufacturers may not yet have formulated such a plan.

No worries. If you perform your RM activities in compliance with ISO 14971, you will have an RMP or separate system, including a plan for observations, assessment, and action (ISO 14971:2019 § ten). Reference this in your technical file. What about the PMCF report? Well, if you’ve performed post-market surveillance, develop one. OTechnical File conversion from a 510k submission is easy, but five elements are missing from a 510k that you will need to add. Otherwise, see the next item below.

Technical File Conversion includes a risk management report

While not required by the FDA in your 510k submission, you most likely have fulfilled this ISO 14971 requirement. Reference it in your technical file. Ensure you also confirm in the report that appropriate methods are in place to obtain production and post-production information. If detailed enough, you can also reference the report as a PMCF report.

Risk class/applicable classification rule (based on Annex VII of the MDR) – FDA defines Classes I through III, which are not parallel to Classes 1, IIa, IIb, or III in the EU MDR.

Using either of the latter systems, identify the relevant rule, and classify your device—document in your technical file.

If you have finished your 510k technical file conversion, you might want to perform a technical file audit before submission to your notified body.

Technical File Conversion – 5 gaps to avoid Read More »