2017 HMIS Data Standards Manual V1.3 April 2018

HMIS-Data-Standards-Manual

User Manual:

Open the PDF directly: View PDF .
Page Count: 91

Download
Open PDF In Browser	View PDF

HMIS Data Standards

MANUAL

April 2018

U.S. Department of Housing and Urban Development
Aligns with Version 1.3 of the HMIS Data Dictionary

1. INTRODUCTION ......................................................................................................................................... 1
HMIS Data Standards Overview ................................................................................................................ 1
Related Documents................................................................................................................................... 1
HMIS Data Standard Documents .......................................................................................................... 2
HMIS Federal Partner Program Manuals .............................................................................................. 2
HMIS Data Standards Terms and Concepts .............................................................................................. 4
Data Element Structure ............................................................................................................................ 4
Sample HMIS Data Element .................................................................................................................. 4
Reference Tables....................................................................................................................................... 5
Metadata and Data Element Relationships .............................................................................................. 5
2. PROJECT DESCRIPTOR DATA ELEMENTS ................................................................................................... 7
HMIS Project Setup Guidance ................................................................................................................... 8
Multiple Funding Sources ..................................................................................................................... 8
Multiple Project Setup .......................................................................................................................... 9
Elements ................................................................................................................................................. 10
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8

Organization Identifiers ....................................................................................................... 10
Project Identifiers ................................................................................................................. 11
Continuum of Care Code ...................................................................................................... 12
Project Type ......................................................................................................................... 13
Method for Tracking Emergency Shelter Utilization ............................................................ 17
Federal Partner Funding Sources ......................................................................................... 19
Bed and Unit Inventory Information .................................................................................... 22
Additional Project Information ............................................................................................ 27

3. UNIVERSAL DATA ELEMENTS .................................................................................................................. 29
General Data Collection Guidance .......................................................................................................... 29
Data Collection Guidance by Project Type.............................................................................................. 30
Universal Identifier Elements (One and Only One per Client Record).................................................... 33
3.1
3.2
3.3
3.4
3.5
3.6
3.7

Name .................................................................................................................................... 33
Social Security Number ........................................................................................................ 35
Date of Birth ......................................................................................................................... 36
Race ...................................................................................................................................... 37
Ethnicity ............................................................................................................................... 39
Gender.................................................................................................................................. 40
Veteran Status ...................................................................................................................... 41

Universal Project Stay Elements (One or More Value(s) Per Client or Household Project Stay) ........... 43
3.8
3.10
3.11
3.12
3.15
3.16
3.20
3.917

Disabling Condition .............................................................................................................. 43
Project Start Date ................................................................................................................. 45
Project Exit Date ................................................................................................................... 46
Destination ........................................................................................................................... 48
Relationship to Head of Household ..................................................................................... 52
Client Location...................................................................................................................... 54
Housing Move-in Date ......................................................................................................... 55
Living Situation ..................................................................................................................... 56
i

4. PROGRAM SPECIFIC DATA ELEMENTS .................................................................................................... 62
Common Program Specific Data Elements ............................................................................................. 64
4.2
Income and Sources ............................................................................................................. 64
4.3
Non-Cash Benefits ................................................................................................................ 68
4.4
Health Insurance .................................................................................................................. 70
4.5 – 4.10 Disability Elements ............................................................................................................. 72
Physical Disability ................................................................................................................. 73
4.5
4.6
Developmental Disability ..................................................................................................... 74
4.7
Chronic Health Condition ..................................................................................................... 75
4.8
HIV/AIDS ............................................................................................................................... 76
Mental Health Problem ........................................................................................................ 77
4.9
Substance Abuse .................................................................................................................. 78
4.10
4.11
Domestic Violence................................................................................................................ 79
4.12
Contact ................................................................................................................................. 81
4.13
Date of Engagement............................................................................................................. 82
Bed-Night Date ..................................................................................................................... 82
4.14
Housing Assessment Disposition.......................................................................................... 83
4.18
APPENDIX A. FEDERAL PARTNER PROGRAM COMPONENTS: ASSOCIATED HMIS PROJECT TYPES AND
FUNDING SOURCES ..................................................................................................................................... 84
U.S. Department of Housing and Urban Development (HUD)................................................................ 84
U.S. Department of Housing and Urban Development (HUD) and U.S. Department of Justice (DOJ) ... 85
Substance Abuse and Mental Health Services Administration (SAMHSA) ............................................. 85
U.S. Department of Health and Human Services (HHS) Administration for Children and Families (ACYF)
Family and Youth Services Bureau (FYSB) ............................................................................................... 86
U.S. Department of Veteran Affairs (VA) ................................................................................................ 86
APPENDIX B. DATA ELEMENT COLLECTION SUMMARY .............................................................................. 87

1. INTRODUCTION
HMIS Data Standards Overview
A Homeless Management Information System (HMIS) is the information system designated by a local
Continuum of Care (CoC) to comply with the requirements of CoC Program interim rule 24 CFR 578. It is
a locally-administered data system used to record and analyze client, service, and housing data for
individuals and families who are homeless or at risk of homelessness.
HMIS is administered by the U.S. Department of Housing and Urban Development (HUD) through the
Office of Special Needs Assistance Programs (SNAPS) as its comprehensive data response to the
congressional mandate to report annually on national homelessness. It is used by all projects that target
services to persons experiencing homelessness within SNAPS and the office of HIV-AIDS Housing. It is
also used by other federal partners from the U.S. Department of Health and Human Services (HHS) and
the U.S. Department of Veterans Affairs and their respective programs to measure project performance
and participate in benchmarking of the national effort to end homelessness.
The HMIS Data Standards were first published by HUD in 2004 as the HMIS Data and Technical
Standards. The original standards served as the foundation for software developers in constructing HMIS
applications. In March 2010, HUD updated the Data Standards (March 2010 HMIS Data Standards),
primarily to reflect data collection requirements for the Homelessness Prevention and Rapid Rehousing
Program (HPRP). HUD, in collaboration with its federal partners, updated the HMIS Data Standards again
in 2014 with the release of the 2014 HMIS Data Standards Manual and Data Dictionary. Both documents
superseded the previously released HMIS Data Standards. Together, the 2017 HMIS Data Standards
Dictionary and Manual are the documentation of requirements for the programming and use of all
HMIS systems and comparable database systems, 1 effective October 1, 2017.
This manual is designed for CoCs, HMIS Lead Agencies, HMIS System Administrators, and HMIS Users to
help them understand the data elements that are required in an HMIS to meet participation and
reporting requirements established by HUD and the federal partners. An HMIS software must be able to
collect all the data elements defined within these HMIS Data Standards, support the system logic
identified in the HMIS Data Dictionary, and ensure that the visibility of data elements is appropriate to
the Project Type and Federal Partner Funding Sources for any given project.
There are many software products on the market that communities across the county have chosen to
use as their HMIS. Each product has unique features and was built to meet the different data collection
needs of each community. Each software vendor should provide the guidance, support, and
documentation necessary for the CoC to understand the system they are using.
Communities may elect to add data elements or maintain historical data element collection beyond
what is specified in the Data Standards as long as it does not impact the ability of the CoC to accurately
collect and report on the required data elements. In these cases, HMIS Leads should work directly with
their HMIS vendors to meet their individual needs.
Related Documents
There are a variety of documents that comprise the suite of HMIS Data Standard resources. Each of the
documents has a specific purpose and intended audience. The HMIS Lead should be familiar with all of
the documents and collectively use them as their HMIS reference materials along with specific materials
provided by the software vendor.
1

Comparable databases are required for use by providers of services for victims of domestic violence, as
described in the VAWA.
1

HMIS Data Standard Documents
The 2017 HMIS Data Standards Dictionary and Manual together contain the foundation for the data
contained within an HMIS, project set up instructions, and data collection instructions.
Document Name
HMIS Data Standards
Dictionary

Intended Audience
HMIS Vendors & HMIS
Lead Agencies

Contents
The Dictionary provides the detailed information
required for system programming of each HMIS
element and the responses required for an HMIS
software. It delineates data collection
requirements, system logic, and contains the XML
and CSV tables and numbers.
It also includes critical information about data
collection stages, federal partner data collection
required elements, and metadata data elements.

HMIS Data Standards
Manual

HMIS Lead Agencies &
HMIS Users

The manual provides data collection instructions
for the Project Descriptor Data Elements,
Universal Data Elements, and the common
Program Specific Data Elements. It contains
information on project setup, client-level data
collection requirements, and detailed
descriptions of each data element.

HMIS Federal Partner Program Manuals
These manuals contain specific and detailed information on project setup for each of the federal
partners participating in HMIS including: HMIS project typing, the specific data elements required for
collection by that federal partner, program-specific meanings and definitions, and key information that
the federal partner has identified as required for their program. Each Manual was created jointly by HUD
and the relevant federal partner, and approved by both entities prior to publishing.
Links to each Manual will be made available on the 2017 HMIS Data Standards resource page as they are
updated.

Manual Name
CoC Program
HMIS Manual

Intended
Audience
• HMIS Lead
Agencies
• HMIS Users
• Grantees

Federal Partner

Contents

U.S. Department of Housing and
Urban Development –
Office of Special Needs
Assistance Programs

The manual assists in project set up
of all Continuum of Care (CoC)
Program component projects:
Transitional Housing, Permanent
Supportive Housing, Rapid ReHousing, and Services Only.

CoC Program information link

ESG Program
HMIS Manual

•
•
•
•

HOPWA
Program HMIS
Manual

PATH Program
HMIS Manual

•
•
•
•
•
•

RHY Program
HMIS Manual

•
•
•

VA Program
HMIS Manual

•
•
•

HMIS Lead
Agencies
HMIS Users
Recipients
Subrecipients

HMIS Lead
Agencies
HMIS Users
Grantees
HMIS Lead
Agencies
HMIS Users
Grantees
HMIS Lead
Agencies
HMIS Users
Grantees

HMIS Lead
Agencies
HMIS Users
Grantees

U.S. Department of Housing and
Urban Development –
Office of Special Needs
Assistance Programs
ESG Program information link

U.S. Department of Housing and
Urban Development –
Office of HIV/AIDS Housing
HOPWA Program information
link
U.S. Department of Health and
Human Services
Substance Abuse and Mental
Health Services Administration
PATH Program information link
U.S. Department of Health and
Human Services
Administration for Children and
Families
Family and Youth Service Bureau
RHY Program information link
Department of Veterans Affairs
VA Program information link

Information aligns with the CoC
Program Interim Rule
The manual assists in project set up
of all Emergency Solution Grant
(ESG) Program component
projects: Emergency Shelter (night
by night and entry/exit), Street
Outreach, Rapid Re- Housing and
Homelessness Prevention.
Information aligns with the ESG
Program Interim Rule
The manual assists in project set up
of all of the Housing Opportunities
for Persons with AIDS (HOPWA)
program components.
The manual assists in project set up
for all Projects for Assistance in
Transition from Homelessness
(PATH) program component
projects: Street Outreach and
Services Only.
The manual assists in project set up
for all Runaway and Homeless
Youth program component
projects: Basic Center Program,
Street Outreach Program,
Transitional Living Program, and
Maternity Group Homes.
This manual assists in projects set
up for the Veteran’s homeless
programs. Programs on HMIS
include: SSVF and GPD programs of
the VA.

HMIS Data Standards Terms and Concepts
Continuum of Care (CoC) is used in multiple ways:
1. Continuum of Care and Continuum means the group organized to carry out the responsibilities
required under the CoC Program Interim Rule (24 CFR Part 578) and comprises representatives
of organizations, including nonprofit homeless providers, victim service providers, faith-based
organizations, governments, businesses, advocates, public housing agencies, school districts,
social service providers, mental health agencies, hospitals, universities, affordable housing
developers, and law enforcement, and organizations that serve homeless and formerly
homeless persons to the extent that these groups are represented within the geographic area
and are available to participate.
2. CoC Program refers to the federal funding source which provides housing and/or service grant
dollars.
3. Continuum project refers to a distinct unit of an organization, which may or may not be funded
by HUD or the federal partners, whose primary purpose is to provide services and/or lodging for
the homeless and is identified by the Continuum as part of its service system. [Note: a project
funded by the HUD’s CoC Program may be referred to then as a “CoC Program-funded
continuum project”.]
HMIS User means the individual who uses or enters data in an HMIS or a comparable database
approved by the CoC.
HMIS Lead means the entity designated by the Continuum of Care in accordance with the HMIS
Proposed Rule 2 (24 CFR Part 580) to operate the Continuum’s HMIS on the Continuum’s behalf.
HMIS System Administrator means the individual(s) whose job it is to manage the HMIS
implementation at the local level: enrolling programs and managing appropriate use, supporting users
through connection to, or direct provision of, user training, and overseeing system setup.
Project versus Program Across the federal agencies the terms project and program are used differently.
In this document, and for the purposes of data collection in HMIS, a program refers to the federal
funding source (e.g., HUD CoC, HHS PATH, VA SSVF, etc.) whereas project refers to a distinct unit of an
organization as set up in the HMIS.
Data Element Structure
The key data elements required by HUD and most federal partner programs are included in this Manual.
This Manual is intended to be read in conjunction with the HMIS Data Dictionary, providing the data
collection guidance necessary for System Administrators and HMIS Users to use in local trainings. The
following format is used to describe each data element:
Sample HMIS Data Element
Rationale and Reporting Utility provides a basic rationale for data collection for the element and
describes how the data are used in national or local reporting.
Data Collection Instruction (client-level data elements only) or Project Setup Instruction (project
descriptor data elements only) provides overall instructions for data collection and entry. Project setup
and data collection instructions specific to an HMIS federal partner program can be found in the HMIS
Federal Partner Program Manuals.
2

As of June, 2017 the HMIS Rule is not in effect. When HUD publishing the final HMIS Rule communities will be
given time to come into compliance with the rule.

Most data elements include a ‘Client doesn’t know’ or ‘Client refused’ response category. It is not the
intention of the federal partners that clients be denied assistance if they refuse or are unable to supply
the information. However, some information may be required by projects or public or private funders to
determine eligibility for housing or services, or to assess needed services.
The ‘Client doesn’t know’ or ‘Client refused’ responses should not be used to indicate that the case
manager or data entry person does not know the client’s response. Nor are these responses to be
assumed without first asking the client to provide the information. Some clients may decline to provide
responses to some fields but case managers or data entry staff may not make that decision for them. At
a national level, in every project type, a majority of clients are willing to provide identifying information.
If a project is experiencing a high rate of client refusals as compared to similar projects, CoCs may wish
to consider implementing trainings around interviewing or trust-building techniques to support client
engagement. A deeper engagement with clients may lead to more rapid movement off the street and
placement in housing, consistent with meeting federal goals to end homelessness and improvement on
HUD’s System Performance Measures.
The HMIS Data Standards assume that fields for which data are not collected will be left blank (i.e.,
‘missing’). In situations where a system requires a response to all data fields before saving a record, the
system must use a specific response category to indicate that data were not collected. In such cases,
that response category must be treated as missing data for reporting purposes.
Data Element Fields and Responses
Field

Dependency

# Field
Name

Dependent Fields and the Field/
Response option to which they are
dependent.
The dependencies outlined in the
Data Dictionary are expected to be
visible to users on-screen. The
methods vendors use to make
dependencies visible will vary by
software provider.

Response Category/
Data Type
# All response options
associated with the
field, and their data
type, if specified.

Descriptions
General definitions and
descriptions of fields and
responses.
More detailed, programspecific descriptions can
be found in the HMIS
Federal Partner Program
Manuals, as applicable.

Reference Tables
Additional information about each client-level data element can be found in the Appendices.
•

•

Appendix A identifies all HMIS Federal Partner programs and components that may use the
HMIS, the Program and Component/Activity abbreviations used throughout the Manual, and
associates each Component/Activity with an HMIS Project Type and Federal Partner Funding
Source.
Appendix B summarizes the client universe for each data element contained in this manual and
when it is collected.

Metadata and Data Element Relationships
The term metadata is often defined as “data about data.” Instead of capturing information about a
project or a client, Metadata Elements capture information about the data itself; when it was collected,
when it was entered into HMIS, who entered it, and which project is responsible for it. The Metadata
Elements are intended to facilitate reporting from HMIS, to simplify the writing of programming
specifications, and to provide an audit trail.
5

A complete list of metadata elements and logic for those elements can be found in the HMIS Data
Dictionary. These elements do not represent an attempt to standardize the way that HMIS solutions
store data. As long as an HMIS solution is able to accomplish the purposes identified in the rationale for
the Metadata Elements, the solution is not required to use the exact metadata elements. Programming
specifications for reports reference the Metadata Elements.

2. PROJECT DESCRIPTOR DATA ELEMENTS
Project descriptor data elements (PDDE) are intended to identify the organization, specific project, and
project details to which an individual client record in an HMIS is associated.
They enable the HMIS to:
1. Associate client-level records with the various projects that the client will enroll in across
continuum projects;
2. Clearly define the type of project the client is associated with the entire time they received
housing or services;
3. Identify which federal partner programs are providing funding to the project; and
4. Track bed and unit inventory and other information, by project, which is relevant for the Annual
Homeless Assessment Report (AHAR), System Performance Measures, Housing Inventory Counts
(HIC), Point In Time (PIT) counts, and utilization analysis
This section describes the data to be recorded in HMIS for each project descriptor data element and its
relation to each project entering data. Correct use of the 2.4 Project Type and 2.6 Funding Sources data
elements will help assure that projects are identified for correct visibility and are able to generate
reports required for each of the federal partners as reporting parameters will be based off of one or
both of these elements.
Project descriptor data are generally entered and managed in an HMIS by the HMIS Lead, not a project
end user. They are created at initial project setup within the HMIS and should be reviewed at least once
annually and as often as needed to ensure that reporting is accurate. The HMIS Lead, in consultation
with the CoC, should develop a plan and timeline for routine review and updates to PDDEs. If any
project descriptor data is entered or updated by project end users, the HMIS Lead Agency must have
oversight and data entry/edit ability along with strong review procedures to assure timely, accurate and
complete data.
At a minimum, the HMIS Lead Agency must ensure that the HMIS includes project descriptor
information for all continuum projects participating in HMIS and all residential continuum projects,
regardless of their participation in HMIS. If the HMIS database includes client and service data entered
by non-continuum projects, the continuum must identify them as such using the PDDEs to ensure that
data are excluded from required reporting on continuum projects.
HUD requires that the CoC must collect program information in the HMIS on all continuum projects
within its jurisdiction participating in HMIS and all residential continuum projects, regardless of their
participation in HMIS (last required in the 2010 data standards). This is to facilitate AHAR participation.
The following Project Descriptor Data Elements are required for project setup in HMIS:
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8

Organization Identifiers
Project Identifiers
Continuum of Care Code
Project Type
Method for Tracking Emergency Shelter Utilization
Federal Partner Funding Sources
Bed and Unit Inventory Information
Additional Project Information

