Blog

Author Archive

Is monitoring every procedure required?

Process monitoring is required but do you know whether monitoring every procedure is required by the FDA QSR or ISO 13485?

One of the elements that Medical Device Academy has incorporated into each procedure we created in our turnkey quality system is a section titled, “monitoring and measurement.” The purpose of this section is to force each process owner to identify a process metric for monitoring every procedure. In some cases, we suggest a metric that would be appropriate for most companies establishing a new quality system. In other procedures, we use the following default text:

Enter a quality metric that you want to track for this process in accordance with ISO 13485:2016, Clause 8.2.5 and the procedure for Monitoring, Measurement, and Analysis (SYS-017).

Where are the requirements for process monitoring in 21 CFR 820?

Some of the companies that have purchased our turnkey quality system have asked, “Is it required to monitor and measure something in every procedure?” In general, it is not a specific requirement to have a metric specified in each procedure. In fact, if your quality system is not ISO 13485 certified, there are actually only a few places where the US FDA requires monitoring. The FDA does not have a section specific to monitoring and measurement of processes, but there is a section of the regulations specific to statistical techniques (i.e. 21 CFR 820.250). However, it does not state in the QSR that statistical analysis is required for all processes. In fact, there are only six instances where the word “statistical” is used:

  • 21 CFR 820.100(a)(1) – “Analyzing processes, work operations, concessions, quality audit reports, quality records, service records, complaints, returned product, and other sources of quality data to identify existing and potential causes of nonconforming product, or other quality problems. Appropriate statistical methodology shall be employed where necessary to detect recurring quality problems;”
  • 21 CFR 820.200(b) – “Each manufacturer shall analyze service reports with appropriate statistical methodology in accordance with § 820.100.”
  • 21 CFR 820.250 – “(a) Where appropriate, each manufacturer shall establish and maintain procedures for identifying valid statistical techniques required for establishing, controlling, and verifying the acceptability of process capability and product characteristics. (b) Sampling plans, when used, shall be written and based on a valid statistical rationale. Each manufacturer shall establish and maintain procedures to ensure that sampling methods are adequate for their intended use and to ensure that when changes occur the sampling plans are reviewed. These activities shall be documented.” Note: the other two instances are the title of 21 CFR 820.250.

The word “monitoring” is equally rare (i.e. 4x) in the QSR:

  • 21 CFR 820.70(a) – “Each manufacturer shall develop, conduct, control, and monitor production processes to ensure that a device conforms to its specifications…Where process controls are needed…(2) Monitoring and control of process parameters and component and device characteristics during production.”
  • 21 CFR 820.75(b) – “Each manufacturer shall establish and maintain procedures for monitoring and control of process parameters for validated processes to ensure that the specified requirements continue to be met…(2) For validated processes, the monitoring and control methods and data, the date performed, and, where appropriate, the individual(s) performing the process or the major equipment used shall be documented.”

Where are the requirements for process monitoring in ISO 13485:2016?

ISO 13485:2016 has a section specific to monitoring and measurement of processes (i.e. Clause 8.2.5). In addition, the word “monitoring” occurs 52 times in the standard and there are 60 incidents of some variant or the exact word. , but there is a section of the regulations specific to statistical techniques (i.e. 21 CFR 820.250). However, it does not state in the QSR that statistical analysis is required for all processes. In fact, there are only six instances where the word “statistical” is used. There are four Clause headings that actually include the word monitoring:

  • Clause 7.6, Control of monitoring and measuring equipment
  • Clause 8.2, Monitoring and measurement
  • Clause 8.2.5, Monitoring and measurement of processes
  • Clause 8.2.6, Monitoring and measurement of product

In Clause 1, Scope, and Clause 4.1.5, the Standard states that any outsourced processes remain the responsibility of the company and must be accounted for in the quality system by monitoring, maintaining, and controlling the processes.

Monitoring of risk is included in the definition of “risk management” in the Standard (i.e. Clause 3.18).

Clause 4.1.3 states that the organization shall, “b) ensure the availability of resources and information necessary to support the operation and monitoring of these processes…d) monitor, measure as appropriate, and analyze these processes.”

Clause 4.2.3 states that the contents of the Medical Device File (i.e. MDR or TF), shall include, “d) procedures for measuring and monitoring.”

Monitoring and measurement of processes and product are required inputs to the Management Review in Clauses 5.6.2e) and f).

Clause 6.4.1 requires a procedure for monitoring the work environment if it can have an effect on product quality.

Clause 7.1 requires the company to consider including monitoring in product realization planning.

Clause 7.4.1 requires a plan for monitoring suppliers.

Clause 7.5.1 requires monitoring production and service, including the monitoring of process parameters and product characteristics.

Clause 7.5.6 requires monitoring of validated process parameters.

Clause 7.5.8 requires identification of status with regard to product monitoring and measurement (i.e. inspection status).

Clause 7.6 requires monitoring and measurement of calibrated devices and validation of any computer software used to monitor calibrated devices.

Clause 8.1 states that companies shall plan and implement monitoring and measurement of processes.

Clause 8.2 is titled, “Monitoring and measurement.”

Clause 8.2.1 requires monitoring of customer feedback.

Clause 8.2.5 requires monitoring of processes to ensure planned results are achieved.

Clause 8.2.6 requires monitoring of products to ensure product requirements have been met.

Clause 8.4 requires data analysis of monitoring data from at least six different processes:

  1. Feedback
  2. Conformity to product requirements
  3. Characteristics and trends of processes and products, including opportunities for improvement
  4. Suppliers
  5. Audits
  6. Service reports, as appropriate

In summary, while not every single clause that requires a procedure includes a requirement for monitoring, there are a number of processes where the requirement to monitor the process is explicitly stated.

Why do all of our procedures include the requirement for metrics?

Medical Device Academy expanded the requirement for monitoring to all procedures for five reasons:

  1. Quality objectives must be “established at relevant functions and levels within the organization.” Therefore, establishing monitoring requirements for each procedure ensures that top management has metrics for every process and a lack of data is never an excuse for not establishing a new quality objective when improvement is needed.
  2. If every procedure has a requirement for monitoring, then employees don’t have to remember which processes require monitoring and which processes do not explicitly require monitoring.
  3. The process approach to auditing includes metrics of the process as one of the seven items that are included in every process turtle diagram, and therefore, including metrics for each procedure facilitates the process approach to auditing.
  4. If a company does not have a process metric already established, it is often difficult to perform an investigation of the root cause of quality issues. If a metric is already being monitored for the process, this facilitates the investigation of the root cause and you can use the baseline monitoring data to help you establish effectiveness criteria for the corrective action.quantitative effectiveness check 300x209 Is monitoring every procedure required?
  5. Finally, most companies struggle to identify preventive actions as required by Clause 8.5.3, and we have found that data analysis of monitoring data is the best source of identifying new preventive actions.

What are the disadvantages when you monitor and measure something in every procedure?

The primary reason for resistance to identifying a metric for monitoring in every procedure is that it will increase the workload for the employees responsible for that process. However, monitoring of data does not always increase workload. In fact, when process data is recorded in real-time on a run chart it is often possible to identify a trend much earlier than when data is simply recorded and subjected to monitoring.

  • Example #1: The automatic tracking of toner in a printer tells HP when to ship you a new toner cartridge before you need it. This ensures that there is no loss in productivity because you never run out of ink or the ability to print documents.
  • Example #2: Companies will use project management software (e.g. Asana) to monitor labor utilization. This will help identify when a specific resource is nearing capacity. When this occurs, the project manager can add time buffers to prerequisite steps and adjust the starting date of the resource-limited tasks to an earlier starting date. This ensures that more time is available to finish the task or to take advantage of resource availability at an earlier date.
  • Example #3: Monitoring the revision date for procedures helps the document control process owner identify procedures that should be evaluated for the need to be revised and updated. Often this is articulated as a quality objective of reviewing and updating all procedures within 2 years. This also ensures that procedures remain current and compliant with regulatory requirements.

What are the advantages of monitoring every procedure?

The phrase “what gets measured gets managed” is a popular business philosophy that implies measuring employee activity increases the likelihood that employees will complete a task or perform it well. In contrast, if a process is not monitored, employees may assume that it is not important and the tasks may be skipped or completely forgotten. Setting quantitative goals is also sometimes integrated with economic incentives or bonuses that are granted to individuals and teams.

FDA transition from QSR to ISO 13485

