Written and maintained by CASRAI Editorial Board
Last updated
Failure to rescue (FTR) does not measure how often patients develop complications. It measures how often a complication, once it has happened, ends in death. That distinction is the entire point of the metric, and it is the one most dashboards blur when they file FTR next to a hospital’s overall mortality rate as if the two answer the same question. For infection preventionists, patient-safety officers, quality directors, and risk managers, getting the numerator and denominator right is what separates a program that actually targets surveillance and rescue capability from one that is quietly re-measuring case mix and calling it quality.
The Numerator and Denominator, Precisely
FTR is a conditional measure. It is not calculated across every discharge or every death in a hospital — it is calculated only within the subset of patients who already had a defined, serious complication.
- Denominator: patients who underwent a qualifying procedure (in most operational versions, surgical patients) and went on to develop one of a defined set of serious, potentially survivable complications — for example, categories like postoperative sepsis, pneumonia, deep vein thrombosis or pulmonary embolism, shock or cardiac arrest, gastrointestinal hemorrhage, or acute renal failure recur across the major versions of this measure. The exact current list of qualifying complications is set by whichever technical specification a hospital is reporting against, and that list is revised periodically — treat any specific complication roster as time-bound, not fixed.
- Numerator: the subset of that denominator population who died, rather than survived the complication.
Everything follows from that structure. A patient who dies without ever developing one of the qualifying complications does not enter the calculation at all — that death belongs to the hospital’s overall mortality rate, not to FTR. A patient who develops a qualifying complication and survives counts in the denominator but not the numerator, and pulls the rate down. Only death after a qualifying complication moves FTR.
Two Definitions in Circulation, Not One
“Failure to rescue” gets used loosely, but two specific operationalizations sit behind most of what’s cited under that name, and hospitals reporting the measure should know which one a given source or benchmark is actually using.
The original epidemiological definition (Silber et al., 1992)
The term originates with Silber JH, Williams SV, Krakauer H, and Schwartz JS, “Hospital and patient characteristics associated with death after surgery: a study of adverse occurrence and failure to rescue” (Medical Care, 1992;30(7):615–29), a study of 5,972 Medicare patients undergoing elective cholecystectomy or transurethral resection of the prostate. The paper’s contribution was separating three distinct outcomes that quality reporting had previously blurred together: the death rate, the adverse-occurrence (complication) rate, and the failure rate — deaths conditioned on having had an adverse occurrence. That three-way split is the conceptual ancestor of every FTR measure since.
AHRQ PSI 04 and its administrative-claims respecification
AHRQ operationalized the same concept as an administrative-data indicator: PSI 04, Death Rate among Surgical Inpatients with Serious Treatable Complications. Like every AHRQ Patient Safety Indicator, PSI 04 is built entirely from ICD-10-CM/PCS diagnosis and procedure codes already present on a hospital’s claims, gated by Present on Admission (POA) coding — a complication that was already present on admission (POA flag Y or W) does not count as a hospital-acquired event and is excluded from the numerator logic; only complications coded N or U as POA are eligible to trigger. That POA gate is exactly what keeps PSI 04 measuring what happened during the stay rather than what the patient arrived with. See our guide to the POA indicator for the full Y/N/U/W coding mechanics, and our walkthrough of the broader AHRQ Patient Safety Indicators and the PSI 90 composite for where PSI 04 sits relative to the indicators that do roll into PSI 90 — it notably does not; PSI 04 is reported as a standalone indicator, not a PSI 90 component.
AHRQ’s Patient Safety Network additionally reports that CMS has respecified this concept as a chart-and-claims-based outcome measure — the “Thirty-day Risk-Standardized Death Rate among Surgical Inpatients with Complications” — adopted for the Hospital Inpatient Quality Reporting program beginning federal fiscal year 2027. Where PSI 04 is a same-admission, ICD-code-driven screen, the newer CMS measure extends the death window to 30 days post-procedure and risk-standardizes across hospitals. A quality team reporting FTR internally should confirm which version a given benchmark or peer comparison is actually built on before treating two “FTR rates” from different sources as comparable.
Why FTR Is Read as a Surveillance/Response Proxy, Not a Prevention Measure
This is the operational reason FTR earns a place on a patient-safety dashboard distinct from complication-rate measures like the PSI 90 components: a hospital’s complication rate and its FTR rate are not the same axis, and they can move independently. A hospital can have a comparatively high rate of qualifying complications — driven by case mix, procedure volume, or patient acuity — and still rescue most of those patients, producing a low FTR. Conversely, a hospital with a low complication rate can still fail to recognize and respond to the complications it does have, producing a high FTR despite looking “safe” on a raw complication count. Because case mix and procedure selection already condition the denominator, FTR is read as isolating a different capability than complication prevention: whether the organization’s surveillance systems detect a deteriorating patient in time, and whether its response systems — escalation pathways, rapid response activation, staffing, diagnostic turnaround — act on that detection before the complication becomes fatal.
That is why FTR sits naturally alongside rapid response and early-warning infrastructure rather than alongside infection-prevention bundles aimed at stopping the complication from occurring in the first place. Our guide to rapid response team activation criteria uses FTR as the programme-level outcome measure for exactly this reason — it is the number a rapid response system is conceptually built to move, even though, as covered below, attributing a specific FTR change to a specific rescue system is harder than it sounds.
How FTR Interacts With Related Patient-Safety Measures
FTR does not operate in isolation from a hospital’s other surveillance and reporting infrastructure:
- Sepsis is one of the most common qualifying complications feeding FTR’s denominator in surgical populations, which links FTR performance directly to how reliably a hospital’s teams execute the SEP-1 sepsis bundle once sepsis is suspected in a postoperative patient.
- POA coding accuracy determines whether a complication is even eligible to enter the FTR/PSI 04 calculation in the first place — see the POA indicator guide for how documentation gaps at admission can misclassify a hospital-acquired complication.
- Case review of individual FTR events is where the measure becomes actionable rather than just a rate on a scorecard — our guide to the morbidity and mortality (M&M) conference covers the structured peer-review process hospitals use to work through why a specific rescue failed, and the peer-review protections that shape what gets documented.
- PSI 90 and the broader AHRQ PSI module measure complication occurrence itself; see AHRQ Patient Safety Indicators explained for how PSI 04 relates to (and stays outside) that composite.
For the broader programme context these measures sit inside, see the patient safety pillar.
Where the Evidence Gets Contested
Two limitations are worth stating plainly rather than glossing over, because they affect how much weight a quality committee should put on FTR movement as evidence that a specific intervention worked.
Attribution is weaker than the intuitive story suggests. It’s tempting to treat “we stood up a rapid response team, so our FTR should fall” as a straightforward causal chain. The evidence doesn’t fully support that. A 2010 systematic review and meta-analysis of rapid response team implementations (Chan PS, Jain R, Nallmothu BK, Berg RA, Sasson C, Archives of Internal Medicine, 2010;170(1):18–26 — 18 studies, roughly 1.3 million admissions) found a real reduction in non-ICU cardiopulmonary arrest in adults (33.8% reduction, RR 0.66, 95% CI 0.54–0.80) but no statistically significant reduction in overall hospital mortality (RR 0.96, 95% CI 0.84–1.09) — the authors’ own conclusion was that “robust evidence to support their effectiveness in reducing hospital mortality is lacking.” A later 2018 review reported a modest mortality benefit (RR 0.85, 95% CI 0.76–0.94) but graded the underlying evidence low quality given heterogeneity across studies. FTR is the outcome a rapid response system is designed to move, but a falling FTR rate and a functioning rapid response programme are correlated, not proven causally linked, in the published evidence base.
Small denominators make the rate volatile. Because FTR’s denominator is restricted to patients who already had a qualifying complication, a hospital with a modest surgical volume can see its FTR rate swing sharply on a handful of cases in either direction. Reviewing FTR trends on a rate alone, without also tracking the underlying case count, risks reading noise as a signal.
Frequently Asked Questions
Is failure to rescue the same as hospital mortality rate?
No. Overall mortality counts every death in the hospital or after a procedure, regardless of whether the patient had a complication. FTR only counts deaths among the subset of patients who already developed one of a defined set of serious complications. A hospital’s overall mortality rate and its FTR rate can move in different directions.
What counts as a “serious complication” for failure-to-rescue purposes?
It depends on which specification is being used. Across the major versions of the measure, qualifying complications commonly include categories such as postoperative sepsis, pneumonia, deep vein thrombosis or pulmonary embolism, shock or cardiac arrest, gastrointestinal hemorrhage, and acute renal failure. The authoritative, current list is set by the specific technical specification (AHRQ PSI 04’s specification, or a payer/registry’s own definition) a hospital is reporting against, and that list is periodically revised.
Does a low failure-to-rescue rate mean a hospital has fewer complications?
Not necessarily. FTR and a hospital’s raw complication rate are different axes. A hospital can have a relatively high complication rate but rescue most of those patients (low FTR), or a low complication rate but still fail to detect and respond to the complications it does have (high FTR). That’s the basis for treating FTR as a surveillance-and-response measure rather than a complication-prevention measure.
Is PSI 04 the same measure as the original Silber “failure to rescue” definition?
They share the same underlying logic — death conditioned on a prior complication — but PSI 04 is AHRQ’s specific administrative-claims operationalization of that concept, built from ICD-coded diagnoses and POA flags, whereas Silber’s 1992 study used its own study-specific population and complication criteria. Treat PSI 04, any given payer or registry’s own FTR definition, and CMS’s newer 30-day risk-standardized respecification as related but distinct measures, not interchangeable numbers.
Why does failure to rescue matter to infection prevention specifically?
Sepsis and other infection-related complications are among the most frequently occurring qualifying complications feeding FTR’s denominator in surgical populations, which means an infection preventionist’s surveillance and early-recognition work is directly upstream of whether a complication gets caught in time to avoid the numerator. FTR performance is one of the places infection prevention, rapid response, and quality reporting functions have to coordinate rather than operate as separate programmes.
