Blog

Author Archive

510k Design Control Requirements and 510k Risk Management Requirements

This article reviews 510k design control and risk management requirements when compared with your design history file (DHF) and your risk management file.

Design Controls and Risk Management 510k Design Control Requirements and 510k Risk Management Requirements

Last week I presented a free webinar on how to combine Risk Management with Design Controls, when planning to submit a 510k. There were many questions about what design history file (DHF) and risk management file (RMF) documents are required for a 510k. There is no specific part of the the regulations stating what the 510k design control requirements are. However, certain elements of the DHF are required as 510k design control documentation, but not necessarily in the exact form as maintained in the DHF. For example, Design Inputs and Design Outputs are presented as applicable recognized standards and design specifications, while others will remain exactly the same (i.e., verification and validation test reports).

For Risk Management, the only submissions that require inclusion of risk documentation are devices containing software of at least moderate level risk. There are some exceptions to this as well though, based on a few special control guidance documents—especially when the submission type is an abbreviated 510k. This is article identifies which of the DHF and RMF elements are 510k design control requirements and 510k risk management requirements.

510k Design Control Requirements

Design Controls are identified in 21 CFR 820.30. Every manufacturer of any class II or class III devices, and certain class I devices (class I devices with software, tracheobronchial suction catheters, surgeon gloves, protective restraints, radionuclide applicators, radionuclide teletherapy devices) need to control design per this regulation. The requirement for a Design History File is item j) and states:

“Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.”

The “requirements of this part” refers to the other bullets in 21 CFR 820.30 which can be summarized as:

a) Establish and maintain procedures to control design of device.

b) Design and Development Planning – Each manufacturer shall establish a plan that describes the design and development activities, and defines responsibilities for implementation.

c) Design Inputs – Manufacturers need to ensure design requirements relating to a device are appropriate and address the intended use of the device.

d) Design Outputs – Design outputs need to be documented in terms that allow an adequate evaluation of conformance to design input requirements. Design outputs that are essential for the proper functioning of the device should be identified.

e) Design Review – Formal documented reviews of design results should be planned and conducted at appropriate stages of device development.

f) Design Verification – Design verification confirms that the design output meets the design inputs requirements.

g) Design Validation – Design validation shall be performed under defined operating conditions on initial production units or their equivalents, and shall ensure that devices conform to defined user needs and meet the intended use of the device.

h) Design Transfer – Design transfer documentation shall ensure that the device design is correctly translated into production specifications.

i) Design Changes – changes should be identified, documented, validated/verified, reviewed and approved before their implementation.

The Design History File is intended to be a repository of the records required to demonstrate compliance with your design plan and design control procedures. While companies are required to create, and maintain this documentation according to the FDA regulation, not all of the documentation will be reviewed as part of the 510k. The following table compares the elements that comprise a DHF with the 510k design control requirements.

DHF Element 510k Design Control Requirements
Design Plan Not Required
User Needs Not Required
Design Inputs

Cover Sheet (Section 1) and

Declaration of Conformity (Section 9)

 

Some design inputs will appear in the form of standards in FDA Form 3514 (Cover Sheet) and in the Declaration of Conformity FDA Form 3654 (Standards Data Report)

Design Outputs

Device Description (Section 11)

 

The Device Description lists the specifications of the device, and your Design Outputs document will help populate the Device Description. This can include drawings, pictures, or written specifications that describe your device.

Labeling

Proposed Labeling (Section 13)

The labeling is usually considered part of the Design Outputs within the DHF, and is included specifically in the labeling section of the 510(k) submission. This includes both the Instructions for Use and any Package Labeling.

Verification and Validation Protocols

Not Required

 

You do not have to include the protocols, but the reviewer may ask to see them if they have any questions when reviewing the reports.

Verification and Validation Reports

Sterilization (Section 14)

Biocompatibility (Section 15)

Software (Section 16)

Electrical Safety and EMC (Section 17)

Bench Performance Testing (Section 18)

Animal Performance Testing (Section 19)

Clinical Performance Testing (Section 20)

 

