Transfers fail in the days after the transfer, not just during it. If 988 escalates to 911 and never receives outcome information, the system cannot learn, cannot update risk plans, and cannot prevent repeat escalation for the same person and household. Closed-loop feedback is therefore a core reliability function, not an optional “nice to have.” This article sits within 988–911 crisis routing and interfaces and supports practical crisis response models where accountability includes what happens after dispatch, not only what happens during the handoff.
Why outcome feedback is the hidden control that stops repeat crisis routing
In real operations, 988 often knows only that a call was transferred, not whether responders arrived, what disposition occurred, whether the person was transported, diverted, refused care, or stabilized at home. Without that information, 988 cannot calibrate triage accuracy. Services cannot correct false positives (defensive escalations) or false negatives (delayed escalation). Families also lose trust: they experience repeated storytelling, repeated dispatch, and repeated system friction with no visible improvement.
Two oversight expectations shape this domain. First, funders and system owners increasingly expect evidence of closed-loop care continuity: documented follow-up attempts and credible integration with downstream responders, not just call-answer metrics. Second, PSAP and emergency response partners expect governance that reduces repeat utilization and misrouting by feeding operational learning back into protocols, scripts, and cross-agency agreements.
Define “feedback” as a minimum dataset with a time standard
Closed-loop feedback should be defined as a minimum dataset that returns to 988 within a defined time window. A workable minimum dataset typically includes: whether dispatch was accepted, response time band (not necessarily minute-by-minute), responder type (EMS, law enforcement, co-responder, fire), field disposition (transported, treated on scene, refused, not located), and safety flags relevant to future routing (violence risk indicators, medical triggers observed, communication needs, and any protective factors confirmed).
Crucially, feedback must be linkable. That requires a shared incident identifier created at the time of transfer, plus a record-matching method that does not rely on perfect spelling or a single data field. Systems that skip this step end up with “feedback” that cannot be reconciled, making learning impossible and creating avoidable privacy disputes because staff improvise data sharing.
Operational Example 1: Dispatch accepted, but no responder located the person—preventing repeat “unknown location” escalations
What happens in day-to-day delivery: A 988 counselor transfers a high-risk call to 911, generating a shared incident identifier and recording a structured location narrative (exact address if known, landmarks, entry instructions, and whether the person is mobile). Within 24 hours, the PSAP outcome feed (or agreed manual workflow) returns a disposition: “not located / unable to access.” A 988 follow-up specialist reviews the record, contacts the original caller if appropriate, and updates the crisis plan with an improved location strategy: confirming address format, establishing a safe callback method, and documenting the best way to direct responders (gate codes, nearby landmarks, safe approach guidance). The updated information is stored in the 988 case record and used in future contacts.
Why the practice exists (failure mode it addresses): “Not located” outcomes are a major driver of repeat escalation because the system repeats the same failure. Without feedback, 988 assumes dispatch equals response, and the same household later calls again with higher urgency and lower trust.
What goes wrong if it is absent: The system treats the transfer as finished. When the person recontacts or a family member calls again, the same incomplete location narrative is used, producing another failed response. Over time, escalation becomes more forceful and more law-enforcement-heavy because responders arrive with less certainty and higher perceived risk.
What observable outcome it produces: Reduced repeat dispatch for the same location failure pattern, improved responder access on subsequent events, and an auditable trail showing that the system learned from an outcome and corrected the operational cause rather than blaming the caller.
Operational Example 2: Transport occurred, but 988 never learns where the person went—building a post-transport continuity bridge
What happens in day-to-day delivery: A 988 counselor escalates to 911 due to imminent risk and medical uncertainty. The outcome feed returns: “transported to ED.” A 988 continuity workflow triggers a same-day or next-day outreach attempt with the caller or designated support person (when consent and policy allow) to confirm basic continuity questions: current location, discharge expectations, medications changed, and follow-up appointment timing. The 988 team records a stabilization plan that includes a clear recontact pathway, warning signs for deterioration, and a structured follow-up contact schedule for the next 72 hours. The plan is designed so future calls do not default immediately to 911 because continuity is missing.
Why the practice exists (failure mode it addresses): A large share of repeat crisis calls occur after ED discharge because the person returns home with incomplete follow-up and unclear ownership. Without a continuity bridge, the system recreates crisis conditions and repeat dispatch becomes the default safety mechanism.
What goes wrong if it is absent: 988 has no idea whether transport occurred, whether the person was discharged, or what changed. The next call begins with uncertainty, the family is forced to retell the story, and the safest operational choice becomes “send 911 again,” even when a structured post-discharge plan could have reduced risk.
What observable outcome it produces: Measurable reductions in repeat contacts driven by “unknown disposition,” improved follow-up appointment completion, and improved documentation that shows continuity actions were taken after a high-risk event.
Operational Example 3: “Defensive escalation” learning loop—using outcomes to recalibrate triage thresholds
What happens in day-to-day delivery: Over a month, QA identifies a cluster of 988 calls escalated to 911 for “agitation and possible violence,” but outcome data repeatedly shows “no crime, no medical transport, resolved on scene.” A joint review group (988 clinical lead, PSAP liaison, and responder representative) examines a sample of calls. They identify a pattern: escalation was triggered by ambiguous language from third-party callers and inconsistent questions about immediate intent and access to weapons. The teams update the script, add a clearer decision gate for third-party information quality, and retrain staff using scenario-based coaching. Outcome data is then monitored to confirm whether unnecessary dispatch falls without increasing missed risk.
Why the practice exists (failure mode it addresses): Systems drift into defensive escalation when they cannot see what happens after dispatch. Outcome feedback allows triage thresholds to be refined with evidence rather than fear, protecting safety while preserving 911 capacity.
What goes wrong if it is absent: 988 continues escalating at a high rate with no learning signal. 911 and responders experience growing burden and may become resistant to 988 transfers. Meanwhile, callers learn that contacting 988 results in dispatch even when it is not necessary, reducing engagement and increasing direct 911 use.
What observable outcome it produces: Fewer unnecessary dispatches, stronger alignment between 988 and 911 on escalation thresholds, and a defensible audit trail showing that changes were made in response to observed outcomes rather than anecdote.
Governance mechanics: who owns feedback, and how disputes are resolved
Closed-loop feedback fails when it is everyone’s responsibility and no one’s job. A practical governance model assigns a named owner for the feedback process in each agency, defines the minimum dataset, sets a time standard (for example, same-day for high-risk events, within 24–72 hours for routine escalations), and specifies how record linkage works. It also defines a dispute pathway for mismatches and privacy concerns so staff do not freeze when questions arise.
In commissioner and funding environments, the most defensible position is to treat closed-loop feedback as a performance requirement tied to system learning: QA review cadence, joint governance meeting frequency, and a documented change-log showing what was improved as a result of outcomes.
How to evidence success without turning feedback into surveillance
Good systems measure what they need to reduce harm: percentage of escalations with a matched outcome record, time-to-feedback for high-risk calls, repeat-contact rates after transport or “not located” outcomes, and the proportion of protocol updates linked to outcome-driven learning. These measures demonstrate system improvement while avoiding unnecessary collection of sensitive detail that does not change the operational pathway.