The US FDA is planning its transition from 21 CFR 820 to ISO 13485 as the quality system criteria. This will force companies to make adjustments to their quality systems and increase the amount of process monitoring performed. My general advice is to work with employees that are performing tasks to identify streamlined methods for monitoring those tasks without being overly burdensome. Then you and the employees you manage can analyze the data together and identify opportunities for improvement. When you do this, experiment with manual methods using whiteboards and paper charts that are visible in public areas first. Only implement automated solutions after you have optimized the data being collected and the frequency of data collection, and remember that not every process will benefit from automated statistical process control. Sometimes the simple approach is best.

Posted in: Uncategorized

Leave a Comment (0) →

What’s new in the 2022 draft cybersecurity guidance?

On April 8, 2022, the FDA released a new draft cybersecurity guidance document to replace the 2018 draft that the industry does not support.

Why was the draft cybersecurity guidance created?

Due to the ubiquitous nature of software and networked devices in the medical industry, the impact of cybersecurity attacks is becoming more frequent and more severe. The WannaCry Ransomeware Attack is just one example of this global cybersecurity issue. The FDA is responding to the need for stronger cybersecurity controls by issuing a new draft cybersecurity guidance for 2022.

The first four paragraphs of the introduction explain why we need this, and WannaCry is mentioned in the second paragraph of the background section. This new guidance is only a draft, but this is the FDA’s third attempt at regulating the cybersecurity of medical devices. The first guidance was finalized in 2014. That’s the 9-page guidance we currently have in effect. The guidance mentions risk 11 times and there is no mention of testing requirements or a bill of materials (BOM). The 2018 draft guidance (24-pages) met with resistance from the industry for a lot of reasons. One of the reasons mentioned by Suzanne Schwartz in an interview is the inclusion of a cybersecurity bill of materials (CBOM). The industry felt it would be too burdensome to disclose all of the hardware elements that are related to cybersecurity. Therefore, the FDA rewrote the 2018 draft and released a new draft on April 8, 2022 (49-pages).

Untitled presentation e1650071404761 What’s new in the 2022 draft cybersecurity guidance?

You might have expected the FDA to soften its requirements in the face of resistance from industry, but the new draft does not appear to be less robust. It is true that the CBOM was replaced by a software bill of materials (SBOM). However, the SBOM must be electronically readable and it must include:

  • the asset(s) where the software resides;
  • the software component name;
  • the software component version;
  • the software component manufacturer;
  • the software level of support provided through monitoring and maintenance from the software component manufacturer;
  • the software component’s end-of-support date; and
  • any known vulnerabilities.

You can be sure that the medical device industry will view providing an SBOM as a hefty burden. After all, a machine-readable SBOM is more complex than UDI labeling requirements. An SBOM will not fit on the “Splash Screen” for anyone’s software application. Companies may provide documentation through the company website with a link in their software to that information. The format of the information could be in the “Manufacturer Disclosure Statement for Medical Device Security (MDS2).” However, MDS2 is a 349-line item Excel spreadsheet to be used as a checklist (i.e. quite a bit longer than the GUDID data elements spreadsheet), and it took the FDA eight years to complete the transition for the UDI Final Rule (i.e. 2013 – 2021).

The 2018 draft cybersecurity guidance document from the FDA required a cybersecurity bill of materials (CBOM). CBOM was defined as “a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.” Therefore, the FDA’s change from a CBOM to an SBOM eliminated the requirement to disclose the hardware components. Despite the change in disclosure requirements, manufacturers will still be expected to monitor potential hardware vulnerabilities to cybersecurity attacks. It should also be noted that the language in the PATCH Act (a new bill submitted to the House of Representatives and to the Senate for ensuring the cybersecurity of medical devices) specifically requires manufacturers “to furnish a software bill of materials as required under section 524B (relating to ensuring the cybersecurity).”

 Structure of the draft cybersecurity guidance

The 2022 draft cybersecurity guidance organizes the requirements into four major principles:

  1. cybersecurity as part of device safety and the quality system regulations
  2. designing for security
  3. transparency
  4. submission documentation

The draft cybersecurity guidance recommends the implementation of a Secure Product Development Framework (SPDF). However, there is not much detail provided in the guidance for a SPDF. In the past, the term for this type of process was referred to as a Secure Software Development Lifecycle (i.e. Secure SDLC). However, in February 2022, the NIST Computer Security Resource Center (CSRC) released version 1.1 of the Secure SDLC guidance which is now titled “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.” This guidance provides guidance on the implementation of best practices for reducing the risk of software vulnerabilities because existing standards for managing the software development lifecycle do not explicitly address software security (e.g. IEC 62304-1:2015). The SSDF recommends implementing a core set of high-level secure software development practices that can be integrated into your SDLC process. Your software development team will also require cybersecurity training.

Design for security is the second principle of the draft cybersecurity guidance

Under this new draft cybersecurity guidance, the FDA will be evaluating the cybersecurity of devices based on the ability of the device to provide and implement the following security objectives:

  • Authenticity, which includes integrity;
  • Authorization;
  • Availability;
  • Confidentiality; and
  • Secure and timely updatability and patchability.

Transparency of cybersecurity information is for users

The draft cybersecurity guidance seeks to give device users more information pertaining to the device’s cybersecurity controls, potential risks, and other relevant information. This information will be in the form of an SBOM that is electronically readable. This information shall include disclosure of 1) known vulnerabilities or risks, 2) information to securely configure and update devices, and 3) communication interfaces and third-party software.

In addition to providing an SBOM, the FDA draft cybersecurity guidance includes requirements for cybersecurity labeling in section VI(A). There are 15 specific labeling requirements identified by the FDA for sharing with device users to improve the transparency of cybersecurity information. The first of these requirements is recommendations from the manufacturer for cybersecurity controls appropriate for the intended use environment (e.g., antimalware software, use of a firewall, password requirements). This first labeling requirement is identical to the 2018 draft guidance. Several of the other requirements are copied from the 2018 draft guidance, but others are new and/or reworded cybersecurity labeling requirements.

FDA Submission Documentation Requirements

The 2022 FDA draft cybersecurity guidance includes requirements for FDA submission documentation. Submission documentation must include a security risk management plan and report. The draft cybersecurity guidance explains on page 13 (numbered 9) that “performing security risk management is a distinct process from performing safety risk management as described in ISO 14971:2019.” Therefore, instead of using your safety risk management process, your software development team will need to have a different risk management process for software security. Details on the content for security risk management plans and reports can be found in AAMI TIR57:2016 – Principles for medical device security—Risk management. Appendix 2 also provides guidance for the inclusion of a) call flow diagrams, and b) information details for an architecture view.

Cybersecurity testing requirements for your FDA submission

The biggest impact of this new draft guidance may be the requirement for testing. The 2014 guidance has no testing requirement, the 2018 draft guidance mentioned testing 5 times in a few bullet points, but this new draft guidance mentions testing 43 times. The testing requirements for cybersecurity risk management verification include:

  1. Security requirements
  2. Threat mitigation
  3. Vulnerability testing
  4. Penetration testing

This guidance also includes a paragraph with multiple bullets of requirements for each of the four types of testing. This would essentially double the size and scope of the current software section for a 510k submission, and manufacturers will need to create new procedures and templates for their cybersecurity risk management process. For example, penetration testing requirements include the following elements:

  • Independence and technical expertise of testers,
  • Scope of testing,
  • Duration of testing,
  • Testing methods employed, and
  • Test results, findings, and observations.

Differences between the cybersecurity guidance documents

The following table provides a high-level overview comparing the four cybersecurity guidance documents released by the FDA, including the 2016 guidance on post-market management of cybersecurity:

Screenshot 2022 04 16 12.48.51 AM 1024x291 What’s new in the 2022 draft cybersecurity guidance?

Vulnerability management plans

The FDA draft cybersecurity guidance document also has a requirement for manufacturers to develop a plan for identifying and communicating vulnerabilities to device users after the release of the device. The FDA requires this plan to be included in your device submission. The vulnerability management plan should include the following information (in addition to the requirements of the 2016 guidance for postmarket cybersecurity management):

  • Personnel responsible;
  • Sources, methods, and frequency for monitoring for and identifying vulnerabilities (e.g. researchers, NIST NVD, third-party software manufacturers, etc.);
  • Periodic security testing to test identified vulnerability impact;
  • Timeline to develop and release patches;
  • Update processes;
  • Patching capability (i.e. rate at which update can be delivered to devices);
  • Description of their coordinated vulnerability disclosure process; and
  • Description of how manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.

What’s the next step for the draft cybersecurity guidance?