HMIS Project Setup Guidance
One of the most critical steps in accurate data collection and reporting is ensuring that a project is set up
properly in an HMIS. If project setup is done incorrectly, this will jeopardize the ability to produce
accurate, reliable reports.
Prior to creating a new project in the HMIS, the HMIS Lead should consult with both the organization
administering the project and the CoC Lead Agency regarding appropriate responses for the PDDEs.
Project Type and Federal Partner Funding Sources are particularly critical as they are the basis for setting
up client-level data collection and for reporting. Project Types must be consistent with grant
agreements and with HIC and PIT guidance issued by HUD each year. Appendix A lists federal funding
sources and programs along with the project type required for each.
Some HMIS applications
automatically configure data collection based on Project Type and Federal Partner Funding Sources to
ensure that minimum requirements are met. Where this is not the case, data collection for each project
must be set up so that all data elements required based on Project Type and Federal Partner Funding
Sources are available for data entry. The HMIS Project Setup Tool provides identifies the required data
elements for each funding source, project type, and funding source combinations.
For additional information on federal partner programs and related project setup guidance, refer to the
applicable federal partner HMIS Program Manual.
Multiple Funding Sources
CoCs may have projects operating in their communities that receive funding from multiple federal
partners for the same project to serve the same clients. There are a few issues the HMIS Lead will need
to consider in these cases.
First, it is important that projects are set up in the system so all data elements needed for all required
reports are “visible” to the end users. For example, a youth shelter may be funded through HUD’s
Emergency Solutions Grants Program (ESG) to support essential services and through HHS’s Runaway
and Homeless Youth (RHY) Program as a Basic Center Program. In this example, the project should be
set up with a Project Type (data element 2.4) of ‘Emergency Shelter’ using the ‘Entry/Exit Date’ Method
for Tracking Shelter Utilization (data element 2.5); it will show both ‘HUD:ESG – Emergency Shelter’
(operating and/or essential services) and ‘HHS:RHY – Basic Center Program’ as the Federal Partner
Funding Source (data element 2.6). With the appropriate project type and correct identification of both
funding sources, all elements required for both federal partner funding sources must be visible, and all
data required for reporting to both funders can be collected. If the HMIS does not automatically
configure data collection based on Project Type and Federal Partner Funding Sources, the HMIS Lead
should reference the HMIS Data Dictionary to appropriately set the element visibility for the project.
Second, it is important to understand how projects are funded and what reports are required of each
funding source because some projects receive funding from multiple funding sources for different
eligible activities. For example, a project may receive a grant for residential operations/leasing costs and
another grant for services. These two grants may be from the same federal program or two different
federal programs. In these cases, HMIS Leads and project providers have two options:
1. Create one project in the HMIS that both the housing provider and the service provider will
jointly share and record data in, or
2. Create two separate projects in the HMIS, one for the housing provider and another for the
service provider.
Correct setup under either option is critically important to accurately record HIC/PIT information and to
support correct system wide performance measures.
8

If a single project is created, the Project Type (data element 2.4) will be the appropriate residential
project type (e.g. Transitional Housing, Permanent Supportive Housing, etc.), and the Federal Partner
Funding Sources (data element 2.6) will identify both funding sources / component types for the project.
If two separate projects are created, each project will be associated only with the specific federal
funding source and component type appropriate to the grant.
•
•

The housing project will have a residential Project Type appropriate to the grant and must
comport with all data collection requirements associated with that project type.
The services project will have a Project Type of ‘Services Only.’ For services only projects, the
Project Type data element includes a question asking if the services only project is affiliated with
a residential project. In this case, the response would be ‘Yes,’ and the residential project would
be identified so that data can be linked.

Multiple Project Setup
There may be other circumstances within the HMIS implementation where a project that appears to be
one project must be set up as two separate projects in an HMIS. Some common examples of this are:
a) If one residential building has both emergency shelter beds and transitional housing beds, this
must be set up as two separate projects, with the Project Types ‘Emergency Shelter’ and
‘Transitional Housing,’ respectively. Clients moving from the shelter bed to the transitional
housing bed, even if in the same building or funded by the same source, will require an exit from
the shelter project and an entry into the transitional housing project. Similarly, a permanent
housing facility may have both a permanent housing for persons with disabilities required for
entry and other units without a disability requirement. Those must be set up as separate
projects in HMIS.
b) Projects that provide Homelessness Prevention and Rapid Re-Housing, whether funded by HUD
or by the VA (i.e., under the Supportive Services for Veteran Families (SSVF) program), must be
set up as two separate projects in the HMIS with the two distinct project types, even if they are
funded under a single grant. In this case, the grant identifier will be the same in both project
setups.
c) Permanent Housing projects are often created with a variety of rental subsidies. Unless the
HMIS has the ability to identify the source and specific grant for a rental subsidy on a client-level
basis, separate projects will have to be created in the HMIS in order to segregate the client
records for reporting purposes. A common example of this is the “pre-HEARTH” McKinney Vento
Shelter Plus Care (S+C) program. Although operated as a unified project, different clients are
served using rental subsidies from multiple S+C grants, each with a different operating year and
grant number. In many systems, in order to accurately report which and how many clients are
served under each separate grant, the grants are set up and maintained as separate projects in
the HMIS unless or until the S+C grants are consolidated under the CoC Program.
d) PATH projects may provide funding to one organization for both traditional street outreach
services and supportive services such case management to persons at-risk of homelessness. In
such cases, PATH requires that two projects be set up in the HMIS, one with the Project Type
‘Street Outreach’ and one with the Project Type ‘Services Only’ to distinguish the projects’
operations and reporting for PATH and to support system level performance measurement.

Elements
2.1
Organization Identifiers
Rationale To uniquely identify organizations operating one or more projects that enter data into HMIS,
as well as any residential continuum projects not participating in HMIS.
Project Setup Instruction Organization Identifiers are assigned once for each organization. Record the
organization’s legal name. The ‘Organization Name’ must be reviewed annually to ensure accuracy.
There must be only one organizational identifier/name for each organization that has projects which
operate in the HMIS implementation.
Many organizations operate multiple projects that participate in HMIS. Projects that are operated by the
same organization must all be associated with the same ‘Organization ID.’ Each project in the HMIS must
be associated with one and only one organization. If the project moves from one organization to
another (e.g. grant transfers to a new organization), an update of the information to associate the
project to the new organization must be made by the system administrator in the HMIS.
An organization’s legal name is not always the name by which it is commonly known in the community.
Some HMIS implementations include an additional field to track more familiar “common names” for
organizations, but this is not required.
Data Element Fields and Responses
Field

Dependency

1 Organization
ID

None

2 Organization
Name

None

Response Category/
Data Type
System generated number
or code. There is no
specified format for this
data element.
[Text]

Descriptions
A unique identifier that must be automatically
generated by the HMIS at the time the
organization is created in the HMIS.
The organization’s legal name.

2.2
Project Identifiers
Rationale To uniquely identify each project entering data into the HMIS, as well as any residential
continuum projects not participating in HMIS. The Project ID is used to link project descriptor
information in other data elements to the specific project, and also to link clients and their enrollment
data to the project.
Project Setup Instruction The ‘Project ID’ must be automatically generated by the HMIS at the time the
project is created in the HMIS. Each project must receive a distinct identifier that is consistently
associated with that project.
In separate fields, record the project's name and operating start/end date, if applicable. This information
must be reviewed annually to ensure accuracy. ‘Project Name’ must be consistent with HUD and other
federal reporting requirements and should match grant agreements or other documentation. Often the
project will have a common name that is used by the community for the specific project, but may also
have different names on formal grant agreements and perhaps even a different name in the HMIS. HMIS
software solutions may elect to create another field for the entry of additional names of the project for
ease of access purposes, but it is not required.
Residential projects that operate in multiple CoCs that cross HMIS systems must be documented in each
CoC’s HMIS, even in cases where all client data are entered into a single CoC’s HMIS.
Project identification can be difficult for HMIS Lead Agencies. A project in HMIS is often referred to as a
“program” by agency providers. When an organization designs a project to assist persons in their
community, they are generally not considering the data collection and reporting requirements
associated with it. Until funding is received for that project, they may not even know the reporting
requirements. Therefore, HMIS project set-up begins with the determination by the System
Administrator or HMIS Lead Agency, in cooperation with the project’s leadership, of whether a new
project will be set up as a single or multiple projects in the HMIS. For more guidance on project setup,
please refer to the Introduction to Section 2.
Data Element Fields and Responses
Field

Dependency

Descriptions

None

Response Category/
Data Type
System generated number or
code. There is no specified
format for this data element.

1 Project ID

2 Project
Name

None

[Text]

The project's name. Where applicable, project
names must be consistent with HUD and other
federal reporting requirements and should match
grant agreements or other documentation.

3 Operating
Start Date

None

[Date]

The first day on which a project provided (or will
provide) services and/or housing. For projects
that began operating prior to October 1, 2012, the
start date may be estimated if it is not known.
Projects that are fully funded but have not yet
begun operating may be entered with future
project start date that reflects the date the
project will begin providing services.

4 Operating
End Date

None

[Date]

The last day on which the project provided or is
expected to provide services and/or housing. It
may be a date in the future; it may also be blank if
the project is expected to continue operating
indefinitely.

A unique identifier that must be automatically
generated by the HMIS at the time the project is
created in the HMIS.

2.3
Continuum of Care Code
Rationale To associate each project entering data into the HMIS, as well as any residential continuum
projects not participating in HMIS, with one or more CoC Code (continuum) for reporting and data
exchange purposes.
Project Setup Instruction ‘Continuum Codes’ are published annually by HUD in the CoC Program NOFA
and are associated with specific geographic areas. Each project must be associated with the HUDassigned code for each CoC in which the project operates (i.e., in which the project is funded to provide
lodging and/or services) and for which the project will be entering data into the HMIS (if applicable).
Some projects are funded to provide lodging and/or services to clients in only one continuum (e.g., CoC:
Transitional Housing); others are funded to provide lodging and/or services across a geographic area
that includes more than one continuum (e.g., some VA-funded SSVF projects). For federally-funded
projects operating in multiple CoCs but entering data into a single HMIS implementation, the
‘Continuum Code’ selected for the project must be consistent with the area served by the project
according to their grant agreement with the federal funder. For example, a VA SSVF project providing
services to clients in both a balance of state and an urban CoC must be associated with the ‘Continuum
Code’ for both the balance of state AND the urban continuum.
Projects participating in an HMIS implementation are subject to the policies and procedures of that
HMIS implementation, regardless of whether participation is by entering data directly into the HMIS or
by providing data exported from another source. Projects providing data from one HMIS
implementation to another HMIS implementation are subject to the policies and procedures of both.
Data Element Fields and Responses
Field

Dependency

1 Continuum
Code

None

Response Category/
Data Type
HUD-assigned CoC codes for
the project location
[Text – 6 characters]

Descriptions
CoC Codes as published by HUD annually. The
format of these CoC codes is 2 letters (state
abbreviation), a dash, and 3 numbers, e.g., XX999. The HMIS software may provide a dropdown list of valid CoC Codes or require manual
entry.

2.4
Project Type
Rationale To associate each project entering data into the HMIS, as well as any residential continuum
projects not participating in HMIS, with the specific type of lodging or services provided. Data related to
project type is necessary to identify corresponding data collection requirements and for reporting
purposes. The element also identifies whether the project is a continuum project or a non-continuum
project. The element also identifies the relationship of a 'Services Only' project to a housing project as
necessary.
Project Setup Instruction A project is to be assigned a type based on the lodging or service it is
providing. All HMIS federal partner programs have identified the requirements and correct project type
for each program and program component in separate HMIS Program Manuals (created for each of the
federal partner programs). Select one and only project type per ‘Project ID.’
If a potential new project has more than one project type, each type must be set up in HMIS as a
separate project. For more guidance on project setup, including determining whether a single or
multiple projects should be set up in your HMIS, please refer to the Introduction to Section 2.
The project type selected directly impacts data collection and reporting requirements. In the event that
the nature of a project changes such that the recorded project type is no longer appropriate, very
careful consideration must be given to whether it is more appropriate to edit the project type for the
existing project or to create an entirely new project with a different type.
Data Element Fields and Responses
Field

Dependency

1 Continuum
Project

None

2 Project Type

None

Response Category/
Data Type
0
No

Descriptions

Yes

A project within the geographic boundaries of the
Continuum(s) of Care served by the HMIS whose primary
purpose is to meet the specific needs of people who are
homeless by providing lodging and/or services. A
continuum project is not limited to those projects
funded by HUD and should include all of the federal
partner projects and all other federally or non-federally
funded projects functioning within the continuum.

Homelessness
Prevention

A project that offers services and/or financial assistance
necessary to prevent a person from moving into an
emergency shelter or place not meant for human
habitation.

Street
Outreach

A project that offers services necessary to reach out to
unsheltered homeless people, connect them with
emergency shelter, housing, or critical services, and
provide urgent, non-facility-based care to unsheltered
homeless people who are unwilling or unable to access
emergency shelter, housing, or an appropriate health
facility. Only persons who are “street homeless” should
be entered into a street outreach project. Projects that
also serve persons other than “street homeless” must
have two separate projects to be set up in an HMIS –
one ‘Street Outreach’ and the other ‘Services Only.’

Emergency
Shelter

A project that offers temporary shelter (lodging) for the
homeless in general or for specific populations of the
homeless. Requirements and limitations may vary by
program, and will be specified by the funder.

Field

Dependency

2 Project Type
(continued)

None

Response Category/
Data Type
11 Day Shelter

Descriptions

Transitional
Housing

A project that provides temporary lodging and is
designed to facilitate the movement of homeless
individuals and families into permanent housing within a
specified period of time, but no longer than 24 months.
Requirements and limitations may vary by program, and
will be specified by the funder.

Safe Haven

A project that offers supportive housing that (1) serves
hard to reach homeless persons with severe mental
illness who came from the streets and have been
unwilling or unable to participate in supportive services;
(2) provides 24-hour residence for eligible persons for an
unspecified period; (3) has an overnight capacity limited
to 25 or fewer persons; and (4) provides low demand
services and referrals for the residents.

PH - Rapid ReHousing

A permanent housing project that provides housing
relocation and stabilization services and short- and/or
medium-term rental assistance as necessary to help a
homeless individual or family move as quickly as possible
into permanent housing and achieve stability in that
housing.

PH Permanent
Supportive
Housing
(disability
required for
entry)
PH – Housing
with Services
(no disability
required for
entry)

A project that offers permanent housing and supportive
services to assist homeless persons with a disability
(individuals with disabilities or families in which one
adult or child has a disability) to live independently.

PH - Housing
Only

A project that offers permanent housing for persons who
are homeless, but does not make supportive services
available as part of the project.

Coordinated
Assessment

A project that administers the continuum’s centralized
or coordinated process to coordinate assessment and
referral of individuals and families seeking housing or
services, including use of a comprehensive and
standardized assessment tool.

A project that offers daytime facilities and services (no
lodging) for persons who are homeless.

A project that offers permanent housing and supportive
services to assist homeless persons to live
independently, but does not limit eligibility to individuals
with disabilities or families in which one adult or child
has a disability.

Field

Dependency

2 Project Type
(continued)

None

Response Category/
Data Type
6
Services Only

Descriptions
A project that offers only stand-alone supportive
services (other than outreach) to address the special
needs of participants (such as child care, employment
assistance, and transportation services) and has
associated housing outcomes.
• If the Services Only project is affiliated with any one of
the following:
o

One residential project and

Does not offer to provide services for all the
residential project clients; Or
 Only serves clients for a portion of their
project stay (e.g. provides classes); Or
 Information sharing is not allowed between
residential project and service provider.
o Multiple residential projects of the same
project type (e.g. multiple PH:PSH) and


Does not serve all the all residential project
clients; Or
 Information sharing is not allowed between
residential projects and service provider.
o Multiple residential projects of different project
types (e.g. PH: RRH and PH:PSH)


Emergency Shelter(s)

Then the project type will be ’Services Only’ and
‘Affiliated with a Residential Project’ will be ‘Yes.’ Each
of the residential projects with which the Services Only
project is associated must be identified.
• If the Services Only project provides only services
(other than outreach), has associated housing
outcomes, and is not limited to serving clients of one
or more specific residential projects, then the project
type will be 'Services Only' and ‘Affiliated with a
Residential Project’ will be 'No.'
• A residential project that is funded under one or more
separate grants to provide supportive services to 100%
of the clients of the residential project will be set up
as a single project with the appropriate residential
project type. All federal funding sources must be

identified in 2.6 Federal Partner Funding Sources.

Other

A project that offers services, but does not provide
lodging, and cannot otherwise be categorized as another
project type, per above. Any project that provides only
stand-alone supportive services (other than outreach)
and has no associated housing outcomes should be
typed as ‘Other.’ For example, a project funded to
provide child care for persons in permanent housing or a
dental care project funded to serve homeless clients
should be typed ‘Other.’ A project funded to provide
ongoing case management with associated housing
outcomes should be typed ‘Services Only.’

Field

Dependency

A Affiliated
with a
Residential
Project

Field 2:
Response 6

Response Category/
Data Type
0
No

1
B Project ID(s)
of Residential
Project(s)
Affiliated
with SSO

Field A:
Response 1

Descriptions
For all projects typed ‘Services Only’ identify if the
services that are being provided are in conjunction with
a residential project which is a separate project in the
HMIS (e.g. a service only project for case management
that services one or more PSH projects.)

Yes

[‘Project ID’]

If the service is being provided to another project within
the HMIS, identify the project ID(s) of those residential
project(s). For the sake of consistency, HMIS vendors are
recommended to create a drop down list from element
2.2 Project Identifiers that includes the ‘Project Names’
and IDs for all non-emergency shelter projects.

2.5
Method for Tracking Emergency Shelter Utilization
Rationale To identify the method used for tracking shelter occupancy for each emergency shelter
project entering data into the HMIS. This allows HMIS reporting to accurately calculate project bed
utilization and length of stay and to distinguish shelters for other data collection and reporting purposes.
Project Setup Instruction Record the method used to track the nights that a client stays at a project.
One method must be identified in an HMIS for each emergency shelter project. Reporting and outcome
requirements will differ depending on the method utilized by the shelter.
•

The entry/exit (e/e) method requires the client have a full record created for each project stay.
All data required for the project at project entry and exit are recorded.

•

The night-by-night (nbn) method requires the client have a full record created, followed by a
record of each night the client was sheltered. For example, a client’s Project Start Date is
January 1. A full record is created reflecting the client’s information on that date. The client
stays that night and then is not back until 5 days later. On the night they return, assuming the
client has not been exited from the shelter, a simple record of the ‘Bed Night Date’ may be
made for the client, using 4.14 Bed Night Date. This collection of scattered nights becomes the
client’s length of stay in the shelter and the example above would give them a length of stay of 2
nights.
To the extent possible in a mass shelter environment, clients in a nbn shelter should also have
all elements required at exit for the project completed. The community should establish a
standard to “automatically exit” a client after a given length of absence (e.g. 90 days from last
bed night). The client’s Project Exit Date would be recorded as the last date the client appeared
at the shelter and the Destination would be marked as ‘No exit interview completed.’ The use of
an automatic exit system enables streamlined data collection for mass shelters, while at the
same time encouraging full exit information wherever possible.

The method used is important for the indication of length of stay in projects. Only projects utilizing a
project start/exit date comparison will be able to report on a continuous length of stay.
Utilization of the night-by-night method does not mean that an HMIS must identify a client in a specific
bed. If the HMIS supports a custom module that identifies clients in a bed that module may continue to
be used. However, use of that module does not necessarily equate with the night-by-night model.
If a shelter/continuum determines the method of tracking needs to be changed, the following approach
must be taken in order to minimize impact on the System Performance Measures and other reports:
1) A new shelter project must be established in the HMIS using the new method of tracking
2) All clients in the exiting HMIS shelter project must be exited
3) All clients that spend the first night in the new HMIS shelter must have data collected for a new
shelter project entry
4) The old shelter project should be disabled from entry in the system (i.e. closed)

Data Element Fields and Responses
Field

Dependency

1 Emergency
Shelter
Tracking
Method

None

Response Category/
Data Type
0
Entry/Exit Date (e/e)

Descriptions

