This article is an introductory look at what exactly is a pFMEA or Process Failure Modes and Effects Analysis, and some ideas on how to use them as part of a living breathing risk management system.
I recently had someone ask for help understanding the
process FMEA a little better. I can’t blame them because I was lost the first
time I tried to fill out a form for one. It can be a confusing and overwhelming
if you have never seen one before.
First things first, what is a pFMEA-
FMEA= Failure Modes and Effects Analysis
A lower-case letter will come before the FMEA, and that denotes the ‘what’, of what the failure is that is being analyzed. A pFMEA will often be examining process failures where a dFMEA might evaluate design failures. (dFMEA’s can be confusing as well, Robert Packard created a training on how to document risk management activities without using one in his Death of the dFMEA Webinar)
Some systems capitalize all the letters. Some capitalize
none. That is not what is important as long as it is consistent throughout your
system. Everyone should be able to easily understand that whatever variation of
pfmea is used it means “process failure modes and effects analysis”.
What does a pFMEA do?-
A pFMEA will break down your manufacturing process into its individual steps and methodically examine them for potential risks or failures. For companies that utilize ourTurn-Key Quality Management System, FRM-025 process Failure Modes and Effects Analysis can be used as a template.
For this example, we will look at receiving inspection of
injection molded casing parts for a medical device. This receiving inspection
includes a manual inspection of 10 randomly selected parts out of each delivery
of 100 using an optical overlay.
This area as the section title suggests is the process step. When looking at the process as a whole the pFMEA will break it down into each and every step included in that process. This area is simply that individual step that is going to be examined.
The Process Step, or item function depending on what your form uses for this scenario is going to be part of the random sampling for manual inspection of the received parts using an optical overlay. Our example is going to be the backlighting element of the optical overlay display. The backlighting element will illuminate the inspected part against the template to verify that the part is within specific dimension criteria.
Potential Failure Modes-
A failure mode is a way in which that process step might fail. since it is failure modeS, it needs to be considered that there may be more than one way for the process step to fail. Do not be fooled that because this box on the form has been filled in that the pFMEA will be complete. A thorough examination of all of the possible failures should be investigated.
Our example in this process requires the backlighting element to illuminate a visual template over the parts. The light not illuminating properly is a potential failure mode of this process.
Potential Effects of Failure-
the potential effects of the failure is a look into what the ramifications would be if that failure for that process step actually happened.
In our scenario one of the potential effects of the lighting not functioning properly is that parts outside of the designated sizing acceptance criteria may be accepted rather than rejected as non-conforming parts.
The next area is the first area that requires an estimated grading of the failure. That is ‘Severity’ which is abbreviated as S. There is a scale provided in the ratings section of FRM-025 that outlines the numbering system that Medical Device Academy uses.
In this case our example is using molded plastic pieces of the outside casing of a medical device. Pieces that are too large or too small will not fit when making the final assembly of the device. These plastic pieces do not happen to be patient contacting, and do not affect the function of the device.
The evaluation of this failure is determined to have no
potential affect on patient safety or increase any potential for risk of harm,
therefore the severity is assigned as a ‘business risk’ meaning that it bears
no risk for the user or the patient. This makes the Severity Score 0.
Causes of Failure-
This column is exactly that. What might cause this identified failure to happen? In our example might be the light bulbs in the overlay machine may slowly burn out over time with use. This burnout causes the potential failure.
If the bulb is expected to only have a lifetime of 100 hours,
then the more hours the bulb is used the more dim the light may become. A
slowly dimming light decreases the sharpness of the overlay template and our
parts that are supposed to have a + or – size criteria of 10% now have a fuzzy
template that in reality changes the overlay to show closer to + or – 13%. Now
parts that are too small or too large may be accepted.
This grading criteria is also found in the Ratings section
of FRM-025. This is how often the failure is expected to occur. How often will
the lighting element of our optical overlay fail to function in the appropriate
manner for this cause?
Hopefully not very often. In fact, regularly scheduled
maintenance and calibration of the overlay machine could prevent this from ever
happening in the best-case scenario. Our evaluations determine that the
probability of this happening is low. However, since we cannot be certain it
will never happen the potential for this risk exists and makes the Occurrence
score a 4.
Current Process Controls-
What is currently being done to control this risk? Our
example uses regularly scheduled maintenance and calibration to prevent bulb
burnout effecting the overlay.
Our current process is based off of routine maintenance and
visual inspection. This means that the bulb burnout is something that is
visually inspected for and visual inspections for detectability on the rating
scale are graded as 8. This chart is found in the Ratings Section of FRM-025.
RPN (Risk Priority Number)-
This is a number that is found by multiplying the Severity,
by the Probability, by the Detectability. In our example the numbers RPN
is 0X4X8=32 for an RPN of 32 which is
Below is a short video explaining the math behind calculating the Risk Priority Number
What if anything can be done to improve this process? In our
example a recommended action may be to transfer from visual only inspections to
verification of light output by meter. This makes the Detectability of the
failure measurable by meter or gage which is a detectability score of 4.
This changes the RPN now to 0X4X4=16
The pFMEA shouldn’t be a solo thing-
If it can be avoided this type of analyisis should be done by a multidisciplinary team. Sometimes in smaller companies people end up having to wear more than one hat. There are many entrepreneurs that have to function as the CEO/CFO/Design Engineer/RA/QA manager.
Ideally a team approach should be used if feasable. Have the management level staff who have ownership of the processes participating in this analysis. They should know the process more intimately than anyone else in the company and should have more insight into the possible failure modes of the processes as they have likely seen them first hand. They are also the type of employee who would know the types of recomended actions to control the risk of those failures as well.
The pFMEA should also be a living document-
As new failure modes are discovered they should be added to your pFMEA. A new failure mode might be discovered through a CAPA because the process had an actual failure that was not originally analyzed. Take an instance like that as an opportunity for improvement and to update your pFMEA as part of a living breathing risk management system. Also use this as a time to re-brainstorm potentially similar failure modes that may not have been considered previously so that they can be controlled before they happen.
If you took the time to watch the video above it is also mentioned that in some instances the very first FMEA must be based off of estimates because there is no data. Managers, and engineers may be forced to estimate the probability of occurence. If that is the case the FMEA should be updated in the future to adjust the (O) score to reflect what is occuring in actuality based off of real data and not the theoretical data that was used for the initial estimate.
This article describes updates being made to the ISO 14971 Standard in the new draft version released for comment in July 2018.
There are two versions of ISO 14971 that are currently available. The first is the international version: ISO 14971:2007. The second is the European normative version: EN ISO 14971:2012. There is also a new draft being created by the TC210 committee for release in 2019.
Explanation of the different versions of the ISO 14971 standard
In 2000, the first edition of ISO 14971 was released as the international standard for risk management of medical devices. In 2007, the second edition of ISO 14971 was released. When new international standards are released, a European normative version is also released. The “European Norm” or EN version is intended to identify any gaps between the international standard and the requirements of the applicable European directives (i.e., the MDD, AIMD and the IVDD). These gaps historically were included in the ZA annex at the end of the EN version. However, in 2009 this annex was split into three annexes (i.e., ZA, ZB and ZC) to address each of the three directives separately. In reality, the 2009 annex only differed with regard to the directive referenced. In 2012, a new EN version was released. This new standard included 7 deviations which were controversial. These deviations were intended to identify contradictions between the directives and the international standard, but the interpretations were not agreed with by companies or most of the Notified Bodies. Ultimately, the 7 deviations were required to be addressed in the risk management files for any medical device that was CE Marked.
What changed between ISO 14971:2007 and ISO/DIS 14971:2018?
The TC210 working group assigned to update the ISO 14971 standard (JWG1) was tasked with improving guidance for implementation of ISO 14971, but the committee was also tasked with making these improvements without changing the risk management process. In addition, the committee was asked to move the informative annexes at the end of ISO 14971 from the standard to the guidance document ISO/TR 24971. Therefore, in July the committee released a draft for comment and voting. Draft versions are identified with the prefix “ISO/DIS.” The ISO/DIS 14971 standard released in July has only three annexes: A) Rationale for the requirements, B) Risk management process for medical devices, and C) Fundamental risk concepts (formerly Annex E). The other 7 annexes were moved to the draft of ISO/TR 24971. The reason stated for moving these Annexes to the guidance document was to make future revisions to the guidance easier to implement, because it is a guidance rather than a standard. However, there were also some objectionable recommendations in the informative annexes that were the subject of deviation #3—ALARP from Annex D.8 vs. “As far as possible” in the first indent of section 2 of Annex I in the MDD.
Although the committee was tasks to make improvements in the implementation of ISO 14971 without changing the process, the new draft has subtle changes in the process. Most of these changes can be identified quickly by reviewing the updated risk management flow chart provided in Figure 1. The updated flow chart now has two places where risks are evaluated. The first place is identical the original Figure 1, but now the associated section is clarified to be specific to evaluating individual risks. The second place in the flow chart is new, and specific to evaluation of overall residual risks. The draft standard also states that different acceptability criteria and methods of evaluation may be used for each evaluation phase in the process. There have also been subtle changes to the names of process phases:
Section 7.4 is now “Benefit/Risk” analysis instead of “Risk/Benefit” analysis—although the draft flow chart does not reflect this.
Section 9 is now “Risk Management Review” instead of “Risk Management Report”
Section 10 is now “Production and post-production activities” instead of “Production and post-production information”
There is also more detail in the diagram under the phases for: 1) risk analysis, 2) risk control, and 3) production and post-production activities.
Three new definitions are introduced in the draft standard: 3.2, benefit; 3.15, reasonably foreseeable misuse; and 3.28, state of the art. The section for identification of hazards, Clause 5.4, was reworded and expanded to consider the reasonably foreseeable sequences or combinations of events that can result in a hazardous situation. The draft standard now states that your risk management plan must also include a method to evaluate the overall residual risk and the criteria for acceptability of the overall residual risk. In the section for risk estimation, Clause 5.5, the draft standard states that if the probability of the occurrence of harm cannot be estimated, the possible consequences shall be listed for use in the risk evaluation and risk control. The risk control option analysis priorities in section 7.1 are updated to match the new MDR, Regulation (EU) 2017/745, nearly exactly. In section 9, risk management reports were changed to risk management review and the clause now requires determining when to conduct subsequent reviews and when to update reports. This emphasizes the requirement to continuously update risk management documentation with input from production and post-production information. This mirrors the emphasis on continuously updating post-market clinical follow-up in Regulation (EU) 2017/745, Annex XIV, Part B, Section 5; and continuously updating clinical evaluations in Regulation (EU) 2017/745, Annex XIV, Part A, Section 1.
Will ISO 14971:2019 address the 7 Deviations in EN ISO 14971:2012?
The new MDR, Regulation (EU) 2017/745, revised and clarified the wording of the essential requirements in the MDD. The MDR attempts to clarify the requirements for risk management files of CE Marked products, but the MDR remains different from the requirements of ISO 14971. Unfortunately, because the ISO/DIS 14971 was not intended to change the risk management process of ISO 14971:2007, there will continue to be “deviations” between the MDR and standard.
Some people have tried use ISO/TR 24971, the risk management guidance, as the official interpretation of how the risk management standard. However, the guidance is also a product of the TC210 committee, and it does not meet all requirements of the MDD or the MDR.
The new draft does, however, include changes that address some of the deviations in EN ISO 14971:2012. Below, each of the 7 deviations are listed and hyperlinks are provided to other articles on each individual deviation.
Negligible Risks – The word “negligible” was only in one location in the body of the standard as a note referring to Annex D.8. In the draft, Annex D was removed and relocated to ISO/TR 24971, and the note was eliminated from Clause 3.4—now Clause 4.4 in the draft. This deviation should be fully resolved by the draft.
Risk Acceptability – Clause 7 was renumbered to Clause 8 in the draft, but the title of this clause was also changed from “Evaluation of overall residual risk acceptability” to “Evaluation of overall residual risk.” However, if you read the Clause it still refers to determining acceptability of risks. In note 2 of Annex ZA of the draft, it states that determining acceptable risk must be in compliance with Essential Requirements 1, 2, 5, 6, 7, 8, 9, 11 and 12 of the Directive. This deviation should be fully resolved by the draft.
ALARP vs. “As far as possible” – The European Commission believes that the concept of “ALARP” implies economic considerations, and some companies have used economics as a reason for not implementing certain risk controls. ALARP was eliminated from the notes in the risk management plan clause and by moving Annex D.8 to ISO/TR 24971 and adding note 1 in Annex ZA. This deviation should be fully resolved by the draft.
Benefit/Risk Analysis – The contradiction in requirements between the International Standard and the MDD, as it relates to determining when a benefit/risk analysis must be conducted has not been updated. This deviation is not resolved by the draft. Companies that CE Mark products will need to perform a benefit/risk analysis for all residual risks and all individual risks—despite the wording of the standard.
Risk Control – The contradiction in requirements between the International Standard and the MDD, as it relates to determining when risk controls must be implemented. The International Standard gives companies the option to avoid implementation of risk controls if the risk is acceptable, while the MDD requires that risk controls be implemented for all risks unless the risk controls create additional risks that increase risks or the risk controls do not actually reduce risks further. This deviation is not resolved by the draft. Companies that CE Mark products will need to implement risk controls for all individual risks—despite the wording of the standard.
Risk Control Options – The intent of Clause 6.2 in ISO 14971:2007 was likely to be the same as the MDD. However, the European Commission identified the missing word “construction” as being significant. Therefore, to prevent any misunderstandings, the TC210 committee copied the wording of Regulation (EU) 2017/745. This deviation should be fully resolved by the draft.
IFU Validation – Again, to prevent any misunderstandings, the TC210 committee copied the wording of Regulation (EU) 2017/745. However, the examples of information for safety (i.e., warnings, precautions and contraindications) were not included. Hopefully, the final version of 3rd edition will include these examples. Clause 8, evaluation of overall residual risk, was also reworded to state, “the manufacturer shall decide which residual risks to disclose and what information is necessary to include in the accompanying documentation in order to disclose those residual risks.” This deviation should be fully resolved by the draft.
Recommendations for your Risk Management Process?
The most important consideration when establishing a risk management process for medical devices is whether you plan to CE Mark products. If you intend to CE Mark products, then you should write a procedure that is compliant with the current requirements of the MDD and future requirements of Regulation (EU) 2017/745. Therefore, the 7 deviations should be addressed. In addition, you need to maintain compliance with the current version of the Standard.
I recommend creating a process based upon the new updated process diagram in the new draft. The process should begin with a risk management plan. For you plan, you may want to create a template and maintain it as a controlled document. It could also be part of your design and development plan template, but the plan should include each of the following risk management activities:
Risk control option analysis
Risk control verification of effectiveness
Evaluation of overall residual risk
Risk management review
Production and post-production activities
Your procedure should also be integrated with other processes, such as: 1) design control, 2) post-marketing surveillance, and 3) clinical evaluation. Your procedure must clearly indicate the priority for implementation of risk control options. The best strategy for ensuring risk control priorities are compliant is to copy the wording of the new EU Regulations verbatim. Your process should include performing benefit/risk analysis. You should also define your process for risk management review. Your review process should specify when subsequent reviews will be done and when your risk management report will be updated. Finally, you should identify a post-market surveillance plan for each device, or device family, and use that post-market surveillance data as feedback in the risk management process.
The one element that appears to be weakly addressed in the body of the standard is the requirement for traceability of each hazard to the other elements of the risk management process. Although traceability is mentioned in Clause 3.5 of the 2nd edition, and Clause 4.5 of draft 3rd edition of ISO 14971, that is the only place is mentioned in the body of the standard. Traceability is mentioned several more times in Annex A, but the focus seems to be on the risk management file. Companies need more guidance on how to achieve this traceability. The appropriate place for this guidance is probably in ISO/TR 24971, but in order to maintain this documentation it is likely that a software database will be critical to maintaining traceability as changes are made during design iterations and after commercialization. This type of software tool is also need to expedite the review of risk management documentation during complaint investigation.
Which Risk Analysis Tool should you use?
In Annex G of ISO 14971:2007, and the EN 2012 version, there are five different risk analysis tools described. The word “described” is emphasized, because informative annexes are not “recommended.” The committee that created the 2nd edition of ISO 14971 wanted to provide several suggestions for possible risk analysis tools to consider. However, each tool has strengths and weaknesses. Additionally, the widespread use of the failure-mode-and-effects analysis (FMEA) tool in the automotive and aerospace industries has spread to the medical device industry and companies seem to believe that regulators prefer the FMEA tool. This is not true. Companies should be trained in all of these tools, training should consist of more than just reading Annex G and the tools should be used where they are most beneficial. My personal recommendations are below:
Preliminary Hazard Analysis (PHA) – This process is absolutely critical during development of design inputs. It is also the most underutilized analysis tool. I have not seen a single example of this tool written in a procedure by any medical device company. I believe this process should be continuously updated as part of training new design team members and should be both product and project specific.
Fault-tree Analysis (FTA) – This process is a top-down approach to risk analysis. It is heavily utilized by transportation engineers when intersections are designed, and accidents are investigated. This tool depicts risk analysis pictorial as a tree of fault modes representing each possible root cause for failure. At each level of the tree, fault mode combinations are described with logical operators (i.e., AND, OR). The information displays frequency of each fault mode quantitatively. Therefore, when you are investigating a complaint, the tree can be used to help identify possible fault modes that may have been the root cause of device failure. You may also be interested in the standard specific to Fault tree analysis (FTA): IEC 61025:2006.
Failure Mode and Effects Analysis (FMEA) – This process is a bottom-up approach to risk analysis. It is heavily utilized by the automotive and aerospace industries. This tool systematically lists all failure modes in groups organized by component. Risks are estimated based upon severity of effect, probability of occurrence and detectability. Over time, the FMEA process split into three tools: 1) process FMEA (pFMEA), 2) design FMEA (dFMEA), and 3) use FMEA (uFMEA). The first is ideal for analyzing and reducing risks associated with manufacturing of devices. In particular, the detectability factor can be linked closely with process validation. The second evolved from the realization that detection of a risk after the device is in the user’s hands does not actually reduce risk. A risk reduction only occurs if detectability is proactive. Therefore, this was stated in Annex G.4 and companies began to eliminate detectability and continued to use FMEA as their primary tool. Due to the widespread familiarity with the FMEA tool, usability FMEAs became popular for documenting risks associated with use of a device. Unfortunately, the only real advantages of a dFMEA and uFMEA are familiarity with the tool. You may also be interested in the standard specific to FMEA: IEC 60812:2018.
Hazard and Operability Study (HAZOP) – In addition to the risks of using devices, there are also risks associated with the production of devices. Processes related to coating, cleaning and sterilization are all processes that typically involve hazardous chemicals. The chemical and pharmaceutical industries use HAZAP as a tool to analyze these process risk and prevent injuries. You may also be interested in the standard specific to HAZOP: IEC 61882:2016.
Hazard Analysis and Critical Control Point (HACCP) – This process is primarily used by the food industry to prevent the spread of contaminated food supplies. Even though it is not typically used by medical device manufacturers, it should be considered as a tool for managing the supply chain for devices. This model is useful when manufacturing is outsourced, or secondary processing is conducted at second and third-party suppliers. Since many FDA inspectors started in the food industry as inspectors, this is also a method that is supported by the FDA as a risk control process for outsourced processes.
How to document your risks?
For simple devices, risk management documentation is a burdensome task. For complex devices, a spreadsheet could include hundreds of lines or more than even one thousand individual lines. In addition, the requirement for traceability requires additional columns in a table. Therefore, it becomes nearly impossible for you to include all the required information on a page that is 11 inches wide. If you expand your page to 17 inches wide, the size of your font will need to be very small. If you make a change, your spreadsheet can be difficult to update quickly. You could purchase a 43” widescreen TV for your monitor, or you can use dual monitors for your display, but changes remain difficult to implement without a mistake.
You need to stop relying upon spreadsheets. Use a database, and don’t use Microsoft Access. Purchase a database that is designed to document design controls and risk management traceability. If your company has software expertise, develop your own software tool to do this. You should also design standardized templates for exporting your reports. By doing this, it will only take minutes to create an updated report when you make design changes. If you describe the risk management activities as notes in your software, the description of these activities can also be automatically converted into summary pages for each report summarizing that risk management activity. You can even prompt the user to answer questions in the software to populate a templated document. For example, you can prompt users to input subsequent updates of your risk management reviews and that can be automatically converted into a summary paragraph. This reporting capability is especially helpful when responding to FDA review questions asking for cybersecurity risks.
Additional Training Resources for ISO 14971
The risk management training webinar was being completely rewritten to address changes proposed in the new draft of ISO 14971 (i.e., ISO/DIS 14971) released in July 2018 and European requirements for compliance with Regulation (EU) 2017/745. The webinar was live on October 19, 2018; but it was recorded for anyone that was unable to participate in the live session.
SYS-010, Medical Device Academy’s Risk Management Procedure, is compliant with EN ISO 14971:2012. The procedure includes templates for documentation of design risk management and process risk management. However, we are rewriting the procedure for compliance with ISO/DIS 14971:2018 and Regulation (EU) 2017/745. The new version of the procedure will be available on or before October 26, 2018. The procedure is temporarily available at a discounted pre-order price, but the cost will increase to $299 once the new version is available.
This article compares the risk management requirements for a 510k submission with the risk management requirements for your design history file (DHF).
Risk Management Requirements and Design Control 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 asking what the design control and risk management requirements are for a 510k.
What are the Design Control Requirements in 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).
What are the Risk Management Requirements in a 510k?
For 510k submissions, the only risk management requirements are the inclusion of risk documentation for 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.
510k Design Control Requirements
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)
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.
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
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.
Only required for sterilization validation typically, but there are exceptions for novel materials and coatings
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
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.
510k Risk Management Requirement
Risk Management Plan
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.
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
Special Controls Guidance Documents with Risk Management Requirements
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 Design Control and 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 consider registering for one of our training webinars:
If you need any further information or specific assistance with your 510k submission, please feel free to send me an email at firstname.lastname@example.org or schedule a call with our principal consultant, Rob Packard who can answer any of your medical device regulatory questions.
Article explains checking adverse event data for medical devices as part of design and development, risk management and post-market surveillance.
When should you be checking adverse event history?
There are three times when you should be checking adverse event history:
when you are planning a new or improved medical device and you want to know how current devices on the market malfunction (design and development planning),
when you are identifying hazards associated with a medical device as part of your risk management process, and
when you are gathering post-market surveillance data about your device and competitor devices.
Where should you be checking adverse event history?
Most countries have some kind of database for gathering adverse event data for medical devices, but most of these databases are not open to the public. The most common question I am asked is, “How do you access the Eudamed database?” for reporting of adverse events in Europe. Unfortunately, you can’t access Eudamed. The Eudamed database is only available to competent authorities at this time. The primary publicly accessible database for adverse event reporting is the US FDA MAUDE database. The MAUDE database is also integrated with other FDA databases for 510k submissions and recalls. This combined database is called the Total Product Life Cycle database.
Are there other public databases for checking adverse event history?
Yes. The Therapeutic Good Administration (TGA) in Australia makes adverse event data publicly available. The TGA also has a national registry for implanted orthopedic devices that publishes an annual report. There are other countries that also have public registries.
When will checking adverse event data for Europe be possible?
The Eudamed database for Europe was created in 1999 by the German organization DIMDI. In 2000 the responsibility for the database was taken over by the European Commission. The latest update is that manufacturers will be responsible for updating the Eudamed database in the future as part of the new European Regulations. This requirement will be implemented during the next years. The database will also become accessible to the public.
When you collect post-market surveillance data, which data should you collect?
Searching for post-market surveillance data should be performed on a frequency that is risk-based. If you have a brand new device, a high risk device or a device that is implanted; post-market surveillance data should be reviewed frequently–either monthly or quarterly. In fact, the new European guidance document for clinical evaluation reports (MEDDEV 2.7/1 rev 4) requires that clinical evaluation reports be updated at least annually for these devices. It is also important that you collect post-market surveillance data for both your device and competitor products. Therefore, you should be reviewing all the publicly available adverse event databases. You should also be reviewing your own complaint data, and you should be searching for journal articles that may include adverse event data–possibly associated with a clinical study.
This article explains how to use risk management traceability for CE Marking in order 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 below provides a simple template for nomenclature of risk management elements that you need to cross-reference and provides risk management traceability for 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 and 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.
Basic Concept of Risk Management Traceability
The concept of risk traceability is more than being able to identify the verification and validation study that was performed in order to verify effectiveness of risk controls in your FMEA, because it is in the same row of your table. 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 the 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 prior to 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, but 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 and report that also cross-reference to these risks and associated risk controls–or provide a justification for not conducting a PMCF study. In the 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 being 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”).
Risk Management Traceability to Warnings & Precautions
ISO 14971:2007 indicates that disclosing residual risks to users of your device is a risk control. In Annex ZA, deviation 7 of EN ISO 14971:2012 it indicates that you cannot claim to reduce the risks of your product by disclosing this 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 prior to 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 more information related to risk management. 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 procedure (SOP) and associated form for risk management please click here.
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 submission only requires submission of a design risk analysis. Knee implants do not require submission of a 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:
compliance with ISO 14971:2007 instead of EN ISO 14971:2012
reduction of risks as low as reasonably practicable (ALARP) instead of reducing risks as far as possible (AFAP)
reducing risks by notifying users and patients of residual risks in the IFU
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.
Notified Body auditors are supposed to be reviewing your risk management process and sampling your risk management files to verify that you conform with the requirements for risk management as defined in EN ISO 14971:2012 and in 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 7 deviations. The first column would state the requirement from the applicable annex of EN ISO 14971:2012. The second column is used to document where in the risk management procedure each of the seven requirements is addressed. If 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 where in the risk management file the auditor was able to find compliance with one of the deviations. 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.
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
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 modes 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 risk / benefit analysis to be performed when risks are not acceptable, while the European MDD requires that all CE Marked products include a risk / benefit 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 the risk analysis will be linked directly with post-market surveillance after the product is released.
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, but the proposed European Medical Device Regulations (EMDR) requires that the hazards are identified 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 risks that are unacceptable. 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.
In order to perform a risk / benefit analysis you have to know the likelihood of potential hazards resulting in harm and the clinical benefits of a product. Unfortunately, reduced cost cannot be used to justify the acceptability of a device. Risk / benefit analysis must be performed for each risk and the overall residual risks. Therefore, it is important to identify clinical benefits that outweigh each of the risks. I recommend using a risk traceability matrix in order to document each risk / benefit 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 information provided to patients and users when risks cannot be completely 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 specific 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 & Templates
If you are looking for a procedure (SOP) for risk management please click here.
This article reviews the requirements for Instructions for Use and labeling as risk controls in the risk management standard for medical devices: ISO 14971. Specifically, the impact of the seventh deviation identified in the European national version of the ISO 14971 Standard (http://bit.ly/ISO14971-2012changes) is reviewed.
Labeling, instructions and warnings are required for medical devices. Unfortunately, information provided by manufacturers is not effective at preventing hazardous situations and foreseeable misuse–especially if the user throws the paper leaflet in the garbage 10 seconds after the box is opened. Since information provided to the user and patients is not effective in preventing harm, the European Commission indicated that this information shall not be attributed to risk reduction.
The European Commission is not suggesting that your company should stop providing directions or warning users of residual risks. The intent of this deviation is to identify incorrect risk estimation procedures. For example, if you are using Failure Mode And Effects Analysis (FMEA), (see Annex G.4 of the risk management standard) to estimate risk for a new product, you should not be listing labeling and IFUs as a primary risk control. Clause 6.2 of the ISO 14971 Standard correctly identifies “information for safety” provided by the manufacturer as risk controls, but the effectiveness of these risk controls is so poor that you should not estimate that risks are reduced by implementation of labeling and IFUs.
In Clause 2.15 of the ISO 14971 Standard, residual risk is defined as “risk remaining after risk control measures have been taken.” However, I prefer the following following definition which incorporates the concept of clinical evidence, design validation and post-market surveillance:
“Residual risks are risks that remain: 1) after implementation of risk controls, 2) when products are used for new indications for use, 3) when products are used for wider user and patient populations, 4) when products are misused, and 5) when products are used for periods of time longer than the duration of pre-market clinical studies.”
The second essential requirement (ER2) states that users shall be informed of residual risks, but the conclusion that “information aboutresidual risks cannot be a risk control” is incorrect. The most important wording in the deviation is ¨the information given to the users doesnot reduce the (residual) risk any further.¨ Failure to reduce risks any further is due to the lack of effectiveness of risk controls. Validation of risk control effectiveness should be performed during design validation, but validation will be limited to a small group of users and patients.
Risk Management Report & Post-Market Surveillance Plan
In your risk management report, risk control options analysis should be summarized. Instead of evaluating risk acceptability prior to implementing risk controls, risk controls should be implemented and any residual risks should be identified. A risk/benefit analysis must be performed for each residual risk and the overall residual risks. If the conclusion is that the benefits of the device outweigh the residual risks, then the device can be commercially released.
At the time of the final design review and commercial release a Post-Market Surveillance (PMS) plan should be developed that includes an updated risk management plan. The updated risk management plan should specifically address how to estimate residual risks and verify the effectiveness of information provided to users and patients. Verification of risk control effectiveness should be part of the design verification and validation activities, but verification of effectiveness should also be part of on-going PMS.
In order to facilitate future updates of your risk management report, you may want to organize risk controls into the following categories (in this order):
Design elements (highly effective)
Materials of construction (highly effective)
Methods of manufacture (highly/moderately effective)
This blog discusses risk control options for medical devices; the 6th deviation identified in the European National version of the Risk Management Standard.
Design is not the same as design and construction. This is the interpretation of the European Commission. The sixth of the seven deviations identified in the European National (EN) version of the Risk Management Standard (i.e., EN ISO 14971:2012; http://bit.ly/ISO14971-2012changes), states that “inherent safety by design” is not precise enough. Section 2 of the Essential Requirements (i.e., Annex I of the MDD) states that the first risk control option must be selection of design and construction that eliminates or reduces risk as far as possible, while the international (ISO) risk management standard (i.e., ISO 14971:2007) only states that inherent safety by design is required.
The difference between the requirements of the ISO and the EN standard are not just semantics. If you read part II of the Essential Requirements (ERs; i.e., ER 7-13), there are many examples of how the construction of devices should be considered. The following are three examples:
ER 7.5 – leaking from the device
ER 8.2 – tissues of animal origin
ER 9.2 -aging of materials
Therefore, in order to comply the the intent of the Directive, you must consider far more than just the design of the device. Construction is interpreted as both the risks associated with the materials to fabricate a device and the methods of manufacture. In the proposed EU regulations, the European Commission seeks to clarify the requirements for implementation of risk controls, but the draft legislation still seems vague.
Implementing Risk Control Options for Medical Devices
The following wording for implementation of risk control options in the new proposed second Essential Requirement is below:
“The manufacturer shall apply the following principles in the priority order listed:
a. identify known or foreseeable hazards and estimate the associated risks arising from the intended use and foreseeable misuse;
b. eliminate risks as far as possible through inherently safe design and manufacture
c. reduce as far as possible the remaining risks by taking adequate protection measures, including alarms; and
d. provide training to users and/or inform users of any residual risks.”
In this proposed wording, the word “construction” was replaced by the word “manufacture.” However, in other parts of the new proposed Essential Requirements (http://bit.ly/NewERCGap) the materials of fabrication are specifically addressed, as well. For example:
ER 7.1d) was added as a new requirement…”d) the choice of materials used, reflecting, where appropriate, matters such as hardness, wear and fatigue strength.”
ER 7.6 was added as a new requirement to address risks associated with the size and properties of particles—especially nanomaterials.
The new proposed Essential Requirements also include numerous examples of how the manufacturing processes must ensure proper safety. Essential Requirement 10 specifically references new Commission Regulation (EU) No 722/2012 (http://bit.ly/AnimalTissueReg)–specific to devices manufactured using animal tissues or cells of animal origin.
Even though the proposed regulations are more detailed with regard to application of risk management, they do not specify if it is required to implement risk control options for both materials and methods of manufacture simultaneously, or if the manufacturer may choose between the two. The phrase “taking account of the generally acknowledged state of the art” is used in the second Essential Requirement, but “state of the art” is a moving target, and the European Commission may find existing Standards to be deficient.
For reducing the risk of infection, the Commission does not require that companies implement aseptic processing, antimicrobial materials and terminal sterilization. One of the three is sufficient. This is why we have ISO Standards for sterilization validation, and we define “sterile” as a sterility assurance level of 10-6.
If the Commission maintained the language of the ISO 14971:2007 Standard, “as low as reasonably practicable,” then manufacturers could select risk control options based upon acceptability of risk. However, the EN version of the risk management standard creates significant challenges for implementation, and we are forced to evaluate the risk control measures we implement against those used by other manufacturers during the process of risk option analysis.
The author reviews ISO 14971 Deviation #5, which is specific to selecting risk control options and protective measures for CE Marking medical devices.
If your company is CE Marking medical devices, you are required to satisfy the Essential Requirements for Safety and Performance as defined in the three European Directives: the MDD, the AIMDand the IVDD. Throughout these Essential Requirements, there is a requirement to reduce risks “as far as possible” (AFAP) by implementing risk controls. At one time, the expectation was for companies to implement the state of the art with regard to risk controls, and “state of the art” was interpreted as the latest version of the harmonized ISO Standards. However, lawyers dominating the European Commission appear to disagree with the status quo.
Therefore, in 2012, the European National (EN) version of the Medical Device Risk Management Standard was revised. There is no change to the content of Clauses 1 through 9. Instead, the European Commission identified seven content deviations between the ISO 14971 Standard and the EU Directives. These deviations are identified and explained in Annexes ZA, ZB, and ZC. This blog is the fifth installment of Medical Device Academy’s seven-part blog series on this topic. The goal of the series is to identify solutions for meeting the Essential Requirements by suggesting changes to the current best practices of implementing a risk management process for medical device design.
Discretion as to the Risk Control Options/Measures
Essential Requirement 1 and 2 require that risk control options are implemented for all risks prior to determining acceptability of residual risks. The 2nd Essential requirement also requires manufacturers to implement all risk control options—unless the risk controls do not further reduce risk.
Clause 6.2 of the 14971 Standard suggests that you only need to use “one or more” of the risk control options, and Clause 6.4 indicates that further risk control measures are not needed if the risk is acceptable. There is a clear contradiction between the intent of the Standard and the Directives.
If risk acceptability has no impact upon whether you will implement risk controls, there is really no need for performing a preliminary risk evaluation. Therefore, I have three recommendations for changes to your current risk management process:
Ignore Clause 5 of the 2007/2009 version of ISO 14971
Eliminate the second step of risk assessment from your flow chart for risk management (see Figure 1 from the 14971 Standard)
Define risk management policies upon clinical benefits, rather than absolute risks
Instead of performing a preliminary risk evaluation (Clause 6.5), risk/benefit analysis should be moved to Clause 7, where the evaluation of overall residual risk acceptability is required. By making this change, risk controls will be implemented, regardless of risk acceptability, and acceptability of risks will be dependent upon the risk/benefit analysis alone.
Impact of this Deviation
Implementing changes to your risk management process to address this deviation has great potential to impact the design of devices—not just the risk management documentation. Design teams will no longer be able to stop the design process with an initial design that has an “acceptable risk.” Instead, design teams will be forced to implement additional risk controls and protective measures for device designs that already have a low risk of harm for certain failure modes.
The requirement to implement additional risk controls will increase the cost of devices that may have been relatively safe without the risks controls. For example, if a device is not intended to be implanted, but it is a potential foreseeable misuse, then your company may have used the instructions for use to communicate the residual risk associated with misuse of the device. However, now your company will have to implement design controls (e.g., –selection of materials suitable for implantation) to eliminate the risks associated with misuse, and protective measures (e.g., – radio-opaque thread) to help retrieve product that was implanted in an “off-label” usage.
The author reviews ISO 14971 Deviation 4, which is specific to the requirement for risk-benefit analysis. This blog is the fourth in a seven-part series.
This blog is the fourth installment in our seven-part series, which reviews each of the content deviations between the three device directives for Europe and international risk management standard (ISO 14971:2007). The deviations were identified in the new European National version of the Standard released in 2012. There was no change to the content of Clauses 1 through 9 in ISO 14971, but the there were seven deviations from the directives identified by the European Commission.
Discretion as to Whether a Risk-Benefit Analysis Needs to Take Place
The fourth deviation is specific to the requirement for risk-benefit analysis. Clauses 6.5 and 7 of the 14971 Standard both imply that a risk/benefit analysis is only required if risks exceed a threshold of acceptability, and Annex D.6.1 indicates that “A risk-benefit analysis is not required by this InternationalStandard for every risk.” However, essential requirement 1 and 2 require that you perform a risk/benefit analysis for each risk and overall residual risk. Essential requirement 6a also requires a risk-benefit analysis as part of the conclusion in your Clinical Evaluation Report (http://bit.ly/ER6aMEDDEV).
Your company may have created a risk management procedure, which includes a matrix for severity and probability. The matrix is probably color-coded to identify red cells as unacceptable risks which require a risk/benefit analysis, yellow cells that are ALARP and green cells that are acceptable. Based upon the guidance provided in ISO 14971, your company probably identified that a risk/benefit analysis is only required for a risk which falls in the red zone of the matrix where the risk is “unacceptable.”
Unfortunately, this approach is not compliant with the European Directives, because the Directives require that a risk-benefit analysis be performed for each risk and all residual risks—not just the risks you identify as unacceptable. The fourth deviation between the ISO 14971 Standard and the Essential Requirements of the European Directives is relatively simple to address with a change to your risk management process. To comply with EN ISO 14971:2012, the “red zone” should not be labeled as risk-benefit analysis, because even risks in the “green zone” require risk/benefit analysis.
Impact of this Deviation
In a previous blog about deviation #2, we determined that all risks must be reduced by the implementation of risk controls. In this blog, we established that after implementation of risk controls, all residual risks must be subject to a risk-benefit analysis. Your company will need to eliminate the use of a risk evaluation matrix like the one shown above. Instead of relying on a risk management policy for evaluating the acceptability of risk, your company should be performing a risk/benefit analysis to determine the acceptability of risks.
The best way to integrate risk-benefit analysis for evaluation of acceptability of all risks is to integrate this with the clinical evaluation process. In addition to using clinical literature, clinical study data and post-market surveillance as inputs for your clinical evaluation, your company should also be using residual risks as inputs to the evaluation. The clinical evaluation should be used to assess the significance of these residual risks, and verify that there are not any risks identified in the clinical evaluation that were not considered in the risk analysis.
In order to document that your company has performed a risk-benefit analysis for each residual risk, you will need to reference the risk management report in the clinical evaluation and vice-versa. Both documents will need to provide traceability to each risk identified in the risk analysis, and conclusions of risk acceptability will need to be based upon the conclusions of the clinical evaluation.
Once the product is launched, you will need to update the clinical evaluation with adverse events and other post-market surveillance information. As part of updating clinical evaluations, you will need to determine the acceptability of the risk when weighed against the clinical benefits. These conclusions will then need to be updated in the risk management report—including any new or revised risks.