Closed Loop Social Care Referral Platforms: Who Actually Confirms That the Food Box or the Housing Help Ever Arrived?

Why the referral disappears and everybody stops caring

A nurse care manager screens a patient at discharge. Food insecurity, transport difficulty, and a housing situation that will not survive the winter. She makes three referrals through the platform the health system bought last year, feels she has done her job, and moves to the next patient. She never hears anything again about any of the three.

On the other side, a food pantry with one and a half paid staff receives the referral in an inbox they check on Tuesdays. They already know this family. They have been serving them for two years. The referral asks them to log into a system, confirm receipt, record the service and close the loop, which takes eleven minutes they do not have, for a health system that sends them no money. They help the family, because that is what they do, and they never touch the system. The closure rate report shows the referral as open. Eighteen months later the health system concludes that closed loop referral does not work and blames the software.

The software was not the problem. The problem is that the model asks the least resourced party in the chain to do the most administrative work for the least benefit. Any platform that does not solve for that, whatever it costs, will produce the same report. This is the central design question in the category and it is not a technical one.

Problem one: the community organisation has no reason to use your system

Unite Us built a genuine network business and made real progress on this by contracting with community organisations and moving money through the network, which is the honest answer to the incentive problem. findhelp comes at it from the directory side and has the broadest resource coverage in the country, which is exactly what a clinician needs at the point of referral. Julota works from the cross-agency, consent-first direction and suits regional coalitions well. Every one of them still faces the same wall at the last mile: a two person organisation with a paper intake process and a shared laptop.

What a custom build does: meet each partner where they already are, and accept that this means several tiers rather than one product. The organisation with a case management system gets an interface, so their existing record closes the loop without anyone retyping. The organisation with staff but no system gets a mobile web page with no login friction, reached from a text message link, where confirming a service is two taps. The organisation with neither gets a phone call from a network coordinator whose job is closing loops, and the system's job is telling that coordinator which fifteen referrals to chase today rather than expecting them to chase all four hundred. That third tier is not a failure of the software, it is the correct design for the reality, and budgeting a human coordinator is what separates networks that report seventy percent closure from networks that report twenty.

Problem two: a referral into a full service is worse than no referral

Directories tell you an organisation exists and what it does. They rarely tell you whether it can take anyone this week. So referrals flow toward the best known organisations, which are already full, while capacity sits unused two neighbourhoods over. The family gets a phone number, calls it, is told the waiting list is closed, and does not call the second number.

What a custom build does: hold capacity and eligibility as live data, and make updating it trivially cheap for the organisation. A weekly text message asking whether they are accepting referrals, answered with one tap, keeps a status fresher than a quarterly directory audit ever will. Eligibility gets modelled properly, because it is what actually determines a match: catchment area, income threshold, household composition, documentation required, languages spoken, whether they serve people without an address. Then the referral routes to an organisation that can genuinely take this person, and where nothing matches, the system says so honestly to the referrer rather than sending a family into a closed door. Showing a care manager that no housing capacity exists in the county this week is more useful than a referral that fails silently, and it is also the evidence your network needs when it asks a funder for more capacity.

Problem three: consent across sectors is where these projects get stopped

Health information moving to a housing organisation, a food pantry or a legal aid office is not covered by the arrangements your health system already has. Substance use treatment information carries stricter federal protection. A patient may consent to a food referral and not to anyone knowing about their mental health treatment. Consent given at a hospital bedside during discharge is questionable consent, and the person may want to revoke it next week.

What a custom build does: consent as a structured, scoped, revocable record that gates what actually flows, not a signature on a form in a folder. The scope names categories of information and named recipient organisations. A referral then carries only what that partner needs and consent covers, which for a food pantry is usually a name, a contact method and a household size, and specifically not a diagnosis list. Revocation takes immediate effect and every disclosure is logged. Doing this properly also solves an adoption problem you did not expect, because community organisations are often more privacy-conscious than health systems and will refuse to participate in a network that hands them clinical data they never asked for.