In March the “Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act)” was introduced to the House of Representatives and the Senate. The goal of the PATCH Act is to enhance medical device security by requiring manufacturers to create a cybersecurity risk management plan for monitoring and addressing potential postmarket cybersecurity vulnerabilities. The FDA seeks comments on the draft cybersecurity guidance through July 7, 2022. Given the support of the new bill in the House of Representatives and Congress, it is likely that the FDA will get the support it needs for this new guidance. 

Posted in: 510(k), Cybersecurity

Leave a Comment (0) →

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

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

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

Benefits from the human factors process

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

Why was your rationale for no usability testing rejected?

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

What is the 10-step human factors process?

  1. Define human factors for your device or IVD
  2. Identify use errors
  3. Conduct a URRA
  4. Perform a critical task analysis
  5. Conduct a risk control option analysis
  6. Conduct formative usability testing
  7. Implement risk controls
  8. Conduct summative usability testing
  9. Prepare HFE/UE documentation
  10. Collect post-market surveillance data specific to use errors

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

Why is formative testing needed?

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

Why is the human factors process crazy expensive to outsource?

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

Why was your Usability Engineering File refused?

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

    URRA table example from the FDA 1024x399 Human factors process, can we make this easy to understand?

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

    The primary problem with using an FMEA or Fault-Tree risk analysis tool is that these tools involve estimation of the severity of harm and the probability of occurrence of harm, while the FDA does not feel it is appropriate to estimate the probability of occurrence of harm. Instead, the FDA instructs companies to assume that use errors will occur and to implement risk controls to mitigate those risks (see URRA example above). Although “mitigation” is unlikely, and use risks will only be reduced, this is the approach the FDA wants companies to use. In addition, the FDA expects your company to provide traceability of risk control implementation to each use-related risk you identified and the FDA expects documentation of verification testing (i.e. usability testing) that shows your risk controls are effective. Finally, the FDA (and ISO 14971, Clause 10) expects you to collect and perform a trend analysis of use errors. Any use errors that are reported should be evaluated for the need to implement additional corrective actions to prevent future use errors. Blaming “user error” is not an acceptable approach. 

  2. You provided risk analysis and human factors testing in your 510(k) submission, but the FDA reviewer said you need to identify critical tasks and provide traceability to each critical task in your summative validation report. – Critical tasks are specifically mentioned in section 3.2 of the FDA guidance on applying human factors and usability engineering–and a total of 49 times throughout the guidance. However, “critical tasks” are not mentioned even once in ISO 14971:2019 or ISO/TR 24971:2020. The term “critical tasks” is not even found in IEC 62366-1:2015. There is mention of “tasks”, and “task” is a formal definition (i.e. Definition 3.14, “Task – one or more USER interactions with a MEDICAL DEVICE to achieve a desired result”). Therefore, companies that are familiar with the ISO Standards and CE Marking process frequently need training on the FDA requirements for the human factors process. After receiving training, then your company will be prepared to modify your usability engineering file documentation to comply with the FDA requirements for human factors.
  3. You completed a summative validation protocol, but the FDA disagrees with your definition of user groups. – Each user has a different level of experience, training, and competency. Therefore, if you define the intended user population too broadly (e.g. healthcare practitioners), the FDA may not accept your summative usability testing. This is the reason that the human factors process begins with defining the human factors for your IVD or device. Radiologists, for example, have the following training pathway:
    • graduate from medical school;
    • complete an internship;
    • pass state licensing exam;
    • complete a residency in radiology;
    • become board certified; and
    • complete an optional fellowship.

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

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

Additional resources for the human factors process and usability testing

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

Leave a Comment (4) →

What are the IVDR risk management requirements?

This article reviews unique IVDR risk management requirements for CE Marking of in vitro diagnostic (IVD) devices in Europe.

Last week I posted a blog about “How to create an IVDR checklist.” The article was very popular because we included a form for downloading a free IVDR checklist. That form included the opportunity for people to ask a question about the IVDR. One of the subscribers, a gentleman from New Zealand, entered a very simple comment: “risk management requirements.” My first thought was that the risk management file is the required technical documentation for the IVDR. Then I quickly remembered that in 2012, EN ISO 14971:2012 was released with three new annexes for the three directives: ZA (for the MDD), ZB (for the AIMD), and ZC (for the IVDD). In Annex ZC there were seven deviations, and even though ISO 14971 was updated in 2019, the international standard continues to deviate from the European regulations in significant ways. Therefore, this blog provides an overview of the IVDR risk management requirements.

If you are already compliant with ISO 14971:2019, do you meet the IVDR risk management requirements?

The biggest difference between the ISO 14971:2019 standard and the IVDR risk management requirements is that the standard only requires a benefit-risk analysis to be performed if risks are unacceptable. In contrast, the IVDR requires that a benefit/risk analysis be performed for all risks and the overall residual risk. Therefore, you must include a benefit/risk analysis in your technical file submission regardless of risk acceptability. The harmonized version of the standard (i.e. EN ISO 14971:2019/A:11:2021) was released in December of 2021. If you already purchased ISO 14971:2019, you only need to purchase the amendment which consists of Annex ZA (comparison between the standard and Annex I of MDR) and ZB (comparison between the standard and Annex I of the IVDR).

In the amendment, it states that manufacturers must have a risk management policy that is compliant with Annex I of the EU regulation. There are notes at the beginning of each harmonization annex that indicates that the risk management process needs to be compliant with the IVDR, which means risks have to be ‘reduced as far as possible’, ‘reduced to a level as low as reasonably practicable’, ‘reduced to the lowest possible level’, ‘reduced as far as possible and appropriate’, ‘removed or reduced as far as possible’, ‘eliminated or reduced as far as possible’, ‘prevented’ or ‘minimized’, according to the wording of the corresponding section in Annex I of the IVDR. The comparison table has a column with remarks/notes. In most cases, the deficiency identified states, “Device-specific execution of the process is not covered.” There are also two remarks/notes that state “Device-specific and usability-specific execution of the process is not covered.” 

Where are the IVDR risk management requirements?

Blog tip 1024x183 What are the IVDR risk management requirements?

IVDR risk management requirements are found in Annex II, Section 5 of the IVDR. However, there are 228 references to the word risk throughout the IVDR. The following risk-related requirements in IVDR are particularly important:

  • Article 10, Sections 2 & 8(e) – risk management procedure requirement
  • Annex I, Section 3 – reiteration of risk management procedure requirement, but specific steps in the risk management process are identified (e.g. a risk management plan, hazard identification, estimation of risks, evaluation of risks, etc.)
  • Annex I, Section 4 – Priority of risk control measures
  • Annex I, Section 5 – Elimination or reduction of use-related risks
  • Annex III, Section 1(b) – Reassessment of the benefit-risk analysis and risk management using post-market surveillance data

How should you document your risk management file for the IVDR?

In your risk management file of course. There is no format requirement for risk management files, but there are requirements for the content and there is a GHTF guidance document for risk management, and ISO/TR 24971:2020 is a new guidance document on the application of ISO 14971 to medical devices. Neither of these guidance documents is specific to IVDR risk management requirements. Annex H of ISO/TR 24971:2020, however, provides guidance specific to IVD devices.

What do the IVDR risk management requirements include for risk analysis?

In our March 23, 2022 blog posting, I described four types of risk analysis:

  1. Design risk analysis
  2. Process risk analysis
  3. Software hazard analysis
  4. User-related risk analysis (URRA)

Of these four types of risk analysis, only the software hazard analysis is sometimes not applicable. For an FDA 510(k) submission, you would need to provide software hazard analysis and URRA in the actual submission. The other two types of risk analysis would only be included in your design history file (DHF), and the FDA would review the design and process risk analysis during a routine inspection when the DHF is sampled as part of the design control process.

In contrast, the IVDR requires that a complete risk management file be submitted as part of the technical file (see Annex II, Section 5):

“Benefit-risk analysis and risk management

The documentation shall contain information on:

    • the benefit-risk analysis referred to in Sections 1 and 8 of Annex I, and
    • the solution adopted and the results of the risk management referred to in Section 3 of Annex I.”

The above documentation typically consists of design risk analysis and does not typically include process risk analysis, software hazard analysis, or use-related risk analysis. These other three risk analysis documents are IVDR risk management requirements, but they are referenced by the technical file in other sections. The most obvious IVDR risk management requirements are referenced in Annex I, Sections 1-9. These are referred to as the General Safety and Performance Requirements (GSPRs), and this requirement is typically met by including a GSPR checklist in the technical file to meet the requirement of Annex II, Section 4.

