A referral is not a service
Most social service referrals end the moment they are made. A case manager hands a person a phone number for a food pantry, a housing program or a job center, writes "referred" in the case notes, and never learns what happened. The person may have called and been helped, called and been told the program was full, or never called at all. A closed-loop referral network exists to answer that question for every referral: did the person actually receive the service, and if not, why not.
Closing the loop sounds like a software feature. It is mostly an agreement among organizations about what happens to a referral after it is sent, backed by software that makes the agreement easy to keep. Programs that buy a platform first and work out the agreement later end up with an expensive directory nobody updates. Programs that define the lifecycle first, then choose or build tools to support it, end up knowing where people fall through.
The referral lifecycle
Every referral moves through the same small set of states. The target windows below are illustrative; each network sets its own by service type, because an emergency shelter referral and a job training referral run on very different clocks.
Lifecycle of One Referral
Illustrative target windows. Set them per service type and write them into the network agreement.
The last state is the one that matters. A referral closed as "served" tells you the person walked in. A referral closed with an outcome tells you whether the need was met: the family got groceries, the person got a bed, the job seeker started training. That outcome, recorded with a reason when the need was not met, is what turns a referral system into a picture of what the community can and cannot provide.
Define the states before the software
Write the state model down as a one-page agreement every participating organization signs. For each state, define what it means, who moves a referral into it, and how long it may sit there before someone is alerted. A referral that has been "sent" for a week with no response is not pending. It is a failure that nobody has noticed yet.
Define the reasons a referral can be declined or closed without service, and keep the list short: the person does not meet eligibility, the program is at capacity, the person could not be reached, the person declined the service, the need was met elsewhere. Free text reasons cannot be counted. A short coded list, with an "other" that someone reviews monthly, can be.
Decide what happens to a declined referral. The best networks treat a decline as a handoff, not an ending: the referral goes back to the referring organization, or to a coordinator, with the reason, so someone finds the next option the same day. Without that rule, the person who was turned away is in exactly the position they would have been in with a phone number on a slip of paper.
Provider capacity data
A referral to a program that is full wastes the person's time and the provider's. The network needs two kinds of provider data. The first is the directory: who offers what, where, when, for whom, in what languages, with what eligibility rules. The second is capacity: whether the program can take a new person this week.
Directory data is the foundation, and it decays constantly. Phone numbers change, programs close, hours shift. Open Referral's Human Services Data Specification is an open standard for structuring this kind of resource data, and using a shared structure makes it far easier to exchange directory records with 211 and other networks. Whatever the format, assign each record an owner and a review date, and treat a record that has not been confirmed in a set period as suspect.
Capacity data is harder, because most community organizations do not track openings in real time. Keep it simple: a status a provider can update in seconds, such as accepting, waitlist or closed to new referrals, with a date it was last set. Watch declines as a capacity signal too. A provider declining most referrals for capacity is telling the network something its status flag may not.
Consent and data sharing
A referral carries personal information from one organization to another, often across organizations that follow different privacy rules. Some are health care providers covered by HIPAA. Many community organizations are not. Some handle records with stricter protections: substance use disorder treatment records under 42 CFR Part 2, and domestic violence programs, which work under strict limits on sharing survivors' identifying information.
Build consent into the referral itself. The person agrees, in plain language, to share specific information with a specific receiving organization for the purpose of getting the service. Record the consent with the referral, and share only what the receiving organization needs to act on it. A food pantry does not need a diagnosis. A housing program may need income but not a criminal history it has no use for.
Decide early whether consent is given per referral or once for the whole network, and what the person can see and withdraw. Per-referral consent is easier to explain and limits each disclosure to one organization. Network-wide consent reduces repeated forms but asks more of the person's trust. Whichever you choose, have the network's privacy lead and the participating organizations' counsel review the model before launch, and write it into a data sharing agreement every organization signs.
Interoperability
Referrals increasingly start in health care: a clinic screens a patient for food insecurity or housing instability and refers them to a community organization. That makes the connection between health records and community referral tools important, and it is where standards matter.
The HL7 Gravity Project develops consensus data standards for social care, covering screening, assessments, goals and interventions, including referrals, and its work builds on HL7 FHIR. In FHIR terms, a referral is commonly represented as a service request with an associated task whose status tracks the work, which maps naturally onto the lifecycle above. A network that models its states with that alignment in mind will find it far easier to exchange referrals with health systems that adopt the standards.
Be practical about it. Many community organizations will never connect a system through an interface. The network still needs a simple web interface, and email or text alerts, for organizations that will only ever use a browser. Interoperability is for the high-volume connections, typically health systems and large agencies. Everyone else needs something easy.
Working with 211
In most of the country, 211 is already the front door for people looking for help, and 211 organizations maintain some of the most carefully curated resource directories available. A referral network that ignores 211 duplicates that work and splits the front door in two.
There are three useful connections. Share directory data in both directions, so updates made by either side reach the other. Let 211 specialists send referrals into the network, so a caller can be connected rather than handed a number. And send closed-loop outcomes back to 211 in aggregate, so the people maintaining the directory can see which services are reachable and which are not. Each connection needs its own data agreement, and the 211 organization should be a partner in designing the network, not a vendor to it.
Metrics that tell you whether the loop is closing
The point of a closed loop is measurement. These are the metrics that matter, computed per provider, per service type and per referring organization.
| Metric | Definition | What it tells you |
|---|---|---|
| Response time | Time from sent to accepted or declined | Whether receiving organizations are watching their queue |
| Time to first contact | Time from sent to the first successful contact with the person | The single best measure of whether the handoff worked; delays here are where people give up |
| Acceptance rate | Share of referrals accepted, with declines broken out by reason | Eligibility mismatches and capacity shortages, by provider and service type |
| Completion rate | Share of referrals that reach served | How many people actually received the service |
| Need met rate | Share of closed referrals where the need was met | Whether the service solved the problem, not just whether it was delivered |
| Loop closure rate | Share of referrals with a recorded outcome within the target window | Data quality: how much of the network is visible at all |
| Stale referrals | Count of referrals past their state's time limit | The daily work list for coordinators |
Watch loop closure first. If most referrals never reach a recorded outcome, every other metric describes only the organizations that report, and those tend to be the ones doing well. A network with a low closure rate should spend its first year raising it, before drawing conclusions from anything else.
Then break every metric down by the people being referred, by area, language and the kind of need, wherever the numbers are large enough to report without identifying anyone. A network can post a strong overall completion rate while referrals for Spanish speakers or rural residents fail at twice the rate of everyone else. Those gaps are the most useful thing the data shows, because they point to a specific missing service, a provider that needs an interpreter, or an area where nobody is taking referrals at all.
Where closed loops break
The failure points are predictable, and almost none of them are technical.
- Receivers never log in. A small organization with no time for another system ignores the queue. Alerts by text or email, and a status update that takes one click, fix most of it.
- Nobody owns the stale list. Without a named coordinator who works overdue referrals every day, they accumulate silently.
- The directory goes stale. Referrals go to programs that moved, closed or changed eligibility, and both sides lose trust in the system.
- Contact information is wrong. The person's phone number is out of date or shared. Capture a second contact method and the best time to reach them.
- Closed without outcome. Providers mark referrals served and stop. Make the outcome field required to close.
- Consent dead ends. A referral stalls because consent was not captured or does not cover the receiving organization.
- Duplicate referrals. Three organizations refer the same person to the same pantry. Match on the person and show open referrals before a new one is sent.
- Unpaid documentation. Community organizations are asked to do data entry for a network that funds none of it, and eventually stop.
The last one deserves attention from funders. Closing the loop is real work for the receiving organization. Networks that compensate community partners for the documentation, or fund staff time for it, get far better data than networks that treat it as a favor.
A closed loop is only as good as the least-resourced organization asked to close it.
Choosing or building a platform
Whether you buy, adapt an open-source tool, or build, the questions are the same. Run every option through this list before signing anything.
- It supports your state model, including coded decline and outcome reasons and time limits per state
- Consent is captured per referral and shown to the receiving organization, with withdrawal supported
- Information shared is limited per receiving organization, by role and need
- Receiving organizations can work it from a phone or a browser, with text and email alerts
- Directory data can be imported and exported in an open format, and synchronized with 211
- Referrals can be exchanged with health systems through standards-based interfaces
- Every metric in the table above can be computed from data you can export
- You own the data, including the right to export all of it in a usable format if you leave
- Pricing does not charge community organizations to receive referrals
- Security controls and audit logs meet the requirements of the most sensitive organization in the network
Pay particular attention to data ownership and pricing. A platform that holds the network's history and charges each organization a seat fee can make leaving prohibitively expensive, and can price the smallest partners out of the network entirely.
Pilot before committing the whole network. Pick one service type and a handful of referring and receiving organizations, run real referrals for a few months, and measure loop closure and time to first contact from the start. The pilot will expose the gaps in the state model, the consent flow and the provider workload while they are still cheap to fix, and it gives the rest of the network a working example instead of a promise.
Frequently asked questions
A referral in which the referring organization learns what happened after it was sent: whether the receiving organization accepted it, whether the person was contacted and served, and whether their need was met. An open-loop referral ends when the person is given a name or a phone number, and nobody knows the result.
Start with loop closure, the share of referrals with a recorded outcome, because every other metric depends on it. Once closure is high, time to first contact is the most useful measure of whether handoffs work, since delays in that step are where many people stop pursuing help.
Many community organizations are not HIPAA covered entities, but referrals that start in health care carry information the sending organization must protect. The network handles this with clear consent, limits on what is shared with each receiver, and a data sharing agreement every participant signs. Have the network's privacy lead and counsel review the model before launch.
Treat 211 as a partner. Share directory data in both directions, let 211 specialists send referrals into the network so callers are connected rather than handed a number, and share aggregate outcomes back so the directory reflects which services are actually reachable.