HMIS Software for a Continuum of Care: What to Build, What to Configure, and What You Should Never Rebuild

Why the system of record is the wrong thing to build

Every few years a continuum of care lead agency gets frustrated enough with its HMIS vendor to ask what a custom system would cost. It is a fair question and it usually has the same answer, so we will give it before the sales pitch rather than after.

HUD revises the HMIS data standards on a fiscal year cycle, with changes taking effect at the start of October. Every revision touches elements, response values, logic and exports. Your system has to produce the HUD CSV export exactly, because the annual performance report and the CAPER are uploaded to SAGE and rejected if the file is wrong, and the longitudinal system analysis submission is stricter still. Federal partner programmes bring their own elements: runaway and homeless youth, PATH, and veteran services all add requirements on top of the core.

Absorbing that every year, forever, is the actual product a vendor sells you. Clarity, Community Services and ClientTrack all do it, and they do it across hundreds of communities so the cost is shared. A single continuum that builds its own becomes the only organisation on earth maintaining that codebase against an annual federal specification change, and the person who understands it will eventually take a different job. We have built plenty of regulated systems and we would still tell you not to build this one.

What is worth building is everything the HMIS was never designed to do, which is most of what your continuum actually struggles with on a Tuesday night.

Problem 1: coordinated entry prioritisation is a local committee decision

HUD requires a coordinated entry process and deliberately leaves the prioritisation design to the community. Yours was designed by a committee, revised after an equity review, and probably moved away from a single vulnerability score toward something combining chronicity, health, time homeless, and locally weighted factors. It changes when the committee decides it should.

HMIS platforms support coordinated entry as configuration: an assessment form, a score, a queue, a referral. That is the generic shape of the process and it fits the first version of most communities' policy. It fits the third version much less well, because by then your policy has case conferencing, tie breaking rules, veteran and youth carve outs, unit specific eligibility matching, and a requirement that any manual override be justified and reviewed.

What a custom layer does: hold the prioritisation policy as a versioned rule set that the committee can see and change without a vendor ticket, evaluate it against HMIS data read through the vendor API, and produce a by name list with the reasoning visible for each person's position. Matching to available units checks actual eligibility, which is where most referrals fail today: a household referred to a unit they cannot qualify for costs a week of everybody's time. Every override records who, why and under which policy version, so your equity review has data instead of anecdote.

Problem 2: bed inventory at 9pm is not what HMIS was built for

Shelter operations are a real time problem. Who is here tonight, which beds are down for maintenance, which family needs two adjoining rooms, who is on a bar and for how long, who left at 6am and whether their bed holds. HMIS enrolments record a stay after the fact. They do not run a front desk at 9pm with a queue in the lobby.

So most shelters run a whiteboard, a Google Sheet or a paper log, and the HMIS entry happens the next morning from that log. Which means your live inventory is fiction, your diversion decisions are made without knowing what is actually free across the continuum, and the data quality problems in your APR were created at a front desk that had no usable tool.

What a custom layer does: a fast check in and check out screen designed for one hand and a queue, bed and unit level inventory with holds and maintenance status, and writes back to HMIS through the vendor API so the enrolment record is created as a by product of operations rather than as a second data entry task. Continuum wide availability becomes visible to outreach and to the coordinated entry team, which is the precondition for diversion actually working.

Problem 3: data quality is a report you export and chase in email

Every HMIS produces a data quality report. The lead agency exports it, sorts it by agency, and emails partner agencies asking them to fix missing destinations, null incomes and open enrolments from 2023. The partner agency has one data person who is also a case manager. Nothing moves until the APR deadline creates a panic.

What a custom layer does: turn quality into a live work queue per agency, per user, per record, with the specific fix required stated in plain language and a direct link into the HMIS record. Trend visibility by agency lets the lead have an evidence based conversation at the governance meeting instead of a scolding email. Detection runs continuously, so an open enrolment surfaces at 30 days rather than at reporting time, which is the difference between a correction and an archaeology project.

Problem 4: the comparable database for domestic violence providers must live outside HMIS

Victim service providers are prohibited from entering client level data into HMIS under the Violence Against Women Act confidentiality provision, and are required instead to use a comparable database that produces equivalent aggregate reporting. Continuums handle this in one of three ways: the provider uses a thin vendor product, the provider uses a spreadsheet, or the provider effectively does not report and the continuum absorbs the gap.

