Homeless Services HMIS Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do continuums keep deciding to replace their HMIS?

Every few years a lead agency gets frustrated enough with its vendor to price a custom system of record, and the reasoning is always sound at the surface. The vendor is slow. A change request that should take a week takes two quarters. Coordinated entry no longer matches the policy the committee approved. Reports do not answer what funders ask. All of that is real.

The conclusion does not follow, because the frustration is with the gaps and the proposal replaces the core. Bitfocus Clarity, WellSky Community Services and Eccovia ClientTrack are not primarily selling you screens. They are selling the annual work of absorbing HUD data standard revisions across hundreds of communities so that the cost is shared. Take that on alone and you have converted a licence fee into a permanent engineering commitment, funded from grants that were not written to cover it.

It also happens because replacement is a decision a board can make in one meeting, whereas identifying the four things your continuum actually needs takes a week of sitting with a shelter front desk, an outreach worker and the person who assembles the annual report.

The fix is a two column exercise before anyone writes a specification. In one column list everything failing that is genuinely about the federal standard and the export. In the other, list what is failing about coordinated entry policy, bed inventory, data quality chasing, outreach in the field and local funder reporting. The first column is a procurement question, and running a competitive process between Clarity, Community Services, ClientTrack and Apricot is the correct response. The second column is what a build should address. Ask any developer whether you should replace your HMIS, and if they say yes without raising the annual data standard cycle, they are either uninformed or selling.

What goes wrong when the companion layer starts reading HMIS data?

The data problems in this sector are not the usual ones. There is rarely a migration, because the HMIS stays. The problems are coverage, identity and consent.

Coverage is the first. Vendor application programming interfaces vary considerably in what they expose, and the field you need is frequently the one that is not there. Custom assessment questions your community added, the fields a partner agency uses for its own programme, and anything in a vendor specific module tend to be the least accessible, and those are exactly the fields a local prioritisation policy depends on.

Identity is the second. The same person appears across agencies, across programme types and across years, with different name spellings, partial dates of birth and varying levels of identifying information collected under different consent postures. Any by name list, any prioritisation queue and any measure of returns to homelessness rests on resolving that, and no vendor export resolves it for you.

Consent is the third, and it is not a technical attribute. Providers in the same continuum operate under different data sharing agreements, so two records that look identical may carry different permission to be seen, matched or reported.

The fix is a coverage audit and a reconciliation report before design. Pull the actual interface documentation, test the specific fields your policy needs, and write down which ones will require a scheduled export instead of a live read. Then build a divergence report that shows where the companion layer and the HMIS disagree, so drift is visible rather than silent. Treat identity resolution as a named workstream with a human review queue, never as a silent automatic match, because a wrong merge in this sector is a safety issue rather than a data quality issue.

Why do the vendor integrations break after launch?

Two clocks run against you, and neither is under your control.

The first is the federal one. HUD revises the data standards on a fiscal year cycle with changes taking effect at the start of October, touching elements, response values, logic and exports. Your vendor implements those changes on their own schedule, which means field meanings and response sets in the interface you read can shift during a period when your staff are also learning new intake questions. A companion layer that assumed last year's response values will produce quietly wrong prioritisation for weeks before anyone notices, because the numbers still look plausible.

The second is the vendor's own release cycle. Schema changes, deprecated endpoints, tightened rate limits and revised authentication all arrive with vendor release notes that nobody at the lead agency reads, because reading vendor release notes is not anyone's job.

The fix is contract validation and one named owner for the interface. Validate the shape of what you receive on every run rather than assuming it, and fail loudly with an alert when a field disappears or a response value is unrecognised, instead of processing it as a null. Give one person at the lead agency responsibility for reading vendor release notes and for the October standards change, and plan a review of prioritisation logic every autumn as a standing task. Ask any developer what they did when a vendor interface did not expose a needed field. The realistic answer involves scheduled exports, reconciliation and a documented divergence report, not a claim that everything syncs perfectly.

What happens when consent and victim service confidentiality are not designed in?

Two gaps in this sector are not inefficiencies. They are harms.

