Risk Management File Compliance for 510k and CE Marking

This article compares risk management file FDA requirements for CE Marking and 510k submission requirements.

The FDA only requires documentation of risk management in a 510k submission if the product contains software, and the risk is at least a “moderate concern.” Even then, the 510k only requires the submission of a design risk analysis rather than your complete risk management file. Knee implants do not require submission of risk analysis, even though manufacturers are required to perform risk analysis in accordance with ISO 14971, because knee implants do not contain software. Therefore, it is not uncommon for a product that is already 510k cleared to receive audit nonconformities related to the risk management documentation during a technical file review by a Notified Body.

The FDA recognizes ISO 14971:2007 as the standard for risk management of medical devices. CE Marking also requires compliance with ISO 14971, but specifically the European national version of the standard (i.e., EN ISO 14971:2012). The most common technical file deficiencies related to risk management during a CE Marking application include the following:

1. compliance with ISO 14971:2007 instead of EN ISO 14971:2012
2. reduction of risks as low as reasonably practicable (ALARP) instead of reducing risks as far as possible (AFAP)
3. reducing risks by notifying users and patients of residual risks in the IFU
4. only addressing unacceptable risks with risk controls instead of all risks–including negligible risks

Each of these deficiencies is also explained in Annex ZA, ZB, and ZC of EN ISO 14971:2012.

7 Deviations you must address in your risk management file

Notified Body auditors are supposed to be reviewing your risk management process and sampling your risk management file(s) to verify that you conform with the requirements for a risk management file as defined in EN ISO 14971:2012 and the applicable European directive. Most manufacturers with CE Certificates have updated their procedures for compliance with the European National version, but the updates are not always complete or done correctly. Therefore, auditors need to be systematic in their review for compliance. I recommend creating a three-column table in your audit notes for each of the seven deviations. The first column would state the requirement from the applicable annex of EN ISO 14971:2012. The second column is used to document wherein the risk management procedure, and each of the seven requirements is addressed. Suppose you can’t find it quickly during your review–as the person you are auditing to find it for you. The third column is used to document which risk management file you sampled, and wherein the risk management file, the auditor was able to find compliance with one of the deviations. Risk management training of the cross-functional risk management team should also be sampled by the auditor. If the auditor can’t find an example of compliance in the procedure or the risk management file, then there is a minor nonconformity that needs to be corrected and recurrence needs to be prevented.

Note: Remember that auditing is about verifying compliance–not scouring 100% of the records for nonconformity.

Procedure review

The first step in responding to correcting deficiencies in your risk management process is to update your procedure. The following basic elements need to be included in the procedure:

• risk management plan
• hazard identification
• risk analysis
• risk control option analysis
• verification of risk control effectiveness
• risk/benefit analysis
• risk management report

Many of the procedures I review focus on the risk analysis process, and the most common tool for risk analysis is a failure mode and effects analysis. This is an excellent tool for process risk analysis, but it is only one of many possible tools, and it is not ideally suited for design risk analysis. In addition, your procedure is not adequate as a risk management plan. You need risk management plans that are product-specific or specific to a product family. Your risk management plan must also change and adapt as products progress from the design and development process to post-market surveillance. Finally, many of the procedures only require a benefit/risk analysis to be performed when risks are not acceptable, while the European MDD requires that all CE Marked products include a benefit/risk analysis for each risk identified in the risk analysis and the overall risk of the product or product family.

Risk management plans

Risk management is required throughout product realization, but the activities are quite different during the pre-market and post-market phases. Therefore, I recommend including a risk management plan as part of the design and development plan to address pre-market needs for risk management. Once a product development project reaches the design transfer phase, then a post-market risk management plan needs to be written. I incorporate this plan into the post-market surveillance plan for the product or product family. This approach ensures that the risk analysis will be linked directly with post-market surveillance after the product is released.

Hazard identification

Many companies do create a specific document that identifies all the hazards associated with a product. This is an important step that should occur early in the design and development process before design inputs are finalized. During the development process, these hazards may need to be updated as materials and production processes are developed. Some companies may choose to identify hazards at a different time or in a different way. Still, the proposed European Medical Device Regulations (EMDR) require that the dangers are recognized as one of the essential requirements. The ISO 14971:2007 standard suggests that design teams should identify as many hazards as possible, estimate the risks, and then implement risk controls for any unacceptable risks. The EN ISO 14971:2012 standard requires that risk controls be implemented for hazards–regardless of acceptability. For this reason, I recommend companies restrict their identification of hazards to the most likely product malfunctions and hazards of high severity. This list should include any hazards already identified in the FDA’s MAUDE database.

Benefit/risk analysis & risk traceability matrix

To perform a benefit/risk analysis, you have to know the likelihood of potential hazards resulting in harm and the clinical benefits of a product. Unfortunately, reduced costs cannot be used to justify the acceptability of a device. Benefit/risk analysis must be performed for each risk and the overall residual risks. Therefore, it is important to identify the clinical benefits that outweigh each of the risks. I recommend using a risk traceability matrix in order to document each benefit/risk analysis. This can be a separate risk management document, or it can be incorporated into a design requirements matrix. It is also important to identify any warnings, precautions, or contraindications that should be documented in the information provided to patients and users when risks cannot be eliminated. This may be the last column of your risk traceability matrix.

Risk management report

The risk management report should be a summary technical document (i.e., STED). The STED should reference the procedure that was used and indicate all the risk management activities that were performed specifically to the product or product family defined in the scope of the risk management report. The dates of activities, changes made, and cross-references to any controlled documents should be included in the risk management report. I recommend maintaining the risk management report as a controlled document and revising the document to reference additional risk management activities when they occur. The bulk of details should be contained in the referenced risk management documents within the report.

Procedures and templates for your risk management file

We also have a procedure (SOP) for risk management (SYS-010).