This is one of the genuinely strong build cases in the sector, because the requirement is aggregate equivalence rather than HMIS integration, so you are not chained to the full data standard implementation in the same way. A purpose built comparable database can be designed around the safety needs of the programme, with scoped access, address suppression, controlled export and a quick exit, while still producing the aggregate outputs the continuum needs. Scope is contained and the value to the provider is immediate.

Problem 5: your local funders do not use HUD categories

The city general fund contract wants outcomes by council district. The county behavioural health contract wants service units by programme with a different definition of engagement. A philanthropic funder wants a narrative with three specific numbers. None of them map cleanly onto HUD categories, so somebody exports HMIS data to Excel every month and rebuilds all three.

What a custom layer does: a warehouse that pulls HMIS through the vendor API on a schedule, joins it to whatever else matters locally such as street outreach contacts, diversion outcomes or a housing unit inventory, and holds each funder's definitions as versioned metric logic. Reports are generated with drill down to records. Once that exists, the monthly rebuild disappears and, more importantly, the numbers stop disagreeing between reports, which is what erodes trust with funders.

What a companion build should include

• Read and write integration with your HMIS vendor API, with reconciliation reporting so divergence is visible rather than silent.
• Versioned coordinated entry prioritisation with visible reasoning and governed overrides.
• By name list quality tooling for communities working toward functional zero.
• Live bed and unit inventory with front desk grade check in.
• Offline capable street outreach app, because outreach happens where there is no signal and re entering contacts later is how contacts get lost.
• Continuous data quality work queues per agency.
• Local funder reporting from a warehouse with versioned metric definitions.
• Role based access consistent with your continuum's data sharing agreements and client consent model, which differ by provider and by project type.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, a companion layer for a continuum, meaning HMIS integration plus one or two high value modules such as coordinated entry decision support and data quality queues, runs $60,000 to $150,000 and ships in 10 to 16 weeks. A fuller build adding bed inventory, outreach mobile, warehouse and multi funder reporting runs $180,000 to $400,000 across 6 to 12 months. A domestic violence comparable database as a standalone project sits at the lower end, typically $50,000 to $110,000, because its scope is genuinely contained.

What drives cost up here: your HMIS vendor's API, which varies considerably in coverage and in what it will let you write back, and in the worst case forces scheduled exports instead of live integration. The number of partner agencies, since each one brings a data sharing agreement and a consent posture. Offline outreach, which is real engineering. And any ambition to include non HMIS systems such as behavioural health, jail release or benefits data, where the legal agreements take longer than the code.

What keeps cost down: choosing the one module that hurts most and shipping it alone. Continuums that try to build everything at once usually ship nothing before the next APR deadline consumes the staff.

When to build and when to configure

Configure, and stop, if your continuum has under roughly 20 participating agencies, a coordinated entry policy that fits a score and a queue, and no shelter operations problem. Your vendor's configuration will cover you and a build will not repay.

Build a companion layer when two or more of these are true. Your coordinated entry policy has outgrown a score, particularly after an equity redesign. Your shelters run on whiteboards and your live availability is unknown. Your data quality process is an email chase. Local funders require reporting that 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.

Do not build the system of record. If your dissatisfaction is with your vendor rather than with the gaps, the right move is a competitive procurement between Clarity, Community Services, ClientTrack and Apricot, not a custom rewrite of a federal specification you did not write and cannot freeze.

How to choose a developer for homeless services systems

Ask them whether you should replace your HMIS. A developer who says yes without asking about the annual data standard cycle is either uninformed or selling, and both are expensive.

Ask what they have done with a vendor API and what they did when the API 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.

Ask how they would represent a coordinated entry policy that the committee changes annually while historical placements must remain explicable under the policy that applied at the time. Versioned rule sets and decisions that store their version is the answer.

Ask how consent and data sharing agreements are enforced when providers have different postures, and specifically what the system does about a victim service provider's data. Then settle ownership in writing before kickoff: repository, cloud accounts, data export and the right to hire another firm. At Digital Heroes the lead agency owns the code from the first commit, which matters because continuum leadership rotates and the system has to survive that.