The night-by-night method may be used by
some high-volume shelters and shelters where
a significant proportion of clients spend a night
at the shelter as needed on an irregular basis.
The night-by-night method relies on creating a
separate record of each individual date on
which a client is present in the shelter as a
means for calculating length of stay and
implies that the emergency shelter is generally
unable to collect as much client data at project
exit as an emergency shelter that uses an
entry/exit method for tracking utilization.

Night-by-Night (nbn)

The e/e method should be used for all shelters
that are able to collect client data (Universal
Data Elements and certain Program-Specific
Data Elements) at project entry and project
exit, including projects that require or strongly
encourage a continuous stay while a client
resolves their homelessness. For such shelters,
length of stay is calculated based on the
number of nights between project entry and
project exit and performance measures will
include changes from project start and project
exit data collection stages.

In this method: (1) entry information is
collected the first time that a client stays at the
shelter (2) the project records every discrete
date (or series of dates) that the client utilizes
a bed; (3) the HMIS maintains historical data
on the nights a client is sheltered; (4) the client
may be exited when shelter staff has
information that indicates that the client is
unlikely to return to the shelter or the system
may be designed to automatically generate an
exit after an extended absence; and (5) for
reporting purposes, a client’s length of stay in
the project will be based on the actual number
of bed nights and not on the period of time
from entry to exit.

2.6
Federal Partner Funding Sources
Rationale To identify federal funding sources for each project entering data into the HMIS, as well as
any residential continuum projects not participating in HMIS, and associate projects with corresponding
data collection requirements and reporting specifications.
Project Setup Instruction The federal funding sources listed in Field 1 are the federal partner programs
and their project components that have agreed either to participate in HMIS or are otherwise
considered continuum projects.
All continuum projects that receive funding from any of the funding sources identified in this element
must record: the name of the federal program and grant component; a grant identifier; grant start date;
and grant end date. Each project must include as many Funding Source records as is necessary to
identify all the funding sources for the project that appear on the list. Identification of additional funding
sources is not required.
When a project is funded by multiple grants and 100% of clients served by the project receive lodging
and/or services under each of the grants, a single project may be set up in HMIS as long as it is
configured such that data collection and reporting requirements for each funder are satisfied.
When a project is funded by multiple grants and different clients receive lodging and/or services under
different grants, it must be possible to identify which clients were served by which grant (or grants) and
any grant-level reporting must exclude clients not specifically served under the grant. In general, this is
accomplished in one of two ways:
•
•

There are separate projects set up in HMIS for each of the grants and clients are entered into
those projects based on the source of funding for particular services received; OR
The HMIS has implemented additional data collection such that a client’s enrollment and/or
specific services may be associated with the appropriate grant.

The grant identifier must uniquely identify the grant, although several projects may share the same
grant identifier if they are, in fact, funded under the same grant but split into separate projects in HMIS.
This may happen, for example, when a grant has multiple sub-grantees and needs to be able to identify
which clients were served by each of the subgrantees, or when a single grant funds services that fall
under different project types.
Correctly identifying each grant's start and end date allows for inclusion or exclusion of certain projects
in grant- or system-level reporting. For example, this information is critical for in the generation of
income measures for the system performance measures.
The system administrator must regularly collect and review federal funding source information, grant
start, and grant end dates from all projects. The information is required to be reviewed and updated, if
necessary, at least annually, but HUD and the federal partners strongly recommend reviewing the grant
identifiers before any HUD or federal partner-required reporting or data transfers.
Additional information on federal partner programs and related project setup guidance can be found in
the applicable HMIS Program Manual.

Data Element Fields and Responses
Field

Dependency

1 Federal
Partner
Program and
Components

None

Response Category/
Data Type
1
HUD: CoC – Homelessness Prevention
(High Performing Comm. Only)
2
HUD: CoC – Permanent Supportive
Housing
3
HUD: CoC – Rapid Re-Housing
4
HUD: CoC – Supportive Services Only
5
6
7
43
8
9
10
11
12
13
14
15
16
17
18
19
20
35
36
21
22
23
24
25
26
27
37
38
39
40

Descriptions

HUD: CoC – Transitional Housing
HUD: CoC – Safe Haven
HUD: CoC – Single Room Occupancy (SRO)
HUD: CoC - Youth Homeless
Demonstration Program (YHDP)
HUD: ESG – Emergency Shelter (operating
and/or essential services)
HUD: ESG – Homelessness Prevention
HUD: ESG – Rapid Re-housing
HUD: ESG – Street Outreach
HUD: Rural Housing Stability Assistance
Program
HUD: HOPWA – Hotel/Motel Vouchers
HUD: HOPWA – Housing Information
HUD: HOPWA – Permanent Housing
Placement (facility based or TBRA)
HUD: HOPWA – Permanent Housing
Placement
HUD: HOPWA – Short-Term Rent,
Mortgage, Utility assistance
HUD: HOPWA – Short-Term Supportive
Facility
HUD: HOPWA – Transitional Housing
(facility based or TBRA)
HUD: HUD/VASH
HUD: Pay for Success
HUD: Public and Indian Housing (PIH)
Programs
HHS: PATH – Street Outreach & Supportive
Services Only
HHS: RHY – Basic Center Program
(prevention and shelter)
HHS:RHY – Maternity Group Home for
Pregnant and Parenting Youth
HHS:RHY – Transitional Living Program
HHS:RHY – Street Outreach Project
HHS:RHY – Demonstration Project
VA:CRS Contract Residential Housing
VA: Grant Per Diem – Bridge Housing
VA: Grant Per Diem – Low Demand
VA: Grant Per Diem – Hospital to Housing
VA: Grant Per Diem – Clinical Treatment

Field

Dependency

Descriptions

None

Response Category/
Data Type
41 VA: Grant Per Diem – Service Intensive
Transitional Housing
42 VA: Grant Per Diem – Transition in Place
30 VA: Community Contract Safe Haven
Program3
32 VA: Compensated Work Therapy
Transitional Residence3
33 VA: Supportive Services for Veteran
Families
34 N/A
[no specified format]

1 Federal
Partner
Program and
Components
(continued)

None

2 Grant
Identifier

3 Grant Start
Date
4 Grant End
Date

None

[Date]

The start date of the grant.

None

[Date]

The grant end date may remain
empty until the term of the grant
ends. If the exact same grant
source and component is
renewed (with the exception of
projects funded by HHS:RHY), the
grant end date is not required to
be entered. The grant end date
may remain empty until such
time as the renewal(s) end.

The ‘Grant Identifier’ may be the
grant number assigned by the
federal partner or any other
grant identification system used
by the federal partner, grantee or
the CoC, unless a specific grant
identifier is required by the
federal partner.

These VA programs are not required to enter client-level data, although Project Descriptor Data Elements must
be recorded.

2.7
Bed and Unit Inventory Information
Rationale To record bed and unit inventory for each project entering data into the HMIS, as well as any
residential continuum projects not participating in HMIS, for use in tracking utilization, data quality
analysis, and reporting.
Project Setup Instruction At a minimum, an HMIS must have an accurate record of bed and unit
inventory as of October 1, 2017 for all continuum residential projects. These data must be finalized and
accurately entered by January 2018 (i.e., by the time of the 2018 Housing Inventory Count date). The
Inventory Start Date for these records should reflect the date on which they first became available
under the relevant project; if the precise date is not available, an estimate may be used; the
'Information Date’ should be the same as the Inventory Start Date.
A project may have multiple current records of inventory:
•
•
•

•

Projects that serve more than one household type must have a separate inventory record for
each household type.
Emergency shelters with more than one bed availability (year-round, seasonal, overflow) or bed
type (facility-based, voucher, other) must have separate records for each bed type, availability,
and household type.
For any inventory added since the date of the most recent HIC, a separate Bed and Unit
Inventory record must be created for the new beds and units with an Inventory Start Date that
shows the date that the additional inventory became available. The record for the existing
inventory should remain as is.
Projects that operate in more than one CoC must have separate Bed and Unit Inventory records
for each CoC.

For example, a project serving single adults that has 100 beds, of which 20 are seasonal, would have two
bed and unit inventory records. One record is for the 80 facility-based year-round beds for households
without children and a second record is for the 20 facility-based seasonal beds for households without
children.
Projects that target certain populations are advised that nothing in these standards allows for
circumventing fair housing laws. The Fair Housing Act prohibits discrimination because of, among other
things, familial status. Except where otherwise permitted by the federal program statute, housing
covered under the Fair Housing Act may not deny admission to households with children.
A project may have multiple historical records of inventory. Changes over time should be documented
such that a historical record of inventory is retained. Minor day-to-day fluctuations need not be
recorded, but differences due to significant changes in project operations should be entered as they
occur.
•

•

When a project adds inventory, a new record should be added with an 'Information Date’ and
Inventory Start Date that reflect the date of the increase. Inventory under development (i.e.,
beds for which funding has been approved but are not yet available) should also be separate
using the current date as the 'Information Date’ and the date that the beds are expected to be
available as the Inventory Start Date.
When a project reduces inventory, but will continue to serve the same household type with a
smaller number of beds, a new record should be added with an 'Information Date’ of the
effective date of the decrease; the same Inventory Start Date from the previous record should
be used. The earlier record should be closed out by recording an Inventory End Date that is the
day prior to the effective date of the decrease.
When a project is eliminating all inventory for a given household type, an Inventory End Date
reflecting the last date on which beds were available should be entered for the existing record.
22

•

Changes in the number of HMIS participating beds or the number of beds dedicated for
chronically homeless, Veteran, or youth clients should be documented by closing out the old
record with an Inventory End Date that is the date before the effective date of the change. A
new record should be created with an 'Information Date’ that is the effective date of the
change; the same Inventory Start Date from the previous record should be used. At annual
review, if there are separate records for beds of the same type and all Inventory Start Dates are
more than one year prior to the most recent HIC, the individual records should be closed out by
recording an Inventory End Date that is the day prior to the current date. A new record should
be created to combine the total inventory of the individual records using the current date as the
'Information Date’ and the earliest Inventory Start Date from the individual records.

Data Element Fields and Responses
Field

Dependency

1 Information
Date

None

Response Category/
Data Type
[Date]

Descriptions
The 'Information Date’ depends on the status of the inventory:
• Under Development: Inventory which is fully funded but not
yet available for occupancy, use the date on which the record
is created.
• New: Inventory added since the date of the most recent HIC
and available for occupancy (and for which a record does not
yet exist as “under development”), use the date on which the
beds/units became available.
• Existing Inventory: When creating a new record to reflect
changes in the number of beds/units; number of beds
designated for veterans, youth, or chronically homeless;
household type; or availability, use the effective date of the
change. See data collection instructions for more details about
when to create new records or close out existing records for
inventory changes.

2 Inventory Start
Date

None

[Date]

The date on which the inventory became available, or, for
inventory under development, the date on which it is expected
to become available.

3 Inventory End
Date

None

[Date]

The last date that an inventory record is relevant:
• For current records, ‘Inventory End Date’ should be blank.
• For records that are being closed out because a change that
requires a new record has occurred, ‘Inventory End Date’ will
be the day before the effective date of the change.
• For inventory that is no longer available, ‘Inventory End Date’
will be the last date that beds were available.

4 CoC Code

None

[as identified in data
element 2.3]

5 Household Type

None

This specifies the household type (at project entry) served by beds and units in a given
inventory record. Projects that serve more than one household type must have
separate records of inventory for each household type.
1

Households
without
children

Projects that operate in more than one CoC must have separate
Bed and Unit Inventory records for inventory located in each
CoC. From the CoC codes entered in data element 2.3, indicate
the CoC code associated with the inventory record.

Beds and units typically serving households with adults only.
This includes households composed of unaccompanied adults
and multiple adults.

Field

Dependency

5 Household Type
(continued)

None

6 Bed Inventory

None

Response Category/
Data Type
3
Households
with at least
one adult and
one child
4
Households
with only
children
[Integer]

Descriptions
Beds and units typically serving households with at least one
adult and one child.

Beds and units typically serving households composed
exclusively of persons under age 18, including one-child
households, multi-child households or other household
configurations composed only of children.
The ‘Bed Inventory’ is a count of the total number of beds
available for occupancy as of the 'Information Date.’ The
number of beds is generally equivalent to the number of
persons a lodging project can house on a given night and, for
Emergency Shelters, should be counted distinctly for each
combination of ‘Bed Type’ and ‘Availability.’
For projects that serve multiple household types, but where a
precise number of beds are not designated exclusively for a
particular type of household, the total number of beds may be
distributed among the household types served by the project
using one of the following methodologies:
• Divide the beds based on how the bed(s) were used on the
night of the HIC. If the facility is not at full capacity on the
night of the count, then extrapolate the distribution based on
the prorated distribution of those who are served on the night
of the count.
• Divide the beds based on average utilization. For example, a
project has 100 beds that could be used by either households
with only children or households with at least one adult and
one child. If one-half of the beds are used by persons in
households with only children on average and the other half
are used by persons in households with at least one adult and
one child, then record 50 beds for households with only
children, and for the 50 beds for households with at least one
adult and one child in the HIC.
Projects that only have units and no fixed number of beds can
estimate the number of beds based on average household size
using a multiplier factor (e.g., a project with 30 family units and
an average family size of 3 would record 90 beds).
Projects that provide housing rental assistance and have a fixed
number of vouchers should determine the number of beds and
units based on the number of vouchers currently funded and
available for use.
Projects that provide emergency shelter or housing rental
assistance vouchers and without a fixed number of units or
vouchers (e.g., Emergency Shelter-hotel/motel project, Rapid ReHousing, some scattered site PH-Permanent Supportive Housing)
should determine the number of beds (and units) based on the
maximum number of persons (and households) who can be
housed on a given night.

Field

Dependency

7 Unit Inventory

None

8 Bed Types

2.7 Project
Type =
'Emergency
Shelter'

9 Availability

2.7 Project
Type =
'Emergency
Shelter'

Response Category/
Data Type
[Integer]

Descriptions
The ‘Unit Inventory’ is a count of the total number of units
available for occupancy as of the 'Information Date.’ Projects
that do not have a fixed number of units (e.g., a congregate
shelter project) may record the bed inventory, the number of
residential facilities operated by the project, or the number of
rooms available as the unit integer. For additional instructions,
see ‘Bed Inventory,’ above.
Record the number of beds of each Bed Type offered by
emergency shelter projects: Facility-based beds, voucher beds,
and other beds. The total of the three types should equal the
total ‘Bed Inventory’ shown in 2.7 Field 6.

Facility-based
Beds

Beds (including cots or mats) located in a residential homeless
assistance facility dedicated for use by persons who are
homeless.

Voucher Beds

Beds located in a hotel or motel and made available by the
homeless assistance project through vouchers or other forms of
payment.

Other Beds

Beds located in a church or other facility not dedicated for use
by persons who are homeless.

Availability is recorded to identify whether the beds and units are available on a
planned basis year-round, seasonally, or on an ad hoc or temporary basis, as demand
indicates.
1

Year-round

Year-round beds and units are available on a year-round basis.

Seasonal

Seasonal beds are not available year-round, but instead are
available on a planned basis, with set start and end dates, during
an anticipated period of higher demand.

Overflow

Overflow beds are available on an ad hoc or temporary basis
during the year in response to demand that exceeds planned
(year-round or seasonal) bed capacity.

10-12 Dedicated
Bed Inventory

All beds that have been funded by HUD or another federal partner that are dedicated to one or more of
the following subpopulations must be recorded in the appropriate category. A bed may be counted
more than once across categories (e.g., a project may have beds dedicated for persons who are both
chronically homeless and a veteran). The number of beds for each subpopulation is a subset of the
total bed inventory for a given project and must be equal to or less than the total bed inventory. A
dedicated bed is a bed that must be filled by a person in the subpopulation category (or a member of
their household) unless there are no persons from the subpopulation who qualify for the project
located within the geographic area.

10 Veteran Bed
Inventory

None

[Integer]

The number of beds that are dedicated to house homeless
veterans and their household members.

11 Youth Bed
Inventory

None

[Integer]

The number of beds that are dedicated to house homeless youth
(persons up to age 24) and their household members.

12 Chronically
Homeless Bed
Inventory

2.7 Project
Type = 'PH:
Permanent
Supportive
Housing'

[Integer]

The number of beds that are dedicated to house chronically
homeless persons and their household members.

Field

Dependency

13 HMIS
Participating
Beds

None

Response Category/
Data Type
[Integer]

Descriptions
Total number of beds participating in HMIS as of the
'Information Date.’ For projects that serve a mixed population
without a fixed number of beds per household type, record
participating beds according to instructions provided in 2.7 Field
6 ‘Bed Inventory.’ If a project is only collecting and entering data
in HMIS for clients staying in a portion of its beds, then only
record the count of beds participating in HMIS. Non-contributing
CoC projects must enter “0” in the HMIS participating beds field.

2.8
Additional Project Information
Rationale To record location data required by each project entering data into the HMIS, as well as any
residential continuum projects not participating in HMIS. This information is relevant for HIC and AHAR
reporting.
Project Setup Instruction Each residential continuum project must have at least one record of Additional
Project Information. Projects that operate in more than one CoC but enter data into a single HMIS must
have separate Additional Project Information records for each CoC. Responses in each record should be
associated with the correct Continuum of Care Code (see data element 2.3).
Information must be reviewed at least annually. If the information has changed, a new record should be
created to document the change in information. A new record is only required if a change has occurred;
the 'Information Date’ of the new record should reflect the date of the change. Data entry errors should
be edited to correct the error.
‘Geocode,’ ‘Project ZIP code,’ and ‘Project Street Address’ fields must reflect the location of the project’s
principal lodging site or, for multiple site projects, the area in which most of the project’s clients are
housed. Tenant-based scattered site projects and Victim Services Providers are only required to
complete the geocode and ZIP code fields and may use mailing or administrative address information if
they wish to complete the remainder of the address fields. When there are multiple records associated
with different CoCs, the geocodes will differ – the geocode must be located within the CoC.
‘Geography Type’ is a new field in the 2017 HMIS Data Standards that will allow HUD to collect more
nuanced information about urban, rural, and suburban homelessness in the AHAR. These geography
types will be automatically determined by the HMIS based on the ‘ZIP Code’ entered for the project.
HUD will issue the official crosswalk of ZIP Codes and geography types; the geography type cannot be
locally determined.

Data Element Fields and Responses
Field

Dependency

Response Category/
Data Type
[Date]

Descriptions

1 Information
Date

None

2 CoC Code

None

[as identified in data
element 2.3]

Projects that operate in more than one CoC must have separate
Additional Project Information records for inventory located in
each CoC. From the CoC codes entered in data element 2.3,
indicate the CoC code associated with the inventory record.

3 Geocode

None

[6 digits]

Geocode associated with the geographic location of the project’s
principal site. HUD provides a list of geocodes as part of the
annual CoC Program competition.

4 Target
Population

None

DV: Domestic
Violence
victims
HIV: Persons
with HIV/AIDS

At least 75% of persons served by the project must be victims of
domestic violence.

Neither of the other response categories applies.

NA: Not
applicable
No

Yes

A private nonprofit organization whose primary mission is to
provide direct services to victims of domestic violence.

3
4

The 'Information Date’ should correspond to Project Start Date
(data element 2.2 Project Identifiers) or, for new records created
to document a change in information, to the effective date of the
change.

At least 75% of persons served by the project must be persons
with HIV/AIDS.

5 Victim Services
Provider

None

6 Project ZIP
Code

None

[5 digits]

The ZIP code of the project’s principal site or, for scattered site
projects, the ZIP code in which most of the project’s clients are
housed.

7 Geography
Type