Problem four: the outcome report has to survive a payer's analyst

If your programme is funded through value based payment, a state 1115 waiver arrangement or a health plan contract, somebody will audit the numbers. Closure rate alone is a weak measure and is easily gamed, since closing a referral as unable to contact still closes it. What a payer wants is need identified, referral made, service delivered, and where possible a health outcome linked to it.

What a custom build does: distinguish outcome states rather than collapsing them. Service delivered, client declined, ineligible, capacity unavailable, unable to contact, and duplicate of an existing service are six different facts and each tells you something different about your network. Screening results map to standard coding, which matters because CMS now includes social needs screening in hospital quality reporting and your health system is already collecting the data for that purpose, so the referral platform should reuse it rather than screening the same person twice. Adopting the emerging FHIR-based standards for social care data through the Gravity Project work is worth doing where your partners can support it, because a network that speaks a standard can exchange with the health plan's systems without a bespoke integration per payer.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering screening intake, a resource directory with eligibility and capacity, referral creation and routing, the low friction partner confirmation path and the coordinator worklist runs $60,000 to $130,000 in 12 to 16 weeks. A full platform adding EHR integration for screening and referral write-back, consent management with segmentation, partner system interfaces, closure and outcome reporting, and a client-facing self-referral path runs $150,000 to $400,000 across 6 to 12 months.

What drives cost up: EHR integration, which is where most of the value sits for the health system side and which is a real project against Epic or Cerner rather than a connector you switch on. Number of partner system integrations, each of which is its own negotiation and technical effort and should be earned by volume rather than granted by default. Multi-language and accessibility, which is not optional in this category given who the users are and which is genuinely additional work. Identity matching across organisations, needed if you want to know that the person the pantry served is the person the hospital referred. And payer specific reporting formats, one per contract.

What keeps cost down: reuse the screening your clinical teams already do rather than building a second one, start with the twenty partners who receive most of your referrals, and use the text-message confirmation path for everyone before building any partner integrations.

Build versus buy, and when buying is the right call

Buy if you are a single hospital or clinic that wants to make referrals and know what exists. findhelp gives you national directory coverage that you could not maintain yourself and a workable referral path, at a cost that is trivial next to a build. Buy also if your region already runs a Unite Us network with partners onboarded, because the value in this category is network density and standing up a competing network in the same geography splits the partners you are both trying to reach, which helps nobody.

Build when two or more of these are true. You are the convener rather than a participant, meaning a health plan, a regional coalition or an accountable entity that owns the network's outcomes. You have value based payment or waiver funding tied to delivery and outcomes, which raises the evidence bar above what a general platform reports. Your partner mix is dominated by very small organisations, so the last mile problem is your whole problem and it needs designing rather than licensing. You need consent segmentation across behavioural health and social services that a general product does not express. Or you are already paying for a platform and your closure rate has stalled below what the contract needs, and the reason is the design of the loop rather than effort.

Our position, stated plainly: this software succeeds or fails on whether the smallest organisation in the network can close a loop in under thirty seconds, from a phone, without a login. Everything else is secondary, and any vendor conversation that starts with dashboards is starting at the wrong end.

How to choose a developer for a social care referral platform

Ask them how a two person food pantry with no case management system closes a loop. If the answer involves a portal login, they have not understood the category. You want to hear about text message links, no-login confirmation pages, phone-based coordinator workflows and integration only where a partner's volume justifies it.

Ask how they model consent. Scope, named recipients, categories, revocation, disclosure logging and segmentation of behavioural health data should come back immediately. This is the item most likely to stop the project in legal review, so it belongs in the first design conversation.

Ask what they have integrated with Epic or Cerner, by name and by interface type. Screening data flowing out and referral status flowing back are two different pieces of work, and the second is usually the one that gets dropped when timelines slip, which is precisely the piece that makes the loop visible to the clinician.

Ask who owns the code and settle it before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. For a network built on the trust of community partners, being able to say the platform belongs to the coalition rather than to a vendor is worth more than it sounds.