The process risk analysis is typically included with manufacturing information to meet the requirement of Annex II, Section 3.2. This documentation may include, any and all of the following elements:

  1. a process failure mode and effects analysis (pFMEA)
  2. a risk control plan including all processes from receiving inspection to final inspection and product release
  3. a process validation plan that is risk-based and linked to the risk control plan

The best practice for estimation of process risks is to link the probability of occurrence and probability of detection to the quantitative data gathered during process validation. In addition, you may establish a risk management policy that prescribes specific types of process risk controls (e.g. automated inspection) for the highest risk processes where manufacturing process errors are not acceptable residual risks. For example, an inspection of printed circuit board assemblies (PCBAs) typically requires automated optical inspection (AOI) methods, because visual inspection is not sufficient by itself and not all PCBAs allow sufficient ICT coverage, and functional testing is limited.

The software hazard analysis, if applicable, is typically performed in accordance with IEC/TR 80002-1:2009, Guidance on the application of ISO 14971 to medical device software. In the software hazard analysis, it is unnecessary to estimate the probability of occurrence of harm. Instead, it is only necessary to identify hazards and estimate harm. Examples of these hazards include loss of communication, mix-up of data, loss of data, etc. Software failures are systemic in nature and the probability of occurrence cannot be determined using traditional statistical methods. Therefore, we recommend that you assume that the failure will occur and estimate software risks based on the severity of the hazard resulting from the failure. For these reasons, it is recommended that software hazard analysis documentation is maintained as a separate document from your design risk analysis. The software hazard analysis documentation should be referenced in your risk management report, but the software hazard analysis should be included as part of your software verification and validation. The IVDR requires that you include a summary of software verification and validation in Annex II, Section 6.4 rather than the complete hazard analysis document.

A use-related risk analysis should be part of your useability engineering file for IVD devices as required by EN 62366-1:2015. Use-related risks are mentioned in Annex I, Section 5:

“In eliminating or reducing risks related to use error, the manufacturer shall:

    • reduce as far as possible the risks related to ergonomic features of the device and the environment in which the device is intended to be used (design for patient safety), and
    • Give consideration to the technical knowledge, experience, education, training and use environment, where applicable, and the medical and physical conditions of intended users (design for lay, and professional, disabled or other users).”

The above requirement includes not only the ability to read and interpret test results of IVD devices but also the ability of laypersons to properly self-select if an IVD is intended to be sold as an over-the-counter product. Usability also is mentioned in Article 78, Section 3(f):

“for the identification of options to improve the usability, performance and safety of the device;”

Therefore, there should be specific elements of your post-market surveillance plan that are designed to gather feedback on the usability of your IVD device. 

When should risk management activities be performed for IVD devices?

The IVDR does not specifically define when in the design and development process the various risk management activities shall be performed. However, the required risk management activities are specified in the IVDR within Annex I. ISO 14971:2019, however, is more descriptive of the risk management activities and the risk management process. Therefore, your risk management plan should align with the process defined in ISO 14971:2019, Clause 4.1.

Unfortunately, most companies do not include risk management as an integral part of the design and development process. Instead, risk management documentation is created retroactively as part of the documentation preparation for technical file submission. For this reason, most medical device executives fail to see the benefit associated with the risk management process. Even biomedical engineers struggle to appreciate the necessity of following the process outlined in the risk management standard in order to prevent device malfunctions and use errors.

The following is a list of the required risk management activities in the order that they should be occurring. Each activity also references the applicable clause of ISO 14971:2019. We have also grouped the activities into the five phases of design and development:

Design Controls with risk 1024x542 What are the IVDR risk management requirements?

Design Planning

    • Risk management planning (Clause 4.4)

Design Inputs

    • Identification of hazards and hazardous situations (Clause 5.4)

Design & Development

    • Risk estimation (Clause 5.5)
    • Risk evaluation (Clause 6)
    • Risk control option analysis (Clause 7.1)
    • Implementation of risk control measures (Clause 7.2)
    • Residual risk evaluation (Clause 7.3)

Design Verification and Validation

    • Benefit/risk analysis (Clause 7.4)
    • Risk control effectiveness verification (Clause 7.6)

Design Release

    • Evaluation of overall residual risk (Clause 8)
    • Risk management review (Clause 9)

If your company is preparing a 510(k), the company may be able to submit the 510(k) immediately after completion of risk control effectiveness verification. You may also be able to postpone the benefit/risk analysis until you submit your IVD technical file for CE Marking approval. The benefit/risk analysis is not required by ISO 14971 unless the risks are unacceptable, and the FDA does not require a benefit/risk analysis except for novel devices seeking market authorization through a De Novo Classification Request or a Pre-Market Approval (PMA). The FDA also does not require the submission of the complete risk management file.

IVDR risk management requirements are quite different than the US FDA requirements for risk management. An IVD technical file must include a risk management summary report that summarizes all activities that were performed according to the risk management plan. A benefit/risk analysis is required for each risk and the overall risk. The Notified Body auditor is also expected to sample the complete risk management file during quality system audits. Finally, the IVDR includes a requirement for a post-market surveillance plan that includes the collection of production and post-production data as feedback on the risk management process and a post-market clinical performance follow-up (PMPF) plan. 

What production and post-production information should you be collecting for IVD devices?

Medical device manufacturers struggle to see the benefits of requiring a post-market surveillance system, and smaller companies, in particular, complain that the cost of the new European post-market surveillance requirements is excessive and prohibits innovation. However, the primary role of post-market surveillance is to ensure rapid initiation of containment and corrective actions for devices that malfunction and/or present unacceptable risks to the intended users and intended patient population. The purpose of generating the post-market surveillance data is defined in the IVDR within Article 78, Section 3.

The minimum requirements for post-market surveillance are defined in Annex III, Section 1(a):

  • Information concerning serious incidents, including information from PSURs, and field safety corrective actions;
  • records referring to non-serious incidents and data on any undesirable side-effects;
  • information from trend reporting;
  • relevant specialist or technical literature, databases and/or registers;
  • information, including feedback and complaints, provided by users, distributors, and importers; and
  • publicly-available information about similar medical devices.

The IVDR is not prescriptive regarding what production data shall be collected for post-market surveillance, but the reason for this is that there are many different types of manufacturing processes with different process risks. In addition, the IVDR includes software as a medical device where there is no manufacturing process at all. Therefore, the best approach for determining what production data to collect is the review your process risk analysis (e.g. pFMEA). The process risk analysis for each manufacturing process should allow you to identify the manufacturing process steps that have the greatest residual risks (e.g. risk priority number or RPN) and potentially the highest severity of the effect. The risks should be identified as a priority for post-market surveillance. You should also include process parameter monitoring data for any validated processes (e.g. sterilization time, temperature, and pressure). Finally, you should also monitor rejects at incoming inspection, in-process inspection, and final inspection operations.  

Other IVD Risk Management Resources

The following resources may be helpful for creating and maintaining your IVD risk management file:

  1. EN ISO 14971:2019 + A11:2021
  2. ISO/TR 24971:2020
  3. GHTF/SG3/N15R8
  4. Regulation (EU) 2017/746 (i.e. IVDR)
  5. IEC/TR 80002-1:2009
  6. EN 62366-1:2015 + A1:2020

Note: Whenever possible, hyperlinks to the Estonian Centre for Standardization and Accreditation (EVS) are provided for procedures, because we find that this source is frequently the least expensive, and digital versions are available on-demand as a multi-user license.

Posted in: ISO 14971:2019 (Risk Management), IVDR - Regulation (EU) 2017/746

Leave a Comment (2) →

How to create an IVDR checklist

This article provides an IVDR checklist for updating your ISO 13485 quality system to comply with EU Regulation 2017/746.

IVD Checklist 1024x474 How to create an IVDR checklist

Why I created an IVDR checklist?

Hundreds (if not thousands) of IVD manufacturers are currently updating their ISO 13485:2016 certified quality system from compliance with the In Vitro Diagnostic Directive (i.e. Directive 98/79/EC) or IVDD to the new EU In Vitro Diagnostic Regulation (i.e. Regulation 2017/746). Revision of technical files and the associated procedures for creating your technical files is a big part of these updates. However, there is much more that needs to be updated than just the technical documentation. Therefore, IVD manufacturers are asking Medical Device Academy to conduct remote internal audits of their quality system to identify any gaps. Usually, we conduct internal audits using the process approach to auditing, but this is one of the scenarios where the element approach and an audit checklist are invaluable.

If you would like to download our IVDR checklist for FREE, please fill in the form below.

How do you use an audit checklist?

