Medical device FMEA using IEC 60812

An FMEA is a systematic, bottom up analysis. The design or process is first broken down into items: assemblies, components, or process steps. For each item, the analysis asks how it can fail, why, and what the failure does, first to the item itself and then to the device as a whole. IEC 60812, the International Electrotechnical Commission standard for FMEA, sets out the method.

The analysis climbs one level at a time. The effect of a failure at a lower level becomes the cause of a failure at the next level up, until the effect on the whole device is reached.

An FMEA pays off most when it is done early, while a design change is still cheap, and it has to be revised every time the design changes. It is a team exercise: design, quality, manufacturing, and clinical people each see failure modes the others miss.

• Failure mode. The manner in which an item fails. Shaft separates under tension.
• Cause. Why it fails. Bond strength below specification.
• Local effect. What the failure does to the item itself. Shaft parts at the hub bond.
• End effect. What it does at the level of the whole device, and to the patient. Retained fragment in the vessel.

Severity is scored on the end effect. A row that writes a cause where the failure mode belongs, or stops at the local effect, cannot be scored correctly.

The three kinds ask different questions, and a row belongs in the one whose question it answers.

• Design FMEA. Can the design, as specified, fail to do its job? Rows start from the characteristics of a part or assembly.
• Process FMEA. Can a manufacturing step make the product wrong? Rows start from process steps: fabrication, assembly, labeling, cleaning, sterilization, packaging.
• Use FMEA. Can a user make an error that leads to harm? Rows start from user tasks.

A part made out of tolerance is a process failure. A design that is wrong can pass every factory inspection, because every part matches the drawing.

Every row carries three scores, each from 1 to 5 in rmForge.

• Severity is how bad the end effect is. rmForge scores it on the worst credible outcome, not the typical one.
• Occurrence is how often the failure mode happens. IEC 60812 asks that the time period behind the estimate be stated. rmForge counts a Design FMEA per unit over the device's labeled life, or per use for a single use device, and prints that basis in the workbook.
• Detection is how likely the failure is to be caught before it matters, and where. IEC 60812 separates the two kinds. In a Design FMEA, the design deficiency is found by review, analysis, simulation, or test. In a Process FMEA, the defect is found in the process: by an operator, statistical process control, a quality check, or a later step.

That split is where many FMEAs go wrong. Final inspection finds a part made wrong. It cannot find a design that is wrong, so in rmForge it earns no Detection score in a Design FMEA. It belongs in the Process FMEA.

The traditional Risk Priority Number (RPN) multiplies the three scores. The scores are rankings, not measurements, and multiplying rankings misleads. On the common 1 to 10 scales, a failure scored Severity 10, Occurrence 3, and Detection 2 comes to 60, while one scored 5, 5, and 5 comes to 125. The failure that can kill ranks below the ordinary one. Different combinations land on the same number, and only 120 of the numbers from 1 to 1,000 can occur at all.

rmForge multiplies nothing. The Risk Level comes from Severity and Occurrence through a fixed table, the same table the Hazard Analysis uses, with the same four levels: Low, Medium, High, and Unacceptable. A Severity 4 or 5 failure never lands in Low.

The RPN, from 1 to 20, is read from a second fixed table of Risk Level against Detection. It sets the order rows are worked in within a level, and that is all. Detection never moves a row from one level to another, and the RPN never decides whether a risk is acceptable. Both tables are printed in the workbook, and the Risk Level and RPN cells are live formulas, so a reviewer who changes a score sees the result change with it.

ISO 14971, the International Organization for Standardization standard for medical device risk management, requires the risk management process. It does not require an FMEA. An FMEA is one technique inside that process, and it has to agree with the Hazard Analysis. In rmForge, an FMEA is built only on a finished Hazard Analysis that you have accepted as its baseline, and the rmForge operator records that acceptance with the date.

• Every FMEA row lists the Hazard Analysis rows it can lead to, by their HZ numbers, or says why it has none: missing from the Hazard Analysis, or no safety consequence.
• A row is never scored below the most severe hazard it links to, and the same end effect carries the same Severity everywhere in the file. The software raises a lower score. It never lowers one.
• The FMEA writes no risk controls of its own. It carries the Hazard Analysis Risk Control Measures that apply to it, word for word, so the two files cannot describe the same control two different ways.
• The Hazard Analysis workbook gains two columns, DFMEA Cross-Ref and PFMEA Cross-Ref, so the link reads in both directions.

In a Design FMEA, the artificial intelligence (AI) says which of your requirements govern each failure mode and whether each one is aimed at it. The software then sets Detection from your requirements matrix, the document that ties each design input to its design output and its verification record.

• 1. A released verification record aimed at the failure mode, with its acceptance criterion stated.
• 2. The same, with the acceptance criterion still to be determined.
• 3. A released record not aimed at the failure mode that could still reveal it, such as a system level test.
• 4. A requirement whose verification report is not cited yet, or a record that covers the item only indirectly.
• 5. No requirement governs it, or no requirements matrix was supplied.

Each FMEA is its own multi-column Excel workbook. A Design FMEA row carries the item, its part number and function, the failure mode, effects and cause, the detection method and its record, the three scores, Risk Level and RPN, the Hazard Analysis links, the carried risk controls, and the revised scores. A Process FMEA row has the process step and step number in place of the item, and a link back to the Design FMEA.

Both workbooks carry the same reference tabs: a Cover Page, a Transferred Rows tab, a Column Guide, the Risk Level and RPN tables, the Scales, a gaps tab for the Hazard Analysis, a gaps tab for your requirements matrix or control plan, and a Disclaimer.

Part numbers come from the item list confirmed with you in the working session, never from the AI.

The rmForge operator builds the Design FMEA or the Process FMEA with you in a working session, from your finished Hazard Analysis and your own records: the bill of materials and requirements matrix for the Design FMEA, the process flow or control plan for the Process FMEA. AI drafts the failure modes, effects, causes, and first scores. Fixed rules set the Risk Level, the RPN, the Design FMEA Detection score, and the Severity floor from the Hazard Analysis.

Each workbook is a draft. It requires qualified cross functional review and approval by your team, and rmForge does not determine regulatory compliance or guarantee that a submission is accepted.