Disruptions in community care rarely stay inside one organization. County incident coordination, hospital discharge pressure, pharmacy and DME constraints, and local emergency management decisions all shape what HCBS providers can deliver. This guide, part of After-Action Reviews & System Learning, supports Continuity of Operations Planning (HCBS/LTSS) by showing how to run a multi-agency AAR that produces cross-system fixes—without turning into a blame meeting or a vague “lessons learned” document.
Why multi-agency AARs are different in HCBS
Internal AARs can change internal workflows. Multi-agency AARs must also change interfaces: referral pathways, escalation routes, data handoffs, and service authorizations during abnormal operations. In practice, the hardest failures are the seams—unclear authority for service exceptions, conflicting information to families, duplicated welfare check efforts, or discharge activity that outpaces available community capacity. A multi-agency AAR must surface these seam failures, agree what “good” looks like across partners, and assign corrective actions that each organization can actually implement and evidence.
Two oversight expectations that shape multi-agency learning
Expectation 1: Shared situational awareness and role clarity. Counties, payers, and oversight partners often expect providers to show they understand who holds decision authority during disruptions and how information is coordinated. Multi-agency AARs should prove that the system clarified roles and reduced future confusion.
Expectation 2: Corrective actions that address cross-system failure modes. When adverse impacts stem from interagency breakdowns (late discharge notifications, inconsistent guidance, delayed approvals), reviewers typically look for joint corrective actions, not only internal policy edits.
Define scope before the meeting: what is being reviewed and what is not
Multi-agency AARs can collapse under their own breadth. A disciplined scope statement should include: the disruption period (start/end), the affected populations (e.g., waiver participants with high acuity), and the operational objectives being evaluated (service continuity, safety escalations, medication access, welfare checks, and communications). It should also explicitly exclude non-productive themes, such as assigning individual fault or re-litigating policy positions unrelated to the operational interface. When scope is clear, the meeting can focus on the system mechanics that can be improved.
Operational Example 1: Building a shared timeline that survives disagreement
What happens in day-to-day delivery
The AAR coordinator (often a county lead or a designated convener) requests time-stamped artifacts from each organization: county situational reports, provider on-call logs, hospital discharge notifications, EMS/fire welfare check requests, and vendor communications that affected service delivery. Each agency submits a short chronology of key decision points and constraints. The coordinator merges these into a single “system timeline” with referenced sources and circulates it 48 hours before the AAR. During the AAR, the first segment is a timeline validation: participants flag conflicts, and the group resolves them by referencing source artifacts or agreeing to a documented “uncertain” note with a follow-up owner to confirm.
Why the practice exists (failure mode it addresses)
This exists to prevent the failure mode where agencies arrive with different realities and the AAR becomes a debate about memory. In HCBS events, each partner sees only part of the system. Without a shared timeline, root-cause decisions will be wrong or politically distorted, and corrective actions will not target the true seam failures.
What goes wrong if it is absent
If there is no shared timeline, agencies often default to defensiveness (“we notified you”), and the meeting wastes time arguing about who did what. The result is usually a bland summary with no enforceable fixes, and the same cross-system breakdown repeats in the next disruption—especially around escalation, discharge coordination, and public messaging.
What observable outcome it produces
Observable outcomes include a validated chronology that all parties can reference, faster identification of interface failures (e.g., duplicated welfare check lists, inconsistent contact numbers, delayed discharge notifications), and a foundation for assigning corrective actions with credible evidence support.
Confidentiality and data handling: keep it safe and still useful
Multi-agency AARs must balance learning with confidentiality. Providers should avoid unnecessary disclosure of protected health information by using de-identified case examples, aggregating counts, and focusing on process breakdowns rather than individual client narratives. Where client-level detail is needed to understand a failure mode (e.g., a missed high-risk contact), the AAR should use minimum necessary information, document the rationale, and confirm that any shared artifacts are stored and accessed appropriately. The objective is operational learning with a defensible information-handling posture.
Operational Example 2: A seam-failure map that turns cross-system pain into joint actions
What happens in day-to-day delivery
After validating the timeline, the group maps seam failures using a structured template: Interface point (e.g., discharge, welfare check request, service exception approval) → required information → sender/receiver → timeframe → current pathway → observed breakdown → consequence. Each seam failure is then converted into a joint corrective action that specifies: the revised pathway, responsible owners in each organization, and what evidence will prove it works (updated contact lists, revised referral forms, signed MOUs, or system configuration changes). Actions are written in operational language, such as “County duty desk provides a standardized daily high-risk list by 10:00 a.m. with verified contact fields” rather than “improve coordination.”
Why the practice exists (failure mode it addresses)
This prevents the failure mode where partners agree the experience was “challenging” but cannot define what interface failed. Seam-failure mapping forces the group to specify the handoff, the expected information, the timing, and the exact control gap—so corrective actions can be concrete and testable.
What goes wrong if it is absent
Without seam-failure mapping, corrective actions default to training or reminders, which rarely fix interface design. Agencies leave with different interpretations of what to change, and improvements remain fragmented. The next disruption recreates the same confusion, especially around client prioritization, escalation authority, and family communications.
What observable outcome it produces
Observable outcomes include fewer “lost handoffs,” clearer escalation thresholds, improved consistency of lists and contact data, and a set of joint actions that can be tracked to completion across organizations.
Assign ownership like a contract: who does what by when, and how you will know
Multi-agency corrective actions fail when ownership is ambiguous. Each action should have a named owner in each participating organization, a due date, and an agreed verification method. Verification matters: it prevents “done” from meaning “we talked about it.” In practice, verification can include document revision, staff briefings with attendance records, system configuration screenshots, drill outcomes, or a small sample audit of new workflow usage. The AAR output should read like an implementation plan, not a meeting note.
Operational Example 3: Joint testing of new interfaces through a tabletop-plus-live check
What happens in day-to-day delivery
Within 30–60 days, partners run a short joint test of the corrected interfaces. First, a tabletop scenario tests the decision and communication pathway: how a high-risk client list is generated, who receives it, how providers confirm contact, and how unmet needs are escalated. Second, a “live check” validates real-world readiness: contact numbers are called, backup channels are verified, and a small sample of referrals or service exceptions is processed using the new pathway. Results are captured in a simple test record with issues logged, owners assigned, and deadlines set for refinements.
Why the practice exists (failure mode it addresses)
This exists to prevent the failure mode where interface changes look good on paper but fail under time pressure. Joint testing exposes practical problems—unmonitored inboxes, missing fields in forms, unclear escalation thresholds—before the next real disruption forces the system to rely on them.
What goes wrong if it is absent
If partners do not test, they assume readiness and discover flaws during the next emergency. The system then reverts to ad hoc workarounds, risking missed contacts, inconsistent messaging, and delayed escalations—exactly the failures the AAR was meant to prevent.
What observable outcome it produces
Observable outcomes include verified working channels, faster and more consistent handoffs, fewer escalation failures, and a documented test trail that demonstrates genuine cross-system learning and readiness improvement.
Make learning portable: a shared summary that each organization can govern
Multi-agency AAR outputs should include two layers: a shared summary (validated timeline, seam failures, joint actions) and organization-specific annexes (internal actions and evidence plans). This allows each partner to govern implementation through its own leadership structure while maintaining shared commitments. The shared summary should be concise and operational, suitable for distribution to relevant leads without exposing unnecessary sensitive details.
Multi-agency AARs are where community care resilience is built at the seams. When partners agree the facts, map interface failures, assign joint owners, and test changes together, learning becomes a system capability—not a one-off document.