An audit checklist is used by quality system auditors to collect objective evidence during an audit. This objective evidence verifies compliance with regulatory requirements or internal procedural requirements. If the auditor is unable to find supporting evidence of compliance, the auditor may continue to search for data or identify the requirement as a nonconformity. Typically the checklist is in four columns using a tabular form. The left-hand column lists each requirement. The next column is where the auditor documents records sampled, procedures reviewed, and personnel interviewed. In the third column, the auditor indicates what they were looking for in the records, procedures, or during the interview. Some of the information in the second and third columns can often be entered prior to starting the audit by reviewing audit preparation documents (e.g. procedures and previous audit reports). In the fourth column the auditor will enter the objective evidence for conformity collected during the audit.

How to create an IVDR quality plan

Most of the companies that are preparing for an IVDR audit by their notified body already have ISO 13485:2016 certification and they are using the self-declaration pathway for CE Marking under the IVDD. Under the IVDR, a notified body must now review and approve the technical file. The notified body must also confirm that their quality system has been updated to include the IVDR requirements. The Technical File requirements are found in Annex II and III; while most of the quality system requirements are found in the Articles.  The quality system requirements include:

  1. a risk management process in accordance with Annex I – deviations from ISO 14971:2019 will be necessary)
  2. conduct a performance evaluation–including a post-market performance follow-up (PMPF). This requirement is defined in Article 52 and Annex XIII
  3. create and maintain a technical file in accordance with Annex II & III
  4. create and maintain a Declaration of Conformity in accordance with Article 17
  5. CE Mark the product in accordance with Article 18
  6. implement a UDI system in accordance with Article 24, 26, and 28
  7. record retention requirements for the technical file, Declaration of Conformity, and certificates shall be increased from 5 years to 10 years
  8. set-up, implement, and maintain a post-market surveillance system in accordance with Article 78
  9. document a procedure for communication with Competent Authorities, Notified Bodies, Economic Operators, Customers, and/or other Stakeholders
  10. update procedures for reporting of serious incidents and field safety corrective actions in the context of vigilance to require reporting within 15 calendar days
  11. update the product labeling to comply with Annex I, section 20
  12. revise the translation procedure to ensure translations of the instructions for use are available in all required languages of the member states, and make sure these translations are available on the company website
  13. create a procedure for utilization of the Eudamed database for registration, CE Marking applications, UDI data entry, and vigilance reporting

Which IVDR requirements are already met by your quality system?

Some companies also manufacture medical devices that must comply with Regulation (EU) 2017/745. For those companies, many of the above requirements are already incorporated into their quality system. In this case, you should still include all of the IVDR checklist requirements in your plan, but you should indicate that the requirement has already been met and audited previously.

Content related to our IVDR checklist

On Friday, April 1, 2022 @ 11 am EDT (8 am Pacific), Rob Packard will be Joe Hage’s guest speaker on the weekly MDG Premium Live video (please click on the link to register). The topic of the live presentation will be “How to create an IVDR quality plan.” #MedicalDevices #MDGpremium

Posted in: CE Marking, In Vitro Diagnostic (IVD) Devices, ISO 13485:2016, ISO Auditing, ISO Certification, IVDR - Regulation (EU) 2017/746

Leave a Comment (3) →

What are the four types of risk analysis?

You are familiar with design and process risk analysis, but do you know all four types of risk analysis?

Last week’s YouTube live streaming video answered the question, “What are the four different types of risk analysis?” Everyone in the medical device industry is familiar with ISO 14971:2019 as the standard for medical device risk management, but most of us are only familiar with two or three ways to analyze risks. Most people immediately think that this is going to be a tutorial about four different tools for risk management (e.g. FMEA, Fault Tree Analysis, HAZOP, HACCP, etc.). Instead, this article is describing the four different quality system processes that need risk analysis.

What are the four different types?

The one most people are familiar with is risk analysis associated with the design of a medical device. Do you know what the other three are? The second type is process risk management where you document your risk estimation in a process risk analysis. The third type is part of the medical device software development process, specifically a software hazard analysis. Finally, the fourth type is a Use-Related Risk Analysis (URRA) which is part of your usability engineering and human factors testing. Each type of risk analysis requires different information and there are reasons why you should not combine these into one risk management document or template.

Design Risk Analysis

Design risk analysis is the first type of risk analysis we are reviewing in this article. The most common types of design risk analysis are the design failure modes and effects analysis (dFMEA) and the fault-tree analysis (FTA). The dFMEA is referred to as a bottom-up method because you being by identifying all of the possible failure modes for each component of the medical device and you work your way backward to the resulting effects of each failure mode. In contrast, the FTA is a top-down approach, because you begin with the resulting failure and work your way down to each of the potential causes of the failure. The dFMEA is typically preferred by engineers on a development team because they designed each of the components. However, during a complaint investigation, the FTA is preferred, because you will be informed of the alleged failure of the device by the complainant, but you need to investigate the complaint to determine the cause of the failure. Regardless of which risk analysis tool is used for estimating design risks, the risk management process requires that production and post-production risks be monitored. Therefore, the dFMEA or the FTA will need to be reviewed and updated as post-market data is gathered. If a change to the risk analysis is required, it may also be necessary to update the instructions for use to include new warnings or precautions to prevent use errors.

Process Risk Analysis

Process risk analysis is the second type of risk analysis. The purpose of process risk analysis is to minimize the risk of devices being manufactured incorrectly. The most common method of analyzing risks is to use a process failure modes and effects analysis (i.e. pFMEA). This method is referred to as a bottom-up method because you begin by identifying all of the possible failure modes for each manufacturing process step. Next, the effects of the process failure are identified. After you identify the effects of failure for each process step, the severity of harm is estimated. Then the probability of occurrence of harm is estimated, and the ability to detect the failure is estimated. Each of the three estimates (i.e. Severity, Occurrence, and Detectability) are multiplied to calculate a risk priority number (RPN). The resulting RPN is used to prioritize the development of risk controls for each process step.

As risk controls are implemented, the occurrence and detectability scores estimated again. This is usually where people end the pFMEA process, but to complete one cycle of the pFMEA the risk management team should document the verification of the effectiveness of the risk controls implemented. For example, if the step of the process is sterilization then documentation of effectiveness consists of a sterilization validation report. This is the last step of one cycle in the pFMEA, but the risk management process includes monitoring production and post-production risks. Therefore, as new process failures occur the pFMEA is reviewed to determine if any adjustments are needed in the estimates for severity, occurrence, or detectability. If any of the risks increase, then additional risk controls may be necessary. This process is continuously updated with production and post-production information to ensure that process risks remain acceptable.

Software Hazard Analysis

Sofware hazard analysis is becoming more important to medical devices as physical devices are integrated with hospital information systems and with the development of software as a medical device (SaMD). Software risk analysis is typically referred to as hazard analysis because it is unnecessary to estimate the probability of occurrence of harm. Instead, it is only necessary to identify hazards and estimate harm. Examples of these hazards include loss of communication, mix-up of data, loss of data, etc. For guidance on software hazard identification, IEC/TR 80002-1:2009 is a resource. FDA software validation guidance indicates that software failures are systemic in nature and the probability of occurrence cannot be determined using traditional statistical methods. Therefore, the FDA recommends that you assume that the failure will occur and estimate software risks based on the severity of the hazard resulting from the failure. 

Use-Related Risk Analysis

The fourth and final type of risk analysis is use-related risk analysis (URRA). Most development teams assume that they are able to use traditional hazard identification techniques to identify the potential use-related risks. However, use-related risks are inextricably linked to the experiences of the user. The development team has unique knowledge of the device they are developing, and therefore it is likely that use-related risks associated with a lack of knowledge about the device will result in use errors that the development team would not realize. For this reason, formative testing is necessary to identify unforeseen use-related risks. Once formative testing identifies these risks, additional formative usability testing can be used to create and refine the instructions for the use of a medical device. Finally, formative testing can be used to develop user training programs that prevent potential use errors. Once the development team has completed the necessary formative testing, then summative usability testing is used to validate the effectiveness of the risk controls that were implemented.
 
In the past, I believed that the FDA’s focus on usability was the review of summative usability testing. However, I have learned that the FDA feels it is equally important to begin the human factors testing process by first performing a use-related risk analysis and then identifying the critical tasks. Without identifying these critical tasks, it is not possible for the FDA to determine if the moderator of the summative testing has observed all of the critical tasks being performed correctly. An example of a Use-Related Risk Analysis (URRA) was provided by the FDA in a 510(k) AI deficiency letter that we received. The example is provided below.
URRA table example from the FDA 300x117 What are the four types of risk analysis? Example of a URRA Table provided by the FDA
 