The first is consent modelling. Access designed as a single global role model, where a case manager sees everything or nothing, does not match how a continuum actually operates. Providers have different data sharing agreements, clients give different permissions, and some project types carry additional restrictions. A companion layer that reads broadly and displays broadly can expose information a client never agreed to share across agencies, and the person who discovers that is usually the client.

The second is victim service providers. They are prohibited from entering client level data into HMIS under the Violence Against Women Act confidentiality provision, and are required to use a comparable database producing equivalent aggregate reporting. Continuums that never solve this end up with a provider on a spreadsheet, or effectively not reporting, and the continuum absorbs the gap.

The fix is to make consent a first class property and to build the comparable database as its own project. Permissions should follow the provider agreement and the client's recorded consent, enforced at query time rather than in the user interface, with an access log. For victim services, the requirement is aggregate equivalence rather than HMIS integration, so scope is genuinely contained and the design can centre on safety: scoped access, address suppression, controlled export and a quick exit. Settle retention and destruction rules at the same time, because a system holding this data with no deletion policy is a liability waiting for a subpoena.

Should you build custom or configure what you already own?

If your continuum has under roughly twenty participating agencies, a coordinated entry policy that genuinely fits a score and a queue, and no shelter operations problem, configure and stop. Your vendor's configuration will cover you and a build will not repay. That is the honest answer for a large number of communities and we give it regularly.

Configuration handles the first version of a coordinated entry policy well: an assessment, a score, a queue, a referral. It handles the third version much less well, once you have case conferencing, tie breaking rules, population carve outs, unit level eligibility matching and a requirement that manual overrides be justified and reviewed after an equity redesign. That is where a versioned rule set with visible reasoning per person starts to matter, and it is the clearest single build case in the sector.

Build a companion layer when two or more of these are true. Your coordinated entry policy has outgrown a score. Your shelters run on whiteboards and continuum wide availability is unknown at nine at night. Data quality is an email chase that only moves before a deadline. Local funders require reporting HUD categories cannot produce. Or you have a victim service provider without a workable comparable database, which is both a compliance gap and a service gap.

And to repeat the point that matters most: do not build the system of record.

How do hidden costs get into the quote?

Four items reliably arrive after signature. The vendor interface, quoted as an integration and delivered as a coverage negotiation once you discover which fields are not exposed and which have to come through scheduled exports. The number of partner agencies, because each brings a data sharing agreement, a consent posture and a training obligation, and none of that is engineering. Offline outreach, which is real engineering rather than a mobile view. And any ambition to include non HMIS sources such as behavioural health, jail release or benefits data, where the legal agreements take substantially longer than the code.

The fifth is the annual maintenance nobody quotes: the October standards review, the vendor release cycle, and the prioritisation logic review that follows every policy change your committee makes.

The fix is to price the ongoing obligation alongside the build. Ask what the annual cost is to keep the companion layer aligned with the vendor and the standards, who performs the October review, and what happens if a needed field is not available through the interface. A developer who has done this will answer specifically. One who treats it as a one off project has not shipped into a federally specified environment.

What separates an HMIS companion build that works from one that fails?

The builds that work pick one module and ship it alone. Continuums that attempt coordinated entry, bed inventory, outreach, data quality and funder reporting simultaneously usually ship nothing, because the next annual report deadline consumes the same staff the project depends on. Choose the thing that hurts most, deliver it, let people use it, then extend.

They make policy visible and versioned. A prioritisation rule set the committee can see and change without a vendor ticket, with each person's position on the list explaining itself, and every decision storing the policy version that produced it. That last detail is what lets you explain a placement made two years ago under a policy you have since revised, which is the question an equity review will actually ask.

They design for the front desk and the street rather than for the report. Check in and check out that works with one hand and a queue in the lobby, writing the enrolment back through the vendor interface so the record is a by product of operations rather than a second data entry task. An outreach app that captures contact, location, needs and consent with no signal and syncs later, because anything requiring live connectivity will be abandoned within a fortnight and the contacts will be lost.

And they settle ownership before kickoff: the repository, the cloud accounts, a usable data export and the unrestricted right to hire another firm, in writing. At Digital Heroes the lead agency owns the code from the first commit. Continuum leadership rotates, funding changes, and the system has to survive both.