Of course, not all of these sections will be applicable for every device, but you should include all relevant validation test reports within your submission in the appropriate section of the 510k. Typically, each of these sections will have a cover sheet that outlines the reports that are included within the section, and then you can just include the report from the DHF in its entirety behind the cover sheet in that section.

Process Validation Only required for sterilization validation typically, but there are exceptions for novel materials and coatings
Work Instructions Not Required for 510k
Design Review Meeting Minutes Not Required for 510k
Design Trace Matrix Only required for software
Risk Management File Sometimes – See Risk Management File Table Below
Post-Market Surveillance Plan Not Required, but a few exceptions for high risk devices
Clinical Data Summary Required only if used to demonstrate safety and efficacy
Regulatory Approval Will result from 510k Clearance, so nothing to be included in 510k submission.

510k Risk Management Requirements

Regarding the FDA regulations for risk management, there is a requirement under the Design Validation section of 21 CFR 820.30 that states:

“Design validation shall include software validation and risk analysis, where appropriate.”

For the purposes of FDA compliance and CE Marking, both recognize ISO 14971 as the standard for risk management. FDA recognizes ISO 14971:2007 whereas EN ISO 14971:2012 is the European National version for CE Marking. Rob Packard wrote an article describing the contents of the risk management file as well as the specific differences in the requirements between the FDA and CE Marking with regard to ISO 14971.

For the purposes of your 510k submission, the FDA only requires risk management documentation to be included if the product contains software and the risk is at least a level of “moderate concern”. There are some other cases when risk management is required by special controls guidance documents, but even when it is required you only have to submit your risk analysis. The table below describes the risk management requirements in greater detail.

RMF Element 510k Risk Management Requirement
Risk Management Plan Not Required
Hazard Identification

510ks with Software Only (Section 16)

 

Hazard Identification is only required for devices that have a software component. It is not required for most other devices.

Risk Assessment

510(k)s with Software (Section 16)

Certain Special Controls Guidance

 

The Risk Assessment is only required to be included if your device contains software, or if a special controls guidance document specifically requires risk assessment. It is not required for other 510ks.

Risk Control Option Analysis Software and Certain Special Controls Guidance
Risk Control Verification and Validation

Sterilization (Section 14)

Biocompatibility (Section 15)

Software (Section 16)

Electrical Safety and EMC (Section 17)

Bench Performance Testing (Section 18)

Animal Performance Testing (Section 19)

Clinical Performance Testing (Section 20)

 

This will not be any additional or special documentation specific to Risk Management, and was already included in the DHF breakdown above, but the verification and validation also relate back to risk management in ensuring that the risks have been adequately mitigated.

Risk Benefit Analysis

Not Required for 510(k)

 

Risk Benefit analyses are only required for De Novo applications, Humanitarian Device Exemptions and PMAs.

Informing Users and Patients of Risks

Labeling (Section 13)

 

Part of the risk management will appear in the Labeling section of the 510k as warnings, contraindications, and precautions within the Instructions for Use and Package Labeling.

Risk Management Report Not Required

Your first step in preparing your 510k submission is to search the FDA Guidance Document Database to determine if there is an applicable guidance document for your device. You can read another blog we wrote to explain Special Controls Guidance documents, and how to determine if one is applicable to your device. The following list provides examples of Class II Special Controls Guidance documents that require risk analysis to be included within the 510k:

When there are 510k risk management requirements, the special controls guidance document will typically state, “We recommend that the summary report contain:

An identification of the Risk Analysis method(s) used to assess the risk profile in general as well as the specific device’s design and the results of this analysis. (Refer to Section 6 for the risks to health generally associated with the use of this device that FDA has identified.)

Discussion of the device characteristics that address the risks identified in this class II special controls guidance document, as well as any additional risks identified in your risk analysis.”

The special controls guidance will also identify risks to health that have been identified for products of that type, which you should be sure to include in your risk analysis as appropriate.

More information on 510k design control & risk Management requirements