Can you use only the IFU to prevent use-related risks?

Instructions for use (IFU) are required to include warnings and precautions. This information provided by the manufacturer explains how to use a medical device correctly and identifies the residual risks. This is a form of risk control, but it is the least effective form of risk control and should be the risk control of last resort. Not everyone reads the IFU, and you cannot guarantee that everyone will understand the instructions. You certainly can’t be sure that users will remember all your warnings or precautions when they are tired, stressed, or acting in an emergency situation. Design controls and protective measures should be implemented as the first and second priority for risk controls, and the IFU should be your lowest priority.
 
This is the reason why we have color-coding, design features that eliminate the possibility of a use error, we provide training to users, and we are required to monitor use-related risks for medical devices. Formative usability testing is intended to identify use errors we did not anticipate, to help us develop instructions for use (IFU), and help us develop training for users. Summative testing is intended to validate that the design, training, and IFU are effective at preventing use errors. All three of these aspects work together–not the IFU alone. In fact, there is an entire alarms standard that identifies protective measures that shall be used for electromedical devices to prevent use errors (i.e. – IEC 60601-1-8).

 

Facilitating Risk Management Activities – An Interview with Rick Stockton

I listened to our YouTube video about the four different types of risk analysis, you may have heard my reference to Rick Stockton’s interview that we posted on our YouTube channel and embedded above. In our interview with Rick Stockton, we discussed how to facilitate risk management activities during the design and development of medical devices. If you are interested in learning more about Rick and facilitating risk management activities, please watch the video of our interview with Rick.
 

Posted in: ISO 14971:2019 (Risk Management)

Leave a Comment (1) →

Feedback options for your pre-sub meeting request

This article analyzes feedback options offered for a pre-submission meeting request and gives you insight into which option is best for you.

Pre submission meeting request feedback options Feedback options for your pre sub meeting request

In 2021 the FDA published an updated guidance document about pre-submission meeting requests (i.e., pre-sub meetings). The purpose of a pre-submission meeting is to ask and obtain answers to your questions directly from the FDA. The guidance document has great advice on what to ask the FDA and what you should not ask. The best time to be asking the FDA questions is before you begin your verification and validation testing. The FDA can give you valuable feedback on your testing plan to demonstrate safety and efficacy, but if you already started your testing it’s too late. Unfortunately, the guidance document has no advice on which method of feedback to select or why.

What is the last section of your pre-sub?

The last section of your pre-submission meeting request should indicate what method of feedback you prefer and what your preferred dates are for a potential meeting with the FDA. There are three options offered for methods of feedback:

  1. a face-to-face meeting
  2. a conference call
  3. an email response

Feedback option 1 – A Face-to-Face Meeting

Some executives believe that face-to-face meetings are critical in establishing relationships with people. However, you need to understand the culture of the people your are trying to build a relationship with. The FDA is an overworked bureaucracy, and government agencies have security concerns. When the FDA meets with visitors they must go to a different building and arrange for their guests to pass through security. This is more work and takes more time. To justify the extra work and time, you need a compelling reason why a face-to-face meeting with the FDA is necessary.

Traveling to the FDA will cost your team money and time that conference calls and emails will not. More importantly, you are limited to one hour for a pre-submission meeting. One hour is barely enough time to ask questions and listen to the answers. You only have minutes to introduce your company, your team and the describe the product. There is no time for relationship building. The best way to impress the FDA is to: 1) prepare thoroughly, 2) conduct an efficient meeting, and 3) ask smart questions.

There is one time when you should visit the FDA face-to-face–if you have a powerful demonstration and video just isn’t good enough.

Feedback option 2 – Conference Call

Conference calls save you time and money, but conference calls also save the FDA time and effort. You won’t personally meet people from the agency, but you can communicate information prior to the meeting and you can provide videos of simulated use for your device. Conference calls do have the advantage of allowing you to mute the call for a moment and make a comment among your team members without the agency listening as well. Whenever you are discussing a performance testing plan or a clinical study protocol with the FDA, you will probably want a conference call to enable clarification questions.

Feedback option 3 – Email

Email responses from the FDA are highly underrated in value. When you specify an email response, you generally receive a response to your questions sooner. You also should receive more information, because each person from the agency is able to provide an hour of their time to write detailed feedback. In a conference call, you are speaking for part of the hour and only one person from the FDA can speak at a time. Therefore, you almost always have less feedback during conference calls and face-to-face meetings. The primary downside to email as a feedback method is that it is not interactive.

Update Related to Covid-19 Pandemic

The FDA is not allowing face-to-face meetings during the Covid-19 pandemic. Three of the pre-subs Medical Device Academy submitted during the pandemic were rejected by the FDA due to insufficient FDA resources. We are also noticing increased delays in the pre-sub timeline. Two pre-subs had a 5-month scheduling lead-time instead of 60-75 days. Due to these delays, we have advised many clients to skip the presub if testing requirements are well defined in guidance documents and predicate 510k summaries. Althought the email option should theoretically result in a faster response from the FDA, during the pandemic we have actually seen that the teleconference options has been faster. My theory is that the teleconferences are require coordinating the schedules of multiple people, and therefore there is more focus by lead reviewers in making sure the feedback is provided in time for the scheduled teleconference. 

Which feedback option will you pick?

Regardless of which feedback method you choose, you can always follow-up with supplemental questions and obtain additional feedback from the FDA after you receive the initial response to your pre-submission meeting request. If you are planning a clinical study, you might seek interactive feedback in a conference call during the pre-submission meeting. Then you can follow-up with a clinical study protocol as a supplement to obtain additional feedback from the FDA.

Additional Resources

If you are interested in learning more about a pre-submission meeting request to the FDA, consider watching and listening to a webinar on the topic.

Posted in: 510(k)

Leave a Comment (1) →

How to find updated FDA forms for a 510k

Before you complete FDA forms for your 510k submission, you need to made sure you have the most updated FDA forms.

How do you know if the FDA form you are using is current?

The FDA assigns numbers to each FDA form and the document control number is found in the bottom left footer of the document. In addition, the top right-hand header of the document will have an expiration date for the form (see the picture below). Often the changes to FDA forms are minor, but you should only submit the current version of the FDA form which has not expired.

FDA Form 3881 screen capture How to find updated FDA forms for a 510k

What happens if you are using an expired FDA form?

In the past, if you included an obsolete document in your submission the FDA would often ignore this an proceed with the review of your submission anyway. Now FDA reviewers will identify the obsolete form and require you to resubmit the document on the current version of the form. If the reviewer is conducting an initial Refusal to Accept (RTA) screening, and one of the required items in the RTA screening are identified, then you will receive an RTA Hold letter and the RTA checklist will include a comment that you have used an obsolete version of an FDA Form.

If there are no deficiencies identified in the RTA checklist, the reviewer may still send you an email asking you to submit the document on the correct form. This could be a formal amendment (e.g. K123456/A001) or it could be as an informal email of the corrected document. This type of request could also be identified after the substantive review is complete in the form of a comment in an Additional Information (AI) Request or as part of an Interactive Review Request. An AI Request must be responded to with a formal supplement submitted to the Document Control Center (DCC) as a supplement to the original submission (e.g. K123456/S001) or as an informal ammendment submitted by email.

Examples of updated FDA forms for your 510k submission

Expired forms are frequently submitted to the FDA because submitters are using templates that have not been properly maintained or the submitter modified a form that was submitted in a previous 510k submission. The most common examples include: FDA Form 3514 (i.e. Submission Coversheet), FDA Form 3881 (i.e. Indications for Use), and the RTA Checklist.

Where can you find updated FDA forms?

Recently one of our clients noticed that the 510k template folder we share with people that have purchased our 510k course included obsolete templates for Financial Disclosure. There are three financial disclosure forms that can be used for a 510k submission or De Novo Classification Request:

  1. FDA Form 3454, Certification: Financial Interest and Arrangements of Clinical Investigator (PDF)
  2. FDA Form 3455, Disclosure: Financial Interest and Arrangements of Clinical Investigators (PDF)
  3. FDA Form 3674, Certification of Compliance, under 42 U.S.C. , 282(j)(5)(B), with Requirements of ClinicalTrials.gov (PDF)

We normally update these FDA forms as soon as the new form is released, but this financial disclosure forms are only used in about 10-15% of 510k submissions.