None

Urban

HUD will release a crosswalk of ZIP codes and a geography type
for each. Geography type must correspond to the HUD crosswalk;
geography types may not be locally defined.

Suburban

Rural

Site-based single site
Site-based clustered/
multiple sites
Tenant-based scattered site

8 Housing Type

None

9 Project Street
Address 1

None

[Text]

10 Project Street
Address 2
11 Project City

None

[Text]

None

[Text]

All clients are housed in a single project facility.
Clients are housed in more than one project facility in multiple
locations.
Clients have leases or other occupancy agreements and are
housed in residences that are not owned or managed by the
project.
The street address of the project’s principal site or, for scattered
site projects, the address in which most of the project’s clients
are housed. For tenant-based – scattered site projects, the field
may be left blank or the administrative address may be used.

3. UNIVERSAL DATA ELEMENTS
HMIS Universal Data Elements are elements required to be collected by all projects participating in
HMIS, regardless of funding source. Projects funded by any one or more of the federal partners must
collect the Universal Data Elements, as do projects that are not funded by any federal partner (e.g.
missions) but are entering data as part of the Continuum of Care’s HMIS implementation.
The Universal Data Elements are the basis for producing unduplicated estimates of the number of
people experiencing homelessness, accessing services from homeless assistance projects, basic
demographic characteristics of people experiencing homeless, and patterns of service use, including
information on shelter stays and homelessness over time.
The Universal Data Elements are the foundation on which the Annual Homeless Assessment Report
(AHAR) is developed. The AHAR provides Congress the national estimates of the current state of
homelessness across the United States and the use of homeless assistance programs. It is used locally to
inform communities on how their specific homeless information compares nationally and to understand
changes within communities over time. The AHAR is used a critical resource for informing the U.S.
Interagency Council on Homelessness and other federal partners on the nature of homelessness in the
United States and provides a unique longitudinal lens to inform homelessness policy nationwide.
Universal Data Elements also help local communities to better target resources, and position programs
to end homelessness.
Universal Identifier Elements (One and Only One per Client Record)
3.1
Name
3.2
Social Security Number
3.3
Date of Birth
3.4
Race
3.5
Ethnicity
3.6
Gender
3.7
Veteran Status
Universal Project Stay Elements (One or More Value(s) Per Client or Household Project Stay)
3.8
Disabling Condition
3.10 Project Start Date
3.11 Project Exit Date
3.12 Destination
3.15 Relationship to Head of Household
3.16 Client Location
3.20 Housing Move-In Date
3.917 Living Situation
In the 2017 HMIS Data Standards, Data Element 4.17 Residential Move-In Date was significantly
modified and became universal data element 3.20 Housing Move-In Date.
Appendix B summarizes the client universe for each universal and program-specific data element and
when it is collected.
General Data Collection Guidance
Universal data elements are required to be collected by all projects participating in an HMIS, regardless
of funding source. Data elements 3.1 through 3.7 are required to be collected once per client, regardless
of how many project stays that client has in the system. If, upon Project Start in a new project, the data
29

in these elements are observed to be incorrect or outdated, the data must be corrected in the original
record. The remaining universal data elements are to be collected at least once per project stay. The
timing of when the data are to be collected and about whom is noted below in each data element.
The Universal Data Elements in particular can lead to questions about what to enter in the HMIS if a
client does not complete a consent form for the HMIS. When considering client consent in the context of
HMIS, it is important to make a distinction between HMIS data entry and HMIS data sharing. At this
time, there is no requirement that client consent be obtained in order to enter client information into
HMIS. There is only a requirement that client consent be obtained in order to share information entered
into HMIS with one or more other HMIS participating providers.
This means that it may not be necessary at all to obtain written consent from every client to simply
enter the data into your HMIS. However, if your HMIS is configured in such a manner that information
entered into HMIS is automatically shared with other HMIS participating projects, then client consent is
necessary. Consult with your Continuum of Care and HMIS Lead Agency for more information.
Data Collection Guidance by Project Type
Some project types are more complex and require additional data collection instruction. Although the
following information is also provided within each individual data element, it is all are collected here for
ease of reference for System Administrators and end users managing these project types.
•

Street Outreach
o

De-Duplication of Client Records: It is possible in a street outreach setting that a single
client may be contacted by multiple street outreach workers over a period of time in
different locations. Local protocols should be established for coordination among street
outreach projects to effectively manage the identification and data collection of clients.
In smaller CoCs, it may be possible to coordinate street outreach efforts and reduce
duplication of client records through case conferences or other efforts. In larger CoCs, to
manage the identification of clients, client search functionality may be made available in
HMIS so that street outreach workers can perform queries or client searches by “madeup” names or aliases, or other informal identifiers shared with street outreach workers.
The use of temporary “made-up” names should not be an excuse for excessive deidentified clients or poor data quality. Street Outreach projects and local HMIS
leadership should work together to minimize the use of “made-up” names and attain
high data quality.

Contacts: Most street outreach projects are expected to record every contact made with
each client in the HMIS. A contact is defined as an interaction between a worker and a
client designed to engage the client. Contacts include activities such as a conversation
between the street outreach worker and the client about the client’s well-being or
needs, an office visit to discuss their housing plan, or a referral to another community
service. A Contact (4.12) must be recorded anytime a client is met, including when a
Date of Engagement (4.13) or Project Start Date (3.10) is recorded on the same day.

Engagements: Most street outreach projects are expected to record the Date of
Engagement (4.13) with each client in the HMIS. Per the HMIS Data Standards and by
agreement across all federal partners, an engagement date is the date on which an
interactive client relationship results in a deliberate client assessment or beginning of a
case plan. The Date of Engagement should be entered into HMIS at the point that the
client has been engaged by the outreach worker. This date may be on or after the
Project Start Date (3.10) and must be prior to the Project Exit Date (3.11). If the client
exits without becoming engaged, the Date of Engagement should be left blank. If the
30

client was contacted on the date of engagement, a Contact (4.12) must also be entered
for that date.

•

Data Quality: Reporting on data quality for street outreach projects is limited to clients
with a Date of Engagement (4.13). Therefore, it is important that outreach workers
record the Date of Engagement and also review all Universal Data Elements and
applicable Program Specific Data Elements for completeness and accuracy. The Date of
Engagement coincides with the requirement for HMIS data quality, therefore all
Universal Data Elements should be entered into HMIS on or before the Date of
Engagement.

Project Exit: Project exit represents the end of a client’s participation with a project. The
exit date should coincide with the date that the client is no longer considered to be
participating in the project. This standard should be applied consistently across all Street
Outreach projects. Reasons to exit a client include:


The client has entered another project type (e.g., TH, PSH) or otherwise found
housing;



The client is engaged with another outreach worker or project;



The client is deceased;



The outreach worker has been unable to locate the client for an extended
period of time (e.g. 90 days from last contact) and there are no recorded
contacts.

‘Night-by-Night’ Emergency Shelters
o

Night-by-night (nbn) shelters should be set up to collect all data required for Emergency
Shelters. However, HUD understands that often nbn shelters are not able to collect exit
data. Persons who leave/disappear without completing an exit interview are to be
recorded with Destination (3.12) of ‘No Exit Interview Completed.’

Contacts: Most nbn shelters must record Contacts (4.12) they have with each person
served. A contact is defined as an interaction between a worker and a client designed to
engage the client. Contacts may include activities such as a conversation between the
shelter worker and the client about the client’s well-being or needs, an office visit to
discuss their housing plan, or a referral to another community service. A Contact must
be recorded anytime a client is met, including when a Date of Engagement (4.13) or
Project Start Date (3.10) is recorded on the same day.

Engagements: Most nbn shelters are required to record a client’s Date of Engagement
(4.13). Per the HMIS Data Standards and by agreement across all federal partners, an
engagement date is the date when an interactive client relationship results in a
deliberate client assessment or beginning of a case plan. The Date of Engagement
should be entered into HMIS at the point when the client has been engaged by the
shelter worker. This date may be on or after the project entry date and must be on or
prior to project exit. If the client exits without becoming engaged, the Date of
Engagement should be left blank. If the client was contacted on the date of
engagement, a contact must also be entered for that date.

Day Shelter
o

Follow the requirements for Entry/Exit Shelters when collecting data for Day Shelters.

•

Permanent Housing: PSH and RRH
o

With the changes to the HMIS Data Standards, all types of Permanent Housing projects
are now able to collect data on assistance provided to the client prior to the client
entering housing.

For these project types, the Project Start Date (3.10) is the date following application
that the client was admitted into the project. To be admitted indicates the following
factors have been met:


Information provided by the client or from the referral indicates they meet the
criteria for admission;



The client has indicated they want to be housed in this project; and



The client is able to access services and housing through the project. The
expectation is the project has a housing opening (on-site, site-based, or
scattered-site subsidy) or expects to have one in a reasonably short amount of
time.

At project start, record the Universal Data Elements and any other information required
at the project start.

When the client or household moves into any type of permanent housing, regardless of
funding source or whether the project is providing the rental assistance, enter the date
in Housing Move-In Date (3.20).

Universal Identifier Elements (One and Only One per Client Record)
3.1
Name
Rationale To support the unique identification of each person served.
Data Collection Instruction When creating a new client record, enter the client’s name and select the
appropriate data quality indicator. When enrolling a client who already has a record in the HMIS, verify
that the name in the system is accurate and as complete as possible – and correct or complete it if it is
not.
HMIS records should use a client’s full, legal name whenever possible– doing this as a standard practice
makes it easier to find records when searching and avoid creating duplicate records. Generally, projects
are not required to verify that the information provided matches legal documents. However, each
project should be aware of funders’ record keeping requirements, and if maintaining copies of legal
documents is a requirement, they should be collected and pertinent information updated in HMIS
accordingly.
Street outreach projects may record a project entry with limited information about the client and
improve on the accuracy and completeness of client data over time by editing data in an HMIS as they
engage the client. The initial entry may be as basic as the project entry date, a “made-up” name (e.g.,
“Redhat Tenthstreetbridge”) that would be identifiable for retrieval by the worker in the system, and
gender. Over time, the data must be edited for accuracy (e.g. replacing “Redhat” with “Robert”) as the
worker learns that detail.

Data Element Fields and Responses
Field

Dependency

1 First

None

Response Category/
Data Type
[Text]

Descriptions

2 Middle

None

[Text]

3
Last

None

[Text]

4 Suffix

None

[Text]

5 Name
Data
Quality

None

Full name
reported

Select ‘Full name reported’ for Name Data Quality as long
as complete, full first and last names have been recorded.

Partial, street
name, or code
name reported

Select ‘Partial, street name, or code name reported’ in
any of the following circumstances: 1) a partial, short, or
nickname was used instead of the full first name; 2) a
street name or code name was used for street outreach
clients at initial intake and until the client was able to
supply their full legal name; 3) a name modification was
used for security reasons; or 4) for any other reason the
name does not match the clients full name as it would
appear on identification.

Client doesn't
know

Select 'Client doesn't know' when client does not know
their name. Use 'Client doesn't know' rather than 'Partial,
street name or code name reported' if a false name/made
up name was entered in order to create a record in the
system solely because the client did not know or was
unable to provide their name.

Client refused

Select 'Client refused' when client refuses to provide their
name. Use 'Client refused' rather than 'Partial, street
name, or code name reported' if a false name/made up
name was entered in order to create a record in the
system solely because the client refused to tell staff their
name.

Data not
collected

To avoid duplicate record creation, the full first name
should be used (e.g., James vs. Jim)
To avoid duplicate record creation, the last name should
be recorded in full. Use the current last name, use the
format the client normally provides as identification (e.g.
with hyphen or without hyphen). Use the order of last
names as the client indicates is culturally correct.

3.2
Social Security Number
Rationale To support the unique identification of each person served.
Where data are shared across projects, the SSN greatly facilitates the process of identifying clients who
have been served and allows projects to de-duplicate at project start.
Where data are not shared, CoCs rely on unique identifiers to produce an unduplicated count in the
central server once the data are sent to the HMIS Lead. Name and date of birth are useful unique
identifiers, but the SSN is significantly more accurate.
Also, an important objective for ending homelessness is to increase access and utilization of mainstream
programs by persons who are experiencing homelessness or are at-risk of homelessness. Since SSN is a
required data element for many mainstream programs, projects may need the SSN in order to help their
clients access mainstream services.
Data Collection Instruction In separate fields, record the nine-digit SSN and appropriate SSN Data
Quality Indicator.
If a partial social security number is obtained, HMIS vendors will provide the ability to indicate missing
digits and otherwise devise methodologies to allow entry and effective matching of partial SSNs.
When enrolling a client who already has a record in the HMIS, verify that the SSN in the system is
accurate and correct it if it is not.
Some projects may serve clients that do not have an SSN. In these cases, select 'Client doesn't know.'
The federal statute at 5 U.S.C. Section 522a prohibits a government agency from denying shelter or
services to clients who refused to provide their SSN or do not know their SSN, unless the requirement
was in effect before 1975 or SSN is a statutory requirement for receiving services from the project. For
example, in order to receive Homelessness Prevention or Rapid Re-Housing services through Supportive
Services for Veteran Families grants, veterans must provide a Social Security number in order to receive
services because it’s relevant to verifying eligibility. The veteran’s household members, however, may
decline to provide a Social Security number.
Data Element Fields and Responses
Field

Dependency

Descriptions

None

Response Category/
Data Type
[9 digits]

1 Social
Security
Number
2 SSN Data
Quality

None

Full SSN Reported

A complete and valid SSN is provided.

Approximate or partial
SSN reported

Any SSN other than a complete and valid 9
digit SSN, regardless of the reason, is provided.

Client doesn't know

A client does not know or does not have a SSN.

Client refused

A client refuses to provide any part of their
SSN, regardless of the reason.

Data not collected

3.3
Date of Birth
Rationale To calculate the age of persons served at time of project start or at any point during project
enrollment and to support the unique identification of each person served.
Data Collection Instruction Record the month, day, and year of birth for every person served.
When enrolling a client who already has a record in the HMIS, verify that the date of birth on the record
is accurate and correct it if it is not.
If the client cannot remember their birth year, it may be estimated by asking the person's age and
calculating the approximate year of birth. If a client cannot remember the month or day of birth, record
an approximate date of '01' for month and '01' for day. CoCs that already have a policy of entering
another approximate date may continue to use their existing policy. Select ‘approximate or partial date
of birth.’
If a client is not able to estimate their age within one year of their actual age, select ‘Client doesn’t
know.’ Select ‘Client refused’ when a client refuses to provide any part of their DOB.
Data Element Fields and Responses
Field

Dependency

Descriptions

None

Response Category/
Data Type
[Date]

1 Date of Birth
2 DOB Data
Quality

None

Full DOB reported

The complete date of birth is provided by the
client.

Approximate or partial
DOB reported

The client cannot remember their full or exact
date of birth, but is able to recall their age
within one year.

Client doesn't know

Use 'Client doesn't know' rather than
'Approximate or partial DOB reported' if an
approximate or partial date of birth was used
because the client did not know their date of
birth within one year.

Client refused

Use 'Client refused' rather than 'Approximate
or partial DOB reported' if a partial or
approximate date of birth was entered in order
to create a record in the system because the
client refused to provide their date of birth or
their age for staff to approximate.

Data not collected

3.4
Race
Rationale To indicate clients' self-identification of one or more of five different racial categories.
Supports system planning, local, and national understanding of who is experiencing homelessness.
In the October 30, 1997 issue of the Federal Register (62 FR 58782), the Office of Management and
Budget (OMB) published “Standards for Maintaining, Collecting, and Presenting Federal Data on Race
and Ethnicity.” All existing federal recordkeeping and report requirements must be in compliance with
these Standards as of January 1, 2003. These data standards follow the OMB guidelines.
Data Collection Instruction In separate data fields, record the self-identified race(s) of each client
served. Help the client select the race or races that they most identify with. Allow clients to identify as
many racial categories as apply (up to five).
When enrolling a client who already has a record in the HMIS, verify that race information is complete
and accurate – and correct it if it is not.
Staff observations should never be used to collect information on race. Provide all options to every
client. Even if staff believes they can guess a client’s race, every client must be asked for their selfreported information. No documentation is required to verify a client's response.
‘Client doesn’t know,’ ‘Client refused,’ and ‘Data not collected’ are explanations for missing race data.
None of these three responses are valid in conjunction with any other response.
This data element can be challenging to separate from ethnicity. As one example, some people of Latin
American descent often indicate their race is 'Hispanic,' and would not be referred to in casual
conversation or seen in their communities or by themselves as 'White' or ‘Black or African American.’
Unless the person is from an original people’s group—that is, indigenous or American Indian—in which
case, they would select that option, the staff will have to ask follow-up questions to ascertain the best
response for Race. Staff may ask something like "do you know if your ancestors were originally from a
country like Spain, somewhere in Africa, or are you part of an indigenous group?” The response is tied to
where their ancestors came from, not necessarily where they were born or lived during their lifetime.
By the time clients get to data element 3.5 Ethnicity, they may have already responded to Race with
something like ‘Hispanic,’ ‘Guatemalan,’ or ‘Latino,’ so staff should be able to clearly distinguish
between these two data elements and select responses accordingly, even if the answers are provided
out of order.
Projects are cautioned against providing a default answer. It is important to ask about all household
members’ race and identity because it is impossible to tell just based on a person’s appearance or name.
If the client does not know his or her race or ethnicity, or refuses to disclose it, use ‘Client doesn’t know’
or ‘Client refused,’ rather than making an appearance or name-based assumption.

Data Element Fields and Responses
Field

Dependency

1 Race

None

Response Category/
Data Type
1
American Indian or
Alaska Native

Descriptions

Asian

A person having origins in any of the original
peoples of the Far East, Southeast Asia or the
Indian subcontinent including, for example,
Cambodia, China, India, Japan, Korea,
Malaysia, Pakistan, the Philippine Islands,
Thailand and Vietnam.

Black or African
American

A person having origins in any of the black
racial groups of Africa. Terms such as 'Haitian'
can be used in addition to 'Black or African
American.'

Native Hawaiian or
Other Pacific Islander

A person having origins in any of the original
peoples of Hawaii, Guam, Samoa, or other
Pacific Islands.

White

A person having origins in any of the original
peoples of Europe, the Middle East or North
Africa.

Client doesn't know

‘Client doesn’t know' should only be selected
when a client does not know their race(s) from
among the five listed races. 'Client doesn’t
know' should not be used in conjunction with
any other response.

Client refused

‘Client refused' should only be selected when a
client refuses to identify their race(s) from
among the five listed races. 'Client refused'
should not be used in conjunction with any
other response.

Data not collected

A person having origins in any of the original
peoples of North and South America, including
Central America, and who maintains tribal
affiliation or community attachment.

3.5
Ethnicity
Rationale To indicate clients who do and do not identify themselves as Hispanic or Latino. Supports
system planning, local, and national understanding of who is experiencing homelessness.
Data Collection Instruction Record the self-identified ethnicity of each client served. Help the client
select the ethnicity that they most identify with.
When enrolling a client who already has a record in the HMIS, verify that ethnicity information is
complete and accurate -- and correct it if it is not.
Staff observations should never be used to collect information on ethnicity. Even if a staff person
believes they can guess a client’s ethnicity, every client must be asked for their self-reported
information. No documentation is required to verify a client's response.
Additional instruction about assisting clients to differentiate between Race and Ethnicity can be found
under data element 3.4 Race.
Data Element Fields and Responses
Field

Dependency

1 Ethnicity

None

Response Category/
Data Type
1
Non-Hispanic/NonLatino
2
Hispanic/Latino

