Pathfinders for Hope
01 · —
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.
No. Operation Iron Gate does not replace your HMIS homeless management information system, does not compete with it, and is not a second place to type the same client data. Your HMIS reports what happened. Operation Iron Gate records one thing your HMIS does not: whether the person you handed off actually arrived.
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
Does not replace your HMIS
No second place to type client data
Your HMIS stays your system of record
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
Already in your HMIS
Client demographics
Program enrollment
Internal case notes
Exit reason
3
Fields the handoff adds
Who received the referral
Whether the person arrived
When it was confirmed
Everything on the left already lives in your HMIS. It is not re-collected here.
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
Your HMIS reports what happened. Operation Iron Gate makes sure it happens.
What changes, what doesn't
Nothing is decommissioned. Your data stays yours.
Do we have to replace 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
Does Operation Iron Gate replace our HMIS?
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. The purpose of a confirmed handoff is to separate 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. This record only establishes what happened at the handoff, and it does not replace that responsibility.
That distinction matters. 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.