The current version of most FDA forms can usually be found by simply conducting an internet search for the form using your favorite browser. However, sometimes you may find a copy of the document that was editted by a consultant to facilitate completion of the document as an unsecured PDF or Word document. Although this is convenient, you should not use these “bastardized” forms. You should use the original secured form provided by the FDA. These native forms require Adobe Acrobat to complete the form and save the content. The most current version of the FDA form can be found using the FDA’s Form search tool.

Editing and Signing FDA Forms

Most of the FDA forms are secured and you can only enter information in specific locations. If there is a location for a signature, usually the signature cannot be added in Adobe to the secured form. In these situations, our team will save the document as a “Microsoft Print PDF” format. Once the document has been saved in this “non-native” format, you can manipulate almost anything in the document. Then we will add signatures using the “Fill and Sign” tool in Adobe Acrobat or we will use the “Edit” tool. Editing also gives us ability to make corrections when the document has incorrect information filled in the form somewhere.

Another option for adding dates and signatures is for you to save the document as a non-secure PDF. Then using an electronic signature software tool like Docusign, you can request that another person add their electronic signature or you can add your own electronic signature. Some companies prefer to do this to ensure the electronic signature meets 21 CFR Part 11 requirements, but the FDA accepts scanned images of a signature that was added to the document without certification in a 510k submission. This is even true for the Truthful and Accuracy Statement for a 510k. That document can be attached as a PDF in an FDA eSTAR template or you can electronically sign the eSTAR template if the person preparing the eSTAR is also the person signing the Truthful and Accuracy Statement.

Tips and Tricks for maintaining templates

Our company is a consulting firm, and we do not have a formal document control process that would be typical of our clients. However, we do have a shared Dropbox folder where we maintain the most current version of 510k templates. Any obsolete versions we move to an archive folder. However, there are ways to improve this informal system. You can include a date of the document in the file name. For example, “Vol 4 001_Indications for Use (FDA Form 3881) rvp 2-7-2022.” This indicates that this file is the FDA Form 3881 which is the indications for use form used in Volume 4 of the 510k submission. The document is the first document in that volume. The date the form was revised and saved is February 7, 2022 and the author’s initials are “rvp.”

If you are saving 510k templates you might consider adding an expiration date to the file name. For example, “Vol 4 001_Indications for Use (FDA Form 3881) exp 06-30-2023.” This file name indicates that the form’s expiration date is June 30, 2023. The inclusion of an expiration date in the file name is a visual reminder of when you will need to search for an updated FDA form.

A third way to manage your FDA Forms is to include them in your documents of external origin. ISO 13485:2016, Clause 4.2.4, requires that you maintain control of documents of external origin. Therefore, if your company has a formal quality system, a list or log of documents of external origin is the best way to manage FDA forms. Your log should indicate the date the updated FDA form was created, any parent guidance documents should be cross-referenced, and the expiration date of the FDA form should be identified. By using a log of this type, you can sort the list by expiration date or by the date of creation if there is no expiration date identified. Sorting the list will help your team prioritize which documents need to be reviewed next for new and revised versions.

Additional 510k submission resources

The FDA will be updating the 510k guidance for the new FDA eSTAR template by September 2022. Medical Device Academy will be systematically updating all of our templates and training webinars related to preparation of 510k submissions. We will also be preparing for the transition from FDA eCopy submissions to electronic submissions via a Webtrader Account.

You can keep up-to-date on template revisions in one of two ways:

  1. Purchase our 510k course, and you will receive access to the updated templates as they are created. We will send email notifications each time a template is updated.
  2. Register for our New Blog email subscription for automated email notifications of when a new blog is released about updated FDA forms, templates, and webinars.
  3. Register for our New Webinar email subscription for automated email notifications of when a new or revised webinar is scheduled and for email notification of our newest live streaming YouTube videos.

Posted in: 510(k)

Leave a Comment (0) →

Individual process audits or one full quality system audit, which is better?

You can conduct multiple individual process audits or you can conduct one full quality system audit, but which solution is better?

What are individual process audits?

There are 25 processes that require procedures for compliance with the US FDA quality system regulations and ISO 13485:2016 has 28 required procedures. Individual process audits focus on one of these procedures, the process it controls, the equipment and software used by that process, the work environment where the process is performed, the people responsible for the process, the records resulting from that process, and any metrics or quality objectives associated with that process. An individual process audit can be completed in remotely or on-site, and these audits will be much shorter in duration than a full quality system audit. Another way to think of an individual process audit is to realize that a full quality system audit is comprised of many individual process audits scheduled back-to-back. Auditing one process might be as short in duration as 30 minutes (e.g. control of records) but individual process audits can take as long as four hours (e.g. design controls and technical file audits).

What is a full quality system audit?

A full quality system audit is typically a single audit conducted annually to address all the requirements for conducting an internal audit of your quality system. In this type of audit, all of the procedures and processes should be covered. Therefore, full quality system audits are necessarily longer. If the person assigned to conduct the full quality system audit is an employee, that person cannot audit their own work. This can be addressed in two ways: 1) the audit can be a team audit, and the other team members can audit areas the lead auditor was responsible for; and 2) the process(es) that the lead auditor is responsible for can be audited as individual process audits by another auditor at another time.

If the person assigned to conduct the full quality system audit is a consultant from outside the company, there is still potential for conflicts regarding independence. If the consultant audited the company in the previous year, then the auditor cannot audit last year’s internal audit. In our consulting firm we address this issue in two ways: 1) we rotate who is assigned to audits so that the same auditor does not conduct a full quality system audit two years in a row, or 2) we assign another auditor in our company to conduct the audit of internal auditing as a team member.

How do you evaluate auditing effectiveness?

Some companies perceive that auditing is a necessary evil and they want to put as little effort and resources into the audit as possible. In this situation, auditing might be evaluated based upon whether it was completed on-time, by how much the audit cost the company, and the fewer nonconformities identified the better the perceived outcome. This perspective typically results in a single full quality system audit that is three days in duration or shorter if an auditor can manage to complete the audit in less time. Of course the shorter the audit is, the fewer records that an auditor has time to review. Therefore, shorter audits typically have fewer findings and management is pleased at the outcome because the audit required fewer resources and had little or no nonconformities.

The better approach is to look at auditing as a method for identifying areas that need improvement. Identifying areas where your quality system needs improvement is the intent of requiring internal audits. Therefore, the amount of time your company allocates to auditing should reflect the benefits for improvement that are identified. Top management of your company needs to identify which process areas they feel needs improvement. Only then can the audit program manager design an audit schedule that will focus on identifying opportunities for improvement and nonconformities in the process areas where management feels improvement is most needed. Ideally, this approach to auditing will focus on looking for inefficiency and metrics with negative trends. These findings result in preventive actions instead of corrective actions, because the process is not yet nonconforming. In general, the more opportunities for CAPAs that are identified the more valuable the audit was.

What advantages do one full quality system audit present?

Sometimes a single full quality system audit is easier to schedule, because it is only once per year. The rest of the year your company will not need to spend much time discussing audits or even thinking about them. If your company perceives audits as a necessary evil, then the less disruption caused by scheduling an audit the better.

Another advantage of conducting full quality system audits is that you can more easily afford to use external consultant auditors, because the travel costs for auditing are limited to one trip per year. If you had more than twenty individual process audits each year, and external consultant auditors conducted all of the audits, then you would have to pay for travel costs twenty times each year. Unless the consultant lives locally, these travel costs can be substantial.

What advantages exist for individual process audits?

Individual process audits are much easier for the auditor to complete within the time established in the audit agenda, because the auditor does not have another audit process immediately proceeding or immediately after the process they are auditing. There are also fewer people that need to attend an opening or closing meeting for an individual process audit, because only one process is being audited. Managers from other departments are seldom needed for participation in the opening or closing meeting.  The combined benefits result in the auditor being more likely to start the opening meeting on-time and to start the closing meeting on-time.

The shorter duration of individual process audits is also an advantage. There are very few times in a year when none of your department managers will be traveling, sick, or on vacation. These rare weeks only happen a few times each year, and sometimes auditors must proceed with an audit even if someone is absent because they have no alternative. If you are preparing for an audit remotely, you face-to-face audit time is only 90 minutes, and your report writing time is also conducted remotely, then finding 90-minutes of available time in an department manager’s schedule is usually quite easy.

Can both approaches to internal audit scheduling coexist?

You can combine both approaches to audit scheduling in several possible ways. First you can schedule one full quality system audit each year in order to make sure that the minimum audit requirements are met, and then top management can review the results of the full quality system audit to decide which processes would benefit from individual process audits.