Client doesn't know

Client refused

Data not collected

Descriptions

A person of Cuban, Mexican, Puerto Rican,
South or Central American or other Spanish
culture of origin, regardless of race.

3.6
Gender
Rationale To indicate whether clients self-identify as male, female, transgender female, transgender
male, or gender non-conforming. Supports system planning, local, and national understanding of who is
experiencing homelessness.
Data Collection Instruction Record the self-reported gender of each client served. Users should be
sensitive to persons who do not identify as male, female or transgender.
When enrolling a client who already has a record in the HMIS, verify that gender information is
complete and accurate -- and correct it if it is not. Update the gender previously recorded in HMIS if it
does not match the person’s current gender.
Staff observations should never be used to collect information on gender. Provide all options to every
client. Even if staff thinks they can guess a client’s gender, every client must be asked for their selfreported information. If they refuse to give it or say they don’t know, do not select a response for the
client. Gender does not have to match legal documents and clients may not be asked about medical
history or other information to try to determine the person’s gender. Simply asking, “Which of these
genders best describes how you identify?” is appropriate and focuses on the person’s own internal
knowledge of their gender.
If a client does not understand what Transgender Female and Transgender Male mean, the definitions
below can be provided.
Clients reporting different gender identities or presenting different gender expressions at multiple
projects within the same CoC are not violating standards for accurate collection of information. Clients
decide to which projects they will disclose potentially sensitive information. Project staff should enter
the self-reported information as directed by the client.
A transgender client may elect to share their transgender status with project staff, or not. In the event
that a client discloses being transgender, staff should consult that client about whether the client
prefers to have the HMIS data element for “gender” reflect their transgender status or not. For instance,
if a client identifies as a transgender man but would prefer not to have this reflected in his HMIS record,
then the staff person would select “male” instead of “transgender female to male”. Staff can still note in
a confidential case management note, if this feature is available in the HMIS, an individual’s transgender
status if it is appropriate and necessary to the provision of services.
Data Element Fields and Responses
Field

Dependency

1 Gender

None

Response Category/
Data Type
0
Female

Descriptions

Male

Trans Female (MTF or
Male to Female)

Clients who live or identify as women, even
though they were assigned male at birth.

Trans Male (FTM or
Female to Male)

Clients who live or identify as men, even
though they were assigned female at birth.

Clients who do not identify exclusively as male
or female.

Gender Non-Conforming
(i.e. not exclusively male
or female)
Client doesn't know

Client refused

Data not collected

3.7
Veteran Status
Rationale To indicate whether clients are veterans of the United States armed forces. Allows for an
accurate count of how many veterans experience homelessness. Useful for screening for possible
housing and service interventions and for gaining understanding of veterans’ service needs.
Data Collection Instruction Record whether the client is a veteran. An HMIS should only have one
record of Veteran Status for each client, no matter how many enrollments they have.
When enrolling a client who already has a record in the HMIS, verify that the veteran status recorded is
accurate and correct it if it is not.
Veteran Status is not dependent on discharge status. A dishonorable discharge limits eligibility for
certain VA benefits and programs, but it does not mean that the person is not a veteran for HMIS and
PIT purposes. Unless the project’s funder has eligibility requirements for veteran status, it is not
necessary to obtain documentation for users to record a ‘yes’ response to this data element.
Asking additional questions may result in more accurate information as some clients may not be aware
that they are considered veterans. For example, “Have you ever been on active duty in the military?” or
“Were you disabled during a period of active duty training?”
This data element is only required for adult clients. There are several options for addressing instances
where clients turn 18 while enrolled:
•
•

Collect the data at the time of enrollment for clients expected to turn 18.
HMIS may automatically select “no” for clients who turn 18 while enrolled.

Data Element Fields and Responses
Field

Dependency

1 Veteran
Status

None

Response Category/
Data Type
0
No

Descriptions
Veteran Status should be ‘No’ for anyone who has not
been on active duty, including:
Individuals who attended training but were discharged
before reporting to a duty station.
Reservists or National Guard who were never activated
or deployed.

Yes

Anyone who has ever been on active duty in the armed
forces of the United States, regardless of discharge
status or length of service.
Army, Navy, Air Force, Marine Corps, and Coast Guard:
active duty begins when a military member reports to a
duty station after completion of training.
Reserves and National Guard: active duty is any time
spent activated or deployed, either in the United States
or abroad.
Or
Anyone who was disabled in the line of duty during a
period of active duty training.
Or
Anyone who was disabled from an injury incurred in the
line of duty or from acute myocardial infarction, a
cardiac arrest, or a cerebrovascular accident during a
period of inactive duty training.

8
9

Client doesn't
know
Client refused

Data not collected

Universal Project Stay Elements (One or More Value(s) Per Client or Household Project Stay)
3.8
Disabling Condition
Rationale To indicate whether or not clients have a disabling condition. This data element is to be used
with other information to identify whether a client meets the criteria for chronic homelessness.
Data Collection Instruction Record whether the client has a disabling condition at the time of each
project start. A disabling condition is one or more of the following:
•

A physical, mental, or emotional impairment, including an impairment caused by alcohol or drug
abuse, post-traumatic stress disorder, or brain injury that:
1) Is expected to be long-continuing or of indefinite duration;
2) Substantially impedes the individual's ability to live independently; and
3) Could be improved by the provision of more suitable housing conditions.

•
•

A developmental disability, as defined in section 102 of the Developmental Disabilities
Assistance and Bill of Rights Act of 2000 (42 U.S.C. 15002); or
The disease of acquired immunodeficiency syndrome (AIDS) or any condition arising from the
etiologic agency for acquired immunodeficiency syndrome (HIV).

Additionally, if the client is a veteran who is disabled by an injury or illness that was incurred or
aggravated during active military service and whose disability meets the disability definition defined in
Section 223 of the social security act, they should be identified as having a disabling condition.
It is not necessary to provide documentation to complete this data element. If a screening or
assessment indicates that a client has a disabling condition, enter ‘Yes.’ Only projects that receive
funding with eligibility criteria that require documentation of the disabling condition should require
documentation.
There should be one and only one value for Disabling Condition for each project stay. If the status
changes over the course of the project stay, or the information was recorded incorrectly at the time of
the project start, correct the record. The value should always reflect the known status of a client's
disabling condition. Sharing information about a client’s disabling condition between agencies should be
handled consistent with the continuum’s policies and procedures.
Some projects may collect more detailed information about specific disabilities in other data elements.
Some systems are set up to default to ‘Yes’ in this data element based on responses to data elements
4.5-4.10 (including a ‘Yes’ response to the dependent field in those elements ‘Expected to be of long–
continued and indefinite duration and substantially impairs ability to live independently’), but it is not
required. Systems that automatically populate Disabling Condition based on responses to data elements
4.5-4.10 must still allow a user to enter ‘Yes’ for Disabling Condition without a corresponding specific
disability in data elements 4.5-4.10.
In addition, a client indicating the following sources of Income (data element 4.2) can be considered to
have a disabling condition: Supplemental Security Income (SSI), Social Security Disability Insurance
(SSDI), VA Service-Connected Disability Compensation or VA Non-Service-Connected Disability Pension.
For residential homeless assistance programs, client intake as part of the program admission process
must be separated from the collection of disability information in order to comply with Fair Housing
laws and practices, unless this information is required to determine program eligibility or is needed to
determine whether applicants need units with special features or if they have special needs related to
communication.
43

Data Element Fields and Responses
Field

Dependency

1 Disabling
Condition

None

Response Category/
Data Type
0
No

Descriptions

One or more of the following:

Yes

A physical, mental, or emotional impairment, including
an impairment caused by alcohol or drug abuse, posttraumatic stress disorder, or brain injury that:
1) Is expected to be long-continuing or of
indefinite duration;
2) Substantially impedes the individual's ability to
live independently; and
3) Could be improved by the provision of more
suitable housing conditions.
A developmental disability, as defined in section 102 of
the Developmental Disabilities Assistance and Bill of
Rights Act of 2000 (42 U.S.C. 15002).
The disease of acquired immunodeficiency syndrome
(AIDS) or any condition arising from the etiologic
agency for acquired immunodeficiency syndrome (HIV).
A veteran who is disabled by an injury or illness that
was incurred or aggravated during active military
service and whose disability meets the disability
definition defined in Section 223 of the social security
act.
8
9
99

Client doesn't
know
Client refused
Data not
collected

3.10 Project Start Date
Rationale To determine the start of each client’s period of participation with a project. All projects need
this data element for reporting time spent participating in the project. In 2017, this data element
changed from Project Entry Date to Project Start Date to capture more complete information about
persons accepted into and residing in all types of Permanent Housing. Paired with 3.20 Housing Move-In
Date, it becomes possible to determine the length of time from project start to housing placement for
all PH clients, not just clients in RRH.
Data Collection Instruction Record the month, day, and year of each client’s project start. The project
start date indicates a client is now being assisted by the project.
For each client’s enrollment in a project, there must only be one Project Start Date. Any errors in
entering the date should be corrected as soon as they are noticed.
Different project types use Project Start Date differently, to address the difference in meaning
associated with “starting” residential, service, and permanent housing projects. See descriptions below
for more information.
Each individual client in a household will have their own project start date. If a new client is added to a
household after the original household members’ start dates, the new client’s start date should reflect
the actual day that client started the project. If this client is a newborn baby, the project start date
would reflect the date the newborn actually started the project, consistent with the responses for
project types identified below, which may be any date on or after the baby’s actual date of birth.
Data Element Fields and Responses
Field

Dependency

1 Project
Start
Date

None

Response Category/
Data Type
[Date]

Descriptions
Street Outreach: Date of first contact with the client.
Emergency Shelter: Night the client first stayed in the
shelter. Night by night shelters will have a project start
date and will allow clients to re-enter as necessary
without “exiting” and “restarting” for each stay for a
specified period.
Safe Haven and Transitional Housing: Date the client
moves into the residential project (i.e. first night in
residence).
Permanent Housing, including Rapid Re-Housing: Date
following application that the client was admitted into the
project. To be admitted indicates the following factors
have been met: 1) Information provided by the client or
from the referral indicates they meet the criteria for
admission; 2) The client has indicated they want to be
housed in this project; 3) The client is able to access
services and housing through the project. The expectation
is the project has a housing opening (on-site, site-based,
or scattered-site subsidy) or expects to have one in a
reasonably short amount of time.
Other Service Projects: including but not limited to:
services only, day shelter, homelessness prevention,
coordinated assessment, health care it is the date the
client first began working with the project and generally
received the first provision of service.

3.11 Project Exit Date
Rationale To determine the end of a client’s period of participation with a project. All projects need this
data element for reporting time spent participating in the project.
Data Collection Instruction Record the month, day and year of last day of occupancy or service.
For each client’s enrollment in a project, there should only be one Project Exit Date. Any errors in
entering the date should be corrected as soon as they are noticed.
Different project types use Project Exit Date differently, to address the difference in meaning associated
with “ending” residential and service projects.
Each individual client in a household will have their own Project Exit Date. If one member of a household
leaves the project before the rest of the household, the leaver’s exit date should reflect the actual day
that client left the project.
For residential projects, this date represents the last day of a continuous stay in the project before the
client transfers to another residential project or otherwise stops residing in the project. For example, if
a person checked into an overnight shelter on January 30, 2014, stayed overnight and left in the
morning, the exit date for that shelter stay would be January 31, 2014.
To minimize staff and client burden at shelters that require most (or all) clients to reapply for service on
a nightly basis, the project can record the Project Start and Project Exit Date at the same time or an
HMIS application can automatically record the Project Exit Date as the day after the Project Start Date
for clients of the overnight project.
Clients in rapid re-housing projects are to be exited after the last RRH service is provided. If eligible RRH
case management services are provided past the final date of receiving rental assistance, for example,
the client must not be exited until those services cease.
For non-residential projects, the exit date must represent the last day a contact was made or a service
was provided. The exit date should coincide with the date the client is no longer considered a
participant in the project. Projects must have a clear and consistently applied procedure for
determining when a client who is receiving supportive services is no longer considered to be
participating in the project. For example, if a person has been receiving weekly counseling as part of an
ongoing treatment project and either formally terminates their involvement or fails to return for
counseling, the last date of service is the date of the last counseling session. In a street outreach services
project, similarly, clients may be exited when the outreach worker has been unable to locate the client
for an extended period of time and there are no recorded contacts. In addition, the client may be exited
upon entering another project type, finding housing, engaging with another outreach project, or passing
away.
If a client uses a service for just one day (i.e., starts and stops before midnight of same day), then the
Project Exit Date may be the same as the Project Start Date.
In the 2017 HMIS Data Standards, a new data collection stage was added: “Post Exit.” This data
collection stage is relevant for project types that provide aftercare/follow-up services, but does not
extend the length of the client’s enrollment in a project. Services provided “post exit” will fall after the
client’s Project Exit Date.
In residential projects that require use of this data collection stage, the client is still to be exited as of the
date of the last day of a continuous stay in the project.

Data Element Fields and Responses
Field

Dependency

1 Project
Exit Date

None

Response Category/
Data Type
[Date]

Descriptions
Residential projects: The last day of continuous stay in the
project before the client transfers to another residential
project or otherwise stops residing in the project.
Non-residential projects: the last day a service was
provided or the last date of a period of ongoing service.

3.12 Destination
Rationale To identify where a client will stay just after exiting a project for purposes of tracking and
outcome measurement.
Data Collection Instruction Record where the client is expected to stay after they complete or stop
participating in project activities. For residential projects that expect a client to move out upon exit,
record where the client is expected to move immediately after leaving. For projects where a client is not
expected to relocate upon exit, such as homelessness prevention, rapid re-housing, transition in place,
or SSO projects, record where the client is expected to stay after they complete or stop participation in
project activities. This may be the same place that they were staying prior to starting in the project.
Select the Destination response category that most closely matches where the client will be staying after
exiting the project.
If a client moves into rental housing with a subsidy, select the response that includes the type of housing
subsidy. A housing subsidy may be tenant-, project-, or sponsor-based and provides ongoing assistance
to reduce rent burden. This includes housing subsidies provided through HUD-funded subsidies (e.g.,
public housing, Housing Choice Voucher or “Section 8”) or other housing subsidy (e.g., state rental
assistance voucher).
If a client moves in with family or friends, select the response that includes the expected tenure of the
destination (permanent or temporary). There is no specific timeframe used to differentiate between
‘permanent’ or ‘temporary.’ Rather, the determination should be made based on whether the situation
reflects family reunification or whether the family member or friend has placed any limitation that
indicates the stay is intended to be temporary (e.g. a specific time limit).
'Other' should be used only as a last resort if the client's destination truly cannot be even loosely
described by any of the available options. Any response of 'Other' will not count in any HMIS-based
reporting as a positive outcome.
Note that the client’s Destination is about where they are staying, not necessarily about why they are
staying there. So the choice of the destination in HMIS should reflect the client’s living situation, not any
particular reason why the client is staying there. For example, clients that are exiting to school or the
military may have housing provided for them. If the client is moving into a dorm or Army-supplied
housing, ‘Rental by Client, with other ongoing housing subsidy’ can be selected, consistent with the
notion that these units are not owned by client, have conditions of tenancy, and have a value ascribed
to them. If the client is moving into housing with a relative during schooling, ‘Living with Family,
Permanent Tenure’ can be selected, consistent with the notion that the client may stay with the family
member for as long as needed to complete school.
Mass shelters that track bed nights using the night by night method may have high rates of missing
Destination data when the client is exited. Often, in this model, a client is exited after a period of time of
not coming into the shelter, at which point the opportunity to ask clients where they are going is lost.
HUD and other federal partners strongly encourage shelters – even large scale shelters – to consider
themselves to be a part of the community’s system working to end homelessness. Any steps these
projects can take to establish relationships with clients, focus on moving clients into more permanent
housing situations, or collaborate with service projects that do so, will improve a system’s functioning,
data quality, and client outcomes.

Data Element Fields and Responses
Field
1 Destination

Dependency
None

Response Category/Data Type

Homeless
Situations

NonHomeless
Temporary
Situations

Descriptions

TEMPORARY SITUATIONS
Place not meant for habitation
e.g., a vehicle, an abandoned
building, bus/train/subway
station/airport or anywhere
outside

Emergency shelter, including hotel
or motel paid for with emergency
shelter voucher

• ESG Emergency Shelter
• HOPWA Hotel/Motel or Short
Term Housing
• RHY BCP shelter
• VA HCHV Community
Contract Emergency Housing
• Locally-funded shelters

Safe Haven

• CoC Safe Haven
• VA Community Contract Safe
Haven
• Locally-funded Safe Haven
type projects

Moved from one HOPWA funded
project to HOPWA TH

Limited to use by HOPWAfunded projects

Transitional housing for homeless
persons (including homeless
youth)

• CoC Transitional Housing
• HOPWA Transitional Housing
(when moving from nonHOPWA projects)
• RHY Maternal Group Homes
or TLP
• VA GPD Bridge Housing,
Service Intensive Transitional
Housing, Hospital to Housing,
or Clinical Treatment
• Any locally-funded
transitional housing project
(facilitates movement to
permanent housing with
occupancy agreement for
terms from 1-24 months).

Hotel or motel paid for without
emergency shelter voucher
Residential project or halfway
house with no homeless criteria

A sober living or other
residential project with no
lease or rights of tenancy, with
or without time limits

Staying or living with family,
temporary tenure (room,
apartment, or house)
Staying or living with friends,
temporary tenure (room,
apartment, or house)

Field
1 Destination
(cont.)

Dependency
None

Response Category/Data Type
Institutional
Situations

4
5
6
7
15
25

Continuum
PH Projects

Descriptions

Psychiatric hospital or other
psychiatric facility
Substance abuse treatment facility
or detox center
Hospital or other residential nonpsychiatric medical facility
Jail, prison, or juvenile detention
facility
Foster care home or foster care
group home
Long-term care facility or nursing
home
PERMANENT SITUATIONS
Rental by client, with RRH or
Use this response category only
equivalent subsidy
if the client is moving directly
into a unit.
•
•
•
•
•

26
3

Rent/Own
with Subsidy

28
19
20

21
Rent/Own
no Subsidy

10
11

Other
Permanent

22
23

Moved from one HOPWA funded
project to HOPWA PH
Permanent housing (other than
RRH) for formerly homeless
persons

Rental by client, with GPD TIP
housing subsidy
Rental by client, with VASH
housing subsidy
Rental by client, with other
ongoing housing subsidy

CoC Rapid Re-Housing
ESG Rapid Re-Housing
SSVF Rapid Re-Housing
VA GPD Transition In Place
Locally-funded Rapid ReHousing

Limited to use by HOPWAfunded projects
• CoC Permanent Supportive
Housing
• HOPWA facility/TBRA
permanent housing (when
moving from non-HOPWA
projects)

Any subsidized rental housing
other than CoC PSH, HOPWA
PH, RRH, GDP TIP, or VASH.
Includes HUD HCV with no
paired services, legacy SRO,
and Pay for Success

Owned by client, with ongoing
housing subsidy
Rental by client, no ongoing
housing subsidy
Owned by client, no ongoing
housing subsidy
Staying or living with family,
permanent tenure
Staying or living with friends,
permanent tenure

Field
1 Destination
(cont.)

Dependency
None

Response Category/Data Type

Descriptions
OTHER SITUATIONS

Other
Situations

24
17

Deceased
Other

No exit interview completed

8
9
99

Client doesn't know
Client refused
Data not collected

Any response of 'Other' will not
count in any HMIS-based
reporting as a positive
outcome. Review the above list
carefully to determine if any
option above is a reasonable
match
This will be considered missing
data for data quality purposes

