Risk Management Traceability for CE Marking Technical Files

How to use risk management traceability for CE Marking to cross-reference hazards, risks, and risk controls throughout your technical file.

This approach will more efficiently integrate risk management tools into your Design History File (DHF), post-market surveillance documentation, and clinical evaluation reports (CERs). The table above provides a simple template for the nomenclature of risk management elements that you need to cross-reference and provides risk management traceability throughout your technical documentation.

The table does not include a cross-reference code for verification and validation reports because there could and typically are multiple risk controls that are validated and verified for each risk. Many times they are applied across multiple product lines. Therefore, it is more efficient to simply reference the controlled document number for the verification report that is applicable to that risk control.

The basic concept of traceability

The concept of risk traceability is more than being able to identify the verification and validation study that was performed to verify the effectiveness of risk controls in your FMEA because it is in the same row of your table. The best practice is to number your hazards, risks, and risk controls so that you can cross-reference more easily throughout all your technical documentation [i.e., design requirements matrix, risk management file, clinical evaluation report, post-market surveillance plan/reports, and post-market clinical follow-up (PMCF) report].

Design Requirements Traceability Matrix (DRTM)

The design requirements traceability matrix (DRTM) is a combination of two documents that have been used for the past two decades by medical device manufacturers: 1) the design requirements matrix or IOVV (i.e., inputs, outputs, verification, and validation), and 2) the risk traceability matrix. The second document is less commonly used, but an example of one is provided in Figure 3 of the GHTF risk management guidance document SG3 N15R8.

The risk management summary table that is presented in Figure 3 of the guidance also provides cross-references to specific tests, and each test has an identification number for traceability. This approach is also used frequently in risk control plans–an excellent tool for production process controls and planning product realization before process validation.

Risk management traceability to post-market surveillance

I recommend that companies create a post-market surveillance plan for devices or device families during the design transfer process. This is NOT the post-market surveillance procedure. Your procedure should indicate the process you use for post-market surveillance. Still, your plan should be process-specific and identify specific risks that you intend to gather post-production data for. The post-market surveillance plan should provide traceability back to each risk in your risk management file (e.g., R1, R2, R3). You should include a post-market clinical follow-up (PMCF) protocol and report that also cross-reference to these risks and associated risk controls–or provide a justification for not conducting a PMCF study. In 2016, the new European Medical Device Regulations (EMDR) will require that both the protocol and the report be included in your post-market surveillance plan as a required section (see Annex II of the proposed regulations) of the technical file or design dossier. Finally, I recommend that you revise and update your risk management plan for post-production data collection at the time of design transfer. When you make this revision, I recommend moving the risk management plan from the design plan to your post-market surveillance plan as an integral part of the plan (i.e., one of the primary sections of the plan).

Risk Management Traceability for Your Clinical Evaluation Report (CER) 

In your clinical evaluation report (CER), if you simply said that “the clinical data reviewed addresses all of the residual risks identified in the risk management summary report,” you are not specific enough. Your clinical evaluation report (CER) should explain how the clinical study data you reviewed addresses each of the risks that you identified in your risk analysis. Personally, I like to have subsections in the discussion section of the clinical evaluation report (CER) for each of the risks identified in the risk management file. I also do this when I write my post-market surveillance plan. When I do this, I include a cross-reference to the applicable hazard in my design requirements matrix, risk analysis, and hazard identification summary report (e.g., “HZ1”, “HZ1” and “HZ3”).

Traceability to warnings & precautions

ISO 14971:2007 indicates that disclosing residual risks to users of your device is risk control. In Annex ZA, deviation 7 of EN ISO 14971:2012, indicates that you cannot claim to reduce the risks of your product by disclosing these residual risks–even though these are considered risk controls. You should still validate the effectiveness of the instructions for use, technique guide, and training through simulated use studies before product release. However, you cannot claim a quantitative risk reduction in your risk analysis as per deviation 7. Of course, there can be a reduction in overall risks when you train users, but you can’t claim it, and the prevalence of “use errors” demonstrates the limited effectiveness of IFUs and training.

Additional risk management references

I have published 14 previous blogs, specifically on the topic of risk management over the past couple of years. Please click here if you are looking for risk management training. You can expect many more blogs on this topic during the next six months because I will be presenting four presentations in Brussels at an international medical device conference scheduled for June 13-17, 2016.

Procedures & templates for risk management

If you are looking for a risk management procedure (SOP), SYS-010 meets the requirements of ISO 14971:2019 and Regulation (EU) 2017/745 for CE Marking.