A second strategy would include conducting individual process audits for each process that resulted in a nonconformity during 3rd party certification audits or during the one full quality system audit. In this scenario, you might have a 3rd party audit in November, a full quality system audit in May, and top management might select 10 other individual processes to audit during the other 10 months of the year.

A third strategy would be to alternate between individual process audits and single full quality system audits each year. During “odd” years the audit program manager would only schedule one full quality system audit, and during “even” years the audit program manager would schedule multiple individual process audits.

A fourth strategy would be for top management to select a few processes that they would like the audit program manager to focus on with individual process audits, and all of the remaining processes would be incorporated into a single audit that covers the remaining 70% of the quality system.

Each of these four strategies for combining the two approaches to audit scheduling is viable and may result in multiple opportunities for improvement being identified. There is no regulation that favors one approach over another, but all four strategies require more time an effort on the part of the audit program manager and top management to discuss and plan the annual audit schedule.

Next steps if you would like to try individual process audits

If your company has always scheduled a single full quality system audit each year, you can test the concept of conducting an individual process audit by selecting just one process to audit. The best choice for this approach is to pick a process that has one or more CAPAs that are in progress or to select a process that top management feels is performing efficiently. The more frustration that top management experiences with a process, the greater the need is to identify opportunities for improvement. If the company has not already identified CAPAs to initiate for that process, you might just need an outsider to state the obvious: “I think we need a CAPA in this department.” The outsider might be a consultant, but it could also be a person from another department. If you would like a quote for an individual process audit, please visit our audit quote webpage.

About the Author

Rob Packard 150x150 Individual process audits or one full quality system audit, which is better?

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

Posted in: ISO Auditing

Leave a Comment (1) →

eSTAR draft guidance is here, and wicked eSubmitter is dead.

I hated the the FDA eSubmitter template which was discontinued May 30, 2021. Finally we have eSTAR draft guidance for the new eSTAR template.

eSTAR draft guidance button eSTAR draft guidance is here, and wicked eSubmitter is dead.

History of 510k electronic submissions

The FDA has experimented with a multitude of pilot 510k submission programs over the years to streamline and improve the 510k submission content, formatting, and to facilitate a faster review process. The Turbo 510k program was one of the first successful pilot programs. In 2012 I wrote one of my first blogs about how to improve the 510k process. In September 2018, the FDA launched the “Quality in 510k Review Program Pilot” for certain devices using the eSubmitter electronic submission template. The goal of the this pilot program was to enable electronic submissions instead of requiring manufacturers to deliver USB flash drives to the FDA Document Control Center (DCC). I hated the eSubmitter template, and the FDA finally discontinued availability of the eSubmitter template on May 30, 2021. During the past 15 years, the FDA gradually streamlined the eCopy process too. Originally we had to submit one complete hardcopy, averaging 1,200 pages per submission, and one CD containing an electronic “eCopy.” Today, the current process involves a single USB flash drive and a 2-page printed cover letter, but today’s eCopy must still be shipped by mail or courier to the DCC.

eSTAR Pilot Program is Launched

During the 15-year evolution of the FDA eCopy, CDRH was trying to develop a reliable process for electronic submissions of a 510k. CBER, the biologics division of the FDA, has already eliminated the submission of eCopy submissions and now 100% of biologics submissions must be submitted through an electronic submissions gateway (ESG). In February 2020, CDRH launched a new and improved 510k template through the electronic Submission Template And Resource (eSTAR) Pilot Program. The eSTAR templates include benefits of the deceased eSubmitter template, but CDRH has incorporated additional benefits:

  • the templates use Adobe Acrobat Pro instead of a proprietary application requiring training;
  • support for images and messages with hyperlinks;
  • support for creation of Supplements and Amendments;
  • availability for use on mobile devices as a dynamic PDF;
  • ability to add comments to the PDF; and
  • the content and logic mirrors checklists used by CDRH reviewers.

Medical Device Academy’s experience with the eSTAR Templates

Every time the FDA has released a new template for electronic submissions we have obtained a copy and tried populating the template with content from one of our 510k submissions. Unfortunately, all of the templates have been slower to populate that the Word document templates that our company uses every day. On May 16 we conducted an internal training for our team on the eSTAR submission templates, and we published that training as a YouTube Video (see embedded video below). Then nine days later the FDA released updates to the eSTAR templates (version 0.7). The new eSTAR templates are available for non-IVD and IVD products (ver 0.7 updated May 27, 2021).

Sharon Morrow submitted our first eSTAR template to the FDA in August and we experienced no delays with the 510k submission during the initial uploading to the CDHR database, there was no RTA screening process, and CDRH did not identify any issues during their technical screening process. Shoron’s first eSTAR submission is now in interactive review, which is a better outcome than 95%+ of our 510k submissions. I have several other eSTAR submissions that are almost ready to submit as well. The other 510k consultants on our team are also working on their first eSTAR submissions.

Finally the CDRH releases an FDA eSTAR draft guidance

On September 29, 2021 the FDA released the new eSTAR draft Guidance for 510k submissions. This is a huge milestone because there have not been any draft guidance documents created for pilot programs. The draft indicates that the comment period will last 60 days (i.e. until November 28, 2021). However, the draft also states that the guidance will not be finalized until a date for requiring electronic submissions (i.e. submission via an ESG) is identified. The draft indicates that this will be no later than September 30, 2022. Once the guidance is finalized, there will be a transition period of at least one year where companies may submit via an ESG or by physical delivery to the FDA DCC.

Are there any new format or content requirements in the FDA eSTAR draft guidance?

There are no new format or content requirements in the eSTAR draft guidance, but the eSTAR template itself has several text boxes that must be filled in with summary information that is not specified in the guidance for format and content of a 510k. The information requested for the text boxes is a brief summary of non-confidential information contained in the attachments of the submission. Therefore, these boxes can information that would normally be in the overview summary documentst that are typically included at the beginning of each section of a 510k. If your overview documents do not already have this information, then you may have some additional work to do in order to complete the eSTAR templates. An example of one of these text boxes is provided below:

Summary of electrical mechanical and thermal testing eSTAR draft guidance is here, and wicked eSubmitter is dead.

Another example of additional content required by the eSTAR templates is references to page numbers. Normally the FDA reviewer has to search the submission for information that is required in their regulatory review checklist. In the new templates the submitter is now asked to enter the page numbers of each attachment where specific information can be found. The following is an example of this type of request for a symbols glossary:

Reference to symbols glossary in labeling eSTAR draft guidance is here, and wicked eSubmitter is dead.

Are there any changes to the review timelines for a 510k in the eSTAR draft guidance?

The eSTAR draft guidance indicates that a technical screening will be completed in 15 calendar days instead of conducting a RTA screening. I believe that the technical screening is less challenging than the RTA screening, but the FDA has not released a draft of the technical screening criteria or a draft checklist. I would imagine that the intent was to streamline the process and reduce the workload of reviewers performing a technical screening, but we only have guesses regarding the substance of the technical review and so far our performance is 100% passing (i.e. 1 of 1). The next step in the 510k review process is a substantive review. Timelines for the substantive review are not even mentioned in the new draft guidance, but the FDA usually has the review clock details in Table 1 (MDUFA III performance goals) and Table 2 (MDUFA IV performance goals) of the FDA guidance specific to “Effect on FDA Review Clock and Goals.” In both tables, the goal is 60 calendar days, and our first eSTAR submission completed the substantive review in 60 days successfully. The 180-day deadline for responding to an additional information (AI) request has not changed in the eSTAR draft guidance, but our first submission is now interactive review. I believe this suggests that companies may have a higher likelihood of having an interactive review with their CDRH lead reviewer instead of being placed upon AI Hold, but we won’t have enough submissions reviewed by the FDA to be sure until the end of Q1 2022.

Register for our new webinar on the FDA eSTAR draft guidance

We hosted a live webinar on Thursday, October 21, 2021 @ Noon EDT. The webinar was approximatley 37 minutes in duration. In this webinar we shared the lessons learned from our initial work with the eSTAR template. Anyone that registers for our webinar will also receive a copy of our table of contents template that we updated for use with the eSTAR templates. Unlike a 510k eCopy, an eSTAR template does not require a table of contents but we still use a table of contents to communicate the status of the 510(k) project with our clients. Finally, we reviewed the eSTAR draft guidance in detail. If you would like to receive our new eSTAR table of content template and an invitation to our live webinar, please complete the registration form below.

About the Author

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

Posted in: 510(k), eSTAR

Leave a Comment (3) →
Page 3 of 26 12345...»