HMIS: Why Homeless Shelters Must Collect Data or Die

Next year, homelessness is scheduled for a head-on collision with information technology. The plan is called HMIS (for "Homeless Management Information System"), and its main architect, the U.S. Department of Housing and Urban Development ( HUD), hopes it will increase understanding of homelessness in America. But homeless advocates argue that HMIS will have little impact besides making services harder for homeless people to access. And privacy experts warn that the plan will prove highly invasive, especially for the most vulnerable.

Regardless, HMIS seems here to stay. Every agency that receives HUD funding for homelessness services must become compliant with HMIS in late 2004 or face potential funding cuts. (In fact, HUD has asked 85 pilot communities to kick off by January 2004.) HUD is responding to pressure from Congress, which has long asked HUD to explain who is homeless in America and how HUD's homelessness grants -- currently $1.2 billion annually -- are addressing the problem.

What Does HMIS Do?

The HMIS project's first goal is to deliver an unduplicated count of homeless people who are assisted by HUD funds. The count must be conducted community-wide (generally by county), so your neighborhood shelter can't just set up an HMIS on its own. HMIS projects must also track demographics and services.

HMIS enthusiasts envision the project leading to a genuine revolution in the system of homeless services. They imagine a case worker pulling up client files, making referrals between agencies, and calculating a client's eligibility for government funds -- all at the touch of a keyboard. In San Francisco, where this vision is already starting to take form, homeless people must submit a data intake form, photo, and fingerprints to a central HMIS database before receiving city services.

Privacy Concerns

Such comprehensive data collection worries privacy advocates. HUD insists that it has no plans to extract detailed personal data from the HMIS, only aggregate counts and cross-tabulations.

But government agents may sieze HMIS data by subpoena, and in some cases merely at will. Malicious intruders can snatch it by guile. The Electronic Privacy Information Center ( EPIC), one of the first advocacy groups to analyze the consequences of HMIS, calls HMIS a "honey pot" of personal data that can be mined to discredit or embarrass people. For women fleeing domestic abusers or people facing discrimination because of HIV and AIDS, these disclosures could be devastating. To add to the confusion, communities must figure out how to balance HMIS's demand for personal client data with other federal regulations (notably new HIPAA rules protecting medical information) that generally forbid disclosure of such data.

The HMIS Standards

Exactly what data must an HMIS collect? HUD's Standards Notice of July 2003 is a good preliminary guide. HUD-funded providers (such as shelters) must collect about a dozen "universal data elements" -- client identifiers, plus demographics such as gender, race, age, and last permanent zip code -- for every homeless person they serve. HUD also suggests about 125 "program-level" data elements to be collected at intake, exit, follow-up, and service delivery. HUD hasn't clarified whether these extra elements are mandatory or optional, so communities may feel forced to collect as many as possible, just in case.

Though the Standards Notice is HUD's blueprint for HMIS, it has some surprising gaps:

• HUD never explains how HMIS data will be used once it is collected. Presumably, communities must eventually deliver aggregate reports to HUD, but no such reports are described.
• Just as oddly, HUD neglects any definition of HMIS's data structure, leaving each community to reinvent the system's essential architecture.
• Incredibly, the standards overlook several of the data elements (notably, determination of "chronic homelessness") most critical to HMIS's success.

HUD promises a revised version of the standards in December. If the revision doesn't address these omissions, communities may simply have to improvise corrections of their own.

Implementing an HMIS Project

HMIS is expensive. Counties in the San Francisco Bay Area are already budgeting tens to hundreds of thousands of dollars each for the first year of HMIS development and operation. Yet funding is scarce; HUD isn't giving communities new money for HMIS (though grantees may raid their HUD program funds to pay for technology), and state and local funders are financially strapped.

To survive HMIS, communities must plan skillfully. It's easy to focus on "which software should we buy," but in fact that's among the last of many decisions.

BACHIC, a Bay Area collaboration of HUD-funded communities, developed a structure for written HMIS plans based on eleven questions about what data to collect and how. This approach acknowledges that HMIS's real challenge isn't technology, it's getting a community of homeless people and their service providers to work together to answer complex questions meaningfully.

HMIS Technologies

That said, the technology involved in an HMIS is complex. Data must be collected (and undublicated) on a community-wide basis, so the first challenge is getting the data from multiple collection points to a single central database.

One way to do that is with Web-based software. Most users need only a computer, a Web browser, and an Internet connection to access the system. Data and software are maintained by a central host. Usually, communities pay a commercial application service provider (or ASP) to host the HMIS for them. If communities are unwilling to let strangers hold their data, they can license software (or even build their own) and host the HMIS themselves, usually in a county office that already has technology infrastructure and experience.

Whether hosted by an ASP or self-hosted, Web-based software is pricey. Besides costs already mentioned, there are generally one-time and ongoing costs for hardware, routers, data lines, network maintenance, and lots and lots of user training. Actual budgets vary greatly, but try $100,000 as a baseline figure for year one.

A far less expensive approach is "paper to desktop." Users collect client data on paper forms; these are handed over to a central location, where staff enter the data to a local system, such as an Microsoft Access database on a desktop computer. It's cheap; it's flexible; it maximizes security, since the central database can be completely off the network; and since it requires minimal training for service providers, it can get rolling quickly. The catch? Data travels to the central database only, so it's not for communities that want to zap client data directly from one agency to another. But it can be a simple, economical way to meet minimum HMIS requirements.

Regardless of the solution, beware any vendor's assurances that a system is "HMIS compliant." So far, HUD won't certify any system as compliant. Your community needs a trusted expert to confirm that a system does, in fact, meet HUD's rather loosely defined (and still-changing) standards.

The Verdict?

For many serving the homeless, HMIS is just another bureaucratic nightmare. Expensive and intrusive, unfunded and poorly designed, the project is unlikely -- they argue -- to achieve its stated goals. Nevertheless, with HMIS apparently here to stay, communities must undertake good planning to make the best of it. By focusing on HMIS's true requirements, instead of technological gadgetry, communities may find modest, cost-effective HMIS solutions. The real payoff is good data, which may eventually support understanding and policies to fight homelessness more effectively, both locally and nationally.

Sources for This Article

• HUD's overview page on HMIS
• "Orwell's Vision Becomes Reality for the Homeless": Editorial from San Francisco's Street Sheet, October 2003: Editorial from San Francisco's Street Sheet, October 2003
• EPIC's "Fact Sheet on HMIS" (PDF)
• "Summary of HIPAA regulations" from U.S. Department of Health and Human Services, Office of Civil Rights (PDF)
• HUD's "Standards Notice" (July 2003, PDF)