FMEA risk scoring for a submission package

Submission risk is usually held in someone's head. A lead who has filed before knows which parts of this package worry them, and that instinct is often right. It is also invisible, unrankable and gone the moment that person changes teams. When risk lives only as a feeling, you cannot say which worry is the biggest, whether it got better since the last dry run, or what was done about it.

Manufacturing solved a version of this decades ago with Failure Mode and Effects Analysis. r4subrisk, part of our open source R4SUB toolkit, brings the same discipline to a filing: every known way the submission could fail becomes a row in a register with a score, so risk is something you can sort, track and close.

Three factors, one number

Each failure mode is rated on three axes, each from 1 to 5:

Probability, how likely the failure is. Impact, how much it hurts the review if it happens. Detectability, how likely you are to catch it before it reaches the agency, where a high score means hard to detect. The Risk Priority Number is the product of the three, so it runs from 1 to 125.

The multiplication is the point. A failure that is unlikely but catastrophic and easy to miss scores higher than a common but visible and harmless one, which is exactly the ordering a filing team wants and the ordering a flat checklist cannot produce. Detectability earns its place as a factor because the failures that sink reviews are rarely the ones everybody can see; they are the ones nothing was looking for.

A register, not a one-time exercise

The output is a risk register: one row per failure mode, its three ratings, its RPN, an owner, and the mitigation. That last column is what turns the score into work. A high RPN with no mitigation is an open action; a high RPN whose mitigation is a check that now runs on every build is a risk brought under control, and the register records both the before and the after.

Because the register is scored the same way each time, it trends. Run it across the dry runs on the way to filing and the total risk should fall as mitigations land and detectability improves. A risk whose RPN does not move is a mitigation that is not working. A new high-RPN row appearing late is a late surprise you want to see in the register rather than in an Information Request.

What it is trying to prevent

The failure modes worth registering are the ones with real regulatory cost: a Refuse-to-File on a package that looked complete, a run of Information Requests that each add a cycle, a reviewer who cannot follow a key derivation and asks for a rework. Naming those as failure modes, rating them and mitigating the top of the list is a cheaper way to spend the weeks before a filing than discovering them after it.

The register does not stand alone. Its aggregate feeds the Risk pillar of the Submission Confidence Index, sitting alongside Quality, Traceability and Usability, so an unmitigated high-RPN item pulls the readiness score down until it is closed. Risk stops being the part of readiness that everyone senses and no one can point to, and becomes a ranked list with an owner against each line.

The R4SUB packages

R4SUB is open source and MIT licensed. The FMEA risk model and RPN registers are implemented in r4subrisk (on CRAN), part of the R4SUB ecosystem (r-universe).