Social Care Referral Platform Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the last mile get scoped as a partner portal so often?

Because a portal is the obvious symmetric answer. The health system has a system, so the partner should have a login to the same system. It demonstrates well, it produces clean data, and it assumes an administrative capacity that most community organisations do not have.

The design that actually closes loops accepts 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 software's job is telling that coordinator which fifteen referrals to chase today rather than expecting them to chase 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 a strong closure rate from networks that report a weak one.

The tell in a scoping conversation is direct. Ask how a two person food pantry with no case management system closes a loop. If the answer involves a portal login, the developer has 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.

What goes wrong when you import a resource directory and existing client records?

The directory decays faster than anyone plans for, and the client records do not match each other.

A directory that says an organisation exists and describes what it does is not the same as knowing whether it can take anyone this week. Imported directories are almost always a snapshot of an organisation's own description of itself, written for a funder, listing every service it has ever offered. Referrals then 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.

Eligibility is the part that gets imported worst, because it is usually free text. Catchment area, income threshold, household composition, documentation required, languages spoken and whether they serve people without an address are what actually determine a match, and none of that survives as a paragraph in a description field. Modelling eligibility as structured data is a piece of work per service, not a bulk import.

Client records are the second problem. Consolidating referrals from several referring organisations means the same person exists in several places with different name spellings, different addresses and no shared identifier. Without identity matching you cannot tell that the person the pantry served is the person the hospital referred, which is the link an outcome report depends on. That matching is a scoped piece of work, and it interacts with consent, because matching a person across organisations is itself a disclosure question.

Why do electronic health record and partner system integrations break after launch?

Because they are two directions and the second one is what gets cut.

Pushing screening results and referrals out of Epic or Cerner is the easier half. Writing referral status back into the clinician's workflow is the half that gets dropped when timelines slip, and dropping it is what makes the loop invisible to the care manager who created the referral. She then experiences exactly the black hole the platform was bought to fix, stops trusting it, and reverts to phoning organisations she knows. Ask for both directions by name and by interface type before signing, and treat the write back as non negotiable rather than as phase two.

The second breakage is screening duplication. CMS includes social needs screening in hospital quality reporting, so your clinical teams are already collecting this data for another purpose. A platform that screens the same person again produces two answers that will eventually disagree, and it burns the patience of both the patient and the clinician. Reuse the existing screening and map it to standard coding rather than building a second instrument.

Partner system integrations break for a more mundane reason: small organisations change systems, lose the staff member who understood the connection, or have their vendor change an interface without notice. Each integration is its own negotiation and its own maintenance obligation, so it should be earned by referral volume rather than granted by default. Two or three partner integrations that work are worth more than fifteen that were built and then quietly stopped delivering.

What happens when consent scoping and outcome definitions are not covered?

The project stops in legal review, and if it does not, the reporting fails its first audit.

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 learning about their mental health treatment, and consent given at a hospital bedside during discharge is questionable consent that the person may want to revoke next week.

Consent has to be a structured, scoped, revocable record that gates what actually flows, rather than 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 nobody predicts, because community organisations are frequently more privacy conscious than health systems and will refuse to participate in a network that hands them clinical data they never asked for.

On outcomes, closure rate alone is weak and easily gamed, since closing a referral as unable to contact still closes it. 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. Agree the measure definitions with the funder's analyst before the build encodes them, because retrofitting a state distinction into a year of collapsed data is not possible.

Should you build custom or configure what you already own?

Buy findhelp if you are a single hospital or clinic that wants to make referrals and know what exists. It gives you national directory coverage you could never maintain yourself and a workable referral path, at a cost that is trivial next to a build. Building your own directory is a permanent maintenance obligation you will regret.

Join rather than compete if your region already runs a Unite Us network with partners onboarded. Unite Us built a genuine network business and made real progress on the incentive problem by contracting with community organisations and moving money through the network, which is the honest answer. 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 including the families.

Julota works from the cross agency, consent first direction and suits regional coalitions well, and is worth evaluating before assuming a build.

Build when two or more 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, your closure rate has stalled below what the contract needs, and the reason is the design of the loop rather than effort.

How do hidden costs get into the quote?

Electronic health record integration is the first and largest. It is a real project against Epic or Cerner rather than a connector you switch on, and it is two pieces of work rather than one because the status write back is separate from the outbound referral. Price both, name both, and refuse to let the second become optional.

Partner system integrations are the second, each one its own negotiation and technical effort. Quote them individually and earn them by volume rather than committing to a number in advance.

Third is multi language and accessibility, which is not optional in this category given who the users are, and which is genuinely additional work rather than a translation file. A no login confirmation page and a self referral path both need to work for people using assistive technology on old devices.

Fourth is identity matching across organisations, needed the moment you want to link a service delivered to a referral made. Fifth is payer specific reporting formats, one per contract, and each contract's analyst has views. Sixth is the network coordinator, which is a salary rather than a software line and is the single item most responsible for the closure rate you will actually achieve. A proposal that does not mention it has priced the technology and not the outcome.

What separates a build that works from one that fails here?

The builds that work are judged on one measure: 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.

They keep the directory fresh with cheap continuous updates rather than periodic audits. A weekly text message asking whether an organisation is accepting referrals, answered with one tap, keeps status fresher than any quarterly audit cycle, and it costs almost nothing to run.

They tell the truth when nothing matches. 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 the network needs when it asks a funder for more capacity. A platform that always finds somewhere to send a family is a platform that is hiding a gap.

They onboard narrowly first. Start with the twenty organisations that receive most of your referrals, get them confirming loops through the low friction path, and expand from there. Networks that try to onboard two hundred partners at launch usually end up with two hundred inactive accounts and a closure rate that proves nothing.

Finally, they settle ownership before kickoff. The coalition should own the repository, the cloud accounts and the data, in writing, and at Digital Heroes the client owns the code from the first commit. This category runs on the trust of community partners, many of whom have been asked to enter data into somebody else's system before and got nothing back. Being able to say the platform belongs to the network rather than to a vendor is a genuine adoption argument, not only a contractual preference.