A program of Pathfinders for Hope
Your Homeless Management Information System Cannot Confirm Every Handoff
A homeless management information system records data. A confirmed referral handoff documents whether a receiving organization accepted a referral, explains a denial, or requires escalation when a person is left waiting. That creates referral accountability. Operation Iron Gate is being built to add that layer alongside existing HMIS workflows.
Referral made
Arrival confirmed
Without confirmation, this is where people are lost.
Your homeless management information system remains the system of record. Operation Iron Gate focuses on the limited handoff question: whether the receiving organization confirms the person arrived. Many HMIS workflows record program activity and referrals without requiring receiving-side confirmation of every cross-organization handoff. The proposed Vallejo pilot would keep that handoff visible while each organization retains its own data, policies, and decisions.
The partner session
We bring the map. You tell us where it breaks.
Before anything is signed or built, one working session with your team — your referral route on the table, drawn end to end.
-
01
Your route, drawn
Where a referral leaves you, who it goes to, and the exact point it stops being visible to anyone who could still act on it.
-
02
The three fields
Who received it. Whether the person arrived. When it was confirmed. Nothing your HMIS already holds is re-collected.
-
03
What stays yours
Your HMIS remains the system of record. Your data exports in a standard format, at any time, without asking us first.
-
04
The rules, in writing
Twelve barrier codes. Ten legal-basis codes. Corrections made by adding a record, never by editing one — so nothing can be quietly rewritten.
No case is lost.
A case cannot silently stop, and a case cannot close without an outcome. That is the commitment the whole system is built to keep.
The handoff
Your HMIS homeless management information system reports it happened. That is not the same as knowing they arrived.
Your HMIS(records)
Operation Iron Gate(confirms)
Referral recorded
Referral tracked to a named receiver
Exit reason logged
Receipt confirmed by the receiving organization
Service entered
Arrival confirmed — or the case reopens
Report generated after the fact
The gap is visible the day it opens
The record closes
The case stays open until the arrival is confirmed
HMIS does this well. It was never built to do the right column.
Illustrative.
Handoff sent
Receipt pending
Arrival confirmed
Your HMIS stays authoritative
No second place to type client data
Your HMIS stays your system of record
The general question
Working Alongside a System of Record
Two questions come before any product question. Both are worth answering in general terms, without reference to any particular vendor.
Can referral tracking software work alongside an existing HMIS?
Yes. Referral tracking and a homeless management information system do different jobs, and they can run at the same time — provided the boundary between them is defined before anything is deployed.
An HMIS is the system of record. It holds client demographics, program enrollment, exits, and the data a Continuum of Care reports to HUD. A referral tracking layer is scoped to the space between organizations: who received a referral, whether the person arrived, and what happens if nobody confirms.
Coexistence works when three conditions are met. The system of record is named and does not change. The tracking layer collects only fields the system of record does not already hold. And the tracking layer never becomes a second place to type the same client data.
It fails when a second platform quietly expands into intake and starts duplicating enrollment fields. At that point staff maintain two records of the same person, and the second one goes stale.
A homeless management information system remains authoritative when the tracking layer is limited to the handoff, not duplicate enrollment data.
How can agencies track referral status without replacing their system of record?
By tracking the handoff rather than the client.
The status of a referral is not a fact about a person. It is a fact about an event between two organizations: a referral was sent, a named receiver acknowledged it, someone arrived or did not, and a next action was required. Those facts do not belong in the client file, which is why capturing them does not require touching the system of record.
What gets added is small and event-scoped — who received it, whether it was confirmed, when, and what happens if it is not. The client record stays exactly where it is.
Agencies commonly reach for one of three workarounds instead: a shared spreadsheet, an email thread, or an automation tool wired between two systems. Each of them records that something was sent. None of them hold a case open until someone on the receiving end confirms an arrival, and none of them surface a referral that has gone quiet.
Operation Iron Gate is scoped to that separation by design. Your system of record stays your system of record. The confirmation layer sits beside it.
The first question
Is this more data entry?
It is the first question every director asks and it is the right one.
The system is scoped to the handoff — the moment a person moves from you to someone else. Not to everything your staff already record. If a field lives in your HMIS, it is not being re-collected here.
Double data entry is the loudest complaint in this sector and it is a legitimate reason to refuse a new system. Any platform that answers it with "our interface is easier" has not answered it.
Your HMIS
The handoff
What stays where it belongsYour HMIS remains the client record.
Client demographics
Program enrollment
Internal case notes
Exit reason
3
What Iron Gate confirmsOnly the handoff. Never the client record.
01 / receiverWho received the referral
02 / arrivalWhether the person arrived
03 / confirmationWhen it was confirmed
The boundary is deliberate: your HMIS holds the person’s record. Operation Iron Gate follows the referral until the handoff is confirmed.
The comparison
What each system is for
Eight rows compared. Two diverge.
Your HMIS
Operation Iron Gate
Primary purpose
HUD reporting and compliance
Confirming the handoff landed
Who selects it
Your CoC
Your organization
Records client demographics
Yes
Not re-collected
Records program enrollment
Yes
No
Records referral sent
Yes
Yes
Records referral received
Rarely, and rarely reliably
Yes — by the receiving org
Reports on the past
Yes
Yes
Acts while a case is open
No
Yes
Many HMIS workflows can report program activity and referrals. A proposed confirmed-handoff workflow would add a separate review point: whether the receiving organization confirms the person reached the agreed next step.
What changes, what doesn't
Nothing is decommissioned. Your data stays yours.
How does this fit with what we already use?
No. Nothing is decommissioned to join the pilot. We walk through how this fits alongside what you already run — including your HMIS, your internal case notes, and whatever spreadsheet is currently holding the part neither of them covers.
That spreadsheet is usually the tell. If your team keeps handoff tracking on paper or in a sheet because the HMIS cannot do it, that is exactly the gap this fills.
Coordination between providers is treated as a core function by the U.S. Interagency Council on Homelessness, but no HMIS homeless management information system is asked to enforce it across organizational lines. That is the distinction worth holding onto when you evaluate this: your HMIS is not underperforming, it is doing the job it was scoped for.
What about our data?
Your organization's data belongs to your organization. Export it in a standard format at any time. You can leave and take it with you.
A person's file is visible to the staff working with that person — not to everyone holding a login.
Every time a file is opened, that is recorded.
The public view carries counts and rates only. No names and no case identifiers, ever.
Could data leak? Every system that holds data carries that risk, and anyone who tells you otherwise is selling something. What we can tell you is exactly who can see what, and that the answer is written down rather than assumed.
Who can see what
Your organization
The staff working with that person
The full file
Everyone else holding a login
No access
The public view
Counts and rates only. No names, ever.
You, at any time
A full export, in a standard format
Written down rather than assumed.
Before you ask
Common questions
What role does our HMIS keep?
No. It is scoped to the handoff — whether a referred person arrived. Your HMIS remains your system of record for HUD reporting and program enrollment.
An HMIS homeless management information system is required infrastructure. Every Continuum of Care operates one under HUD's HMIS Data Standards, your CoC selects it, and your reporting obligations run through it. None of that changes, and nothing here is designed to make it change.
What an HMIS was built to do is produce an accurate account of what a program delivered. What it was not built to do is hold a case open across organizational boundaries until somebody on the receiving end confirms a person walked in. That is a different job with a different owner, and treating it as an HMIS shortcoming misreads what the system is for.
The practical test is the one your own staff already know the answer to. If a worker refers someone out today and wants to find out next week whether that person arrived, can they get that from the HMIS without picking up a phone? For most organizations the answer is no, and the workaround is a spreadsheet nobody wants to maintain. That workaround is what this replaces — not the HMIS.
Will our staff have to enter client data twice?
No. The system is scoped to the moment of handoff, not to the intake fields your HMIS already collects.
Our CoC selected our HMIS. Does joining conflict with that?
No. Joining does not change your CoC relationship, your HMIS contract, or your reporting obligations.
Will this route our funding through Pathfinders for Hope?
No. Joining does not route your funding through us and does not put your contracts in our name. A confirmed handoff is a number you use in your own reporting.
What if our HMIS already tracks referral outcomes?
Then compare them. If your HMIS reliably produces receiving-side confirmation of arrival, you may not need this. Most do not, which is why the spreadsheet exists.
How should a referral be closed?
A referral should not be closed simply because it was sent. A confirmed handoff separates a completed connection from an unverified attempt.
A useful outcome record identifies whether the receiving organization accepted the referral, could not accept it, could not reach the person, or needs more information before a decision can be made. It also records who is responsible for the next step.
Your homeless management information system remains the system of record for program activity. The handoff record establishes only what happened between organizations and who owns the next action.
A sent referral may be progress, but it is not proof that a person reached the service they needed. The handoff stays visible until there is a documented result or a clear reason to escalate it.
What information should a receiving organization see?
Only the information needed for the specific handoff should be shared. A referral process has to respect client privacy, program rules, and the receiving organization’s actual eligibility requirements.
The Vallejo pilot is being designed around that boundary. The goal is not to copy a person’s full record into another tool. It is to make the referral understandable enough for the receiving organization to act, then document the outcome without creating a second case file.
Nothing in this process removes records or reporting responsibilities from the homeless management information system. Each participating organization should be clear about what it can receive, what it must verify, and who can see the result. That is how accountability is strengthened without treating more data as the answer.
What makes outcome reporting useful?
Useful reporting shows where a handoff succeeds, where it breaks, and why. It does not just count the number of referrals created.
When organizations can distinguish an accepted connection from a denial, a missed contact, or an unresolved wait, they can see which barriers repeat. That creates a factual basis for improving workflows, resource lists, and partner coordination instead of relying on assumptions.
It also gives partners a responsible way to review their own process. The question becomes clear: where does a person lose momentum, who owns the follow-up, and what change would prevent the same barrier from happening again?
For Pathfinders for Hope, the standard is simple: no person should disappear between a referral and a result. The point of tracking is not to create another report. It is to make sure somebody owns the next step when the first one does not work.
