Available Now: Complimentary eSTAR Office Hours with our experts

Available Now: Complimentary eSTAR Office Hours with our experts

Available Now: Complimentary eSTAR Office Hours with our experts

Available Now: Complimentary eSTAR Office Hours with our experts

510(k)

How to Document Risk in your 510(k)

510(k)

How to Document Risk in your 510(k)

510(k)

How to Document Risk in your 510(k)

510(k)

How to Document Risk in your 510(k)

You can document Risk in a 510(k) by comparing subject device with one or more similar legally marketed devices to support substantial equivalency claims. To legally market your medical device, you need to demonstrate it is as safe and effective as any other legally marketed product that is not subject to PMA (21 CFR 807.92(a)(3)).

The blog describes key factors for documenting risk management in 510(k) submissions. Here is a list of questions we should understand:

  • What is a predicate device and how to claim substantial equivalence to a proposed device?

  • Types of devices needing risk management for 510(k) submissions?

  • Risk management requirements for a Traditional 510(k)?

  • Where can one find 510(k) risk management requirements?

  • How can manufacturers demonstrate device safety?

  • Key factors for documenting risks before submitting 510(k)?

  • Contents of software related documentation?

  • What are the contents of risk related documentation?

 

Using Substantial equivalence to demonstrate risk management in the 510(k) submission. 

A predicate device is a legally marketed device subjected to premarket approval. We can demonstrate Substantial Equivalence by comparing the applicant’s device to a cleared predicate device, if:

  • it was cleared through the 510(k) process

  • it was legally marketed prior to May 28, 1976 (pre-amendments device)

  • it was originally on the U.S. market as a Class III device (Premarket approval) and later down-classified to Class II or I

  • it is a 510(k)-exempt device

We can demonstrate substantial equivalence if predicate device has:

  • The same intended use as the predicate; and

    • the same technological characteristics as the predicate

  • The same intended use as the predicate; and

    • different technological characteristics and the information submitted to FDA and

    • does not raise new questions of safety and effectiveness; and

    • demonstrates that the device is at least as safe and effective as the legally marketed device.

  • Same technical characteristics can be:

    • The design

    • Energy used or delivered

    • Materials of construction

    • Performance

    • Safety

    • Effectiveness

    • Labeling

    • Biocompatibility

    • Environmental conditions

    • Storage/ transport

    • operating

If the new device has some different technological characteristics the differences must not raise questions of safety or effectiveness when you’re testing the device as safe and effective as the predicate device. However, if testing is done in accordance with FDA recognized standard then certificate of compliance to that standard is sufficient for the submission, and global test information or test data is not required.

A simple way to show substantial equivalence is to create a comparison table including: 

  • Technological specifications mentioned below:

    • Intended use, Indications for use

    • Target population, Anatomical sites, where used (hospital, home, etc.)

    • Energy used and/or delivered

    • Human factors, Design, Performance, Standards met, Materials, Biocompatibility, Compatibility with environment and other devices

    • Sterility, Electrical safety, Mechanical safety, Chemical safety, Thermal safety, Radiation safety

  • A Narrative discussing similarities and differences between new and predicate device


Devices requiring risk management for 510(k) submission.

  • Risk management requirements are only for devices that contain software.

  • Abbreviated 510(k)s generally require declarations of conformity and risk management documents

Risk management requirements for a Traditional 510(k). 

Only embedded software, driven by or standalone software and devices with software component must include Hazard Identification and Risk Assessment in 510(k)s.

When there is insufficient information to create general controls, special controls provide reasonable assurance of safety and effectiveness. It assures FDA that hazards related to device development process were subject to controls and mitigations.

You should include Risk Control Verification and Validation requirements under

  • Packaging Validation
    • Sterilization Validation
    • Biocompatibility
    • Software Verification Validation
    • Electrical Safety and EMC
    • Bench/Pre-Clinical Performance Testing
    • Animal Performance Testing
    • Clinical Performance Testing

Risks to Users and Patients are addressed in the Instructions for Use (IFU) as warnings, contraindications, and precautions (typically because of usability studies and hazard analysis).

Risk-Benefit Analysis is required in Special 510(k)s, De Novo applications, Humanitarian Device Exemptions, and PMAs. It is not required for traditional 510(k).

Where can one find 510(k) risk management requirements?

Design validation-software validation and risk analysis (21 CFR 820.30) FDA and EU CE Marking compliance- recognize ISO 14971 standard:

  • FDA recognizes ISO 14971:2019

  • EU recognizes EN ISO 14971:2019 (differences include omission of Annexes, decoupling of standards to MDR regs),

Best practices to address risks in 510(k) submissions

  • Look for appropriate Special Controls Guidance Docs in the FDA Guidance Document

  • Use Guidance Documents for Controls and Risk Management Requirements

  • Examine the guidance and determine which standards, testing, and hazard/risk analyses are appropriate.

  • Ensure extensive testing

How to demonstrate device safety?

The GHTF/SG1-N11:2008 in 10.0 Risk Analysis and Control Summary states that “The STED [Summary Technical Documentation] should contain a summary of the risks identified during the risk analysis process and how these risks have been controlled to an acceptable level. Preferably, this risk analysis should be based on recognized standards and be part of the manufacturer’s risk management plan.”

Factors to consider regarding risks before submitting 510(k)?