Hopefully, you are now able to determine which elements of your DHF are 510k design control requirements and which elements of your RMF are 510k risk management requirements. If you would like more information about how to implement design controls and risk management within your product development process, please register for our free webinar. If you need any further information or specific assistance with your 510k submission, please feel free to send me an email at mary@fdaecopy.com or schedule a call with our principal consultant, Rob Packard who can answer any of your medical device regulatory questions.


Click here to schedule a 15 minute call 300x62 510k Design Control Requirements and 510k Risk Management Requirements

Posted in: 510(k), Design Control, Risk Management

Leave a Comment (0) →

Cybersecurity FDA Guidance for Devices with Software and Firmware

This article reviews the FDA guidance for premarket and post-market cybersecurity of medical devices with software and firmware—including requirements for reporting of field corrections and removals.

Cybersecurity with custom aspect ratio Cybersecurity FDA Guidance for Devices with Software and Firmware

Hospitals, home health systems, and medical devices are more connected now than ever. The automatic communication between medical devices and network systems is improving the efficiency and accuracy in the world of healthcare. Medical devices are capable of more computing, analysis, reporting and automation to improve the speed and quality of patient care. Along with technological advances, new risks and concerns are also introduced. The risk of hackers exploiting vulnerabilities in networks and software is inevitable. The FDA introduced guidance for both pre-market and post-market cybersecurity to assist manufacturers in developing effective controls to protect patients and users. Cybersecurity protection requires Identification, Protection, Detection, Response, and Recovery.

The first step is incorporating processes and procedures to improve device cybersecurity into your quality management system. You should have a specific cybersecurity plan to outline the steps necessary to ensure a safe and secure medical device.

Identify Cybersecurity Risks

The key to understanding and assessing the cybersecurity risks involved with your device begin in the early stages of design development. At the start of the risk management process, you need to identify the essential safety and performance requirements of the device. You need to identify any potential cybersecurity vulnerabilities that could impact safety or performance, as well as the specific harms that could result if the vulnerability was exploited. In assessing the specific vulnerabilities, the FDA recommends using the Common Vulnerability Scoring System (CVSS). There is a CVSS calculator available online through NIST. The overall score is calculated based on different factors such as: attack vector (local, adjacent network, network), access complexity (high, medium, low), authentication (multiple, single, none), impact of confidentiality (none, partial, complete), exploitability (unproven that exploit exists, proof of concept code, functional exploit exists), remediation level (official fix, temporary fix, workaround, unavailable), collateral damage potential (low, medium, high), etc. This score is used in the hazard analysis in determining the level of risk.

Cybersecurity Protection

The process of assessing the exploitability and harms can also assist in determining mitigations that can be implemented to reduce the cybersecurity risk. During the design process, the FDA expects you to implement as many protections as practicable. Protections include:

  • Limit Access to Trusted Users
    • Password protection, strengthened password requirements
    • User authentication
    • Layered privileges based on user role
  • Limit Access to Tampering
    • Physical locks on devices and/or communication ports
    • Automatic timed methods to terminate sessions
  • Ensure Trusted Content
    • Restrict software or firmware updates to authenticated code
    • Systematic procedures for authorized users to download software and firmware only from the manufacturer
    • Ensure capability of secure data transfer, use of encryption

Cybersecurity Detection

The FDA also requires you to implement features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use. You should develop and provide information to the end user concerning appropriate actions to take upon detection of a cybersecurity event. Methods for retention and recovery should be provided to allow recovery of device configuration by an authenticated privileged user.

If you include off-the-shelf (OTS) software in your device, you are responsible for the performance of the software as part of the device. All software changes to address cybersecurity vulnerabilities of the OTS software need to be validated. You need to maintain formal business relationship with the OTS vendor to ensure timely notification of any information concerning quality problems or corrective actions. Sometimes you will need to involve the OTS vendor to correct cybersecurity vulnerabilities.

Post-Market Surveillance

