🏘 Community Resource Referral Closed-Loop Tracking

Screening for Social Need and Creating the Referral

Closed-loop referral begins the moment a clinical encounter surfaces an unmet social need. Standardized screening tools convert a conversation about food, housing, transportation, or utilities into structured, codeable data — the prerequisite for any downstream tracking. Without a documented referral event, there is no loop to close.

• ~40 M: Patients screened annually (US, est.) (across value-based care networks)
• ~30–40%: Screen-positive for ≥1 need (typical safety-net population)
• PRAPARE, AHC-HRSN: Common screening tools (validated, EHR-embedded)
• Z55–Z65: ICD-10 Z-code range (social determinant diagnosis codes)

From conversation to codeable, referral-ready data

Social needs screening only becomes actionable when it is structured. Tools like PRAPARE (Protocol for Responding to and Assessing Patients' Assets, Risks, and Experiences) and the CMS Accountable Health Communities Health-Related Social Needs (AHC-HRSN) screening tool ask a fixed set of questions — housing stability, food security, transportation, utility needs, interpersonal safety, employment — each mapped to a specific ICD-10-CM Z-code (Z59.4 food insecurity, Z59.0/Z59.1 housing instability, Z59.82 transportation insecurity).

Coding the need is what makes it a discrete, trackable clinical fact rather than a note buried in free text. It timestamps the origin of the referral, links it to the responsible clinician and encounter, and gives population-health teams a denominator: everyone flagged for a given need becomes the cohort against which closure rate is measured.

The referral itself is generated at this point — either automatically from the screening tool or manually by a care coordinator/social worker — specifying the need category, urgency, and (where known) a preferred or in-network CBO.

A referral that is never coded as a discrete, trackable event cannot be lost — because it was never counted in the first place. The single biggest undercount in most SDOH programs is referrals made informally (a printed flyer, a verbal suggestion) that leave no record to close the loop against.

Consent, eligibility, and the decision to refer electronically

Before a referral leaves the four walls of the clinic, staff must confirm the patient consents to having their information shared with an external, often non-covered, community organization — a step governed differently than clinical data exchange under HIPAA. Many platforms capture consent digitally at the point of referral and scope it (which data elements, which organizations, for how long).

Eligibility triage happens here too: some CBOs serve only specific ZIP codes, age ranges, income bands, or immigration statuses. Referring blind to eligibility is a leading cause of early-stage leakage — the referral bounces before it is ever actionable.

Routing Through the Community Resource Platform

Where a referral once meant a fax or a business card, closed-loop platforms — Unite Us, findhelp (formerly Aunt Bertha), NowPow, Healthify — act as a coordinated switchboard. They hold a searchable directory of CBOs, apply matching logic to the coded need, and transmit the referral electronically with a persistent status that both sides can see and update.

• >1M listings: CBOs in major platform networks (aggregated across national directories)
• <1 min: Referral transmission time (vs. days for fax/phone routing)
• Growing rapidly: Networks using shared platforms (state Medicaid 1115 waivers, ACOs)
• 10–15%: Typical early-stage bounce rate (wrong CBO, duplicate, ineligible)

The hub-and-spoke model of coordinated referral

Rather than each clinic maintaining its own list of shelters and food pantries, a resource platform functions as shared infrastructure: clinics, CBOs, health plans, and government agencies all connect to the same hub. A referral submitted by any node is visible, in a standard schema, to every other authorized node in the network.

Matching logic considers need category, geography, language, hours of operation, and — critically — real-time capacity signals from the CBO side, so a referral is not sent to an organization that is already at caseload limit.

Interoperability is increasingly standardized around the Gravity Project's HL7 FHIR implementation guide for SDOH, which defines common data elements (need, referral status, service request, service outcome) so that platforms, EHRs, and CBO case-management systems can exchange referral state without custom point-to-point integrations.

Status as a first-class, shared object

The defining feature of a closed-loop platform (versus a static directory) is that referral status is a shared, mutable object rather than a one-time message. Typical states: Sent → Received → Accepted/Declined → Scheduled → In Progress → Completed/Unable to Complete.

Every state transition is timestamped and visible to the referring clinician, which is what turns "we sent a referral" into "we know what happened to it." Platforms without this shared status model degrade back into one-way fax behavior even if the transmission itself is digital.

Unite Us reports that closed-loop referral networks can raise the share of referrals with a documented outcome from under 20% (fax/phone baseline) to 70%+ once bidirectional status tracking and CBO participation agreements are in place.

CBO Review, Capacity Matching, and Scheduling

Every referral platform eventually meets the same hard constraint: a CBO's caseload is finite. A food pantry can only serve so many households a week; a housing navigator can only carry so many active cases. Acceptance and scheduling is where digital coordination collides with real-world capacity — and where a large share of otherwise well-routed referrals first go quiet.

• 55–80%: Typical CBO acceptance rate (capacity- and eligibility-dependent)
• 1–3 days: Median time to CBO response (ranges to >1 week for under-resourced CBOs)
• ~70%: CBOs reporting chronic understaffing (national CBO capacity surveys)
• ~1 in 5: Referrals requiring re-routing (after initial CBO decline)

Capacity as the binding constraint on closure

Unlike clinical referral networks, most CBOs are small nonprofits with limited case-management staff, no dedicated IT budget, and funding tied to grant cycles rather than referral volume. A platform can transmit a referral instantly, but it cannot manufacture staff time to review and act on it.

When a CBO is at capacity, referrals queue, get silently deprioritized, or are declined and returned to the hub for re-routing to a second-choice organization — adding days and a second point of possible drop-off before the client is ever contacted.

Some platforms surface live capacity signals (open slots, waitlist length) so referring clinicians can route to CBOs currently able to accept, reducing blind referrals that are declined purely on capacity grounds rather than fit.

Outreach, engagement, and the client-side leak

Acceptance by the CBO does not guarantee the client engages. Successful intake requires the CBO to reach the client, confirm continued need, and schedule a service — and clients facing housing or food instability are disproportionately likely to have unstable phone numbers, unpredictable schedules, or competing crises that make a scheduled appointment hard to keep.

Higher-performing networks pair digital referral with warm handoffs (a live introduction between navigator and client before the referral is even sent) and multi-channel outreach (text, call, in-person), which measurably raise the share of accepted referrals that convert to a kept appointment.

Studies of coordinated entry and closed-loop referral programs consistently find that a warm handoff — clinic staff introducing the client to the CBO in real time — roughly doubles the intake show-rate compared with a cold electronic referral alone.

The Client Receives the Service — the Visible Half of the Loop

Service delivery is the part of the process most visible to the client and most often mistaken for "done." A food box handed over, a housing application filed, a utility voucher issued — these are real, valuable interventions. But from a data standpoint, delivery alone is only half the loop: it tells the CBO something happened, but it does not, by itself, tell the referring clinic anything at all.

• 5–9 days: Avg days: referral → service (networked) (vs. 2–4 weeks unmanaged)
• ~60% / 40%: One-time vs. ongoing services (food/transport vs. housing/benefits)
• ~50%: CBOs with case-management software (many still track on paper/spreadsheets)
• ~25–35%: Services delivered without outcome logged (primary source of "silent" leakage)

Why delivery and documentation are two separate events

A CBO case worker's priority, correctly, is serving the client in front of them — not backfilling a referral platform's status field. In many organizations, documenting the outcome in the shared system is an administrative afterthought performed in batches, if at all, especially where staff juggle multiple funder reporting systems with incompatible data models.

This produces a structural gap: the service genuinely happened, the client's need was genuinely met, but the referring clinic's dashboard still shows the referral as "in progress" or "no response" indefinitely — a false negative that looks identical, from the clinic's side, to a referral that actually failed.

Automation as a partial fix for documentation burden

The follow-up automation level (adjustable in this simulation) approximates how much of the outcome-reporting burden is offloaded from manual CBO staff time onto the platform itself: automated SMS check-ins with clients, scheduled reminder pings to CBO staff with unclosed referrals, and — at the highest level — direct system-to-system status sync from a CBO's case-management software into the shared platform via API/FHIR, removing manual re-entry entirely.

Higher automation levels measurably shorten average time-to-service and raise the share of referrals that eventually get an outcome logged, but they cannot substitute for CBO staffing capacity — automation speeds up documentation of what happened, not the underlying service delivery itself.

Confirming the Outcome — Closing the Loop or Counting the Leak

A referral loop is "closed" only when a documented outcome — completed, declined, or unable to reach — travels back through the platform to the referring clinician and is reconciled against the original need. Everything short of that, no matter how much good work happened at the CBO, is measured as leakage: a referral sent into the system whose ultimate disposition the health system cannot account for.

• 65–80%: Closed-loop rate, mature networks (vs. <20% fax-era baseline)
• 30–50%: Closed-loop rate, early-stage networks (CBO onboarding still incomplete)
• 4 types: "Leakage" categories tracked (no response, declined, unreachable, unknown)
• Direct ROI signal: Median added referral value at closure (ties spend to confirmed outcomes)

What "closing the loop" actually requires

True loop closure has three components that must all be present: (1) a structured outcome code (completed / declined / unable to contact / ineligible), (2) a timestamp so time-to-closure can be measured, and (3) delivery of that outcome back to the original referring party — not just storage inside the CBO's own system.

Many programs report a "referral rate" or a "service delivery rate" and describe it as closed-loop tracking, but without the bidirectional confirmation step reaching the referrer, it is still an open loop from the health system's point of view — the clinic has no record of what happened and cannot follow up, adjust the care plan, or attribute any downstream health outcome to the intervention.

The distinction matters clinically, not just administratively: a patient screened positive for food insecurity whose referral silently failed looks, in the EHR, identical to one whose need was successfully met — unless the loop closes. Both cases risk being excluded from re-screening or escalation, because the system believes the need was addressed.

Measuring leakage and designing for closure

Leakage is typically decomposed into where in the pipeline a referral stalls: transmission leakage (never reached a CBO — wrong contact, technical failure), acceptance leakage (CBO declined or never responded), engagement leakage (client never scheduled or attended), and reporting leakage (service happened but outcome was never logged back). Each requires a different fix — better directory data, CBO capacity investment, warm handoffs, and automation, respectively.

Program design responses include participation agreements that require CBOs to log outcomes within a defined SLA, funding tied to closed-loop performance rather than referral volume alone, care coordinator staffing dedicated to chasing down unclosed referrals, and API-level integration with CBO case-management tools so outcome data flows without manual entry.

Interoperability, data sharing, and measuring success at scale

Sustained closed-loop performance depends on standards, not just goodwill between individual organizations. The Gravity Project's HL7 FHIR SDOH Clinical Care implementation guide defines shared resources for ServiceRequest, Task, and Procedure so referral state can move between EHRs, resource platforms, and CBO systems without bespoke integrations. State Medicaid 1115 waiver programs (e.g., California's CalAIM, North Carolina's Healthy Opportunities Pilots) increasingly require closed-loop referral infrastructure and report closure rate as a contractual performance metric tied to reimbursement.

At the population level, the outcome metrics that matter are the same four tracked in this simulation: referral volume by need category, loop closure rate, time-to-service, and leakage rate broken out by stage — the minimum dashboard for any accountable community-linkage program to demonstrate it is more than a directory.