Why Analyze How a Dosing Rule Can Fail?
A dosing rule can produce an appropriate recommendation only if the whole workflow functions as intended: relevant information is available, the rule is applied correctly, its output reaches the right person, and the resulting action is suitable for the patient. A risk analysis focused only on the model’s calculation can miss failures elsewhere in that chain. Failure mode and effects analysis (FMEA) provides a structured way to ask, prospectively, how could each step fail, what might cause that failure, what could happen to the patient, and what controls are needed?
For a dosing workflow, FMEA is most useful when it is specific enough to identify actionable risks. “The system could be wrong” is not a useful failure mode. “A dose recommendation is calculated from a weight recorded in kilograms but interpreted as pounds” identifies a particular way the process could fail and supports targeted controls. FMEA does not establish that a failure will occur or prove that a control is effective. It helps a team organize its risk judgments and make improvement priorities explicit.
Set the Scope Before Scoring
Begin by defining the workflow under review: its starting point, ending point, intended users, patient population, and relevant operating conditions. For example, a review might begin when a clinician enters patient information into a dosing system and end when the recommended dose is administered. It should be clear whether the analysis covers data entry, rule execution, communication of the recommendation, clinical review, and follow-up. A vague boundary encourages either gaps (“that step belongs to someone else”) or an unmanageable list of every possible problem in care.
Break the workflow into steps that are concrete enough to analyze. At each step, ask how the intended action could fail, what conditions could cause that failure, and what the consequences could be. Record existing controls separately from proposed actions. A control might prevent an error, detect it before it reaches the patient, or reduce harm after it occurs. The specific safety gates, input checks, escalation rules, and monitoring processes used in a dosing workflow can therefore be examined as controls without assuming that their presence makes the process fail-proof.
| FMEA element | Question to ask | Dosing-workflow example |
|---|---|---|
| Process step | What is supposed to happen? | Enter the patient’s current weight. |
| Failure mode | How could this step fail? | The entered weight is incorrect. |
| Cause | Why might it fail? | A value is transcribed from an outdated record. |
| Effect | What could follow? | The calculated dose may be too high or too low. |
| Existing control | What currently prevents, detects, or limits it? | The system displays the source and date of the weight. |
| Recommended action | What additional change could reduce risk? | Require confirmation of a recent weight before calculation. |
Be precise about effects. A near-term effect could be an erroneous dose recommendation; a downstream effect could be inadequate treatment or toxicity. The severity rating should reflect the credible clinical consequence under the defined use, rather than how conspicuous the software error might be. State assumptions and uncertainties, including whether a clinician would normally review the output before administration.
Scoring and Prioritizing Failure Modes
Many FMEA teams assign ordinal ratings for severity, occurrence, and detectability. The scales must be defined for the workflow and agreed on before scoring. A common convention is that higher severity means more serious potential harm, higher occurrence means the failure is more likely or more frequent, and higher detectability means it is less likely to be detected in time. Because detectability direction is easy to reverse, write the convention directly on the scoring form.
A team may calculate a risk-priority number (RPN) as the product of these ratings:
Here \(S\), \(O\), and \(D\) are ratings on the team’s chosen scales, not measured quantities. For example, if each is rated from 1 to 5, the resulting RPN ranges from 1 to 125. It is a prioritization aid, not a probability of harm, an expected number of events, or a universal threshold. Multiplying ordinal ratings assumes more numerical meaning than those scales necessarily have, so the RPN should be considered alongside the ratings themselves, the rationale, and clinical judgment.
Worked Example: Separating a Failure Mode from Its Cause and Effect
Hypothetical scenario. A dosing workflow uses a current laboratory result to calculate a recommendation. The team is reviewing the step in which the result is selected. The system can display a result from an earlier encounter, and the clinician may not notice its date.
Process step: select the laboratory result used by the rule. Failure mode: an outdated result is used. Cause: the interface presents older and current results similarly, and the selected result’s date is not prominent. Potential effect: the recommendation may not reflect the patient’s current status and could lead to an inappropriate dose. These are different statements: changing the interface may address a cause, while displaying the result date or blocking use of a result outside an approved time window may serve as controls.
For illustration, suppose the team has defined 1-to-5 scales, with higher detectability scores indicating greater difficulty detecting the failure before action. The team assigns \(S=4\), \(O=2\), and \(D=4\). Then:
The RPN is 32 on this team’s scale. It does not mean a 32% chance of harm. The relatively high severity and difficulty of detection warrant a discussion of controls even though the occurrence rating is low. The team should document why it assigned each rating rather than recording only the product.
From Risk Review to Controls
FMEA is useful only when its findings lead to considered action. For each prioritized failure mode, specify the control, the point in the workflow where it operates, who is responsible, and how the team will check that it works as intended. Prefer a control that changes the process so the failure is less likely or is caught before reaching the patient over a control that relies only on a user remembering to be careful. In practice, controls can be combined: a system check might flag an invalid input, while a clinician review provides another opportunity to catch an unsafe recommendation.
A short justification clarifies why this review should not stop at the initial RPN. Suppose the occurrence rating represents a team’s coarse ordering of how often a failure is expected, and a proposed control is intended to prevent it. If the control is implemented and shown to reduce the failure’s occurrence, the occurrence rating may be reconsidered. If it instead makes the failure easier to detect before administration, the detectability rating may change. The severity rating ordinarily does not fall merely because detection improves: the potential consequence if the failure reaches the patient remains serious.
Therefore, reassessing a control requires asking which part of the risk it changes, and whether there is evidence for that change. A lower post-action RPN is not itself evidence that the control works. The team should verify implementation and examine relevant process evidence, such as whether the check is consistently applied and whether it identifies the intended problem. A proposed control should not be credited as an existing control before it is implemented and evaluated.
Worked Example: Prioritizing a Severe Failure Alongside a Frequent One
Hypothetical scenario. A team uses a 1-to-5 scale for all three ratings, with higher detectability meaning harder to detect in time. It reviews two failure modes in the same dosing workflow.
For a wrong-unit entry that could cause serious harm, the team assigns \(S=5\), \(O=1\), and \(D=2\). Its RPN is:
For a frequent formatting problem that causes a recommendation to be displayed unclearly but is usually corrected during review, it assigns \(S=2\), \(O=4\), and \(D=2\). Its RPN is:
The second RPN is larger, but that does not justify addressing it first in every circumstance. The first failure has a higher severity rating and could warrant a control or further review despite its lower RPN. The team should examine the consequences, current safeguards, and uncertainty in both assessments, and document its rationale for action. The arithmetic supports comparison; it does not make the decision automatically.
Worked Example: Reassessing a Proposed Control
Hypothetical scenario. A team rates use of an incorrect unit as \(S=5\), \(O=2\), and \(D=4\), where higher \(D\) means harder to detect before the dose is acted on. Its initial RPN is:
The team proposes a unit-specific input field that rejects values outside a clinically approved range and displays the unit beside the entered value. Suppose evaluation after implementation supports changing the ratings to \(S=5\), \(O=1\), and \(D=2\). The revised RPN is:
The severity remains 5 because the potential consequence if an incorrect-unit error reaches the patient has not changed. The lower occurrence and detectability ratings are justified only if the team has evidence that the control prevents more errors and makes remaining errors easier to catch. The revised value of 10 describes the team’s updated rating, not a measured reduction in harm or proof that no such error can occur.
Diagnostics, Limitations, and Common Pitfalls
Warning signs of a weak FMEA include broad failure-mode descriptions, effects that stop at “wrong dose,” causes that are simply restatements of the failure, and controls listed without an owner or evidence of operation. Look for empty workflow steps: if no one has considered how data are transferred, recommendations are communicated, or exceptions are handled, the review may have a boundary gap. Check whether participants with different roles have reviewed the process; a technically correct account of the software may still omit how recommendations are used in practice.
- Do not confuse ratings with measured frequencies. An occurrence score is not an empirical rate unless it is explicitly based on suitable data and defined that way.
- Do not let RPN hide a severe hazard. Inspect the severity rating and the reasoning behind it, even when the product is modest.
- Do not count a proposed control as established. Record its implementation and evaluate its performance before treating it as part of the current process.
- Do not assume a control eliminates risk. A check can be bypassed, misconfigured, or ineffective under particular conditions.
FMEA is not a substitute for quantitative risk estimation when suitable data and a suitable model are available. It can also be affected by incomplete process knowledge, disagreement among raters, and a tendency to overlook rare combinations of failures. A single failure-mode review may not capture how multiple safeguards can fail together. Those limitations make documentation important: record the scoring definitions, assumptions, evidence, unresolved uncertainties, and reasons for prioritization. Revisit the analysis when the workflow, patient population, rule, or operating context changes.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A rule uses a dose-weight input. State one plausible failure mode, one distinct cause, and one potential effect.
- On a 1-to-5 scale, a failure has \(S=3\), \(O=2\), and \(D=5\). Calculate its RPN and explain what the number does not mean.
- Why might a failure with a smaller RPN still deserve prompt attention?
- A proposed alert is expected to make an error easier to detect but does not prevent the error. Which rating might change, and which ordinarily should not change just for that reason?
- Name two pieces of information a team should record to make its FMEA ratings interpretable.
Solutions. (1) A failure mode could be entry of an incorrect weight; a distinct cause could be transcription from an outdated record; a potential effect could be an inappropriate dose recommendation. (2) \(\mathrm{RPN}=3 \times 2 \times 5=30\). It is a product of the team’s ordinal ratings, not a 30% probability of harm. (3) Its severity rating may reflect a credible serious consequence that the RPN product obscures; the ratings and clinical rationale should be considered directly. (4) Detectability may improve, represented by a lower \(D\) if the scale defines higher scores as harder to detect. Severity ordinarily remains unchanged because the potential consequence if the error reaches the patient is unchanged. (5) Answers include the rating-scale definitions, the assumptions about the workflow, evidence supporting the ratings, and the rationale for prioritization.