Once you complete the hazard analysis, mitigation implementation, validations, and has deployed their device for use – your activities shift to post-market management. There are several QMS tools that can assist in the cybersecurity processes post-market including: complaint handling, quality audits, corrective and preventive action, ongoing risk analysis, and servicing. A critical component of every cybersecurity program is monitoring of cybersecurity information sources to assist in the identification and detection of risk. You should maintain contact with third-party software suppliers for identification of new vulnerabilities, updates and patches that come available.

There are many sources that companies should follow for information relating to cybersecurity including: independent security researchers, in-house testing, software or hardware suppliers, healthcare facilities, and Information Sharing and Analysis Organizations (ISAO). Involvement in ISAOs is strongly recommended by the FDA and reduces your reporting burden if an upgrade or patch is required postmarket. ISAOs share vulnerabilities and threats that impact medical devices with their members. They share and disseminate cybersecurity information and intelligence pertaining to vulnerabilities and threats spanning many technology sectors, and are seen as an integral part of your post-market cybersecurity surveillance program.

Response and Recovery

If you identify a cybersecurity vulnerability, there are remediation and reporting steps that need to occur. Remediation may involve a software update, bug fixes, patches, “defense-in-depth” strategies to remove malware or covering an access port to reduce the vulnerability. Uncontrolled risks should be remediated as soon as possible, and must be reported to the FDA according to 21 CFR 806. There are certain circumstances that remove the reporting requirement. The decision flowchart below can be used to determine the reporting requirements.

Cybersecurity software change decision tree Cybersecurity FDA Guidance for Devices with Software and Firmware

In addition to reporting corrections and removals, the FDA identifies specific content to be included in PMA periodic reports regarding vulnerabilities and risks. If you have a Class III device, you should review that section thoroughly to ensure annual report compliance.

If a device contains software or firmware, cybersecurity will be an important component of the risk management processes, and continual cybersecurity management will be necessary to ensure the on-going safety and effectiveness of your device. If you need of more help with cybersecurity risk management of your medical device, please schedule a free 15-minute call with Medical Device Academy by clicking on the link below.

Click here to schedule a 15 minute call 300x62 Cybersecurity FDA Guidance for Devices with Software and Firmware

Posted in: Software Verification and Validation

Leave a Comment (0) →

Reprocessed Single-Use Devices: Considerations for a 510k Submission

This is blog entry summarizing an article published on the FDAeCopy website about the unique challenges of 510k submissions for reprocessed devices.

FDA eCopy Blog Abstract Reprocessed Single Use Devices: Considerations for a 510k Submission

Mary Vater joined Medical Device Academy as a new regulatory consultant in March 2017. She published her first new blog on our FDA eCopy website today. The blog explains the unique challenges of reprocessed single-use devices when preparing a 510k submission.

Challenges of 510k Submissions for reprocessed devices

There are three areas in particular that challenge reprocessors when preparing a 510k submission for reprocessed single-use devices:

  1. Section 13, labeling
  2. Section 15, biocompatiblity
  3. Section 18, performance testing

In her article, Mary reviews each of these sections of a 510k submission and identifies both pitfalls and solutions for testing requirements in each of the sections of a 510k.

One of the most important things to know when preparing a 510k submission for a reprocessed device, is whether you need to perform any biocompatibility testing at all. Biocompatibility testing is one of the longest verification and validation tests–as well as the most costly. If you do not modify the device during reprocessing, then you don’t need to perform biocompatibility testing. This article reviews the types of modifications that will require biocompatibility testing.

You also need to develop your own instructions for use and labeling for reprocessed devices. You can reference the original equipment manufacturer’s (OEM) IFU, but you there is specific information needed for reprocessed devices that should be included. This information includes the name and model number of the OEM device.

Finally, it is not enough to provide performance testing data showing that after reprocessing a device it remains equivalent to the OEM device. You must show that the performance remains equivalent after multiple reprocessing cycles. Most devices will deteriorate over time and may only be able to survive a certain number of reprocessing cycles. This testing data needs to be included in your 510k submission.

If you are interested in learning more about how to prepare a 510(k) for a reprocessed single-use device, please visit the FDA eCopy website.

Posted in: 510(k)

Leave a Comment (0) →
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers:

Simple Share Buttons
Simple Share Buttons