3.15 Relationship to Head of Household
Rationale To identify one person to whom all other household members can be linked to at the time
they enter a project. This facilitates the identification and enumeration of households. In addition,
specifying the relationship of household members to the head of household facilitates reporting on
household composition.
Data Collection Instruction Identify one member of a household to whom all other household members
can be associated. A household is a single individual or a group of persons who apply together to a
continuum project for assistance and who live together in one dwelling unit, or, for persons who are not
housed, who would live together in one dwelling unit if they were housed.
There cannot be more than one head of household for any given project start. If the head of household
leaves the project while other household members remain, another member of the household currently
participating in the project must be designated as the head of household and the other members’
relationship to head of household should be corrected to reflect each individual’s relationship to the
newly designated head of household in the event that it differs from the relationship to whoever was
previously identified as the head of household. Records of such changes are not necessary to retain in
the HMIS over the course of a project stay.
In a household of a single individual, that person must be identified as the head of household.
In multi-person households, the term “Head of Household” is not intended to mean the "leader" of the
house. When a group of persons present together as a household or family unit, no matter the
configuration or whether or not a minor is among the members, one of those persons must be
designated as the head of household and the rest must have their relationship to the head of household
recorded.
If the group of persons is composed of adults and children, an adult must be indicated as the head of
household. Other than this restriction, each CoC must develop guidelines for defining and designating a
household member as the head of household and seek to ensure that those guidelines are applied
consistently across participating continuum projects. A particular funder may provide instructions for
determining which household member should be designated as the head of household in projects that
they fund; in the event that the funder’s instructions are in conflict with CoC guidance, the requirements
of the funder should supersede CoC guidance for the relevant projects.
If the group of persons are all children and youth (where none of the youth presenting are the child of
another youth being served by a project), each youth should be entered as their own record in their own
household. It is important to create separate records for youth who present together to better
understand homelessness among youth. Entering them separately is not permitted to be a barrier to or
impact the receipt of future interventions.

Data Element Fields and Responses
Field

Dependency

1 Relationship
to Head of
Household

None

Response Category/
Data Type
1
Self

Descriptions

Head of household's child

Sons and daughters, including step-,
adopted, and foster children of the head
of household, regardless of their age.

Head of household's spouse
or partner
Head of household's other
relation member (other
relation to head of
household
Other: non-relation
member

Heads of household may be alternatively
thought of as the “primary client,” the
“eligible individual” etc., rather than as a
fixed designation.

Groups of people may self-define their
households or families, which may include
other non-relations.
However, If the group of persons are all
children and youth (where none of the
youth presenting are the child of another
youth being served by a project), each
youth should be entered as their own
record in their own household.

3.16 Client Location
Rationale To link client household data to the relevant CoC. Necessary for projects that operate across
multiple CoCs for data export purposes and to ensure accurate counts of persons who are served within
a CoC.
Data Collection Instruction Select or enter the CoC code assigned to the geographic area where the
head of household is staying at the time of project entry. This data element must be manually entered
for all projects with more than one Continuum of Care Code identified in Project Descriptor Data
Element 2.3. It may be auto-populated for projects that operate in a single CoC.
'Information Date’ for Client Location information collected at project start must reflect the date of
project start.
A new Client Location record must be created at any time during a project stay if a client moves into a
different CoC while enrolled. 'Information Date’ for those records must reflect the date of the data
collection.
If Client Location information was recorded incorrectly at project start or update, correct the existing
record.
Data Element Fields and Responses
Field

Dependency

Descriptions

None

Response Category/
Data Type
1
[date]

1 Information Date
2 CoC Code for Client Location

None

HUD assigned CoC code for the
client's location

[Text – 6
characters]

The date the information was
collected.

3.20 Housing Move-in Date
Rationale To document the date that a household admitted into a Permanent Housing project moves
into housing. This data is critical to point-in-time and housing inventory counts as it differentiates
households which are enrolled in a Permanent Housing project but are still literally homeless (in
emergency shelter, Safe Haven, transitional housing or on the street) as they prepare to move into an
available unit from households which have already moved into permanent housing.
Data Collection Instruction For clients with a Project Start Date in a permanent housing project of any
kind (see criteria for recording a Project Start Date under data element 3.10), record the date a client or
household moves into a permanent housing unit.
For RRH projects only, a Housing Move-in Date must be entered regardless of whether or not the RRH
project is providing the rental assistance for the unit. For example, if an RRH project provides supportive
services, but is not providing the rental assistance for the unit, a Housing Move-in Date must still be
entered to differentiate RRH clients in housing from those still experiencing homelessness.
For any other project types that are typed as ‘Permanent Housing’ in the HMIS, clients who are receiving
pre-housing placement services but are ultimately housed by another project or subsidy source should
be exited from the PH project to the appropriate permanent Destination. If the client exits the
permanent housing project for a different housing opportunity without physically moving into a housing
unit associated with the project, do not enter a housing move-in date, simply exit the client and record
the exit destination.
For purposes of the Housing Inventory Count and other point-in-time reporting, households with a
Project Start Date which do not have a Housing Move-In Date at the point in time of the report must be
excluded from counts of persons in permanent housing.
With the addition of this data element to a wider variety of project types in the 2017 Data Standards,
systems must populate the data element for all clients previously enrolled in non-RRH permanent
housing projects with the existing 3.10 Project Start Date. The previous definition of Project Entry Date
for non-RRH permanent housing projects was the date the household moved into housing.
For clients who entered a non-RRH permanent housing project (or an RRH project not previously
required to collect housing move-in data) prior to October 1, 2017, the Housing Move-in Date will be
automatically populated with the value from the client's Project Start Date, but projects can edit these
dates to reflect the actual Project Start Date (if information on when the client was first assisted by the
PH program is available) or actual housing status (if the client is still in the process of being housed).
Data Element Fields and Responses
Field

Dependency

1 Housing Move-In
Date

None

Response Category/
Data Type
[Date]

Descriptions
The date the client moved into housing.

3.917 Living Situation
Rationale To identify the type of living situation and length of stay in that situation just prior to project
start for all adults and heads of households. This data element is to be used with other information to
identify whether a client appears to meet the criteria for chronic homelessness.
The element has been constructed to avoid collecting information which is irrelevant or inappropriate
for the client population being served in a particular situation. For example, eligibility for Homelessness
Prevention requires that a client be in housing. By definition, a person in housing is not chronically
homeless, so some of the fields in this data element used to determine chronic homeless status are not
required in that situation.
Data Collection Instruction Intake staff should ask clients about their homeless history, including
specific instances the client spent on the street, in an emergency shelter, or in a Safe Haven project. This
may require defining or explaining each field to the client.
Although documentation is required by some funders for programs targeting chronic homeless persons,
completing the data fields in HMIS does not require documentation -- a client’s responses are all that is
required. Different project types have different realities they are working in when it comes to
interviewing clients. Some high volume shelters may simply ask people to quickly “ballpark” their
responses to the required fields. Other project types are able to have more complex intake processes
that allow staff to sit with the client and get a clearer picture of the client’s housing history and their
official “breaks” in homelessness, according to the definition of chronic homelessness. PSH projects with
documentation requirements are going to be spending time with clients’ HMIS records and files to get
information for documentation purposes, which they can use to improve data quality in this field. All of
these strategies are acceptable, and HUD anticipates that the data quality will vary from project type to
project type. This data element is intended to provide a consistent way to capture information about
individuals who are likely experiencing chronic homelessness in the HMIS for HUD and CoCs to use for
planning purposes.
Note that this data element does not constitute third-party documentation of chronic homelessness for
projects that require such documentation (HMIS reports of actual enrollments in ES, SH, or SO projects
may be used to meet third-party documentation requirements).
The responses are intended to reflect from the client’s last living situation immediately prior to the
Project Start Date. For projects that do not provide lodging, the ‘prior’ living situation may be the same
as the client’s current living situation.
1. Select the ‘Type of Residence’ that most closely matches where the client was living prior to
project start. Adult members of the same household may have different prior living situations.
2. Record the length of time the client was residing in their previous place of stay.
a. (3.917B) If the client is entering Transitional Housing, any form of Permanent Housing
including Permanent Supportive Housing and Rapid Re-Housing, Services Only, Other,
Day Shelter, Homelessness Prevention, and Coordinated Assessment (Coordinated
Entry) from an institutional setting:
i. Indicate if the client was in the institution for less than 90 days and if so,
indicate if the client’s living situation immediately prior to entering the
institution was on the streets, in an emergency shelter or a safe haven.
ii. If ‘Yes’ to both, proceed to step 3. If ‘No’ to either, stop collecting data for this
element.
b. (3.917B) If the client is entering Transitional Housing, any form of Permanent Housing
including Permanent Supportive Housing and Rapid Re-Housing, Services Only, Other,
Day Shelter, Homelessness Prevention, and Coordinated Assessment (Coordinated
Entry) from any type of transitional or permanent housing:
56

i. Indicate if the client was in the transitional or permanent housing situation for
less than 7 nights and if so, indicate if their living situation immediately prior to
entering the transitional or permanent housing was on the streets, in an
emergency shelter or a safe haven.
ii. If ‘Yes’ to both, proceed to step 3. If ‘No’ to either, stop.
c. If the client is entering Emergency Shelter, Safe Haven, or Street Outreach, proceed to
step 3.
3. Record the actual or approximate date this homeless situation began (i.e. the beginning of the
continuous period of homelessness on the streets, in emergency shelters, in safe havens, or
moving back and forth between those places).
4. Record the number of times the client has been on the streets, in emergency shelters, or in safe
havens in the past three years, including today.
5. Record the cumulative total number of months the client has been homeless on the streets, in
emergency shelters, or in safe havens in the past three years.

Data Element Fields and Responses
Field

Dependency

1 Type of
Residence

None

Response Category/
Data Type
16
1

Descriptions

HOMELESS SITUATIONS
Place not meant for habitation
Emergency shelter, including
• ESG Emergency Shelter
hotel or motel paid for with
• HOPWA Hotel/Motel or Short Term
emergency shelter
Housing
• RHY BCP shelter
• VA HCHV Community Contract Emergency
Housing
• Locally-funded shelters

Safe Haven

• CoC Safe Haven
• VA Community Contract Safe Haven
• Locally-funded Safe Haven type projects

Interim Housing

Limited to use by PSH projects for which
chronic homelessness is an eligibility
criterion.
A housing situation where a chronically
homeless person has: 1) applied for
permanent housing, 2) been accepted, and
3) a unit/voucher for permanent housing
reserved for them, but for which there is
some other situation that prevents them
from moving immediate move into housing.
Where it has been determined to be
absolutely necessary to use transitional
housing to keep the client engaged prior to
moving into PSH, the client must be
identified as coming from “interim housing”
to preserve chronic identification in
reporting. This housing is not a substitute
for a waiting list or for any situation other
than identified here.
INSTITUTIONAL SITUATIONS

4
5
6

7
15
24

Psychiatric hospital or other
psychiatric facility
Substance abuse treatment
facility or detox center
Hospital or other residential
non-psychiatric medical
facility
Jail, prison or juvenile
detention facility
Foster care home or foster
care group home
Long-term care facility or
nursing home

Field

Dependency

1 Type of
Residence
(cont.)

None

Response Category/
Descriptions
Data Type
TRANSITIONAL AND PERMANENT HOUSING SITUATIONS
2
Transitional housing for
• CoC Transitional Housing
homeless persons (including
• HOPWA Transitional Housing (when
homeless youth)
moving from non-HOPWA projects)
• RHY Maternal Group Homes or TLP
• VA GPD Bridge Housing, Service Intensive
Transitional Housing, Hospital to Housing,
or Clinical Treatment
• Any locally-funded transitional housing
project (facilitates movement to
permanent housing with occupancy
agreement for terms from 1-24 months).
26

Residential project or halfway
house with no homeless
criteria

Hotel or motel paid for
without emergency shelter
voucher
Staying or living in a friend’s
room, apartment, or house
Staying or living in a family
member’s room, apartment,
or house
Permanent housing (other
than RRH) for formerly
homeless persons
Rental by client, with VASH
subsidy
Rental by client, with GPD TIP
subsidy
Rental by client, with other
housing subsidy (including
RRH)

13
12

19
25
20

21
22
23

8
9
99

A sober living or other residential project
with no lease or rights of tenancy, with or
without time limits

• CoC Permanent Supportive Housing
• HOPWA facility/TBRA permanent housing

Any subsidized rental housing other than
CoC PSH, GDP TIP, or VASH.
Includes any RRH (CoC, ESG, SSVF, GPD TIP,
or locally-funded), HUD HCV with no paired
services, legacy SRO, and Pay for Success.

Owned by client, with ongoing
housing subsidy
Rental by client, no ongoing
housing subsidy
Owned by client, no ongoing
housing subsidy
OTHER SITUATIONS
Client doesn’t know
Client refused
Data not collected

Field

Dependency

2 Length of
stay in
prior living
situation

None

Response Category/
Data Type
10 One night or less

Two to six nights

One week or more, but less
than one month
One month or more, but less
than 90 days
90 days or more, but less than
one year
One year or longer

Client doesn't know

Client refused

Data not collected

3
4

Descriptions
The length of time the client was residing in
the living situation selected in Field 1. If the
client moved around, but in the same type
of situation, include the total time in that
type of situation. If the client moved around
from one situation to another, only include
the time in the situation selected in Field 1.

Dependent Fields A, B, and C are not applicable to Emergency Shelter, Safe Haven, or Street Outreach projects.
Proceed to Field 3.
A Did the
client stay
less than 90
days?

Field 1; Any
Institutional
Response

Yes

B Did the
client stay
less than 7
nights?

Field 1; Any
Transition
al and
Permanen
t Housing
Response
Fields A & B;
Response 1

Yes

90 days or more in an institutional setting is
considered a “break” according to the
definition of chronic homelessness
7 nights or more in transitional or
permanent housing situations is considered
a “break” according to the definition of
chronic homelessness

C On the
0
No
night
1
Yes
before, did
the client
stay on the
streets, ES
or SH 4
For all Transitional Housing, any form of Permanent Housing including Permanent Supportive Housing and Rapid
Re-Housing, Services Only, Other, Day Shelter, Homelessness Prevention, and Coordinated Assessment
(Coordinated Entry): If 'Yes' to both Fields A and C or Fields B and C, proceed. Otherwise, stop data collection.

“The streets” is being used as short-hand for any place unfit for human habitation (a public or private place not
designed for or ordinarily used as a regular sleeping accommodation for human beings, including a car, park,
abandoned building, bus or train station, airport, or camping ground).

Field

Dependency

3 Date
homelessness
started

None

Response Category/
Data Type
[Date]

Descriptions
Have the client look back to the date of the
last time the client had a place to sleep that
4
was not on the streets, ES, or SH.
Including the situation the client was in right
before entering, plus any continuous time
moving around between the streets, an
emergency shelter, or a safe haven,
determine the date this period of the client’s
“literal” homelessness began.
The look back time would not be broken by
a stay of less than 7 consecutive nights in
any permanent or temporary housing
situation nor would it be broken by an
institutional stay of less than 90 days (i.e.
jail, substance abuse or mental health
treatment facility, hospital, or other similar
facility).
Approximations are permitted.

4 Number of
times the
client has
been on
the streets,
in ES, or SH
in the past
three
years4

5 Total
number of
months
homeless
on the
street, in
ES, or SH in
the past
three
years4

None

One time

Two times

Three times

Four or more times

Client doesn't know

Client refused

Data not collected

101 One month (this time is the
first month)

102
112
113
8
9
99

Including today, count all the different times
the client was on the streets, in an
emergency shelter, or in a safe haven in the
last 3 years where there are full breaks in
between (i.e. breaks that are 90 days or
more in an institution or 7 nights or more in
permanent or transitional housing)

Count the cumulative number of months in
which a person was on the streets, in an ES,
or SH in the last 3 years, including stays in an
institution <90 days or in permanent or
transitional housing <7 days. Round the
number of months up to the next highest
number of full months. The current month,
even if a partial month, can be counted as a
full month.

[Integers 2-12]

More than 12 months
Client doesn't know
Client refused
Data not collected

4. PROGRAM SPECIFIC DATA ELEMENTS
To meet the statutory and regulatory requirements of federally funded programs using HMIS, additional
elements are required for different funding sources. The Program Specific Data Elements are elements
that are required by at least one of the HMIS federal partner programs.
Some of the program specific data elements are collected across most federal partner programs. These
are called “Common” Program Specific Data Elements.
The HMIS Federal Partners have cooperatively developed these elements. For each Program-Specific
Data Element, multiple response categories are provided. Projects may choose to capture more detailed
information (or finer response categories), but only if this information can be exactly mapped to the
required response categories described in this section. For reporting purposes, an HMIS must be able to
produce required reports using the response categories exactly as they are presented in this section.
Local CoCs may elect to require all continuum projects participating in HMIS to collect a subset of the
data elements contained in this section to obtain consistent information across a range of projects that
can be used to plan service delivery, monitor the provision of services, and identify client outcomes.
However, CoCs and projects are encouraged to develop their own data collection protocols and
assessment tools to fully assess client service needs.
4.2
Income and Sources
4.3
Non-Cash Benefits
4.4
Health Insurance
4.5-4.10 Disability Elements
4.5
Physical Disability
4.6
Developmental Disability
4.7
Chronic Health Condition
4.8
HIV/AIDS
4.9
Mental Health Problem
4.10 Substance Abuse
4.11 Domestic Violence
4.12 Contact
4.13 Date of Engagement
4.14 Bed-Night Date
4.18 Housing Assessment Disposition
In the 2017 HMIS Data Standards, Data Element 4.1 Housing Status was retired from use and 4.17
Residential Move-In Date was significantly modified and became universal data element 3.20 Housing
Move-In Date.
Appendix B summarizes the client universe for each universal and program-specific data element and
when it is collected.
Many additional elements have been developed by the federal partners, but are limited to one or two
federal partner programs or a single component of one of the federal partner programs. Information
about the federal partner-specific data elements can be found in the HMIS Data Dictionary and the HMIS
Federal Partner Program Manuals.
An HMIS must have the ability to enable and restrict visibility of elements for each project based on the
reporting requirements of the federal partner program funding the project. An HMIS may do this in
whatever manner the software provider chooses (hard coding, customization via system administrators,
62

etc.). HMIS vendors should note that no federal partner expects that any project would have all
elements visible to the user. The strong preference among the federal partners is that only the elements
required for the programs that fund a specific project are visible to the users at that project.
Program specific guidance issued through HUD and the individual federal partner in the HMIS Federal
Partner Program Manuals provides program setup and visibility information and definitions relevant for
the partner.