Human factors:

“Medical device manufacturers are required to follow FDA’s Human Factors guidance and regulations to help ensure safe use of these devices.” – CDRH website

Recognized standards include ISO 14971 risk management standard, IEC 62366 (joint ISO/IEC standard applying to all devices), IEC 60601-1-6 and AAMI HE75. To comply with standards,

  • Manufacturers will have to develop usability specifications for devices

  • Manufacturers should explore usability issues as part of the risk management process in compliance with standards

  • Include Usability evaluations as part of design validations

The FDA requires a summary of these actions as part of a human factors dossier while submitting pre-market information, which is explained in detail below:

  • Description of device user interface

  • Description of user interaction with UI (use scenarios)

    • Device, Training, Labeling, IFU

  • intended users, uses, use environments and training

  • Summary of known use problems from:

    • Predecessor devices

    • Similar devices

  • Analysis of hazards and risks associated with the use of the device

  • Summary of preliminary analyses and evaluations

  • Description and categorization of critical tasks

  • Details of human factors validation testing

    • Description of test participants (minimum of 15 in each user population)

    • Description of test scenarios

    • Moderator guideline

    • Training offered

    • Test results

    • Test results summary

  • Conclusion

 

Content of Software-related risk documentation.

In the 510(k) submission, medical device manufacturers must:

  • show they identified hazards appropriately and managed risks effectively and

  • provide traceability to link design, implementation, testing, and risk management.

The following information is picked from the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 11, 2005

Device Hazard Analysis: Tabular description of identified hardware and software hazards, including severity assessment and mitigations.

Traceability Analysis: Traceability among requirements, specifications, identified hazards and mitigations, and Verification and Validation testing.

When performing a hazard analysis, it is recommended that you address all foreseeable hazards, including those resulting from intentional or inadvertent misuse of the device.

The risk documentation for software can be in the form of an extract of the software-related items from a comprehensive risk management document, such as the Risk Management Summary described in ISO 14971. In this format, each line item should include:

  • identification of the hazardous event

  • the severity of the hazard i.e., level of concern

  • cause(s) of the hazard i.e., device Hazard analysis

  • method of control (e.g., alarm, hardware design)

  • corrective measures taken, including an explanation of the aspects of the device design/requirements, that eliminate, reduce, or warn of a hazardous event; and

  • verification that the method of control was implemented correctly.

  • Software Description

  • Software Requirements Specification (SRS)

  • Architecture Design Chart

  • Software Design Specification (SDS)

  • Traceability Analysis

  • Software Development Environment Description

  • Configuration management & maintenance plan

  • Verification/ validation Documentation

  • Revision Level History

  • Unresolved anomalies

  • Impact on safety or effectiveness discussion

  • Rationale for accepting

It is recommended to base your estimation of risk for your Software Device on the severity of the hazard resulting from failure, assuming that the failure will occur. You need to use risk identification and control techniques described in consensus standards such as ISO 14971.

Documenting risk in 510(k)

After analyzing the previous material, it is evident that ISO 14971 has identified a method for providing the information necessary by the FDA, namely the traceability summary required in Clause 3.5 of the risk management file.

The information can be provided in a document that is displayed in the GHTF guidance, GHTF/SG3/N15R8 Implementation of risk management principles and activities within a Quality Management System Annex C.  

Example of Risk Management Summary Table 

Risk Traceability Summary

You can add a column with reference to the source document listing each hazard and additional information to improve the use of Risk Traceability Summary, for example:

  • A Human Factors or Usability study that identifies hazards

  • A standard that identifies a hazard and possibly a risk control method

  • MAUDE database identified hazard from predicate device

  • Complaint file from previous similar product

Risk Information in 510(k)

Provide a copy of the Risk Chart, which specifies the Risk Acceptability levels for the product in the submission, and include copies of the definitions of Severity Levels and the Probability of Occurrence Levels.

Take care of probability levels to ensure there is evidence to support the quantified levels and the ranges do not overlap.

Risk chart communicating risk management activities

Conclusion

Managing 510(k) is a tedious process, requiring data from various teams and several elements of test strategy. However, you can still navigate the process of organizing all the data in a simple yet comprehensive manner. It is important to remember that FDA reviewers can only review so much detail, and therefore randomly put together irrelevant data can cause delays in receiving approval. Therefore too much information can negatively impact 510(k) review timelines. It is a manufacturer’s responsibility to submit data accurately and present it in an easily comprehensible format. FDA can have many questions after the application is submitted, and they need to be responded promptly by going back to the source of data and responding to FDA to compress your approval cycle.

Leveraging Regulatory Management Technology (RIM) to build your medical device technical files and 510(k) submissions will help you avoid inconsistency, maintain clarity for managing submission requirements helping you streamline only those processes and parts of of section of your document that need additional detail.

About Essenvia

Essenvia is a regulatory lifecycle management solution to help you optimize the entire regulatory operations process. Our Regulatory Management Software solutions include an innovative approach to building your pre-market submissions like 510(k) and MDR/ IVDR as well as post-market submissions like Regulatory Change Assessment and Post Market Surveillance. Our solution reduces errors, streamlines regulatory process, and guarantees faster regulatory clearance for your medical device.

Schedule a demo now to find out how Essenvia can help you with your regulatory submissions.

Related Articles