Common Program Specific Data Elements
4.2
Income and Sources
Rationale To determine whether households are accessing all income sources for which they are eligible
at the time of project start and to allow for analyzing changes in the composition of income between
project start and exit.
Increase in income is a key performance measure of most federal partner programs. Collecting income
information throughout a project stay supports plans to link clients with all income sources and benefits
for which they are eligible, and helps CoCs improve system design and partnerships by analyzing crosssystems connections to ensure access to additional income sources.
Data Collection Instruction Indicate whether each head of each household served (including minor
heads of their own household) and each adult household member have income and the sources of that
income.
Income data should be entered in HMIS consistent with guidelines for calculating household income
provided by a project funder, if such guidelines exist. For example, for eligibility purposes, both CoC and
ESG-funded projects are instructed to exclude income from the employment of a minor child from
calculations of household income. The same is true for SSVF. However, recording income in an HMIS is
not the same as performing an income evaluation for purposes of project eligibility determination or a
rent calculation for the purpose of determining rental subsidy (24 CFR 5.609 and 24 CFR 5.611(a). Data
recorded in HMIS also does not replace required income verification documentation that may be
required by a funder.
In the absence of income calculation guidelines provided by a funder, as a general rule, any income
associated with a minor used for household expenses and support should be included in the head of
households Income and Sources record. Where the income is not relevant for household expenses, it
could reasonably be excluded from entry. Projects may choose to collect income information for all
household members including minor children within households, as long as this does not interfere with
accurate reporting per funder requirements.
Income and Sources collected at project start and project exit are to reflect the information as of the
date of project start and the date of project exit. 'Information Date’ for those records must reflect the
date of project start and the date of project exit, respectively.
An Income and Sources record must be created at any time during a project stay if income or sources
change. This would include the situation when a minor child enters or leaves the household and the
income received by the household changes as a result. In that case, a new Income and Sources record
must be created for the head of household, reflecting the additional (or lost) income. This would also
include the situation when a minor child in a household turns 18. In that case, a new Income and Sources
record must be created for the 18-year-old client reflecting any income associated with that client. If
some existing income transfers to the 18-year-old’s new record, an additional update record would need
to be created for the Head of Household, reflecting the removal of that income from their record.
'Information Date’ for those records must reflect the date of the data collection.
An Income and Sources record must be created as part of an annual assessment for clients participating
in a project one year or more, even if there is no change in either the income or sources. 'Information
Date’ for those records must reflect the date of the data collection, which must be no more than 30 days
before or after the anniversary of the head of household’s Project Start Date. Annual assessments are
based solely on the head of household’s anniversary date. The annual assessment must include updating
both the head of household’s record and any other family member’s at the same time.
If a client's income information was recorded incorrectly at project start, update, assessment, or exit,
correct the existing record, rather than adding an “update” record.
64

To collect income information, projects are expected to ask clients whether they receive income from
each of the sources listed (either on paper or through client interview) rather than asking them to state
the sources of income they receive. Unless the project funder requires documentation for
recordkeeping purposes, clients are not required to provide documentation of income or benefits.
Requiring documentation of income and benefits when it is not a funder’s requirement unnecessarily
slows down the process for assisting people to exit homelessness.
Income data should be recorded only for sources of income that are current as of the 'Information Date’
(i.e. have not been terminated). Clients may identify multiple sources of income.
•

Example: a client’s employment has been terminated and the client has not yet secured
additional employment. Record the response for Earned income as ‘No.’

•

Example: a client’s most recent paycheck was 2 weeks ago from a job in which the client was
working full time for $15.00/hour, but the client is currently working 20 hours per week for
$12.00 an hour. Record the income from the job the client has at the time data are collected
(i.e. 20 hours at $12.00 an hour).

When a client has income, but does not know the exact amount, a ‘Yes’ response should be recorded for
both the overall income question and the specific source, and the income amount should be estimated.
Income and Sources is intended to identify regular, recurrent earned income and cash benefits. Services
and/or gifts such as phone cards and vouchers that are provided by a project to clients during
enrollment are fundamentally different and are not considered income.
Student financial aid is not to be considered income unless the financial aid includes a cash stipend. The
source for such income would be considered ‘Other,’ and the source can be described in a text field. Be
sure to check your funder’s requirements, however. For example, SSVF does not allow grantees to
include any student financial aid, including GI Bill Student Financial Aid.
Lump sum amounts received by a family, such as inheritances, insurance settlements, or proceeds from
sale of property, or back pay from Social Security are considered assets, not income, and are not
recorded in HMIS.

Data Element Fields and Responses
Field

Dependency

Information Date

None

Income from Any Source

None

Earned income (i.e.
employment income)

None

A
4

Monthly Amount
Unemployment Insurance

Field 3; Response 1
None

B
5

Monthly Amount
Supplemental Security
Income (SSI)

Field 3; Response 1
None

C
6

Monthly Amount
Social Security Disability
Insurance (SSDI)

Field 3; Response 1
None

D
7

Monthly Amount
VA Service -Connected
Disability Compensation

Field 3; Response 1
None

Monthly Amount
VA Non-Service-Connected
Disability Pension

Field 3; Response 1
None

F
9

Monthly Amount
Private disability insurance

Field 3; Response 1
None

G
10

Monthly Amount
Worker's Compensation

Field 3; Response 1
None

E
8

H
11

Monthly Amount
Assistance for Needy
Families (TANF) [or use
local name]

Field 10; Response 1
None

Response Category/
Data Type
[Date]
0
No
1
Yes
8
Client doesn't know
9
Client refused
99 Data not collected
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes

[Currency/decimal]
0
No
1
Yes

Descriptions
The date the information
was collected.

VA service-connected
disability compensation
refers to a benefit paid to
veterans with a serviceconnected disability.

VA non-serviceconnected disability
pension refers to a
benefit paid to wartime
veterans who have
limited or no income and
who are ages 65 or older
or, if under 65, who are
permanently and totally
disabled.

[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes

Field

Dependency

I
12

Monthly Amount
General Assistance (GA)
[or use local name]

Field 11; Response 1
None

J
13

Monthly Amount
Retirement Income from
Social Security

Field 12; Response 1
None

Monthly Amount
Pension or retirement
income from a former job

Field 13; Response 1
None

L
15

Monthly Amount
Child support

Field 14; Response 1
None

M
16

Monthly Amount
Alimony and other spousal
support

Field 15; Response 1
None

N
17

Monthly Amount
Other source

Field 16; Response 1
None

O
P
18

Monthly Amount
Specify Source
Total Monthly Income

Field 17; Response 1
Field 17; Response 1

K
14

Response Category/
Data Type
[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes

[Currency/decimal]
0
No
1
Yes

Descriptions

Social Security Survivor
benefits are Retirement
Income from Social
Security.

Military retirement pay
should be reported under
Pension or retirement
income from a former
job.

[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
0
No
1
Yes
[Currency/decimal]
[Text]
[Currency/decimal]

4.3
Non-Cash Benefits
Rationale To determine whether households are accessing all mainstream program benefits for which
they are eligible at the time of project start and to allow for analyzing changes in the composition of
non-cash benefits between project start and exit.
Data Collection Instruction Indicate whether each head of each household served (including minor
heads of their own household) and each adult household member are receiving any of the listed
benefits.
Non-cash benefits data should be entered in HMIS consistent with guidelines provided by a project
funder, if such guidelines exist. In the absence of guidelines provided by a funder, as a general rule, any
benefits received by or on behalf of a minor household member or on behalf of the household as a
whole (such as SNAP) should be included in the head of households Non-Cash Benefits record. Projects
may choose to collect non-cash benefits information for all household members including minor
children within households, as long as this does not interfere with accurate reporting per funder
requirements.
Non-Cash Benefits collected at project start and project exit are to reflect the information as of the date
of project start and the date of project exit. 'Information Date’ for those records must reflect the date of
project start and the date of project exit, respectively.
A Non-Cash Benefits record must be created at any time during a project stay if non-cash benefits
change. This would include the situation when a minor child enters or leaves the household and the
non-cash benefits received by the household change as a result. In that case, a new Non-Cash Benefits
record must be created for the head of household, reflecting the additional (or lost) benefit. This would
also include the situation when a minor child in a household turns 18. In that case, a new Non-Cash
Benefits record must be created for the 18-year-old client reflecting any benefits associated with that
client. If an existing benefit transfers to the 18-year-old’s new record, an additional update record would
need to be created for the Head of Household, reflecting the removal of that benefit from their record.
'Information Date’ for those records must reflect the date of the data collection.
A Non-Cash Benefits record must be created as part of an annual assessment for clients participating in a
project one year or more, even if there is no change in benefits. 'Information Date’ for those records
must reflect the date of the data collection, which must be no more than 30 days before or after the
anniversary of the head of household’s Project Start Date. Annual assessments are based solely on the
head of household’s anniversary date. The annual assessment must include updating both the head of
household’s record and any other family members at the same time.
If a client's benefits information was recorded incorrectly at project start, update, assessment, or exit,
correct the existing record.
To collect benefits information, projects are expected to ask clients whether they receive benefits from
each of the sources listed (either on paper or through client interview) rather than asking them to state
the sources of non-cash benefits they receive. Clients are not required to provide documentation of
benefits. Requiring documentation of benefits when it is not a funder’s requirement unnecessarily slows
down the process for assisting people to exit homelessness.
Benefits data should be recorded only for benefits that are current as of the 'Information Date’ (i.e. have
not been terminated). Clients may identify multiple sources of non-cash benefits.
•

Example: a client received food stamps on the first of the month and expects to receive food
stamps again on the first of the next month. Record the response for Supplemental Nutritional
Assistance Program (SNAP) as ‘Yes.’

•

Example: a client received food stamps on the first of the month but is not eligible to receive
food stamps on the first of next month. Record the response for Supplemental Nutritional
Assistance Program (SNAP) as ‘No.’

Non-Cash Benefits is intended to identify regular, recurrent benefits. Services and/or gifts such as phone
cards and vouchers that are provided by a project to clients during enrollment are fundamentally
different and are not considered benefits.
Data Element Fields and Responses
Field

Dependency

1 Information Date

None

2 Non-Cash Benefits from Any
Source

None

3 Supplemental Nutrition
Assistance Program (SNAP)
(Previously known as Food
Stamps)
4 Special Supplemental Nutrition
Program for Women, Infants,
and Children (WIC)
5 TANF Child Care services (or
use local name)

None

6 TANF transportation services
(or use local name)

None

7 Other TANF-funded services

None

9 Other source

None

A Specify source

Field 9; Response 1

Response Category/
Data Type
[Date]

0
1
8
9
99
0
1

No
Yes
Client doesn't know
Client refused
Data not collected
No
Yes

None

0
1

No
Yes

None

0
No
1
Yes
0
No
1
Yes
0
No
1
Yes
0
No
1
Yes
[Text]

Descriptions
The date the
information was
collected.

4.4
Health Insurance
Rationale To determine whether clients are accessing all mainstream medical assistance benefits for
which they may be eligible, and to ascertain a more complete picture of changes to economic
circumstances between project start and exit.
Data Collection Instruction In separate fields, indicate whether or not clients are receiving health
insurance from any of the listed sources.
Health Insurance data collected at project start and project exit are to reflect the information as of the
date of project start and the date of project exit. 'Information Date’ for those records must reflect the
date of project start and the date of project exit, respectively.
A Health Insurance record must be created at any time during a project stay if health insurance coverage
information changes. 'Information Date’ for those records must reflect the date of the data collection.
A Health Insurance record must be created as part of an annual assessment for all clients residing in a
project one year or more, even if there is no change in coverage. 'Information Date’ for those records
must reflect the date of the data collection, which must be no more than 30 days before or after the
anniversary of the head of household’s Project Start Date. The annual assessment must include updating
both the head of household’s record and any other family members at the same time.
If a client's health insurance information was recorded incorrectly at project start, update, assessment,
or exit, correct the existing record.
If the response to Covered by Health Insurance is ‘No,’ no further data collection is required. If the
response is ‘Yes,’ record whether or not the client is covered by each of the listed insurance types. If
required by a funder, enter the reason why such insurance is not being received for each health
insurance source.
Applying for coverage through a healthcare exchange could result in a person receiving subsidized
private health insurance or it could result in the person receiving Medicaid. If the client’s health
coverage is through a private provider (even if it is heavily subsidized), record it as Private Pay Health
Insurance. If the client’s health coverage is through Medicaid (even if it was accessed through a
healthcare exchange website), record it as Medicaid.
Health Insurance is intended to identify actual health insurance sources. Indigent care received by a
medical provider or hospital to cover a health care costs does not constitute health insurance coverage
and should not be recorded in HMIS.
Medical and dental health coverage provided through Ryan White funding is not considered health
insurance. If this is the only health coverage a client has, record ‘No’ in the field ‘Covered by Health
Insurance.’ Housing Opportunities for Persons With AIDS (HOPWA) providers record Ryan White health
services in data element W3 Medical Assistance (see HOPWA Program HMIS Manual). It is anticipated
that the combination of these two data elements will be used when measuring access to care for the
HOPWA APR and CAPER.

Data Element Fields and Responses
Field

Dependency

1 Information Date

None

2 Covered by Health Insurance

None

3 Medicaid

None

4 Medicare

None

5 State Children’s Health
Insurance Program (or use
local name)
6 Veteran’s Administration (VA)
Medical Services

None

7 Employer-Provided Health
Insurance

None

8 Health Insurance obtained
through COBRA

None

9 Private Pay Health Insurance

None

10 State Health Insurance for
Adults (or use local name)

None

11 Indian Health Services
Program

None

12 Other

None

A Specify Source
13 Reason (HOPWA ONLY)

None

Field 12;
Response 1
If "No" for
all Insurance
Sources

Response Category/
Data Type
[Date]
0
1
8
9
99
0
1

No
Yes
Client doesn't know
Client refused
Data not collected
No
Yes

0
1
0
1

No
Yes
No
Yes

0
1
0
1

No
Yes
No
Yes

0
1
0
1
0
1
0
1
0

No
Yes
No
Yes
No
Yes
No
Yes
No

Descriptions
The date the information was
collected.

Medicaid is a partnership
between federal and state
funds. It should always be
listed as Medicaid not State
Health Insurance.

Including TRICARE – available
to veterans based on military
service

A health insurance other than
the ones identified in this list.

1
Yes
[Text]
1
2
3
4
8
9
99

Applied; decision
pending
Applied; client not
eligible
Client did not apply
Insurance type N/A
for this client
Client doesn't know
Client refused
Data not collected

4.5 – 4.10 Disability Elements
Rationale To indicate whether clients have any disabling special needs which contribute to their
experience of homelessness or may be a factor in housing.
Data Collection Instruction In separate fields, indicate:
(1) If each client has the indicated disability; and
(2) If there is indication that the disability is expected to be of long-continued and indefinite
duration (applicable to most of the individual disability elements) and substantially impair the
client’s ability to live independently.
Individual Disability records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. Disability update records should be created
at any time during a project stay if a client's physical disability status changes. ‘Information Date’ for
those records must reflect the date of project start, update, and the date of project exit, respectively.
If a client's physical disability status was recorded incorrectly at entry, update, or exit, correct the
existing record rather than creating a new update record.
Unless the project funder requires documentation for recordkeeping purposes, clients are not require
documentation of the disability, not does entering the information in the HMIS constitute a “diagnosis”
by the worker who did the data collection or recording.
If the disability is present and is expected to be of long-continued and indefinite duration, the
corresponding element 3.8 Disabling Condition should also be “yes” whether by manual data entry, or in
some systems, automatic population. It is acceptable for a client to answer 'Yes' to having a physical
disability, and also answer 'No,' that the disability is not expected to be of long–continued and indefinite
duration and substantially impair ability to live independently, although a disability of such type may not
qualify clients for programs meant for severely disabled people and may not indicate a “disabling
condition” according to the universal data element 3.8.
For residential homeless assistance programs, client intake as part of the program admission process
must be separated from the collection of disability information in order to comply with Fair Housing
laws and practices, unless this information is required to determine program eligibility or is needed to
determine whether applicants need units with special features or if they have special needs related to
communication. Projects should be especially sensitive to the collection of disability information from
clients under the age of 18. In households with children accompanied by an adult, children’s disabilities
should be determined based on an interview with the adult in the household.

4.5

Field

Physical Disability

Dependency

1 Information Date

None

2 Physical Disability

None

A Expected to be of long–
continued and indefinite
duration and
substantially impairs
ability to live
independently

Field 2;
Response 1

Response Category/
Data Type
[Date]
0
1

No
Yes

8
9
99
0
1

Client doesn't know
Client refused
Data not collected
No
Yes

8
9
99

Client doesn't know
Client refused
Data not collected

Descriptions
The date the information was
collected.
For the purposes of these Data
Standards, a physical disability
means a physical impairment.

1) Expected to be of long,
continued and indefinite
duration, (2) substantially
impedes an individual’s ability to
live independently, and (3) of
such a nature that such ability
could be improved by more
suitable housing conditions.

4.6

Field

Developmental Disability

Dependency

1 Information Date

None

2 Developmental Disability

None

A Expected to substantially
impair ability to live
independently

Field 2;
Response 1

Response Category/
Data Type
[Date]
0
1

No
Yes

8
9
99
0
1

Client doesn't know
Client refused
Data not collected
No
Yes

8
9
99

Client doesn't know
Client refused
Data not collected

Descriptions
The date the information was
collected.
For the purposes of these Data
Standards, a developmental
disability means a severe, chronic
disability that is attributed to a
mental or physical impairment
(or combination of physical and
mental impairments) that occurs
before 22 years of age and limits
the capacity for independent
living and economic selfsufficiency.

(1) Substantially impedes an
individual’s ability to live
independently, and (2) of such a
nature that such ability could be
improved by more suitable
housing conditions.

4.7

Field

Chronic Health Condition

Dependency

1 Information Date

None

2 Chronic Health Condition

None

A Expected to be of long–
continued and indefinite
duration and substantially
impairs ability to live
independently

Field 2;
Response 1

Response Category/
Data Type
[Date]
0
1

No
Yes

8
9
99
0
1

Client doesn't know
Client refused
Data not collected
No
Yes

8
9
99

Client doesn't know
Client refused
Data not collected

Descriptions
The date the information was
collected.
For the purposes of these Data
Standards, a chronic health
condition means a diagnosed
condition that is more than 3
months in duration and is either
not curable or has residual effects
that limit daily living and require
adaptation in function or special
assistance. Examples of chronic
health conditions include, but are
not limited to: heart disease
(including coronary heart disease,
angina, heart attack and any other
kind of heart condition or disease);
severe asthma; diabetes; arthritisrelated conditions (including
arthritis, rheumatoid arthritis,
gout, lupus, or fibromyalgia); adult
onset cognitive impairments
(including traumatic brain injury,
post-traumatic distress syndrome,
dementia, and other cognitive
related conditions); severe
headache/migraine; cancer;
chronic bronchitis; liver condition;
stroke; or emphysema.

4.8
HIV/AIDS
HIV-related information is covered by confidentiality requirements. As in other areas involving sensitive
or protected client information, information should be recorded only when a project has data
confidentiality protections that conform to the standards specified in the HMIS Final Rule, to be
published. These protections include agency policies and procedures and staff training to ensure that
HIV-related information cannot be accessed by anyone without the proper authorization.
Field

Dependency

Response Category/
Data Type

Descriptions

1 Information Date

None

[Date]

The date the information was
collected.

2 HIV/AIDS

None

A Expected to substantially
impair ability to live
independently

Field 2;
Response 1

0
1
8
9
99
0
1

No
Yes
Client doesn't know
Client refused
Data not collected
No
Yes

8
9
99

Client doesn't know
Client refused
Data not collected

(1) Substantially impedes an
individual’s ability to live
independently, and (2) of such a
nature that such ability could be
improved by more suitable
housing conditions.

4.9

Field

Mental Health Problem

Dependency

1 Information Date

None

2 Mental Health Problem

None

A Expected to be of long–
continued and indefinite
duration and
substantially impairs
ability to live
independently

Field 2;
Response 1

Response Category/
Data Type
[Date]
0
1

No
Yes

8
9
99
0
1

Client doesn't know
Client refused
Data not collected
No
Yes

8
9
99

Client doesn't know
Client refused
Data not collected

Descriptions
The date the information was
collected.
A mental health problem may
range from situational depression
to serious mental illnesses. The
dependent field is designed to
gauge the severity of the mental
health problem.

(1) Expected to be of long,
continued and indefinite
duration, (2) substantially
impedes an individual’s ability to
live independently, and (3) of
such a nature that such ability
could be improved by more
suitable housing conditions.
Select 'Yes' if the mental health
problem was a cause of
homelessness, a significant issue
for the individual, or is of a
serious nature.

4.10

Field

Substance Abuse

Dependency

1 Information Date

None

2 Substance Abuse
Problem

None

A Expected to be of long–
continued and indefinite
duration and
substantially impairs
ability to live
independently

Response Category/
Data Type
[Date]
0
1

No
Alcohol abuse

Drug abuse

Both alcohol and
drug abuse
Client doesn't know
Client refused
Data not collected
No
Yes
Client doesn't know
Client refused
Data not collected

8
9
99
0
1
8
9
99

Descriptions
The date the information was
collected.
Alcohol abuse, without drug
abuse
Drug abuse without alcohol
abuse

4.11 Domestic Violence
Rationale To indicate whether heads of household and other adults served are survivors of domestic
violence. Ascertaining whether a person is a survivor of or fleeing from domestic violence is necessary to
provide the person with the appropriate services to prevent further abuse and to treat the physical and
psychological injuries from prior abuse. Also, ascertaining that a person may be experiencing domestic
violence may be important for the safety of project staff and other clients. At the aggregate level,
knowing the size of the population of persons experiencing homelessness who have also experienced
domestic violence is critical for determining the resources needed to address the problem.
Data Collection Instruction In separate fields, indicate (1) if the client is a survivor of domestic violence,
(2) when the experience occurred, and (3) if the client is currently fleeing domestic violence.
Domestic Violence records created at project start are to reflect the information as of the date of project
start. ‘Information Date’ for those records must reflect the date of project start.
A Domestic Violence record must be created at any time during a project stay if a client's domestic
violence status changes. 'Information Date’ for those records must reflect the date of the data
collection.
If a client's domestic violence status was recorded incorrectly at project start, correct the existing
record.
Verification is not necessary unless it is specifically required for project eligibility, in which case
documentation requirements established by the funder should be followed.
Projects should be especially sensitive to the collection of domestic violence information from clients
and should implement appropriate interview protocols to protect client privacy and safety such as:
asking this question in a private location and not in the presence of a romantic partner; delaying all
entry of data about clients identified with a recent history of domestic violence; or choosing not to
disclose data about clients with a history of domestic violence to other homeless projects. Projects may
wish to consult with specialized staff with training in trauma-informed care, safety needs, or other
population-specific considerations.
If clients are providing inconsistent information (e.g. indicating that they are currently fleeing an abusive
situation but their response to 'When experience occurred' is 'One year ago or more'), clarification
should be facilitated by appropriate staff. Staff can help clients understand that the definition of a DV
experience includes "dangerous... conditions that relate to violence against the individual or a family
member," which is broader than a specific violent episode. There are situations where the act of fleeing
takes place weeks or months after a particular violent episode, but the conditions within the home
remain dangerous. With this clarification, the staff and client together can determine the best response
for 'When experience occurred.'

Data Element Fields and Responses
Field

Dependency

1 Information Date

None

2 Domestic Violence
Victim/Survivor

None

A When experience
occurred

Field 2;
Response 1

Response Category/
Data Type
[Date]
0
1

No
Yes

8
9
99
1

4
8
9
99
0
1

Client doesn't know
Client refused
Data not collected
Within the past three
months
Three to six months
ago (excluding six
months exactly)
Six months to one
year ago (excluding
one year exactly)
One year ago or more
Client doesn’t know
Client refused
Data not collected
No
Yes

8
9
99

Client doesn’t know
Client refused
Data not collected

B Currently fleeing

Field 2;
Response 1

Descriptions
The date the information was
collected.
Domestic Violence
Victim/Survivor should be
indicated as “Yes” if the person
has experienced any domestic
violence, dating violence, sexual
assault, stalking or other
dangerous or life-threatening
conditions that relate to violence
against the individual or a family
member, including a child, that
has either taken place within the
individual’s or family’s primary
nighttime residence.

Currently fleeing should be
indicated as “Yes” if the Person is
fleeing, or is attempting to flee,
the domestic violence situation
or is afraid to return to their
primary nighttime residence.

4.12 Contact
Rationale To record each contact with people experiencing homelessness by street outreach and other
service projects and to provide information on the number of contacts required to engage the client.
Data Collection Instruction Record the date and location of each interaction with a client. The first
Contact with the client will occur at the same point as Project Start Date and therefore requires a record
to be opened in the HMIS for the client. Refer to guidance in HMIS Program Manuals (PATH, CoC, ESG,
or RHY) for more details.
All street outreach projects are expected to record every contact made with each client, including when
the Project Start Date or Date of Engagement is recorded on the same day. There may or may not be a
contact made at project exit.
Contacts include activities such as a conversation between a street outreach worker and client about the
client’s well-being or needs, an office visit to discuss their housing plan, or a referral to another
community service.
Mobile HMIS data entry can be helpful for working in the field. If it is not possible, data will need to be
securely recorded and transported for entry at an office or data can be entered remotely by a colleague
by phone.
Night-by-Night shelters should only record a Contact if the interaction between the shelter personnel
and client goes beyond a basic provision of shelter services. A Contact for emergency shelter does not
include activities of daily sheltering (e.g. bed registration, request for personal care items, dinner signup, meals, etc.), nor should it be redundant with data element 4.14 Bed-Night Date.
Data Element Fields and Responses
Field

Dependency

1 Information Date
2 Staying on Streets, ES,
or SH

None
None

Response Category/
Data Type
[Date]
0
No
1
Yes

Descriptions
The date the information was collected.
A contact is defined as an interaction
between a worker and a client. Contacts
may range from simple a verbal
conversation between the street
outreach worker and the client about the
client’s well-being or needs or may be a
referral to service.

Worker unable to
determine

4.13 Date of Engagement
Rationale To record the date the client became ‘engaged’ in project services after one or more contacts
with outreach or night-by-night shelter.
Data Collection Instruction Record the date a client became engaged by a street outreach project or
night-by-night emergency shelter in the development of a plan to address their situation. Only one date
of engagement is allowed between project start and exit.
This date may be on or after the Project Start Date and if the client becomes engaged, must be on or
prior to the Project Exit Date. If the project has not developed this intensive relationship with the client
before exit, Date of Engagement should be left blank.
If the client returns after a project exit, a new Project Start Date and a new Date of Engagement is to be
established.
Reporting on data quality for street outreach projects is limited to clients with a Date of Engagement. All
Universal Data Elements and applicable Program Specific Data Elements should be reviewed for
completeness and accuracy on the Date of Engagement.
Refer to guidance in HMIS Program Manuals (PATH, CoC, ESG, or RHY) for more details.
Data Element Fields and Responses
Field

Dependency

1 Date of Engagement

None

Response Category/
Data Type
1
Date of
Engagement

Descriptions
The date on which an interactive client
relationship results in a deliberate client
assessment or beginning of a case plan.

4.14 Bed-Night Date
Rationale To determine each bed-night utilized by a client in a night-by-night shelter.
Data Collection Instruction A Bed Night Date record indicates that the client has utilized a bed in a
night-by-night shelter on that date.
Use the methodology built into the HMIS system to record the date of each night a client stays in a bed.
This may be a manual date entry, scan card system, check off, etc.
There must be a record of a bed night on the Project Start Date into a night-by-night shelter; any
additional bed night dates must be after the Project Start Date and before the Project Exit Date.
Data Element Fields and Responses
Field

Dependency

1 Bed-night
Date

None

Response Category/
Data Type
1
Bed-night Date

Descriptions
A date on which the client has utilized a bed in
a night-by-night shelter.

4.18 Housing Assessment Disposition
Rationale To track client disposition following a brief assessment of critical housing needs, such as at a
prevention project. This data element may be used as part of a coordinated assessment system if
appropriate for the CoC's system.
The disposition response categories represent the different types of continuum projects or other
community assistance to which a client may be referred upon presenting to a coordinated assessment
project or related point of contact with a request for assistance to address a housing a crisis.
Data Collection Instruction Indicate the appropriate disposition of the client following a housing crisis
assessment once at or before project exit.
The Housing Assessment Disposition element is only required for projects that are doing coordinated
assessments as part of a CoC's coordinated entry system, to capture information and efforts made to
house the client for planning purposes. This may include a Coordinated Entry project in addition to other
project types (e.g. Homelessness Prevention, Services Only, Day Shelter or others), depending on the
particular setup in each CoC.
Data Element Fields and Responses
Field

Dependency

1 Assessment
Disposition

None

A Other
Assessment
Disposition

Field 1;
Response 14

Response Category/
Data Type
1
Referred to emergency shelter/safe haven
2
Referred to transitional housing
3
Referred to rapid re-housing
4
Referred to permanent supportive housing
5
Referred to homelessness prevention
6
Referred to street outreach
7
Referred to other continuum project type
8
Referred to a homelessness diversion
program
9
Unable to refer/accept within continuum;
ineligible for continuum projects
10 Unable to refer/accept within continuum;
continuum services unavailable
11 Referred to other community project (noncontinuum)
12 Applicant declined referral/acceptance
13 Applicant terminated assessment prior to
completion
14 Other/specify
1
Please specify

Descriptions

APPENDIX A. FEDERAL PARTNER PROGRAM COMPONENTS: ASSOCIATED HMIS PROJECT TYPES AND FUNDING SOURCES
U.S. Department of Housing and Urban Development (HUD)

Grant/Program
Continuum of Care for the
Homeless (CoC)

Legacy
Emergency Solutions
Grants (ESG)

HUD/VASH (H/V) and
HUD/VASH-OTH
(H/V-OTH)
Rural Housing Stability
Assistance Program (RHSP)

Component/Activity
Homelessness Prevention (High
Performing Communities Only)
Permanent Housing: Permanent
Supportive Housing
Permanent Housing: Rapid Re-housing
Supportive Services Only
Transitional Housing
Youth Homeless Demonstration
Program (YHDP)
Safe Haven
Single Room Occupancy - 20-year use
requirement
Emergency Shelter (operating and/or
essential services)
Homelessness Prevention
Rapid Re-Housing
Street Outreach
HUD/VASH
HUD/VASH-OTH
Rural Assistance (RA)

HMIS Project Type (2.4)
12 Homelessness Prevention
3

PH - Permanent Supportive Housing
(disability required for entry)
13 PH - Rapid Re-Housing
Refer to CoC Program HMIS
Manual
2 Transitional Housing
Determination based on funding
opportunity
8 Safe Haven
9 PH – Housing Only
1
12
13
4
3

Emergency Shelter

Homelessness Prevention
PH - Rapid Re-Housing
Street Outreach
PH - Permanent Supportive Housing
(disability required for entry)
3 PH - Permanent Supportive Housing
(disability required for entry)
Pending Funding Availability

Federal Partner Funding Source (2.6)
1 HUD: CoC – Homelessness Prevention
(High Performing Communities Only)
2 HUD: CoC – Permanent Supportive
Housing
3 HUD: CoC – Rapid Re-Housing
4 HUD: CoC – Supportive Services Only
5
43
6
7
8

HUD: CoC – Transitional Housing
HUD: CoC – Youth Homeless
Demonstration Program (YHDP)
HUD: CoC – Safe Haven
HUD: CoC – Single Room Occupancy

9
10
11
20

HUD: ESG – Emergency Shelter
(operating and/or essential services)
HUD: ESG – Homelessness Prevention
HUD: ESG – Rapid Rehousing
HUD: ESG – Street Outreach
HUD:HUD/VASH

HUD:HUD/VASH

HUD: Rural Housing Stability Assistance
Program

Grant/Program
Housing Opportunities for
Persons with AIDS
(HOPWA)

Component/Activity
Hotel/Motel
Housing Information
Permanent Housing TBRA
Permanent Housing Facility Based
Permanent Housing Placement (PHP)
Short Term Rent, Mortgage, Utility
Assistance (STRMU)
Short Term Housing

HMIS Project Type (2.4)
1 Emergency Shelter
6 Services Only
3 PH - Permanent Supportive Housing
(disability required for entry)
3 PH - Permanent Supportive Housing
(disability required for entry)
6 Services Only
12

Homelessness Prevention

Emergency Shelter

Transitional Housing (TH)

Transitional Housing

Supportive Services Only not in
conjunction with housing (SSO)

Services Only

Federal Partner Funding Source (2.6)
13 HUD: HOPWA – Hotel/Motel Vouchers
14 HUD: HOPWA – Housing Information
15 HUD: HOPWA – Permanent Housing
(facility based or TBRA)
15 HUD: HOPWA – Permanent Housing
(facility based or TBRA)
16 HUD: HOPWA – Permanent Housing
Placement
17 HUD: HOPWA – Short-Term Rent,
Mortgage, Utility assistance
18 HUD: HOPWA – Short-Term Supportive
Facility
19 HUD: HOPWA – Transitional Housing
(facility based or TBRA)
Select the appropriate funding source from
the above list

U.S. Department of Housing and Urban Development (HUD) and U.S. Department of Justice (DOJ)

Grant/Program
Pay for Success (PFS)

Component/Activity
Permanent Housing

Public and Indian Housing
(PIH)

Public Housing and Voucher Programs

HMIS Project Type (2.4)
10 PH – Housing with Services (no
disability required for entry)
9 PH – Housing Only

Substance Abuse and Mental Health Services Administration (SAMHSA)

Grant/Program
Projects for Assistance in
Transition from
Homelessness
(PATH)

Component/Activity
Street Outreach (Persons who generally
reside in a place not meant for human
habitation (e.g. streets, abandoned
buildings, etc.)
Supportive Services (Persons who
generally reside in a place meant for
human habitation, or who are at risk of
homelessness)

Federal Partner Funding Source (2.6)
35 HUD: Pay for Success
36

HUD: Public and Indian Housing (PIH)
Programs

HMIS Project Type (2.4)
4
Street Outreach

Federal Partner Funding Source (2.6)
21 HHS:PATH – Street Outreach &
Supportive Services Only

Services Only

HHS:PATH – Street Outreach &
Supportive Services Only

U.S. Department of Health and Human Services (HHS) Administration for Children and Families (ACYF)
Family and Youth Services Bureau (FYSB)

Grant/Program
Runaway and Homeless
Youth (RHY)

Component/Activity
Basic Center Project (which provides
shelter)
Basic Center Project (which also
provides preventive services instead of
or prior to shelter)
Maternal Group Home

HMIS Project Type (2.4)
1 Emergency Shelter

Transitional Housing

Transitional Living Program
Street Outreach Program
RHY Demonstration

2 Transitional Housing
4 Street Outreach
Determination based on funding
opportunity

24
25
26

Component/Activity
HCHV CRS: EH
Community Contract Safe Haven
Program
Transitional Residence

HMIS Project Type (2.4)
1
Emergency Shelter
8
Safe Haven
2

Transitional Housing

SSVF: RRH

PH - Rapid Re-Housing

SSVF: Homelessness Prevention

Homelessness Prevention

GPD: Bridge Housing
GPD: Low Demand
GPD: Hospital to Housing

2
8
2

Transitional Housing
Safe Haven
Transitional Housing

GPD: Clinical Treatment

Transitional Housing

GPD: Service Intensive Transitional
Housing
GPD: Transition in Place

Transitional Housing

PH – Housing Only

Federal Partner Funding Source (2.6)
27 VA: CRS Contract Residential Services
30 VA: Community Contract Safe Haven
Program
32 VA: Compensated Work Therapy
Transitional Residence
33 VA: Supportive Services for Veteran
Families
33 VA: Supportive Services for Veteran
Families
37 VA: Grant Per Diem – Bridge Housing
38 VA: Grant Per Diem – Low Demand
39 VA: Grant Per Diem – Hospital to
Housing
40 VA: Grant Per Diem – Clinical
Treatment
41 VA: Grant Per Diem – Service Intensive
Transitional Housing
42 VA: Grant Per Diem – Transition in
Place

U.S. Department of Veteran Affairs (VA)

Grant/Program
Health Care for Homeless
Veterans (HCHV)
VA Compensated Work
Therapy
Supportive Services for
Veteran Families (SSVF)

VA Funded Transitional
Housing

12
2

Homelessness Prevention

Federal Partner Funding Source (2.6)
22 HHS:RHY – Basic Center Program
(prevention and shelter)
22 HHS:RHY – Basic Center Program
(prevention and shelter)
HHS:RHY – Maternity Group Home for
Pregnant and Parenting Youth
HHS:RHY – Transitional Living Program
HHS:RHY – Street Outreach Project
HHS:RHY – Demonstration Project

APPENDIX B. DATA ELEMENT COLLECTION SUMMARY
Data Element
All
Clients

Data Collected About
HoH
HoH and
Adult
Only Other Adults Clients Only

Record
Creation

When the Data Are Collected
Project
At
At
Annual
Start
Occurrence Update Assessment

At
Exit

3.1

Name

3.2

3.3

Social Security
Number
Date of Birth

3.4

Race

3.5

Ethnicity

3.6

Gender

3.7

Veteran Status

3.8

Disabling Condition

3.10

Project Start Date

3.11

Project Exit Date

3.12

Destination

3.15

Relationship to Head
of Household
Client Location

3.16

X
X

X (at time the
client’s
location
changes
from one
CoC to
another, if
applicable)

Data Element
All
Clients

Data Collected About
HoH
HoH and
Adult
Only Other Adults Clients Only

Record
Creation

When the Data Are Collected
Project
At
At
Annual
Start
Occurrence Update Assessment

At
Exit

3.20

Housing Move-In Date

3.917

Living Situation

4.2

Income and Sources

4.3

Non-Cash Benefits

4.4

Health Insurance

4.5

Physical Disability

4.6

Developmental
Disability
Chronic Health
Condition
HIV/AIDS

4.10

Mental Health
Problem
Substance Abuse

4.11

Domestic Violence

4.12

Contact

4.13

Date of Engagement

4.14

Bed Night Date

4.18

Housing Assessment
Disposition

4.7
4.8
4.9

X (at time of
move-in to
PH, if
applicable)

X (at time each
of contact)
X (at point of
engagement)
X (as provided)

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.6
Linearized                      : Yes
Author                          : U.S. Department of Housing and Urban Development
Company                         : Abt Associates Inc.
Create Date                     : 2018:04:13 11:45:24-04:00
Keywords                        : HMIS;, Data, Standards;, Data, Collection;, Data, Elements
Modify Date                     : 2019:02:22 16:00:22-05:00
Source Modified                 : D:20180413151939
Has XFA                         : No
Language                        : EN-US
Tagged PDF                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.6-c016 91.163616, 2018/10/29-16:58:49
Metadata Date                   : 2019:02:22 16:00:22-05:00
Creator Tool                    : Acrobat PDFMaker 15 for Word
Document ID                     : uuid:ea1c3c6c-4582-466e-9afb-76459503c42e
Instance ID                     : uuid:47cdad3d-3129-fc4f-a922-8c3e76cef6d7
Format                          : application/pdf
Creator                         : U.S. Department of Housing and Urban Development
Title                           : 2017 HMIS Data Standards Manual v1.3 - April 2018
Description                     : 2017 HMIS Data Standards Data Collection Manual
Subject                         : HMIS, Data Standards, Data Collection, Data Elements
Producer                        : Adobe PDF Library 15.0
Marked                          : False
Page Layout                     : OneColumn
Page Count                      : 91

EXIF Metadata provided by EXIF.tools

2017 HMIS Data Standards Manual V1.3 April 2018

HMIS-Data-Standards-Manual

Navigation menu

Versions of this User Manual:

Views

Navigation