RHY-HMIS: Street Outreach Program (Contact)

FY 2024 HMIS
Data Standards
Manual
A GUIDE FOR HMIS END USERS AND HMIS
LEADS/SYSTEM ADMINISTRATORS

U.S. Department of Housing and Urban
Development
VERSION 1.7
RELEASED: MAY 2023
UPDATED: APRIL 2025

Contents
REVISION HISTORY .......................................................................................................................................... 9
INTRODUCTION TO THE HMIS DATA STANDARDS ................................................................................. 14
HMIS DATA STANDARDS OVERVIEW .....................................................................................................................14
PERSON CENTERED APPROACH TO HMIS DATA COLLECTION .............................................................................14
HMIS IMPLEMENTATION .........................................................................................................................................14
HMIS DOCUMENTS & RESOURCES........................................................................................................................15
HMIS FEDERAL PARTNER PROGRAM MANUALS ...................................................................................................16
HMIS DATA STANDARDS TERMS AND CONCEPTS.................................................................................................17
DATA ELEMENT STRUCTURE ..................................................................................................................................18
PROJECT DESCRIPTOR DATA ELEMENTS ............................................................................................... 21
HMIS PROJECT SETUP GUIDANCE ........................................................................................................................22
MULTIPLE PROJECT SETUP ....................................................................................................................................23
PROJECTS THAT OPERATE IN MULTIPLE COCS .....................................................................................................23
2.01 ORGANIZATION INFORMATION ........................................................................................................................24
Rationale ...........................................................................................................................................................24
Project Setup Instruction .................................................................................................................................24
Response Descriptions ...................................................................................................................................25
2.02 PROJECT INFORMATION .................................................................................................................................25
Rationale ...........................................................................................................................................................25
Project Setup Instruction .....................................................................................................................................26
Project Setup Considerations .........................................................................................................................27
Response Descriptions ...................................................................................................................................29
2.03 CONTINUUM OF CARE INFORMATION .............................................................................................................33
Rationale ...........................................................................................................................................................33
Project Setup Instruction .................................................................................................................................33
Response Descriptions ...................................................................................................................................34
2.06 FUNDING SOURCES ........................................................................................................................................35
Rationale ...........................................................................................................................................................35
Project Setup Instruction .................................................................................................................................35
Response Descriptions ...................................................................................................................................37
2.07 BED AND UNIT INVENTORY INFORMATION......................................................................................................39
Rationale ...........................................................................................................................................................39
Project Setup Instruction .................................................................................................................................39
Response Descriptions ...................................................................................................................................43
2.08 HMIS PARTICIPATION STATUS ......................................................................................................................44
Rationale ...........................................................................................................................................................44
Project setup Instruction ..................................................................................................................................45
Response Descriptions ...................................................................................................................................46
2.09 COORDINATED ENTRY PARTICIPATION STATUS ............................................................................................46
Rationale ...........................................................................................................................................................46
Project Setup Instruction .................................................................................................................................47
Response Descriptions ...................................................................................................................................48
UNIVERSAL DATA ELEMENTS ..................................................................................................................... 49

1

GENERAL DATA COLLECTION GUIDANCE ...............................................................................................................49
USES AND DISCLOSURES OF CLIENT DATA............................................................................................................50
3.01 NAME ..............................................................................................................................................................50
Rationale ...........................................................................................................................................................50
Data Collection Instruction ..............................................................................................................................50
Response Descriptions ...................................................................................................................................51
3.02 SOCIAL SECURITY NUMBER ...........................................................................................................................52
Rationale ...........................................................................................................................................................52
Data Collection Instruction ..............................................................................................................................52
Response Descriptions ...................................................................................................................................53
3.03 DATE OF BIRTH ...............................................................................................................................................53
Rationale ...........................................................................................................................................................53
Data Collection Instruction ..............................................................................................................................53
Response Descriptions ...................................................................................................................................54
3.04 RACE AND ETHNICITY .....................................................................................................................................54
Rationale ...........................................................................................................................................................54
Data Collection Instruction ..............................................................................................................................55
Response Descriptions ...................................................................................................................................56
3.07 VETERAN STATUS...........................................................................................................................................57
Rationale ...........................................................................................................................................................57
Data Collection Instruction ..............................................................................................................................57
Response Descriptions ...................................................................................................................................58
3.08 DISABLING CONDITION ...................................................................................................................................58
Rationale ...........................................................................................................................................................58
Data Collection Instruction ..............................................................................................................................58
Response Descriptions ...................................................................................................................................59
3.10 PROJECT START DATE ...................................................................................................................................60
Rationale ...........................................................................................................................................................60
Data Collection Instruction ..............................................................................................................................60
Response Descriptions ...................................................................................................................................61
3.11 PROJECT EXIT DATE ......................................................................................................................................61
Rationale ...........................................................................................................................................................61
Data Collection Instruction ..............................................................................................................................61
Auto-exits...........................................................................................................................................................62
Response Descriptions ...................................................................................................................................63
3.12 DESTINATION ..................................................................................................................................................63
Rationale ...........................................................................................................................................................63
Data Collection Instruction ..............................................................................................................................63
Response Descriptions ...................................................................................................................................65
3.15 RELATIONSHIP TO HEAD OF HOUSEHOLD......................................................................................................65
Rationale ...........................................................................................................................................................65
Data Collection Instruction ..............................................................................................................................65
Response Descriptions ...................................................................................................................................66
3.16 ENROLLMENT COC.........................................................................................................................................67
Rationale ...........................................................................................................................................................67
Data Collection Instruction ..............................................................................................................................67
Response Descriptions ...................................................................................................................................68
3.20 HOUSING MOVE IN DATE ................................................................................................................................68
Rationale ...........................................................................................................................................................68

2

Data Collection Instruction ..............................................................................................................................68
Response Descriptions ...................................................................................................................................69
3.917 PRIOR LIVING SITUATION .............................................................................................................................69
Rationale ...........................................................................................................................................................69
Data Collection Instruction ..............................................................................................................................70
Response Descriptions ...................................................................................................................................74
PROGRAM SPECIFIC DATA ELEMENTS ..................................................................................................... 76
COMMON PROGRAM SPECIFIC DATA ELEMENTS .................................................................................. 76
4.02 INCOME AND SOURCES ..................................................................................................................................76
Rationale ...........................................................................................................................................................76
Data Collection Instruction ..............................................................................................................................76
Response Descriptions ...................................................................................................................................79
4.03 NON-CASH BENEFITS.....................................................................................................................................81
Rationale ...........................................................................................................................................................81
Data Collection Instruction ..............................................................................................................................81
Response Descriptions ...................................................................................................................................83
4.04 HEALTH INSURANCE .......................................................................................................................................84
Rationale ...........................................................................................................................................................84
Data Collection Instruction ..............................................................................................................................84
Response Descriptions ...................................................................................................................................85
4.05 PHYSICAL DISABILITY .....................................................................................................................................87
Rationale ...........................................................................................................................................................87
Data Collection Instruction ..............................................................................................................................87
Response Descriptions ...................................................................................................................................88
4.06 DEVELOPMENTAL DISABILITY .........................................................................................................................89
Rationale ...........................................................................................................................................................89
Data Collection Instruction ..............................................................................................................................89
Response Descriptions ...................................................................................................................................90
4.07 CHRONIC HEALTH CONDITION .......................................................................................................................91
Rationale ...........................................................................................................................................................91
Data Collection Instruction ..............................................................................................................................91
Response Descriptions ...................................................................................................................................92
4.08 HIV/AIDS .......................................................................................................................................................94
Rationale ...........................................................................................................................................................94
Data Collection Instruction ..............................................................................................................................94
Response Descriptions ...................................................................................................................................95
4.09 MENTAL HEALTH DISORDER ..........................................................................................................................95
Rationale ...........................................................................................................................................................95
Data Collection Instruction ..............................................................................................................................96
Response Descriptions ...................................................................................................................................97
4.10 SUBSTANCE USE DISORDER ..........................................................................................................................98
Rationale ...........................................................................................................................................................98
Data Collection Instruction ..............................................................................................................................98
Response Descriptions ...................................................................................................................................99
4.11 DOMESTIC VIOLENCE ...................................................................................................................................100
Rationale .........................................................................................................................................................100
Data Collection Instruction ............................................................................................................................101

3

Response Descriptions .................................................................................................................................102
4.12 CURRENT LIVING SITUATION ........................................................................................................................103
Rationale .........................................................................................................................................................103
Data Collection Instruction ............................................................................................................................103
Response Descriptions .................................................................................................................................105
4.13 DATE OF ENGAGEMENT................................................................................................................................107
Rationale .........................................................................................................................................................107
Data Collection Instruction ............................................................................................................................107
Response Descriptions .................................................................................................................................107
4.14 BED-NIGHT DATE .........................................................................................................................................108
Rationale .........................................................................................................................................................108
Data Collection Instruction ............................................................................................................................108
Response Descriptions .................................................................................................................................108
4.19 COORDINATED ENTRY ASSESSMENT...........................................................................................................108
Rationale .........................................................................................................................................................108
Data Collection Instruction ............................................................................................................................109
Response Descriptions .................................................................................................................................109
4.20 COORDINATED ENTRY EVENT ......................................................................................................................110
Rationale .........................................................................................................................................................110
Data Collection Instruction ............................................................................................................................110
Response Descriptions .................................................................................................................................111
FEDERAL PARTNER PROGRAM SPECIFIC DATA ELEMENTS ............................................................ 114
COC .................................................................................................................................................................. 114
C2 MOVING ON ASSISTANCE PROVIDED .............................................................................................................114
Rationale .........................................................................................................................................................114
Data Collection Instruction ............................................................................................................................114
Response Descriptions .................................................................................................................................115
C3 YOUTH EDUCATION STATUS ...........................................................................................................................115
Rationale .........................................................................................................................................................115
Data Collection Instruction ............................................................................................................................115
Response Descriptions .................................................................................................................................116
C4 TRANSLATION ASSISTANCE NEEDED..............................................................................................................117
Rationale .........................................................................................................................................................117
Data Collection Instruction ............................................................................................................................117
Response Descriptions .................................................................................................................................117
HOPWA ............................................................................................................................................................ 117
W1 SERVICES PROVIDED – HOPWA ..................................................................................................................117
Rationale .........................................................................................................................................................117
Data Collection Instruction ............................................................................................................................118
Response Descriptions .................................................................................................................................118
W2 FINANCIAL ASSISTANCE – HOPWA ..............................................................................................................118
Rationale .........................................................................................................................................................118
Data Collection Instruction ............................................................................................................................119
Response Descriptions .................................................................................................................................119
W3 MEDICAL ASSISTANCE ...................................................................................................................................119
Rationale .........................................................................................................................................................119

4

Data Collection Instruction ............................................................................................................................119
Response Descriptions .................................................................................................................................120
W4 T-CELL (CD4) AND VIRAL LOAD ....................................................................................................................121
Rationale .........................................................................................................................................................121
Data Collection Instruction ............................................................................................................................121
Response Descriptions .................................................................................................................................121
W5 HOUSING ASSESSMENT AT EXIT ....................................................................................................................122
Rationale .........................................................................................................................................................122
Data Collection Instruction ............................................................................................................................122
Response Descriptions .................................................................................................................................122
W6 PRESCRIBED ANTI-RETROVIRAL ....................................................................................................................123
Rationale .........................................................................................................................................................123
Data Collection Instruction ............................................................................................................................123
Response Descriptions .................................................................................................................................124
PATH ................................................................................................................................................................ 124
P1 SERVICES PROVIDED – PATH FUNDED .........................................................................................................124
Rationale .........................................................................................................................................................124
Data Collection Instruction ............................................................................................................................124
Response Descriptions .................................................................................................................................124
P2 REFERRALS PROVIDED – PATH .....................................................................................................................125
Rationale .........................................................................................................................................................125
Data Collection Instruction ............................................................................................................................125
Response Descriptions .................................................................................................................................125
P3 PATH STATUS ................................................................................................................................................126
Rationale .........................................................................................................................................................126
Data Collection Instruction ............................................................................................................................126
Response Descriptions .................................................................................................................................126
P4 CONNECTION WITH SOAR ..............................................................................................................................126
Rationale .........................................................................................................................................................126
Data Collection Instruction ............................................................................................................................126
Response Descriptions .................................................................................................................................127
RHY .................................................................................................................................................................. 127
R1 REFERRAL SOURCE ........................................................................................................................................127
Rationale .........................................................................................................................................................127
Data Collection Instruction ............................................................................................................................127
Response Descriptions .................................................................................................................................127
R2 RHY – BCP STATUS ......................................................................................................................................128
Rationale .........................................................................................................................................................128
Data Collection Instruction ............................................................................................................................128
Response Descriptions .................................................................................................................................129
R4 LAST GRADE COMPLETED ..............................................................................................................................129
Rationale .........................................................................................................................................................129
Data Collection Instruction ............................................................................................................................129
Response Descriptions .................................................................................................................................130
R5 SCHOOL STATUS .............................................................................................................................................130
Rationale .........................................................................................................................................................130
Data Collection Instruction ............................................................................................................................131

5

Response Descriptions .................................................................................................................................131
R6 EMPLOYMENT STATUS ....................................................................................................................................131
Rationale .........................................................................................................................................................131
Data Collection Instruction ............................................................................................................................131
Response Descriptions .................................................................................................................................132
R7 GENERAL HEALTH STATUS .............................................................................................................................132
Rationale .........................................................................................................................................................132
Data Collection Instruction ............................................................................................................................132
Response Descriptions .................................................................................................................................133
R8 DENTAL HEALTH STATUS................................................................................................................................133
Rationale .........................................................................................................................................................133
Data Collection Instruction ............................................................................................................................133
Response Descriptions .................................................................................................................................133
R9 MENTAL HEALTH STATUS ...............................................................................................................................134
Rationale .........................................................................................................................................................134
Data Collection Instruction ............................................................................................................................134
Response Descriptions .................................................................................................................................134
R10 PREGNANCY STATUS ....................................................................................................................................134
Rationale .........................................................................................................................................................134
Data Collection Instruction ............................................................................................................................134
Response Descriptions .................................................................................................................................135
R11 FORMERLY A WARD OF CHILD WELFARE/FOSTER CARE AGENCY .............................................................135
Rationale .........................................................................................................................................................135
Data Collection Instruction ............................................................................................................................135
Response Descriptions .................................................................................................................................135
R12 FORMERLY A WARD OF JUVENILE JUSTICE SYSTEM ...................................................................................136
Rationale .........................................................................................................................................................136
Data Collection Instruction ............................................................................................................................136
Response Descriptions .................................................................................................................................136
R13 FAMILY CRITICAL ISSUES ..............................................................................................................................136
Rationale .........................................................................................................................................................136
Data Collection Instruction ............................................................................................................................137
Response Descriptions .................................................................................................................................137
R14 RHY SERVICE CONNECTIONS ......................................................................................................................137
Rationale .........................................................................................................................................................137
Data Collection Instruction ............................................................................................................................137
Response Descriptions .................................................................................................................................139
R15 COMMERCIAL SEXUAL EXPLOITATION/SEX TRAFFICKING ...........................................................................139
Rationale .........................................................................................................................................................139
Data Collection Instruction ............................................................................................................................140
Response Descriptions .................................................................................................................................140
R16 LABOR EXPLOITATION/TRAFFICKING ............................................................................................................141
Rationale .........................................................................................................................................................141
Data Collection Instruction ............................................................................................................................141
Response Descriptions .................................................................................................................................141
R17 PROJECT COMPLETION STATUS...................................................................................................................142
Rationale .........................................................................................................................................................142
Data Collection Instruction ............................................................................................................................142
Response Descriptions .................................................................................................................................142

6

R18 COUNSELING .................................................................................................................................................143
Rationale .........................................................................................................................................................143
Data Collection Instruction ............................................................................................................................143
Response Descriptions .................................................................................................................................143
R19 SAFE AND APPROPRIATE EXIT......................................................................................................................143
Rationale .........................................................................................................................................................143
Data Collection Instruction ............................................................................................................................144
Response Descriptions .................................................................................................................................144
R20 AFTERCARE PLANS .......................................................................................................................................145
Rationale .........................................................................................................................................................145
Data Collection Instruction ............................................................................................................................145
Response Descriptions .................................................................................................................................145
VA ..................................................................................................................................................................... 145
V1 VETERAN’S INFORMATION ...............................................................................................................................146
Data Collection Instruction ............................................................................................................................146
Response Descriptions .................................................................................................................................146
V2 SERVICES PROVIDED – SSVF ........................................................................................................................149
Data Collection Instruction ............................................................................................................................149
Response Descriptions .................................................................................................................................149
V3 FINANCIAL ASSISTANCE – SSVF ....................................................................................................................150
Data Collection Instruction ............................................................................................................................150
Response Descriptions .................................................................................................................................150
V4 PERCENT OF AMI (SSVF ELIGIBILITY) ...........................................................................................................151
Data Collection Instruction ............................................................................................................................151
Response Descriptions .................................................................................................................................151
V6 VAMC STATION NUMBER ...............................................................................................................................151
Data Collection Instruction ............................................................................................................................151
Response Descriptions .................................................................................................................................152
V7 HP TARGETING CRITERIA ...............................................................................................................................152
Data Collection Instruction ............................................................................................................................152
Response Descriptions .................................................................................................................................152
V8 HUD-VASH VOUCHER TRACKING .................................................................................................................155
Data Collection Instruction ............................................................................................................................155
Response Descriptions .................................................................................................................................155
V9 HUD-VASH EXIT INFORMATION ....................................................................................................................156
Data Collection Instruction ............................................................................................................................156
Response Descriptions .................................................................................................................................156
METADATA ELEMENTS ............................................................................................................................... 156
5.01 DATE CREATED ............................................................................................................................................156
5.02 DATE UPDATED ............................................................................................................................................157
5.03 DATA COLLECTION STAGE ...........................................................................................................................157
5.04 INFORMATION DATE......................................................................................................................................159
5.05 PROJECT IDENTIFIER ....................................................................................................................................159
5.06 ENROLLMENT IDENTIFIER .............................................................................................................................159
5.07 USER IDENTIFIER ..........................................................................................................................................159
5.08 PERSONAL IDENTIFIER .................................................................................................................................159
5.09 HOUSEHOLD IDENTIFIER...............................................................................................................................160

7

5.10 IMPLEMENTATION IDENTIFIER .......................................................................................................................160
APPENDIX A – LIVING SITUATION RESPONSE CATEGORIES AND DESCRIPTIONS ...................... 160
APPENDIX B ACRONYMS ............................................................................................................................ 163

8

Revision History
Version
FY 2024
V1

Revision
2.02 Project Information
• Remove “Emergency Shelter Tracking Method”
• Add “Night-by-Night” to existing emergency shelter response option
(“1”).
• Add Response “0” – “Emergency Shelter Entry Exit” response option
• Add Rapid Re-housing subtype field
• Add “RRH: Services Only” subtype to affiliation field
• Remove HMIS Participating Project field from this element, create new
element for HMIS Participation Status.
• Change “domestic violence victim” to “survivor of domestic violence” in
target population
2.06 Funding Sources
• Remove “HUD: CoC – Joint Component RRH/PSH”
• Add “HUD - ESG RUSH”
• Add “HUD: Unsheltered Special NOFO”
• Add “HUD: Rural Special NOFO”
• Remove “Rural Housing Stability Assistance Program”
2.07 Bed and Unit Inventory
• Change Project Type Applicability for RRH to only PH-Rapid Re-housing
(RRH: Housing with or without services) subtype
2.08 HMIS Participation Status
• New Element for tracking HMIS participation – removing HMIS
participation field from project information PDDE.
• Added comparable database participating
2.09 CE Participation Status
• Add PDDE to identify projects acting as “access points” and projects that
accept referrals from CE including participation status dates.
3.01 Name
• Data collection instruction change – Client may provide preferred name.
“Legal name” not required unless required by the funder.
3.02 Social Security Number
• Data Collection instruction change – HUD CoC and ESG, and SAMHSA
PATH Programs require only last four digits of SSN to be required.
3.04 Race and Ethnicity
• Combine Race and Ethnicity into single data element. (Eliminate 3.05
data element)
• Add response option for “Middle Eastern or North African” and modified
“Hispanic/Latina/e/o” response option. Added text box to provide
additional detail.
3.06 Gender
• Change Female to "Woman (Girl if child)"
• Change Male to "Man (Boy if child)"
• Change “Gender other than…” to "Non-Binary"
• Add "Culturally Specific Identity (e.g., Two-Spirit)
• Add "Different Identity" and text box to add detail

9

Version

Revision
3.07 Veteran Status
• Remove details of definition. Refer to VA Data Guide for legal definition
of “Veteran”
3.12 Destination
• Remove "or RHY Funded" from descriptor of “Host Home”
• Separate Temporary and Permanent Situations into separate headers
• Re-organize response options under headers
• Re-number responses by adding a standard # to the beginning of each
response number based on category (i.e., 1xx for homeless situations,
2xx for temporary situations, etc.)
• Add dependency for permanent subsidized options
3.16 Enrollment CoC
• Change element name to "Enrollment CoC"
• Change data collection stage to project start (only)
• Update data collection instructions
3.917 A & B
• Added in “this episode” to response “Approximate date this episode of
homelessness started” field for clarity.
• Add dependency for permanent subsidized options
4.04 Health Insurance
• Response to say "Veteran's Health Administration (VHA)
4.12 Current Living Situation
• Add dependency for permanent subsidized options
4.19 Coordinated Entry Assessment – RETIRE
4.20 Coordinated Entry Event – RETIRE
4.21 Coordinated Entry Activity – NEW
C1 Wellbeing – RETIRE
C4 Translation Assistance Needed – NEW
W1 Services Provided – HOPWA
• Remove “disorder” from Substance Use services/treatment response
W3 Medical Assistance
• Remove “Receiving Public HIV/AIDS Medical Assistance" field and
dependency responses from the element
W5 Housing Assessment at Exit
• Update response language to say "Jail/prison" and "Deceased"
R3 Sexual Orientation
• Add HUD: CoC – PH: Permanent Supportive Housing to Funder:
Program Component required to collect
R14 RHY Service Connections
• Response label change – change “mother” to "client (person who gave
birth)"
R17 Project Completion Status and R18 Counseling
• Change response labels from “Youth” to “Client”
R18 Counseling
• Field 1 changed from "Counseling received by client" to "Client received
counseling”
U1 Worst Housing Situation – RETIRE
10

Version

June 2023
v. 1.1

July 2023
V. 1.2

Revision
V1 Veteran’s Information
• Add “Space Force” response option
V2 Services Provided – SSVF
• Change “Subsidy” to “Shallow Subsidy"
V3 Financial Assistance – SSVF
• Change “Date” field to "Start Date of Financial Assistance"
• Change “Extended Shallow Subsidy – Rental Assistance” to “Shallow
Subsidy - Financial Assistance"
• Add "Landlord Incentive"
• Add "Tenant Incentive"
• Add new Field - "End Date of Financial Assistance [date field]
V4 Percent of AMI (SSVF Eligibility)
• Change response as follows:
o 30% or less
o 31% to 50%
o 51% to 80%
o 81% or greater
V5 Last Permanent Address – RETIRED
V7 HP Targeting Criteria – language changes throughout
• Change dependency C to "Past experience of homelessness…"
• Change dependency D to "Head of Household is not a current
leaseholder/renter of unit"
• Change dependency E to "Head of household (HOH) never been a
leaseholder/renter of unit"
• Change dependency N to "Single parent/guardian household with minor
child(ren)"
Change “Client Refused” to “Client prefers not to answer”
Update Living Situation Option List in Appendix A
Add Appendix B – Acronyms
Remove redundancies throughout document. Refer to HMIS Data Dictionary for
technical HMIS Data Standards Information
Correct 2.09 project setup instructions where the incorrect field name was
referenced.
Add missing “Rental Subsidy Type” field to 3.917
Add clarity to 4.12 data collection instruction that HUD: CoC – SSO – CE and
HUD SSO – Street Outreach are required to collect the element.
Minor formatting and typo corrections.
Remove 4.21 CE Activity
Reinstate previously removed 4.19 Coordinated Entry Assessment and 4.20
Coordinated Entry Event data elements.
Made updates to 4.20 response descriptions to reflect that location of referral
should be identified from a drop-down list generated by project IDs identified in
2.02 Project Information and projects receiving referrals from CE in the 2.09 CE
Participation Status element. Also removed “Emergency Housing Voucher”
response option.
2.08 HMIS Participation Status - Add guidance for how to handle client data
when a project stops participating in HMIS
3.20 Housing Move-In Date – added clarification that a Housing Move-in Data
should be recorded in any PH project in HMIS, not just PSH and RRH.
11

Version
August
2023
V. 1.3

November
2023
V1.4

February
2024
V1.5
June 2024
V1.6

Revision
Appendix A – replaced “Emergency Housing Voucher” response option with
“Housing Stability Voucher”
2.06 Funding Sources – Response option that read, “HUD: HOPWA –
Permanent Housing Placement (facility based or TBRA)” was corrected to read:
“HUD: HOPWA – Permanent Housing (facility based or TBRA)”
2.07 Bed and Unit Inventory – added clarification that RRH – Services Only
sub-type projects are not required to record Bed and Unit information.
4.19 Coordinated Entry Assessment - remove Program-Component: VA: SSVF
– Rapid Resolution only
C2 Moving On Assistance updated data collected about to only “Head of
Household”
Add HOPWA to applicable Funder Program: Component to C4 Translation
Assistance
Change element 5.10 name to Implementation Identifier (remove “HMIS”)
C4 Translation Assistance Needed – label change to remove “(s)” from
“Preferred language” to clarify that only a single preferred language should be
selected.
C4 Translation Assistance Needed - Fixed formatting to show that “HUD:
HOPWA – Collection required for all components” for this element.
Formatting and label edits throughout to align with HMIS Data Dictionary
Correction to Program/Component applicability for Special NOFO Unsheltered
and Rural projects in 4.12 Current Living Situation. Collection of this element is
required for Special NOFO Unsheltered and Rural SSO – Street Outreach, SSO
– Coordinated Entry projects.
Correction to response description for “yes” in 2.09 Coordinated Entry
Participation Status and added additional detail.
Correction to field label in 4.11 Domestic Violence. Changed dependency that
read, “If Yes for “Survivor of Domestic Violence Victim/Survivor” Are you
currently fleeing?” to “If Yes for “Survivor of Domestic Violence” Are you
currently fleeing?”
Add SSO – Supportive Services Only to Project Type Applicability for R6
Employment Status, since R6 is required to be collected for all GPD Case
Management projects.
Minor formatting and typo corrections.
Added descriptions to Program Specific Data Elements and Common Program
Specific Data Elements sections.
Universal Data Elements - Added missing “3.917 Prior Living Situation” to table
3.917 Prior Living Situation
Revised Flow Charts for better resolution and typo corrections.
Added “other” project type applicability for collection requirements for projects
funded by HUD: Pay for Success (PFS) that do not provide permanent housing
in 3.20 Housing Move-in Date.
Updated Common Data Element data collection instructions for projects funded
by PFS.

12

Version
April 2025
V1.7

Revision
The Person Centered Approaches to HMIS Data Collection; Emergency Shelter
under 2.0 Project Information; Universal Data Elements table; 3.01 Name; 3.02
Social Security Number; and 3.04 Race and Ethnicity sections are updated to
be compliant with the current Administration’s Executive Orders.
Added clarification that "Provide additional specificity the client would like the
share about their race or ethnicity." is an optional field in 3.04 Race and
Ethnicity.
For the following three data elements, the software updates will be required to
be completed during the FY2026 HMIS Data Standards implementation.
• 3.06 Gender – RETIRE to be compliant with the current Administration’s
Executive Orders.
• R3 Sexual Orientation – RETIRE to be compliant with the current
Administration’s Executive Orders.
• V7 HP Targeting Criteria – updated data collection for household size
and population type to be compliant with the current Administration’s
Executive Orders.

13

Introduction to the HMIS Data Standards
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 implemented data system used to record and analyze client, service,
and housing data for individuals and families who are experiencing homelessness or at-risk of
homelessness.
The U.S. Department of Housing and Urban Development (HUD) through the Office of Special
Needs Assistance Programs (SNAPS) partners with other federal agencies to establish the
requirements for HMIS to ensure that there is a 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 HIVAIDS 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 (VA) 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. HUD, in collaboration with its federal partners, has continued to update
the HMIS Data Standards regularly thereafter. Each updated document supersedes the
previously released HMIS Data Standards. A complete historical archive of previous data
standards can be found on the HUD Exchange Data Standards page.

Person Centered Approach to HMIS Data Collection

The HMIS Data Standards Manual is a guide to collecting quantitative data. To fully understand
the personal stories behind that data and ultimately improve system effectiveness and
experiences for those navigating the system, qualitative data must also be collected.
Communities are encouraged to work with people with lived homeless experience to determine
what qualitative data would improve how we serve and expand the public understanding of
homelessness.
Data collection, data-informed processes, and the homelessness system design planning must
always be approached with empathy and with consideration for how you would want to be
treated if you were experiencing homelessness.

HMIS Implementation

An HMIS must be able to collect all the data elements defined within these HMIS Data
Standards, support the system logic identified, and ensure that the visibility of data elements is
appropriate to the Project Type and Funding Sources for any given project.
Victim Service Providers (VSP) are prohibited from recording survivor information in an HMIS as
described in the Violence Against Women Act (VAWA). Instead VSPs are required by HUD to
use a comparable database which is defined as relational database that meets all HMIS Data
Standards and the minimum standards of HMIS privacy and security requirements, including
HUD’s most recent reporting standards and comma separated value (CSV) format
specifications.

14

There are many software products on the market that communities across the country have
chosen to use as their HMIS or comparable database. HUD does not certify or endorse any
specific HMIS or comparable database software product. Each product has unique features and
was built to meet the different data collection needs of each community. CoCs and HMIS leads
are responsible for verifying that any software they use meets their needs, including federal
reporting requirements. Each software provider 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, add response categories, or maintain historical
data element collection beyond what is specified in the Data Standards if 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 community
needs.

HMIS Documents & Resources

There are a variety of documents that comprise the suite of HMIS Data Standards 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 any supplemental instructional materials supplied by vendor.
•

FY2024 HMIS Data Standards Manual

•

FY2024 HMIS Data Standards Dictionary

•

Data Exchange Resources:
•

FY2024 CSV Programming Specifications

•

FY2024 XML Programming Specifications

•

FY2024 Data Logic Model

15

HMIS Federal Partner Program Manuals

These manuals contain specific and detailed information on project setup for each of the federal
partner programs 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.
Manual
Name
CoC
Program
HMIS Manual

Federal partner
U.S. Department of Housing and
Urban Development - Office of
Special Needs Assistance
Programs

Program (s)
All Continuum of Care (CoC) Program
component projects.

CoC Program Information link
YHDP HMIS
Manual

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

All Youth Homelessness
Demonstration Program (YHDP)
projects

YHDP Information Link
ESG
Program
HMIS Manual

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

All Emergency Solutions Grant (ESG)
Program component projects.

ESG Program Information link
HOPWA
Program
HMIS Manual

U.S. Department of Housing and
Urban Development - Office of
HIV/AIDS Housing

All Housing Opportunities for Persons
with AIDS (HOPWA) program
component projects.

HOPWA Program Information link
PATH
Program
HMIS Manual

U.S. Department of Health and
Human Services - Substance
Abuse and Mental Health Services
Administration

All Projects for Assistance in
Transition from Homelessness
(PATH) component projects.

PATH Program Information link
RHY
Program
HMIS Manual

U.S. Department of Health and
Human Services - Administration
for Children and Families - Family
and Youth Services Bureau

All Runaway and Homeless Youth
program component projects.

RHY Program Information Link
VA Program
HMIS Manual

Department of Veterans Affairs
VA Program information link

Supportive Services for Veteran
Families (SSVF), Grant-Per-Diem
(GPD), and Healthcare for Homeless
Veterans (HCHV).
16

VASH
Program
HMIS Manual

U.S. Department of Housing and
Urban Development - VASH and
Department of Veterans Affairs

Veterans Affairs Supportive Housing
(VASH) program.

VASH Program link

HMIS Data Standards Terms and Concepts

The HMIS Data Standards use many acronyms, most of which are defined throughout the
document; however, a comprehensive list of acronyms and their meanings can also be found in
Appendix B. Below are some of the most common and core terms used throughout the HMIS
Data Standards documentation.
Continuum of Care (CoC) is used in multiple ways throughout the Data Standards:
•

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 assistance
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, law enforcement,
and organizations that serve people who have previously and are currently experiencing
homelessness to the extent that these groups are represented within the geographic
area and are available to participate.

•

CoC Program refers to the HUD funding source which provides housing and/or service
grant dollars.

•

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 individuals and families experiencing homelessness or at-risk of
experiencing homelessness and is identified by the Continuum as part of its service
system. For example, a project funded by the HUD's CoC Program may be referred to
as a “CoC Program-funded continuum project”.

HMIS End User means an individual who enters or uses 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 CoC
Interim Rule (24 CFR Part 578) 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: providing agency access to HMIS and managing appropriate
use, supporting users through connection to, or direct provision of, user training, and overseeing
system setup.
Project and Program are terms used to mean different things across the federal agencies. 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 a project refers to a
distinct unit of an organization as set up in the HMIS (e.g., Rapid Re-Housing).
17

HMIS vendor means a contractor who provides materials or services for the operation of
an HMIS. An HMIS vendor includes an HMIS software provider, web server host, or
data warehouse provider.

Data Element Structure

Every data element required by HUD and the Federal partners to be stored within an HMIS is
specified in this document. Each Project Descriptor Data Element, Universal Data Element, and
Common Program Specific Data Element in this document includes the following information:
Rationale: Provides a basic explanation for data collection for the element and describes how
the data are used in national or local reporting.
Data Collection Instruction: provides instructions for data collection and entry. Each data
element includes a brief explanation of who the data is collected about, Funder: Component Program requiring the data to be collected, project types required to collect this data, and the
Data Collection Stage. Information regarding project setup and data collection instructions
specific to an HMIS federal partner program can be found in the HMIS federal partner program
manuals.
Header
Data Collected About

Funder: Component Program
Project Type Applicability
Collection Point

Instruction
The universe of client(s) for whom an element response is
required (e.g., all clients, heads of household, adults).
Data may be collected about a wide group (e.g., all
household members) but may be further limited in data
reporting specifications.
The federal department, the program, and the program
component which requires the collection of the element. If
a program component is not listed, it does not require
collection of the element.
The HMIS project type(s) required to collect and report the
data element, as identified in element 2.02 Project
Information.
The point(s) at which the data must be able to be collected
in an HMIS. Additional guidance about collection points
can be found in 5.03 Data Collection Stage
Record creation – Indicates the element is required to be
collected when the client record is created. Elements
collected at record creation should have one and only
one value for each client in an HMIS.
Project start – Indicates the element is required to be
collected at every project start. Information must be
accurate as of the ‘Project Start Date.’ There should be
one and only one record with a Data Collection Stage of
project start for each relevant data element for any given
project start.
Occurrence Point/Update – Indicates the element may
be collected and entered at any point during a project
18

Header

Instruction
stay to track changes over time or document the
occurrence of events (e.g., a service is provided). These
types of records must be able to be entered at any point
during the project stay. Some data elements are
collected once per project stay, but it may fall at any
point during the project stay.
Annual assessment– Data elements required for
collection at annual assessment must be entered with an
‘Information Date’ of no more than 30 days before or
after the anniversary of the Head of Household’s ‘Project
Start Date’, regardless of the date of the most recent
‘update’ or any other ‘annual assessment’. Information
must be accurate as of the ‘Information Date.’ The Data
Collection Stage may not be inferred from the
Information Date, although the field must have an
Information Date recorded with it. To be considered
reportable to HUD as an annual assessment, data must
be stored with a Data Collection Stage of ‘Annual
Assessment’. The Annual Assessment must include
updating both the Head of Household’s record and any
other household members at the same time.
Project exit – Indicates the element is required to be
collected at every project exit. Elements collected at
project exit must have an ‘Information Date’ that matches
the client’s ‘Project Exit Date’. Information must be
accurate as of the ‘Project Exit Date’. When a data
element with multiple collection points is collected at
project exit, it must be stored with a Data Collection
Stage of ‘project exit’. There should be one and only one
record with a Data Collection Stage of ‘project exit’ for
each relevant data element for any given project exit.
Post exit– Indicates the element may be collected after
project exit for a period of no longer than 180 days.

19

Response Descriptions: identifies response options and their dependencies (if applicable),
and a description of each of the response options.
Field Name
The names
assigned to
the element
fields.

Response Category/ Data
Type
All response options
associated with the field,
and their data type (i.e.,
[date] or [text]), if specified.

Description
A brief explanation of the response option.
Most elements contain responses of “Client
doesn’t know” and “Client prefers not to
answer”. It is not the intention of HUD or the
federal partners that clients be denied
assistance if they prefer not to 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. Unless otherwise specified in the
element, the descriptions below of “Client
doesn’t know”, “Client prefers not to answer”,
and data not collected are applicable in each
element.
“Client doesn’t know” – means that the client
does not know the information.
“Client prefers not to answer” – means the
client knows the information but does not want
to provide the information to record in HMIS.
“Data not collected” – means the worker did
not record the information. This may be
because the client was not available to provide
the information, or the worker simply didn’t
ask. “Data not collected” is not a response
option necessary in every system or in every
element. Adding the response option of “Data
not collected” enables a user who did not
collect or simply does not have the information
to enter a response that does not present a
false answer. HMIS, which require entry of an
element for the system to progress must
implement the “Data not collected” response
for all elements that require a response. “Data
not collected” must equate to missing data or
null values as appropriate for transfer and
reporting purposes.
The "Client doesn't know" or "Client prefers
not to answer" 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
20

provide responses to some fields, but case
managers or data entry staff may not make
that decision for them.
MISSING DATA RESPONSES: 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 was not collected. In such cases, that
response category must be treated as missing
data for reporting purposes. “Data not
collected” continues to be identified as a
response option in these HMIS Data
Standards.
At a national level, in every project type, most
clients are willing to provide identifying
information. If a project is experiencing a high
rate of client refusals as compared to similar
projects, CoCs should consider implementing
training 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.

Project Descriptor Data Elements

Project descriptor data elements (PDDEs) are intended to identify the organization, specific
project, and project details to which an individual client record is associated in an HMIS.
PDDEs 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
Longitudinal Systems Analysis (LSA), System Performance Measures (SPM), Housing
Inventory Counts (HIC), Point-in-Time (PIT) counts, and utilization analysis.
Project setup can be very challenging and is most successful with clear communication between
HMIS Leads/System Administrators, CoCs, and organizations. For example, projects in HMIS
are sometimes referred to as ‘programs’ by agency providers, and staff may not be aware of
21

data collection and reporting requirements. Therefore, collaboration between HMIS Leads, CoC
leadership, and agency staff is critical to develop mutual understanding and ensure project
setup is consistent with funding requirements and reporting obligations.
PDDEs are generally entered and managed in an HMIS by the HMIS Lead, not an HMIS project
end user. They are created at the 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 PDDEs are entered or updated by HMIS project end users, the HMIS
Lead must have oversight and data entry/edit ability, along with strong review procedures, to
ensure timely, accurate, and complete data.
At a minimum, HUD requires that the CoC (typically via the HMIS Lead) collect project
descriptor information in the HMIS for:
•

All continuum projects within its jurisdiction that participate in HMIS by collecting and
entering client-level data.

•

All residential continuum projects, regardless of their participation in HMIS.

If the HMIS database includes client and service data entered by non-continuum projects (e.g.,
food pantries or other services that might be used by people who are not experiencing
homelessness), the continuum must identify them as such using the PDDEs to ensure that data
are excluded from required reporting on continuum projects.

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 HMIS. If project setup is done incorrectly, it will jeopardize the ability to
produce accurate, reliable reports.
Prior to creating a new project in HMIS, the HMIS Lead/System Administrator should consult
with both the organization administering the project and the Collaborative Applicant or
designated HMIS subcommittee from the CoC regarding appropriate responses for the PDDEs.
Project Type and 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 Housing
Inventory Count (HIC) and Point-in-Time (PIT) guidance issued by HUD each year. Some HMIS
software automatically configure data collection based on Project Type and 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 Funding
Sources are available for data entry.
The HMIS Project Setup Tool identifies the required data elements for each funding source
(alone or in combination with others) and project type. Federal partner programs and related
projects often require additional project setup guidance, which can be found in the applicable
federal partner HMIS Program Manuals. HMIS Leads should develop a standard process for
remediation when project setup is done incorrectly.

22

Multiple Project Setup

There may be circumstances within the HMIS implementation where a project that appears to
be one project must be set up as two separate projects in 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 Type' ‘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 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 both Homelessness Prevention (HP) and Rapid Re-Housing
(RRH), whether funded by HUD or by the VA (i.e., under the Supportive Services for
Veteran Families (SSVF) program) or another funding source, must be set up as two
separate projects in HMIS with the two distinct project types, even if they are funded
under a single grant. In this case, the 'Grant Identifier' (data element 2.06) will be the
same in both project setups.
c. Permanent Housing projects are often created with a variety of rental subsidies. Unless
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 HMIS to appropriately
separate the client records for reporting purposes.
d. PATH projects may provide funding to one organization for both traditional street
outreach services and supportive services such as 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' (from data element 2.02 Project Information) 'Street
Outreach' and one with the 'Project Type' (from data element 2.02 Project Information)
'Services Only' to distinguish the projects' operations and reporting for PATH and to
support system-level performance measurement.

Projects that Operate in Multiple CoCs

Some projects are funded to provide lodging and/or services to clients in only one CoC (e.g.,
HUD: CoC- Transitional Housing); others are funded to provide lodging and/or services across a
geographic area that includes more than one CoC (e.g., some VA-funded SSVF projects). In
these cases, funding recipients are expected by the federal partners to participate in the HMIS
implementation of each CoC in which they operate projects. This expectation may be satisfied
either by direct data entry into each HMIS or by entering data into a single HMIS and providing
exports of client-level data to each HMIS, with appropriate agreements in place between the
CoCs involved.
It is important to note that when referring to projects that operate in multiple CoCs, this guidance
is not meant for CoCs that are funded to operate in a single CoC but occasionally place clients
via tenant-based voucher projects in other geographies outside of their CoC. In cases where a tenant-based voucher project (e.g., RRH) is funded to operate in a specific CoC but places a
client outside of their CoC’s geography (while the client continues to participate in the project),
no action must be taken on the client record. The Continuum Code and Enrollment CoC should
reflect the CoC in which the project is located.
23

Residential projects that operate in multiple CoCs that cross HMIS implementations must be
documented in each CoC's HMIS, even in cases where all client data are entered into a single
CoC's HMIS and the data is provided to the other CoC's HMIS via data transfer. This means
that a complete project is set up in each of the CoC’s HMIS with complete PDDE information
and is populated with the relevant client-level data.
If the CoCs decide to enter data into a single HMIS and provide exports to the other HMIS
implementations, it is critical to be able to track the clients by CoC to facilitate exporting the
appropriate data. To do this, federally funded projects that are funded to operate in multiple
CoCs but are entering data into a single HMIS must create a separate record for each
Continuum Code (from data element 2.03 Continuum of Care Information), consistent with the
area served by the project according to their grant agreement with the federal funder. The
associated 'Geocode', 'Project ZIP code', and 'Project Street Address' fields must reflect the
location of the project's principal site in each CoC (or, for multiple site projects, the area in the
CoC which most of the project's clients are housed). The ‘Continuum Codes’ selected in data
element 2.03 would then be used to populate an option list of ‘CoC Codes for Enrollment CoC’
for data element 3.16.
When deciding which CoC will directly enter data versus which CoC data will contribute via
uploads, it is advisable to decide which CoC has the largest share of the funder’s clients. For
example, a VA SSVF project providing services to clients in both a Balance of State and an
urban CoC must, after establishing appropriate agreements between the two CoCs, be
associated with the 'Continuum Code' for both the Balance of State AND the urban CoC. Note
that if an SSVF project is expected to provide assistance to everyone in the catchment area
then all of the CoC codes which cover the area must be selected. However, if the SSVF project
only provides services to people in City X, and City X has a single CoC code, then select the
code that applies to City X’s CoC only. If a project is funded to operate in multiple CoCs and is
participating in the HMIS implementations of each separate CoC with a separate project created
in each, only the ‘Continuum Code’ relevant to the HMIS implementation need be entered.

2.01 Organization Information
Rationale

To uniquely identify organizations operating one or more projects that enter data into HMIS, as
well as any organizations operating residential continuum projects that are not participating in
HMIS. This element is also used to identify organizations that are classified as Victim Service
Providers (VSPs).

Project Setup Instruction
Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Organizations
All Programs – All Components
All HMIS Project Types
Initial HMIS project setup, reviewed/updated no less
than annually

Organization Information is assigned once for each organization and includes an ‘Organization
ID’ that must be assigned to each project via a system generated number or code. There must

24

be only one organizational identifier and name for each organization that has projects which
operate in the HMIS implementation.
Record the organization’s legal name. An organization's legal name is not always the name by
which it is commonly known in the community. For that reason, some HMIS software include an
additional field to track more familiar “common names” for organizations, but this is not required.
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’. For
instance, an organization that operates an emergency shelter, transitional housing project, and
permanent supportive housing project will have the same ‘Organization ID’ associated with each
of those projects. 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.
Indicate if the organization is a ‘Victim Service Provider’ by selecting “Yes”
The HMIS Lead/System Administrator must be able to activate and deactivate an organization
in HMIS.

Response Descriptions
Field

Organization ID

Organization Name
Victim Service
Provider

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

Description

Yes

A Victim Service Provider is defined as a private
nonprofit organization whose primary mission is
to provide services to survivors of domestic
violence, dating violence, sexual assault, or
stalking. Victim Service Providers include rape
crisis centers, battered women's shelters,
domestic violence transitional housing
programs, and other programs.

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

2.02 Project Information
Rationale

To uniquely identify each project entering data into HMIS, as well as any residential continuum
projects not participating in HMIS, and to associate each project with the specific type of lodging
or services provided and the details about those project types. The ‘Project ID’ is used to link
project descriptor information in other data elements to the specific project, and to link clients
and their enrollment data to the project. 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, Rapid Re-Housing subtypes, and the
relationship of a 'Services Only' project (or RRH: Services Only subtype) to a housing project as
25

necessary. Finally, HOPWA-funded projects identify whether they are 'Medically Assisted Living
Facilities' at this stage of project setup.

Project Setup Instruction
Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Projects
All Programs - All Components
All HMIS Project Types
Initial HMIS project setup, reviewed/updated no less
than annually

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. Each project must be associated with one and only one Organization Information;
separate projects operated by the same organization must be associated with the same
‘Organization ID’. The name of the project must be captured in text within the HMIS. An HMIS
may permit the creation of a common name element more familiar to HMIS end users for use
within the application system while retaining the name for use in reporting.
Record the ‘Project Name’. The ‘Project Name’ should be in words that identify the specific
project and are readable and recognizable. The name should be recognizable to:
•
•
•

the HMIS End User as their project in order to identify they are entering data for a client
into the correct project,
the HMIS Lead/System Administrator to identifying the correct project for data review
and reporting, and
funders that receive the report.

The name is not required to match the name on any grant agreements. The name is not a
Globally Unique Indenter (GUID), or a series of letters representing funding sources. The
project name should not change when the project receives a new source of funding. The project
name should not include the year of funding (e.g., “FY09 CoC RRH”). The project name should
not be only equal the project type (e.g., just “emergency shelter” or “RRH”). There are many
cases where funders are receiving the HMIS CSV and using the project name and ID to
accurately identify the project being reported on and to deduplicate projects or longitudinally
make comparisons based on that information. HMIS may include another field for the entry of
additional identification of the projects funding source for reporting purposes but it is not
required and does not substitute for the project name.
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 HMIS. HMIS may include another field for the entry of additional names of the
project for ease of access purposes, but it is not required.
Record the ‘Operating Start Date’. This date should align with the date the project first began
assisting clients. At the point a project closes, and an ‘Operating End Date’ is recorded, all
clients must be exited on or before the ‘Operating End Date’. This may be achieved through a
bulk update or auto exit (if such functionality exists), or manually. It is strongly encouraged that
at a minimum, an alert or notification is provided to indicate active clients remain in the project.
26

Indicate if the project is a ‘Continuum Project’ and select the ‘Project Type’ A project is to be
assigned a type in 'Project 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 one project type per 'Project ID'.
The project type selected directly impacts data collection and reporting requirements. If 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. HMIS software
should allow admins to edit ‘Project Type’ to correct errors; however, if a project goes from
operating as one ‘Project Type’ to operating as another, it is recommended that admins create a
new project with the new ‘Project Type’. Please submit a question in the Ask a Question (AAQ)
on the HUD Exchange if guidance is needed on whether a new project should be created.

Project Setup Considerations

Supportive Services Only Projects
A 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 Funding
Sources.
If the ‘Services Only’ project provides only services (other than street outreach or coordinated
entry) 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”.
If a ‘Services Only’ project meets any of the criteria below, select ‘Services Only’, set ‘Affiliated
with a Residential Project’ to “Yes”, and record the ‘Project ID’ of each residential project. A
project must be able to identify as many affiliated residential projects as needed.
•

•

Provides services in one residential project BUT
o

Does not offer to provide services for all the residential project clients, OR

o

Only serves clients for a portion of their project stay (e.g., provides classes), OR

o

Information sharing is not allowed between the residential project and service
provider.

Provides services in multiple residential projects of the same project type (e.g., multiple
PH:PSH) BUT
o

Does not serve all the residential project clients, OR

o

Information sharing is not allowed between residential projects and service
providers.

•

Provides services in multiple residential projects of different project types (e.g., PH:RRH
and PH:PSH)

•

Provides services in Emergency Shelter(s)

27

Rapid Re-Housing Projects
Beginning in the FY 2024 HMIS Data Standards, Rapid Re-Housing (RRH) projects can be
classified in one of two subtypes – ‘Services Only’ or ‘Housing with or without services’. Select
only one subtype per RRH project. The ‘Housing with or without services’ subtype must be
selected if the project receives any ongoing rental funds, even if not all project participants
receive housing assistance funds from the RRH project. Only select the ‘Services Only’ subtype
if the ongoing housing assistance for all program participants is provided by another funding
source (e.g., Housing Choice Voucher, HUD VASH, other RRH project). If a RRH project has a
‘Services Only’ subtype, no inventory records should be created in Bed and Unit Inventory
Information.
If a project at any point changes from one subtype to another, the project information record
must be closed and a new record opened with the new subtype identified.
Emergency Shelters
Emergency shelters are classified in two different project types: either “Entry Exit” (EE) or
“Night-by-Night" (NbN). Reporting and outcomes will differ depending on the shelter type.
Utilization of the NbN type 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 NbN shelter type.
•
•
•

•

An EE shelter project requires the client to have a full record created for each project
stay. All data required for the project at project entry and exit are recorded.
A NbN shelter project requires the client to 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 five 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 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 two nights.
To the extent possible in a mass shelter environment, HMIS end users should
complete all elements required at exit for clients in NbN shelter. The households who
are known to be housed or are otherwise no longer in the project should be exited
manually, however, 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 day after the client’s last bed
night 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 type of shelter 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.
If a shelter/CoC determines that the type of emergency shelter needs to be changed due to the
project converting from one type to another, for example, the following approach must be taken
to minimize impact on the System Performance Measures and other reports:
28

1. A new shelter project must be established in the HMIS using the new emergency shelter
project type
2. All clients in the closing 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/deactivated from entry in the system (i.e.,
closed)
Record if the project is a ‘HOPWA-funded Medically Assisted Living Facility’ or not, or that the
project is not HOPWA-funded (HOPWA funding source will also be identified in 2.06 Funding
Sources).

Response Descriptions
Field Name
Project ID
Project Name

Response/Data
Type
System
generated
number or code.
[Text]

Operating Start
Date

[Date]

Operating End
Date

[Date]

Continuum
Project

No
Yes

Description
A unique identifier that must be automatically
generated by the HMIS at the time the project is
created in the HMIS.
The project's name. While the project name is not
required to match grant agreements, the project name
should be consistent with the name used across
reports (e.g., APR and HIC).
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 a future project start date that reflects the
date the project will begin providing services.
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 project within the geographic boundaries of the CoC
associated with the HMIS whose primary purpose is to
meet the specific needs of people who are
experiencing homelessness or at risk of
homelessness, 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 CoC.
29

Field Name
Project Type

Response/Data
Type
Emergency
Shelter – Entry
Exit

Emergency
Shelter – Nightby-Night

Transitional
Housing

PH – Permanent
Supportive
Housing
(disability

Description
A project that offers temporary shelter (lodging) for
people experiencing homelessness in general or for
specific populations of people experiencing
homelessness. Requirements and limitations may vary
by program and will be specified by the funder. The EE
shelter project type should be used for all shelters that
collect Universal Data Elements (UDEs) and certain
Program-Specific Data Elements (PSDEs) at project
start and project exit, including projects that require or
strongly encourage a continuous stay while a client
resolves their experience of homelessness. In EE
shelters, length of stay is calculated based on the
number of nights between project start and project exit,
and performance measures will include changes from
project start and project exit Data Collection Stages.
The NbN emergency shelter type 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. This project
type 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 EE
emergency shelter for tracking utilization. In NbN
shelter: (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
resides in the shelter; (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 (dating back to the day after the last
bed night) 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.
A project that provides temporary lodging and is
designed to facilitate the movement of individuals and
families experiencing homelessness 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.
A project that offers permanent housing and supportive
services to assist people experiencing homelessness
with a disability (individuals with disabilities or families

30

Field Name

Response/Data
Type
required for
entry)
Street Outreach

Services Only

Other
Safe Haven

PH – Housing
Only
PH - Housing
with Services (no
disability required
for entry)
Day Shelter
Homelessness
Prevention
PH – Rapid ReHousing

Description
in which one adult or child has a disability) to live
independently.
A project that offers services necessary to reach out to
people experiencing unsheltered homelessness,
connect them with emergency shelter, housing, or
critical services, and provide urgent, non-facility-based
care to those who are unwilling or unable to access
emergency shelter, housing, or an appropriate health
facility. Only persons who are residing on streets or
other places not meant for habitation should be
entered into a street outreach project. Projects
assisting persons other than unsheltered persons must
have two separate projects to be set up in HMIS, one
'Street Outreach' and the other 'Services Only'.
A project that offers only Housing Project or Housing
Structure Specific or Stand-Alone supportive services
(other than Street Outreach or Coordinated Entry) to
address the special needs of participants.
A project that offers services, but does not provide
lodging, and cannot otherwise be categorized as
another project type.
A project that offers supportive housing that (1) serves
hard-to-reach people experiencing homelessness with
severe mental illness who have been unsheltered 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.
A project that offers permanent housing for people
experiencing homelessness but does not make
supportive services available as part of the project.
A project that offers permanent housing and supportive
services to assist people experiencing homelessness
to live independently but does not limit eligibility to
individuals with disabilities or families in which one
adult or child has a disability.
A project that offers daytime facilities and services (no
lodging) for people experiencing homelessness.
A project that offers services and/or financial
assistance necessary to prevent a person from
entering an emergency shelter or place not meant for
human habitation.
A permanent housing project that provides housing
relocation and stabilization services and/or shortand/or medium-term rental assistance as necessary to
31

Field Name

Response/Data
Type

Coordinated
Entry

If PH- Rapid ReHousing, identify
sub type

RRH: Services
Only
RRH: Housing
with or without
services

If Services Only No
for “Project Type”
or RRH: Services
Only subtype,
Affiliated with a
residential project
Yes

If Yes for
“Affiliated with a
residential
project”
Project ID(s) of
residential
project(s)
affiliated with SSO
or RRH: Services
Only project
Housing Type
(applicable only to
residential project
types)

[List of HMIS
Residential
Project IDs]

Description
help an individual or family experiencing homelessness
move as quickly as possible into permanent housing
and achieve stability in that housing.
A project that administers the CoCs centralized or
coordinated process for assessment and referral of
individuals and families seeking housing or services,
including the use of a comprehensive and standardized
assessment tool.
A RRH project that provides services only and does
not provide ongoing rental assistance or support any
inventory for participants.
A RRH project that offers ongoing rental assistance
that may or may not be accompanied by financial or
other supportive services to participants.

For all projects typed 'Services Only', or ‘RRH:
Services Only’ subtype, 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 PH projects).
Residential Project Types are: 0, 1, 2, 3, 8, 9, 10, 13
(subtype 2)

Site-based single site

All clients are housed in a single project facility.

Site-based clustered/
multiple sites

Clients are housed in more than one project facility in
multiple locations, but more than one client is housed
in each project facility. The facility locations are owned,
operated, or sponsored by the project.

32

Field Name

Target Population

HOPWA-Funded
Medically
Assisted Living
Facility

Response/Data
Type

Description

Tenant-based scattered site

Clients have leases or other occupancy agreements
and are housed in residences that are not owned or
managed by the project.

DV: Survivors of
Domestic
Violence

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

HIV: Persons
with HIV/AIDS

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

NA: Not
applicable

Neither of the other response categories applies.

No

HOPWA-funded project is not a Medically Assisted
Living Facility.

Yes

HOPWA-funded project is a Medically Assisted Living
Facility.

NA - nonHOPWA Funded
Project

Project is not HOPWA funded.

2.03 Continuum of Care Information
Rationale

To associate each project entering data into HMIS, as well as any residential continuum projects
not participating in HMIS, with one or more Continuum of Care (CoC) for reporting and data
exchange purposes.

Project Setup Instruction
Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Continuum Projects
All Programs - All Components
All HMIS Project Types
Initial HMIS project set up, reviewed/updated no less
than annually

'Continuum Codes' (or CoC Codes) are published annually by HUD in the CoC Program NOFO
and are associated with specific geographic areas. Each project must be associated with the
HUD-assigned 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 CoC (e.g.,
HUD: CoC – Transitional Housing); others are funded to provide lodging and/or services across
a geographic area that includes more than one CoC (e.g., some VA-funded SSVF projects). For
federally funded projects operating in multiple CoCs but entering data into a single HMIS
33

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
CoC.
'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 VSPs 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 of Continuum of Care Information because of a single project's association with different
CoCs, the geocodes will differ. The geocode must be located within the CoC in the same
record.

Response Descriptions
Field Name
Continuum
Code

Response/Data Type
[Text] [6 characters: XXXXX]

Geocode

[6 digits]

Project street
address 1

[Text]

Project street
address 2
Project city

[Text]

Project state
Project ZIP
code

[2 letters]
[5 digits]

Geography
Type

Urban

[Text]

Description
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., XX- 999. The HMIS software may
provide a drop-down list of valid CoC Codes
or require manual entry.
The 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.
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 or VSPs, the administrative address
may be used.
The city in which the project’s principal site
is located, or for scattered site projects, the
city in which most of the project’s clients are
housed. For tenant-based scattered site
projects or VSPs, the administrative address
may be used.
Standard state or territory abbreviation
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.
HUD will release a regularly updated
crosswalk of ZIP codes and a geography
type for each. 'Geography type' must
34

Suburban
Rural

correspond to the HUD crosswalk;
geography types may not be locally defined.

2.06 Funding Sources
Rationale

To identify funding sources for each project entering data into 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

Header
Data Collected About
Funder: Component Program
Project Type Applicability
Collection Point

Instructions
All Projects
All Programs - All Components
All HMIS Project Types
Initial HMIS project set up, reviewed/updated no less than
annually

The Funding Sources are the federal partner programs and their project components that have
agreed either to participate in HMIS or are otherwise considered continuum projects. There are
also response options for “Local or Other Funding Source” and “N/A”.
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
Grant Identifier
Grant Start Date
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.
The 'Grant Identifier' must uniquely identify the grant; although, several projects may share the
same grant identifier if they are 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 funding source’s 'Grant Start Date' and 'Grant End Date' allows for the
inclusion or exclusion of certain projects in grant- or system-level reporting. For example, this
information is critical in determining which projects to include in the System Performance
Measures.
The HMIS Lead/System Administrator must regularly collect and review 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
35

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 federal partner Program Manuals on the HUD Exchange.
Note – there are funding sources listed within this data element for which there is no specific
guidance for HMIS project setup (e.g., HUD: HOME). However, jurisdictions receiving these
funding sources may require their projects to participate in HMIS. It is important to remember
that the CoC Program Interim Rule gives CoCs authority over and responsibility for HMIS. As a
result, questions such as how to set up a project in HMIS for which there is no explicit project
setup guidance should be addressed by the CoC through any HMIS governance, policies,
and/or agreements in place between associated parties.
Multiple Funding Sources
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.

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' of “Emergency Shelter – Entry
Exit’’; it will show both ‘‘HUD: ESG – Emergency Shelter" and “HHS: RHY – Basic Center
Program” as the ‘Federal Partner Program and Components’. 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
Information (2.02) and Funding Sources (2.06) the HMIS Lead/System Administrator should
reference the HMIS Data Standards to appropriately set the element visibility for the project.
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

36

same federal program or two different federal programs. In these cases, HMIS Leads/System
Administrators and project providers have two options:
1. Create one project in HMIS that both the housing provider and the service provider will
jointly share and record data in, or
2. Create two separate projects in 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 systemwide performance measures.
If a single project is created, the 'Project Type' (from data element 2.02 Project Information) will
be the appropriate residential project type (e.g., TH, PSH, etc.), and the ‘Federal Partner
Program and Components’ (from data element 2.06 Funding Sources) 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 comply with all data collection requirements associated with that project type.
The services project will have a 'Project Type' of ‘Services Only’ or a ‘subtype’ of ‘RRH:
Services Only’. For services-only projects or subtypes, 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.

Response Descriptions
Field Name
Federal
Partner
Program and
Component

Response/Data Type
HUD: CoC – Homelessness Prevention
(High Performing Communities Only)

Description

HUD: CoC – Permanent Supportive
Housing
HUD: CoC – Rapid Re-Housing
HUD: CoC – Supportive Services Only
HUD: CoC – Transitional Housing
HUD: CoC – Safe Haven
HUD: CoC – Single Room Occupancy
(SRO)
HUD: CoC – Youth Homeless
Demonstration Program (YHDP)
HUD: CoC – Joint Component TH/RRH
HUD: ESG – Emergency Shelter
(operating and/or essential services)
HUD: ESG – Homelessness Prevention
37

HUD: ESG – Rapid Re-Housing
HUD: ESG – Street Outreach
HUD: ESG-CV
HUD: ESG-RUSH
HUD: Unsheltered Special NOFO
HUD: Rural Special NOFO
HUD: Pay for Success
HUD: HOPWA – Hotel/Motel Vouchers
HUD: HOPWA – Housing Information
HUD: HOPWA – Permanent Housing
(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: HOPWA-CV
HUD: Public and Indian Housing (PIH)
Programs
HUD: HUD/VASH
HUD: PIH (Emergency Housing
Voucher)
HUD: HOME
HUD: HOME (ARP)
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 Services
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
VA: Grant Per Diem – Service Intensive
Transitional Housing
38

VA: Grant Per Diem – Transition in
Place
VA: Grant per Diem – Case
Management/Housing Retention
VA: Community Contract Safe Haven
Program
VA: Supportive Services for Veteran
Families
N/A
Local or Other Funding Source (Please
Specify)
If local or [Text]
other, please
specify
(dependent
to response
46)
Grant
No specified format
Identifier

Grant Start
Date
Grant End
Date

[Date]
[Date]

2.07 Bed and Unit Inventory Information

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.
The start date of the grant
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.

Rationale

To record bed and unit inventory information for each residential project entering data into
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
Header
Data Collected About

Funder: Component Program

Instructions
All Residential Projects, except for PH – Rapid Re-Housing
subtype: Services Only
All Programs - All Components
39

Header
Project Type Applicability

Collection Point

Instructions
Emergency Shelter – Entry-Exit
Emergency Shelter – Night-by-Night
Transitional Housing
PH – Permanent Supportive Housing
Safe Haven
PH – Housing Only
PH – Housing with Services
PH – Rapid Re-Housing (subtype: Housing with or without
services)
Initial HMIS project set up, reviewed at least annually and
updated as needed to reflect changes.

At a minimum, an HMIS must have an accurate record of Bed and Unit Inventory Information for
all continuum residential projects. Bed and unit inventory records must be created at the initial
HMIS project setup and reviewed/updated no less than annually. This data must be finalized
and accurately entered by the time of the HIC. 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.
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,' and 'Availability'.
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.
'Bed Type' also should be logically consistent with 'Housing Type’ at the project level.
For example, if an Emergency Shelter has both facility-based beds ('Housing Type' =
‘‘Site-based’’) and hotel/motel vouchers ('Housing Type' = "Tenant-based"), then two
HMIS projects would be set up for that Emergency Shelter.
Projects that operate in more than one CoC must have separate Bed and Unit Inventory
Information records for each Continuum of Care Information record.

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 recorded as they occur. For example, if a project spends its
annual operating budget in six months instead of twelve months, this could be considered a
significant change to the inventory. While what constitutes significant change is left to the
community to define, a project’s inventory should be reflective of the reality of residential project
operations and data quality comparisons between the number of available beds, occupied beds,
and persons enrolled in the projects.
While inventory counts should be accurately recorded within the last week of each of the
months of January, April, July, and October (to satisfy APR and LSA inventory accuracy), the
40

CoC should attempt to backdate the date associated with the revised inventory to the actual
date that the significant inventory change occurred. More frequent updates for significant
changes are encouraged, but not required. When the CoC updates the inventory records, they
could enter several changes at once to accurately reflect the history of significant changes or a
step-down of changes in inventory. Or, if a significant inventory change has occurred over a
period of weeks, the CoC could pick a single date in the middle of the period to make the
increase/decrease effective, so the average inventory and utilization comparison will be aligned.
CoCs are not expected to update small variations in inventory that are temporary.
•

•

•
•

When a project adds inventory that will continue to serve the same CoC and household
type with the same 'Bed Type' and 'Availability' as existing inventory, a new record
should be created reflecting the new total bed count. The 'Inventory Start Date' should
reflect the date the new inventory will be available. This date may be prior to the date the
record is created or in the future in the case of under-development beds (i.e., beds for
which funding has been approved but are not yet available). The earlier record should be
closed out by recording an 'Inventory End Date', that is the day prior to the effective date
of the increase.
When a project reduces inventory but continues to serve the same household type with
a smaller number of beds, a new record should be added. The 'Inventory Start Date'
should reflect the date the inventory will effectively be reduced. 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.
Changes in the number of dedicated or non-dedicated beds 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 'Inventory Start
Date', that is the effective date of the change.

There should only be one active inventory record per household type, bed type, and availability
combination. 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 and the earliest 'Inventory Start Date' from the individual records.
Dedicated Bed Inventory
All beds funded by HUD or another federal partner that are dedicated to one or more of the
identified subpopulations must be recorded in the appropriate category. 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. Each category is expected to be mutually exclusive. 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. DedicatedPLUS beds do not qualify as dedicated
beds and should not be included in the dedicated bed inventory unless the project has a subset
of the DedicatedPLUS beds that are dedicated per the descriptions below.

41

Determining Total Bed Inventory
The ‘Total bed inventory’ is a count of the total number of beds available for occupancy as of the
'Inventory Start 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 50
beds for households with at least one adult and one child in the inventory.

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 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.
Determining unit inventory
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 inventory.

42

Response Descriptions
Field Name

Inventory start
date
Inventory end
date

Response/Data
Type
[Date]

Description

[Date]

The last date that an inventory record is relevant:

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

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.
Projects that operate in more than one CoC must
have separate Bed and Unit Inventory records for
inventory associated with each CoC. From the CoC
codes entered in data element 2.03, 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.
Beds and units typically serving households with at
least one adult and one child.
•

CoC Code

Household
type

[as identified in
data
element 2.03.1
Continuum
Code]
Households
without children
Households
with at least one
adult and one
child
Households
with only
children

Bed Type
(dependent to
project Type =
0 and 1)

Facility-based
beds
Voucher beds
Other beds

Availability
(dependent to
project Type =
0 and 1)

Year-round

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.
Beds (including cots or mats) located in a residential
homeless assistance facility dedicated for use by
persons who are experiencing homelessness.
Beds located in a hotel or motel and made available
by the homeless assistance project through vouchers
or other forms of payment.
Beds located in another facility not dedicated for use
by persons who are experiencing homelessness (e.g.,
church).
Year-round beds and units are available on a yearround basis.

43

Seasonal

Overflow

Beds dedicated
to chronically
homeless (CH)
Veterans
Beds dedicated
to youth
Veterans
Beds dedicated
to any other
Veterans
Beds dedicated
to chronically
homeless
youth
Beds dedicated
to any other
youth

[Integer]

[Integer]
[Integer]
[Integer]

[Integer]

Beds dedicated [Integer]
to any other CH
Non-dedicated
beds

[Integer]

Total bed
inventory

[Integer]

Total unit
inventory

[Integer]

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 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.
The number of beds that are dedicated to house
Veterans experiencing chronic homelessness and
their household members.
The number of beds that are dedicated to house
youth (persons up to age 24) Veterans experiencing
homelessness and their household members.
The number of beds that are dedicated to house
Veterans who are not youth and not experiencing
chronic homelessness and their household members.
The number of beds that are dedicated to house
youth (persons up to age 24) experiencing chronic
homelessness and their household members.
The number of beds that are dedicated to house
youth (persons up to age 24) experiencing
homelessness who are not Veterans and are not
experiencing chronic homelessness, and their
household members.
Beds dedicated to non-youth, non-Veteran persons
experiencing homelessness. The number of beds that
are dedicated to house persons experiencing chronic
homelessness and their household members.
All other (non-dedicated) beds not already accounted
for in dedicated bed fields. The number of nondedicated beds for persons experiencing chronic
homelessness, youth, or Veterans used to house
persons experiencing homelessness and their
household members.
The sum total of dedicated and non-dedicated bed
inventories available for occupancy as of the
'Inventory Start Date'.
The 'Total Unit Inventory' is a count of the total
number of units available for occupancy as of the
'Inventory Start Date'.

2.08 HMIS Participation Status
Rationale

To identify the HMIS or comparable database participation status of all Continuum projects.

44

Project setup Instruction
Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Projects
All Programs - All Components
All HMIS Project Types
Initial HMIS project set up, reviewed/updated no less
than annually

Record the participation status of the HMIS project by selecting the appropriate response in the
‘Participation Type’ field. “HMIS Participating” and “Comparable Database Participating” both
mean that a project collects all required data elements according to funder requirements and
local CoC Policies and Procedures. To be “HMIS Participating” means the data is collected
within the CoC’s designated HMIS, or that data is submitted to the CoC’s designated HMIS at
least once a year to cover the whole year of required client data collected by the project. To be
“Comparable Database Participating” means these criteria are also met, but the data is
collected within the VSP’s comparable database, not HMIS.
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.
Record the date that the ‘Participation Type’ status is applicable. For new projects, the
‘Participation Status Start Date’ should match the project’s ‘Operating Start Date’ in 2.02 Project
Information. The ‘Participation Status End Date’ should remain blank for the record unless the
project’s participation status changes or the project ceases operations.
If a project’s ‘Participation Type’ changes, (i.e., a project goes from entering data into HMIS to
not entering data in HMIS while remaining operational) a ‘Participation Status End Date’ must
be added for that ‘Participation Type’ to indicate the day that participation type ended. A new
record must then be created for the new ‘Participation Type’ with a ‘Participation Status Start
Date’ to be the date immediately after the last ‘Participation Status End Date’ record. Date
ranges must not overlap.
Instructions for handling client data when a project stops participating in HMIS:
•

•

•

Exit all clients on or before the ‘Participation Status End Date’.
o The exit destination must align with the actual location of the client (i.e., if shelter
stops participating but the clients continue to reside in the shelter, their
destination must be an emergency shelter)
Create a new HMIS participation Status record. Set the ‘Participation Status Start Date’
to be one day after the former HMIS participation record’s ‘Participation Status End
Date’. The HMIS participation status will be set to “No”
Do not make any changes to the inventory record

If a project ceases operations, the ‘Participation Status End Date’ for the current record should
be the same date as the project’s ‘Operating End Date’ in 2.02 Project Information.
45

Response Descriptions
Field Name
Participation Type

Response/Data Type
Not Participating

HMIS Participating

Comparable Database
Participating

Participation
Status Start Date
Participation
Status End Date

[Date]
[Date]

Description
This response indicates that no
persons residing in or being served by
this project have client data collected
about them in the Universal Data
Elements, Common Data Elements,
and Federal Partner Program Specific
Elements by this project in the CoC’s
HMIS or by a VSP in a comparable
database.
This response indicates that all
persons residing in or being served by
this project have at least their
Universal Data Elements recorded in
the CoC's HMIS by this project. This
includes projects whose data is
imported into the HMIS
implementation. For projects that
began participating in HMIS prior to
October 1, 2012, the start date may
be estimated if it is not known.
This response indicates that all
persons residing in or being served in
this project have at least their
Universal Data Elements recorded by
this project in a VSP comparable
database. For projects that began
participating in the comparable
database prior to October 1, 2012, the
start date may be estimated if it is not
known.
The date on which the participation
type began.
The date on which the participation
type ended.

2.09 Coordinated Entry Participation Status
Rationale

The Coordinated Entry Participation Status is designed to identify a project’s type of
engagement in the local Coordinated Entry System (CES). This element captures information
about whether a project is an access point for the CES and if the project accepts referrals from
the CES.

46

Project Setup Instruction

Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Projects
All Programs - All Components
All HMIS Project types
Initial HMIS project setup reviewed at least annually
and updated as needed to reflect changes.

As defined in Notice CPD-17-01: Notice Establishing Additional Requirements for a Continuum
of Care Centralized or Coordinated Assessment System, “Access Points are the places–either
virtual or physical–where an individual or family in need of assistance accesses the coordinated
entry process”. Indicate if a project is a Coordinated Entry Access Point by selecting “Yes” or
“No”.
If a project is identified as a CE Access Point, select all applicable activities completed by the
project in the dependent ‘Provided by CE Project’ field.
Indicate if a project receives referrals through the CES by selecting “Yes” or “No” to ‘Project
Receives CE Referrals’. Project IDs from those projects identified in this element as receiving
referrals will be used to generate an option list in 4.20 “Coordinated Entry Event” allowing the
person adding the referral to specify the project receiving the referral.
Record the ‘CE Participation Status Start Date’ as the first day on which all elements are
accurate (i.e., if a shelter began accepting referrals on 1/1/22 and then began conducting
housing assessments as well on 6/1/22, the record indicating they accept referrals and conduct
assessments should start 6/1/22) The end date should remain blank for the record unless the
project’s CE participation status changes for any reason. Some examples of CE participation
status changes are, the project ceasing to participate in the CoC’s CES, the project adding
assessment capabilities, or the project ceasing operations.
If a project’s ‘CE Participation Status’ changes from one type to another, a ‘Participation Status
End Date’ must be added for that record to indicate the day that participation status ended. A
new record must then be created to indicate the new ‘CE Participation Status’ with a
‘Participation Status Start Date’ to be the date the new ‘CE Participation Status’ begins.
If a project ceases operations, the ‘Participation End Date’ for the current record(s) should be
the same date as the project’s ‘Operating End Date’ in 2.02 Project Information. It is possible for
a project to be both a CE access point and the recipient of CE referrals and also for these
statuses to change over time. In these cases, the original ‘CE Participation Status’ record must
be updated to include an end date and a new record created reflecting the current status with a
start date. Additionally, if the services provided by the CE Access Point changes, the original
‘CE Participation Status’ record must be updated to include an end date and a new record
created reflecting the current status with a start date.

47

CE Participation change example
CE
Access
Point

Provided by CE
Access Point Project

Receives
Referrals

Start
Date

End Date

Project A

N

—

Y

7/1/2022

12/31/2022

Project A

Y

Y

1/1/2023

4/30/2023

Project A

Y

Y

5/1/2023

Shelter assessments
only
Both shelter and
prevention
assessments

Response Descriptions
Field Name

Response/Data Type

Project is a
Coordinated Entry
Access Point

No

Yes
Provided by CE
Project

Homelessness
Prevention Assessment,
Screening, and/or
Referral
Shelter Assessment,
Screening, and/or
Referral
Housing Assessment,
Screening, and/or
Referral
Direct Services (search
and/or placement
support)

Project Receives CE No
Referrals
Yes
CE Participation
Status Start Date
CE Participation
Status End Date

[date]
[date]

Description

This project conducts CE access
activities.
CE access point conducts screenings,
assessments, or referrals for households
at risk of homelessness and seeking
homelessness prevention assistance.
CE access point conducts screenings,
assessments, or referrals for households
experiencing homelessness and in need
of emergency shelter or other crisis
resources.
CE access point conducts screenings,
assessments, or referrals for households
experiencing homelessness for
placement into housing projects.
CE access point provides problem
solving, diversion, or rapid resolution
services to households at-risk or
experiencing homelessness.
This project accepts referrals and
placements from CE.
The date on which the participation
status began.
The date on which the participation
status ended.

48

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 (UDEs), as do projects that are not
funded by any federal partner (e.g., missions) but have agreed to enter data as part of the
CoC’s HMIS implementation.
The UDEs 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 homelessness, and patterns of service use,
including information on shelter stays and homelessness over time.
The UDEs are the foundation on which the Longitudinal System Analysis (LSA) is developed.
The LSA informs the Annual Homeless Assessment Report (AHAR), which provides Congress
with national estimates of the current state of homelessness across the United States and the
use of homeless assistance programs. The AHAR is 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. The LSA is also used locally via the Stella tool to inform
communities on how trends in their local homeless population change over time.
Universal Identifier Elements (One and
Only One per Client Record)
3.01 Name
3.02 Social Security Number
3.03 Date of Birth
3.04 Race and Ethnicity
3.07 Veteran Status

Universal Project Stay Elements (One or
More Value(s) Per Client, One Value Per
Project Stay)
3.08 Disabling Condition
3.10 Project Start Date
3.11 Project Exit Date
3.12 Destination
3.15 Relationship to Head of Household
3.16 Enrollment CoC
3.20 Housing Move-In Date
3.917 Prior Living Situation

General Data Collection Guidance

UDEs are required to be collected by all projects participating in an HMIS, regardless of funding
source. Data elements 3.01 through 3.07 are required to have one response per client,
regardless of how many project enrollments that client has in the system. If at any point the data
in these elements are observed to be incorrect or outdated, the data must be corrected in the
client record. The remaining UDEs are to be collected at least once per project enrollment. The
timing of when the data are to be collected and about whom is noted in each data element.

49

Uses and Disclosures of Client Data

Collecting UDEs can lead to questions about entering client information into HMIS and client
rights to privacy. Staff must make data collection easy to understand by providing clients with a
written copy of the CoC’s Privacy Notice on request, describing the notice in plain language,
and posting a public statement about data collection and uses. Assuring and maintaining
privacy and confidentiality helps build trust in using HMIS. The client always has a right to
privacy and can refuse to provide their information without being denied service.
Client consent is not needed to ask for the information or enter it into the HMIS. Projects are
required by their funder to ask the client for specific information and to enter it into HMIS. Please
note, however, that collecting the data and using or disclosing the data are two different things,
and that uses and disclosures not listed in the CoC's privacy notice require the client’s consent.
To learn more about this, consult with your CoC and HMIS Lead for more information on your
local HMIS confidentiality and privacy practices as they relate to the 2004 Data and Technical
Standards Notice and Chapter 2 of the Coordinated Entry Management and Data Guide.

3.01 Name
Rationale

To support the unique identification of each person served.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Clients
All Programs - All Components
All HMIS Project Types
Record creation

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 and accurate name whenever possible. If the client
doesn’t associate with their legal name, the name entered into HMIS should reflect the name
the client identifies with, unless legal name is required by the funder (e.g., VA). Doing this as a
standard practice makes it easier to find records when searching and avoids creating duplicate
records. Generally, projects are not required to verify that the information provided matches
legal documents. However, each project should be aware of the 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 and Coordinated Entry projects may record a project entry with limited
information about the client and improve 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 Start Date’ and a “code name” (e.g., “Redhat Tenthstreetbridge”) response in the name
field that would be identifiable for retrieval by the worker in the system. Over time, the data must
50

be edited for accuracy (e.g., replacing “Redhat” with “Robert”) as the worker learns more details,
more information about the client is obtained.

Response Descriptions
Field Name
First

Response/Data Type
[Text]

Middle
Last

[Text]
[Text]

Suffix

[Text]

Name Data
Quality

Full name reported
Partial, street name, or
code name reported

Client doesn’t know

Client prefers not to answer

Data not collected

Description
Record the full first name used by the client.
Preferred name is acceptable over legal name
unless legal name is required by funder.
Record the full last name used by the client in the
format the client prefers. (e.g., with hyphen or
without hyphen).
Record “Jr.”, “Sr.”, etc. as applicable.
Select “Full name reported” for “Name Data
Quality” if complete, full first and last names have
been recorded as provided by the client.
Select “Partial, street name, or code name
reported” if a name other than the full and
accurate name is recorded. This may include a
placeholder name such as a street name or code
name for street outreach clients or a name
modification made for security reasons.
Select “Client doesn't know” when the 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 to create a record in the system solely
because the client did not know or was unable to
provide their name.
Select “Client prefers not to answer” when client
chooses not to provide their name. Use “Client
prefers not to answer”, rather than “Partial, street
name, or code name reported” if a false
name/made up name was entered to create a
record in the system solely because the client
prefers not to answer or tell staff their name.
Select “Data not collected” if the worker did not
attempt to collect the client’s name.

51

3.02 Social Security Number
Rationale

To support the unique identification of each person served.
Where data is shared across projects, the Social Security Number (SSN) greatly facilitates the
process of identifying clients who have been served and allows projects to avoid creating
duplicate records at Project Start.
Where data is not shared, CoCs rely on unique identifiers to produce an unduplicated count in
the HMIS. Name and date of birth are useful unique identifiers, but the SSN is helpful for
deduplicating clients where name and/or date of birth might be the same.
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 to help their clients access mainstream services.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Clients
All Programs - All Components
All HMIS Project Types
Record creation

In separate fields, record the nine-digit 'Social Security Number’ and appropriate 'SSN Data
Quality’. NOTE: PATH, CoC, and ESG Program-funded projects are only required to collect the
last four digits of the SSN, though are not prohibited from collecting all nine digits. CoC and
ESG-funded projects are not penalized for only collecting the last four digits of the SSN.
HMIS end users must have the ability to record all nine digits of the SSN. The software must
allow for the entry of partial SSNs and should allow for the effective matching of partial SSNs.
HMIS Leads/System Administrators should work with their vendor to ensure a complete
understanding of how SSNs are recorded in their HMIS.
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. Do not replace a 9-digit SSN with the 4-digit SSN on existing
clients unless the client has requested this.
Some clients may not have access to or be able to recall their SSN at the time of data
collection.

52

Response Descriptions
Field Name
Social Security
Number
SSN Data Quality

Response/Data Type
[9 digits]

Description

Full SSN reported

A complete and valid SSN is
provided.
Any SSN other than a complete and
valid 9-digit SSN, regardless of the
reason, is provided.
A client does not know or does not
have an SSN.
A client prefers not to provide any
part of their SSN, regardless of the
reason.
No attempt was made to collect an
SSN for the client

Approximate or partial
SSN reported
Client doesn’t know
Client prefers not to
answer
Data not collected

3.03 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

Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Clients
All Programs - All Components
All HMIS Project Types
Record creation

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’ is accurate and complete 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 Date of Birth
(DOB) policy. For ‘DOB Data Quality', select "Approximate or partial DOB reported”
If a client is not able to estimate their age within one year of their actual age, select “Client
doesn't know”. If the client can provide their birth year but declines to provide their day of birth
and month, record an approximate date as indicated above and indicate that the response is
"Approximate or partial DOB reported". Select "Client prefers not to answer’’ when a client
declines to provide their birth year. "Client doesn't know," "Client prefers not to answer," and
"Data not collected" are explanations for missing DOB data. None of these three options are
valid in conjunction with a valid or approximated date entered in 'Date of Birth'.

53

Response Descriptions
Field Name
Date of Birth
Date of Birth
Data Quality

Response/Data Type
[Date]
Full DOB reported
Approximate or partial
DOB reported
Client doesn't know

Client prefers not to
answer

Data not collected

Description
The complete date of birth is provided by
the client.
The client cannot provide their full or exact
date of birth but is able to provide their age
within one year.
Use “Client doesn't know” rather than
“Approximate or partial DOB reported” if
the client did not know their date of birth
within one year.
“Client doesn't know” is an explanation for
missing DOB data. This response is not
valid in conjunction with a full or
approximated date entered in 'Date of
Birth'.
Use “Client prefers not to answer” if the
Client prefers not to answer to provide their
date of birth or their age for staff to
approximate.
"Client prefers not to answer", is an
explanation for missing DOB data. This
response is not valid in conjunction with a
full or approximated date entered in 'Date
of Birth'.
Use “Data not collected” when no attempt
was made to collect DOB information from
the client. ‘‘Data not collected’’ is an
explanation for missing DOB data. This
response is not valid in conjunction with a
full or approximated date entered in 'Date
of Birth'.

3.04 Race and Ethnicity
Rationale

To indicate client’s self-identification with one or more different racial and/or ethnic categories.
This data supports system planning, and local and national understanding of who is
experiencing homelessness.

54

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Clients
All Programs - All Components
All HMIS Project Types
Record creation

Record the self-identified race(s) and ethnicity, if applicable, of each client served. Help the
client select as many race and/or ethnicity options that they identify with.
When enrolling a client who already has a record in the HMIS, verify that race and ethnicity
information is complete and accurately reflects how the client identifies, and correct if it does
not.
Staff observations should never be used to collect information on race and ethnicity. While
interactions between intake staff and individuals seeking services can be brief, there is an
important opportunity to meet each person on a human level and with a person-centered
approach. Traumatic events including but not limited to experience with law enforcement,
mental health, substance abuse, domestic violence, and sex work may influence clients’ comfort
in answering questions. Stigmas surrounding the criminalization of homelessness, behavioral
health concerns, and drug use may also impact a client’s willingness to provide demographic
information.
Provide all options to every client. Even if staff believes they can guess a client's race and/or
ethnicity, every client must be asked for their self-reported information. It is important to ask
about all household members' race and ethnicity because it is impossible to tell just based on a
person's appearance or name. Furthermore, HMIS may not provide a default answer. No
documentation is required to verify a client's response.
This element also includes an open text box field for clients to optionally report any additional
race or ethnicity information they wish to share. For example, a person may identify as
“Hispanic/Latina/e/o” based on the response options provided, but more specifically identifies as
Puerto Rican. Enter this information in the text box field. This information may be used for local
purposes in custom reporting or in case management activities and is reported to federal
partners utilizing the HMIS CSV export for reporting.
If the client does not know their race or ethnicity, or prefers not to disclose it, use "Client doesn't
know" or "Client prefers not to answer", rather than making an appearance or name-based
assumption.

55

Response Descriptions
Field Name
Race and Ethnicity

Response/Data Type
American Indian, Alaska
Native, or Indigenous

Asian or Asian American

Black, African American, or
African

Hispanic/Latina/e/o

Middle Eastern or North
African

Native Hawaiian or Pacific
Islander
White

Description
A person who identifies with any of the
original peoples of North, Central, and
South America. Examples include, but
are not limited to Navajo Nation,
Blackfeet Tribe, Mayan, Aztec, Tlingit,
etc.
A person who identifies with one or
more nationalities or ethnic groups
originating in East Asia, Southeast
Asia, or the Indian subcontinent.
Examples include, but are not limited to
Chinese, Indian, Japanese, Korean,
Pakistani, Vietnamese, or another
representative nation/region.
A person who identifies with one or
more nationalities or ethnic groups
originating in any of the Black racial
groups of Africa, including AfroCaribbean. Examples include, but are
not limited to, African American,
Jamaican, Haitian, Nigerian, Ethiopian,
and Somali.
A person who identifies with one or
more nationalities or ethnic groups
originating in Mexico, Puerto Rico,
Cuba, Central and South American,
and other Spanish cultures. Examples
include, but are not limited to, Mexican
or Mexican American, Puerto Rican,
Cuban, Salvadoran, Dominican, and
Colombian.
A person who identifies with one or
more nationalities or ethnic groups with
origins in the Middle East and North
Africa. Examples include, but are not
limited to, Lebanese, Iranian, Egyptian,
Syrian, Moroccan, and Israeli.
A person who identifies with one or
more nationalities or ethnic groups
originating in Hawaii, Guam, Samoa, or
another Pacific Island.
A person who identifies with one or
more nationalities or ethnic groups
originating in Europe. Examples
include, but are not limited to German,
Irish, Polish, English, French, and
Norwegian.

56

Client doesn’t know

Client prefers not to answer

Data not collected
Additional Race and
Ethnicity Detail

[Text]

"Client doesn't know" should only be
selected when a client does not know
their race(s)/ethnicity from among the
seven listed options. "Client doesn't
know" should not be used in
conjunction with any other response.
"Client prefers not to answer" should
only be selected when a client chooses
not to identify their race(s)/ethnicity
from among the seven listed options.
“Client prefers not to answer” should
not be used in conjunction with any
other response.
Use this response if the staff does not
ask the client to provide their
race/ethnicity.
Provide additional specificity the client
would like the share about their race or
ethnicity.

3.07 Veteran Status
Rationale

To indicate whether clients have ever spent time in the United States Armed Forces and may be
eligible for VA Homeless Programs. Allows for an accurate count of how many Veterans
experience homelessness. Useful for screening for possible housing and service interventions
and for gaining an understanding of Veterans' service needs.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Adults
All Programs - All Components
All HMIS Project Types
Record creation

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:
57

•
•
•

“Have you ever been on active duty in the military?”
“Were you disabled during a period of active-duty training?”
“Were you ever called into active duty as a member of the National Guard or as a
Reservist?”

This data element is only required for adult clients. There are options for addressing instances
where clients turn 18 while enrolled:
•

•

Collect the data at the time of enrollment for clients expected to turn 18 while enrolled; or
Update the client record at the time the client turns 18.

Response Descriptions
Field Name
Veteran
Status

Response/Data
Type
No

Yes

Client doesn't
know
Client prefers not
to answer
Data not collected

Description
Client has never spent any time in the United States
Armed Forces. This includes individuals who attended
training but were discharged before reporting to a duty
station, and Reservists or National Guard who were
never activated or deployed.
Client has ever served in the Armed Forces of the
United States, regardless of discharge status or length
of service. Please see the VA Data Guide for additional
specific information related to ‘Veteran Status’
definition.
“Client doesn't know” should only be selected when a
client does not know their Veteran status.
“Client prefers not to answer” should be selected when
a client chooses not to identify their Veteran status.
Use this response if the staff does not ask the client to
provide their Veteran status.

3.08 Disabling Condition
Rationale

To indicate whether clients have a disabling condition as defined below. This data element is to
be used with other information to identify whether a client meets the criteria for experiencing
chronic homelessness.

Data Collection Instruction

Header
Instructions
Data Collected About
All Clients
Funder: Component All Programs - All Components
Program
Project Type Applicability
All HMIS Project Types
Collection Point
Project Start (Edit as necessary to reflect new information)
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;
58

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).
For any given enrollment, there should be one and only one ‘Disabling Condition’ response to
choose from for reporting purposes and the answer should always be reflective of the most
current disabling condition available (even if the disabling condition onset was after the ‘Project
Start Date’ for the enrollment). 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 current known status of a client's 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 for enrollment, consistent with those funding requirements.
If a Veteran client has a disabling condition as the result of an injury or illness 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.
A client indicating the following ‘Income and Sources’ can be considered to have a disabling
condition: ‘Social Security Disability Insurance (SSDI)’, ‘VA Service-Connected Disability
Compensation’, or ‘VA Non-Service-Connected Disability Pension’. Additionally, recipients of
‘Supplemental Security Income (SSI)’ may be considered to have a disabling condition if their
reason for receiving SSI is not solely based on their age being 65 or older and the benefit is not
for a dependent.
For residential homeless assistance programs, client enrollment as part of the program
admission process must be separated from the collection of disability information 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.

Response Descriptions
Field Name
Disabling
Condition

Response/Data
Type
No
Yes

Description
“No” should be selected when the client knows that
they do not have a disabling condition
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:
• Is expected to be long-continuing or of
indefinite duration;

59

•

Substantially impedes the individual's ability to
live independently; and
• 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.
Client doesn't
“Client doesn't know” should only be selected when a
know
client does not know if they have a disabling condition.
Client prefers not “Client prefers not to answer” should be selected when
to answer
a client chooses not to identify if they have a disabling
condition.
Data not collected Use this response if the staff does not ask the client to
provide their disabling condition status.

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 by a given client. 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 clients accessing permanent housing.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

Instructions
All Clients
All Programs - All Components
All HMIS Project Types
Project Start

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 as defined by project type below.
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.

60

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 the client started the project. If this client is a newborn
baby, the ‘Project Start Date’ would reflect the date the project started providing housing or
services to the newborn, consistent with the responses for project types identified below, which
may be any date on or after the baby's date of birth.

Response Descriptions
Field Name

Project Start
Date

Response/
Data Type
[Date]

Description
Street Outreach: Date of first contact with the client.
Emergency Shelter: Night the client first stayed in the
shelter. NbN 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
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; and
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 scatteredsite 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 Entry): 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

Header
Data Collected About
Funder: Component - Program

Instructions
All Clients
All Programs - All Components
61

Header
Instructions
Project Type Applicability
All HMIS Project Types
Collection Point
Project Exit
Record the month, day, and year of the 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.
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 the client left the project.
Different project types use ‘Project Exit Date’ differently, to address the difference in meaning
associated with “ending” residential and service projects.
•

•
•

For site-based residential projects and Entry-Exit emergency shelters, 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, 2023, stayed overnight, and left
in the morning, the exit date for that shelter stay would be January 31, 2023.
o Clients in RRH 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 Night-by-Night emergency shelters, the exit date should be the day after the last
recorded bed night.
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. If a client uses a service for just
one day (i.e., starts and stops before midnight of the same day), then the ‘Project Exit
Date’ may be the same as the ‘Project Start Date’.
o In a street outreach project, clients may be exited when the outreach staff has
been unable to locate the client for an extended period of time and there are no
recorded contacts. The CoC must be involved in the determination of what
constitutes an "extended length of time”, and to which projects the solution is to
be applied.
o In addition, the client may be exited upon entering another project type, finding
housing, engaging with another outreach project, or passing away. In those
cases, the client would be exited as of the date of the last contact recorded in
4.12 ‘Current Living Situation.’

Auto-exits

Auto-exit functionality is not a required feature of HMIS. However, if it is a feature offered, it
must meet certain requirements:
62

•

•

The CoC must be involved in the determination of what constitutes an "extended length
of time" that has elapsed to trigger auto-exit functionality and must establish a standard
to “automatically exit” a client after a given length of absence from a project. (e.g., 90
days from last bed night).
For residential projects, the client's ‘Project Exit Date’ would be recorded as the last day
the client appeared at the residential project (in the case of Night-by-Night emergency
shelter, the day after the last 4.14 ‘Bed Night Date’ and the 3.12 ‘Destination’ would be
marked as “No exit interview completed.”

The “Post Exit” Data Collection Stage is relevant for project types that provide aftercare/followup 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 described above,
appropriate to the project type.

Response Descriptions
Field
Name
Project
Exit
Date

Response/Data Type
[Date]

Description
Site-based residential projects and Entry-Exit
emergency shelters: The last day of continuous stay
in the project before the client transfers to another
residential project or otherwise stops residing in the
project.
Night-by-Night Emergency Shelters: The day after the
last bed night recorded.
Tenant-based permanent housing projects: The last
day the client receives rental assistance or supportive
services (RRH) or is provided rental assistance
(tenant-based PSH, transition-in-place, or other
permanent housing).
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

Header
Instructions
Data Collected About
All Clients
Funder: Component - Program
All Programs - All Components
Project Type Applicability
All HMIS Project Types
Collection Point
Project Exit
Record where the client is expected to stay after they complete or stop participating in project
activities.

63

Select the ‘Destination’ that most closely matches where the client will be staying after exiting
the project.
If project staff receive corrected information about a client's exit destination from the client
(because the original entry was incorrect), destination responses may be corrected in HMIS.
3.917 Prior Living Situation data should not be used as the source for Destination. Additionally,
Destination should not be pre-filled at project start and unconfirmed, word-of-mouth information
from anyone other than the client should not be used as a source for Destination responses in
HMIS.
For residential projects that expect a client to move out upon exit (Emergency Shelter,
Transitional Housing, Safe Haven, project-based Permanent Supportive Housing), record where
the client is expected to move immediately after leaving. For projects where a client is not
expected to relocate upon exit (Homelessness Prevention, Rapid Re-Housing, Transition in
Place, or Supportive Services 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 during their project enrollment or prior to starting in the project.
If a client moves into rental housing with a subsidy to help them maintain the housing, select
“Rental by client, with ongoing subsidy” which will then allow for a dependent field to provide
additional detail about the type of subsidized housing situation the client is living in. 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 subsidies (e.g., state
rental assistance voucher).
If a client moves into the housing of 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 HMISbased reporting as a positive outcome. If a client is moving into a situation that cannot be
accounted for by the guidance provided, please submit an HMIS AAQ with the specific
circumstances on the HUD Exchange to receive assistance with appropriate categorization.
Note that the client's ‘Destination’ is about where they are staying, not necessarily about why
they are staying there. The destination will depend on the specifics of the situation, but it is
important to select a destination response that reflects the true nature of the situation. For
example, clients who are exiting to attend school, to join the military, or to certain employment
opportunities may have different responses for Destination depending on the specifics. If the
client is moving into a dorm or military-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,
64

consistent with the notion that the client may stay with the family member for as long as needed
to complete school.
Another common example is a situation in which a client is exited from a project and is
“squatting” or occupying an abandoned or unoccupied area or land and/or building that the
client does not own, rent, or otherwise have lawful permission to use, “Place not meant for
habitation” as the exit destination.
NbN shelters may have high rates of missing Destination data. Often, in this type of shelter, a
client is exited after a period 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.

Response Descriptions
Field Name

Destination
Rental Subsidy Type

If Other for “Type of
Residence”

Response/Data Description
Type
See Appendix A - Living Situation Option
List for a complete list of Living Situation
Responses and Destinations
If a response of “Rental by client, with
ongoing housing” is selected, identify the
specific subsidy.
[Text]

Record in the description of ‘Other’
residence type.

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
Header
Data Collected About
Funder: Component Program
Project Type Applicability
Collection Point

Instructions
All Clients
All Programs - All Components
All HMIS Project Types
Project Start

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.
65

There must be one Head of Household for each enrollment and there cannot be more than one
Head of Household for any given enrollment.
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 (retroactively to the beginning of the household's enrollment). The other members'
relationship to the Head of Household should be edited to reflect each individual's relationship
to the newly designated Head of Household (including the individual exiting the program) 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 be retained in HMIS over the course
of a project stay; the Head of Household is simply swapped out, backdating to the start of the
household's enrollment.
In a household of a single individual, that person must be identified as the head of the
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 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 people 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; if the funder's instructions conflict with CoC
guidance, the requirements of the funder should supersede CoC guidance for the relevant
projects.
Where two or more people under the age of 18 present at a project together and one of the
people presenting is not the child of the other (e.g., brother and sister), each person should be
entered as their own record in their own household. It is important to create separate records for
people under 18 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. If two minors present together with a child, the two minors should be recorded in
separate households. The child should be added to the household of the parent that the child
would live with should the parents be separated for any reason.

Response Descriptions
Field Name
Relationship
to Head of
Household

Response/Data Type
Self (Head of
Household)
Head of Household's
child
Head of Household's
spouse or partner
Head of Household's
other relation member

Description
Head of household may be alternatively thought of
as the “primary client”, the “eligible individual” etc.,
rather than as a fixed designation.
Children, including step-, adopted, and foster
children of the Head of Household, regardless of
their age.
Significant other of the Head of Household,
whether in a marital or de facto relationship.
Grandchildren, nieces, nephews, cousins, or other
relatives, regardless of their age.
66

(other relation to Head
of Household)
Other: non-relation
member

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 Enrollment CoC
Rationale

To link client household data to the relevant CoC in which the assisting project operates.
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. For more information about
setting up projects that operate in multiple CoCs, please refer to Introduction to Project
Descriptor Data Elements.

Data Collection Instruction
Header
Data Collected About
Funder: Component Program
Project Type Applicability
Collection Point

Instructions
Head of Household
All Programs - All Components
All HMIS Project Types
Project Start

Select or enter the CoC code assigned to the geographic area for where the project is funded to
operate.
If Enrollment CoC information was recorded incorrectly at project start, correct the existing
record.
It must be possible to associate all project stays with the relevant CoC code. This data element
must be user-entered for all projects with more than one 'Continuum Code' identified in 2.03
Continuum of Care Information. It may be auto-populated for projects that operate in a single
CoC. Systems may set up defaults to the CoC code of the HMIS implementation but must be
able to accept any other 'Continuum Code' identified in 2.03 Continuum of Care Information. For
data quality purposes, the CoC codes for this data element should be limited to the same
'Continuum Code(s)' used for element 2.03 Continuum of Care Information.
To allow projects operating in multiple CoCs to enter data into a single “host’’ HMIS and provide
data to each of the CoCs in which they are serving clients, a CoC must be identified for each
‘Project Start Date.’ The 'CoC Code' will be used in reporting in the host HMIS to exclude
irrelevant data; it will also be used as a parameter for data export to provide relevant data to
other CoCs.
Household members' location data must match the ‘Enrollment CoC’ identified for the Head of
household.
67

Response Descriptions

Field Name
HUD assigned CoC
code for the client’s
location at project start

Response/Data Type
[Text] [6 characters: XXXXX]

Description
HUD assigned CoC code for the
project location at enrollment.

3.20 Housing Move in Date
Rationale

To document the date that a household admitted into a permanent housing project moves into
housing. This date is critical to Housing Inventory Count (HIC) and Point-in-Time (PIT) counts
as it differentiates households that have already moved into permanent housing from
households that are enrolled in a Permanent Housing project but are still experiencing literal
homelessness (in Emergency Shelter, Safe Haven, Transitional Housing, or on the street) as
they prepare to move into an available unit.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program
Project Type Applicability

Collection Point

Instructions
Head of Household
All Programs - All Permanent Housing Components
PFS – All component types
PH - Permanent Supportive Housing
PH - Housing Only
PH - Housing with Services (no disability required for
entry)
PH - Rapid Re-Housing
Other - (PFS ONLY)
Occurrence Point: At move-in

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 living situation. “Move-in” means a lease arrangement has been made,
the client has a key or entry ability to the unit, and that the client has physically slept in the unit.
This date may or may not align with the lease date. If communities need to collect lease dates
for local reasons, they should use a custom data element.
A ‘Housing Move-In Date’ must be recorded at the point the household moves into a permanent
living situation, whether subsidized by the currently enrolled PH project, a different PH project or
subsidy, or without any subsidy at all. This may or may not be the same date as ‘Project Exit
Date’ depending on the provision of additional services after the client is housed. Refer to 3.11
Project Exit Date guidance for instructions on ‘Project Exit Date.’
For purposes of the HIC 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.
If the client vacates a housing situation and the project stops paying rental assistance, staff
should exit the client from the project with an accurate ‘Project Exit Date’ and ‘Destination’ and
68

create a new ‘Project Start Date’ in a second enrollment for the client on the same or following
day. The ‘Prior Living Situation’ in the new enrollment must reflect the location where the client
slept the night before the new ‘Project Start Date.’ The project should continue working with the
client until a new unit is found, at which point a new ‘Housing Move-In Date’ would be recorded
on the second project record. This will ensure that the client’s history of housing is preserved.
If the client moves directly from one unit into another unit, with no days of homelessness in
between, it is not necessary to exit and re-enter them because their ‘Housing Move-In Date’
would still accurately reflect the day they entered permanent housing within that enrollment
record.
If a client is transferred into a PSH, RRH, or other permanent housing project having already
moved into a permanent housing unit, the client’s ‘Project Start Date’ and ‘Housing Move-in
Date’ will be the same date. It is not appropriate to have the ‘Housing Move-in Date’ reflect the
original move-in, since the purpose of the data element is to distinguish between housed and
homeless statuses during a single enrollment.
Pay for Success (PFS) funded recipients may set up “Other” project types in their HMIS in
situations where creating an additional permanent housing project for PFS participants would
result in overlapping enrollments. “Other” project types in the context of PFS must also collect
the Housing Move-in Date.
‘Housing Move-in Date’ must be a date occurring on or between the ‘Project Start Date’ and
‘Project Exit Date.’ There can be only one ‘Housing Move-in Date’ per enrollment. Once a
‘Housing Move-In Date’ has been recorded for an enrollment, it must not be removed from the
client's record, even if they subsequently lose that housing situation. Users must be able to edit
data to correct errors. HMIS software must NOT auto-populate ‘Housing Move-In Date’ from one
enrollment record (‘Enrollment Identifier’,) to another.

Response Descriptions
Field Name

Response/Data Type

Description

Housing Movein Date

[Date]

The date the client moved into permanent
housing. Must be entered if/when a
household moves into any type of
permanent housing, regardless of funding
source or whether the project is providing
the rental assistance, to differentiate
between clients who are housed and
those who are experiencing
homelessness at different points during
their enrollment.

3.917 Prior Living Situation
Rationale

To identify the type of living situation and length of stay in that situation immediately prior to
project start for all adults and the Head of Household. This data element is used with other
information to identify whether a client appears to meet the criteria for experiencing chronic
69

homelessness at various points of enrollment (i.e., at the point of project entry, at a point during
a project enrollment, or at any point over the course of a specified reporting period).

Data Collection Instruction

Header
Instructions
Data Collected About
Head of Household and Adult(s)
Funder: Component - Program
All Programs - All Components
Project Type Applicability
All HMIS Project Types*
Collection Point
Project Start
The element has been constructed to avoid collecting information which is irrelevant or
inappropriate for the client population being served in a particular situation by splitting the
element into 3.917A and 3.917B.
*3.917A is applicable only to Emergency Shelter, Street Outreach, and Safe Haven project
types. 3.917B is applicable to all other HMIS project types. For example, eligibility for
Homelessness Prevention requires that a client be in housing. By definition, a person in housing
is not experiencing chronic homelessness at that point in time, so some of the fields in this data
element used to determine whether a person is experiencing chronic homelessness are not
applicable in that situation.
Intake staff should ask clients about their history of experiencing homelessness, 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. Note, the phrases “on the
street” or "the streets" are used as shorthand for any place that meets the statutory definition of
“place not meant for human habitation” and means 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.
Although documentation is required by some funders for programs targeting people
experiencing chronic homelessness, 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 can have more complex enrollment 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 experiencing
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 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
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 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.
70

1. Select the 'Type of Residence' from the Living Situation Option List 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 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 Entry from any type of temporary, permanent, or other situation:
i.
Indicate if the client was in the temporary, permanent, or other
situation for less than 7 nights and if so, indicate if their living
situation immediately prior to entering the temporary, permanent,
or other situation 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 episode of homelessness 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 this time.
5. Record the cumulative total number of months the client has experienced homelessness
on the streets, in emergency shelters, or in Safe Havens in the past three years.
Users must be able to edit data to correct errors or to enter a response for a client who has
turned 18. Responses to this element must always reflect living situation and circumstances as
of the ‘Project Start Date’ and not at the time of collection. If dependencies are required as
defined below, HMIS must be able to create them and the data for the fields of this data element
should be logically consistent. It is strongly recommended that HMIS is programmed to enforce
these rules or to notify users when inconsistent data has been entered. For example, if there is
a "Yes” response then the next response elements must be available for data entry. If there is
any other response besides “Yes” then the next response element must either be hidden or
formatted or in some other way identified as not to be completed.

71

3.917A Flow Chart is applicable only to Emergency Shelter, Street Outreach, and Safe Haven
project types.

72

3.917B Flow Chart is applicable to all other HMIS project types.

73

Response Descriptions
Field Name

Response/Data Type

Description

Type of
Residence

See Appendix A - Living
Situation Option List

Rental
Subsidy Type

See Appendix A

Rental Subsidy Type

Length of stay
in prior living
situation

One night or less

The length of time the client was residing in the
living situation. If the client moved around, but
was 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 selected situation.

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 prefers not to
answer
Data not collected
[Date]
Approximate
date this
episode of
homelessness
started

Have the client look back to the date of the last
time the client had a place to sleep that 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 experience of
‘‘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.
74

(Regardless
of where
they stayed
last night),
number of
times the
client has
been on the
streets, in
ES, or SH in
the past
three years
including
today

One time

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).

Two times
Three times
Four or more times
Client doesn't know
Client prefers not to
answer
Data not collected
Total number
of months
homeless on
the street, in
ES, or SH in
the past
three years

One month (this time is
the first month)

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
less than 90 days or in permanent or transitional
housing less than 7 days. The current month,
even if a partial month, should be counted as a
full month.

[Integers 2 through 12]
More than 12 months
Client doesn't know
Client prefers not to
answer
Data not collected

75

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.

Common Program Specific Data Elements

The HMIS Federal Partners have cooperatively developed these elements. For each ProgramSpecific 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. CoCs and projects are encouraged to develop their own data collection
protocols and assessment tools to fully assess client service needs.

4.02 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 income between project start,
annual assessment, 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 cross-systems connections to ensure access to additional income
sources.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Instructions
Head of Household and Adults
HUD: CoC – Collection required for all components
except SSO Coordinated Entry
HUD: ESG – Collection required for all components
except ES-NbN
HUD: ESG RUSH – Collection required for all
components except Emergency Shelter or Street
Outreach
HUD: HOPWA – Collection required for all
components

76

Header

Project Type Applicability

Instructions
HUD: Unsheltered NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
HHS: RHY – Collection only required for MGH, TLP,
and Demo
VA: SSVF – Collection required for RRH and
Homelessness Prevention
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types

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 into 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 the funder, generally, any income
associated with a minor used for household expenses and support should be included in the
Head of Household’s Income and Sources record. Where the income is not relevant for
household expenses, it could be excluded from entry. Projects may choose to collect income
information for all household members including minor children within households if 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 18year-old's new record, an additional update record would need to be created for the Head of
77

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 for one year or more, even if there is no change in either the income or
sources. The ‘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 income information was recorded incorrectly at project start, update, assessment, or
exit, correct the existing record, rather than adding an “update” record.
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 record keeping 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. However, be sure to check your funder's requirements. 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.

78

Response Descriptions
Field Name
Information Date

Response/Data Type
[Date]

Income from Any
Source

No

Earned Income
(i.e., employment
income)

Description
The date the information was collected

Yes
Client doesn't know
Client prefers not to
answer
Data not collected
No
Yes

Monthly amount
Unemployment
Insurance

[Currency/decimal]
No

Monthly amount
Supplemental
Security Income
(SSI)

[Currency/decimal]
No

Monthly amount
Social Security
Disability
Insurance (SSDI)

[Currency/decimal]
No

Monthly Amount
VA ServiceConnected
Disability
Compensation

[Currency/decimal]
No

Yes

Yes

Yes

Earned income means any income that is
earned by the client, even if not supported by
official documentation of that income (e.g.,
collecting recycling, cash jobs such as
babysitting).

Unemployment compensation includes
payments the respondent received from
government unemployment agencies or
private companies during periods of
unemployment and any strike benefits the
respondent received from union funds.

Monthly cash benefits paid to people with
limited income and resources who are
disabled, blind, or age 65 or older. Blind or
disabled children may also get SSI.

Cash benefits for disabled person and
certain family members who meet “insured”
requirements. This means the person
worked long enough – and recently enough
– and paid Social Security taxes on earnings.

79

Yes

Monthly Amount
VA Non-ServiceConnected
Disability Pension

[Currency/decimal]
No

Monthly Amount
Private disability
insurance

[Currency/decimal]
No

Monthly Amount
Worker's
Compensation

[Currency/decimal]
No

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

[Currency/decimal]
No

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

[Currency/decimal]
No

Monthly Amount
Retirement Income
from Social
Security

[Currency/decimal]
No

Monthly Amount
Pension or
retirement income
from a former job

[Currency/decimal]
No

Yes

Yes

Yes

Yes

Yes

Yes

A monetary benefit paid to Veterans who are
determined by VA to be disabled by an injury
or illness that was incurred or aggravated
during active military service.

A monetary benefit paid to wartime Veterans
with limited income who are no longer able to
work.

Disability benefits include payments people
receive as a result of a health problem
or disability (other than those from social
security).

Worker’s compensation includes payments
people receive periodically from public or
private insurance companies for injuries
received at work.

Cash public assistance payments lowincome people.

Cash public assistance payments for lowincome people.

A monthly cash benefit that replaces income
when one reduces their working hours or
stops working altogether.

80

Yes

Monthly Amount
Child support

[Currency/decimal]
No
Yes

Monthly Amount
Alimony and other
spousal support

[Currency/decimal]
No

Monthly Amount
Other Source

[Currency/decimal]
No
Yes

Monthly Amount
Specify Source
Total Monthly
Income

[Currency/decimal]
[text]
[Currency/decimal]

Yes

Pension or retirement income includes
payments from the following sources:
companies or unions; federal government
(Civil Service); military; state or local
governments; railroad retirement; annuities
or paid-up insurance policies; individual
retirement accounts (IRAs), Keogh, or 401(k)
payments; or other retirement income.
Child support includes all periodic payments
a parent receives from an absent parent for
the support of children, even if these
payments are made through a state or local
government office.

Alimony includes all periodic payments
people receive from ex-spouses. Alimony
excludes one-time property settlements.
Any other cash income source not named
above.
Name of other cash income source.
Sum of all monthly income.

4.03 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

Header
Data Collected About
Funder: Component - Program

Instructions
Head of Household and Adult(s)
HUD: CoC – Collection required for all components
except SSO Coordinated Entry
HUD: ESG – Collection required for all components
except ES-NbN
HUD: ESG RUSH – Collection required for all
components except Emergency Shelter or Street
Outreach
HUD: HOPWA – Collection required for all components
HUD: Unsheltered Special NOFO – Collection required
for all components except SSO Coordinated Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
81

Header

Project Type Applicability

Instructions
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
HHS: RHY – Collection only required for BCP (HP and
ES), MGH, TLP, and Demo
VA: SSVF – Collection required for RRH and
Homelessness Prevention
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types

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,
generally, 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 Household’s NonCash Benefits record. Projects may choose to collect non-cash benefits information for all
household members including minor children within households if 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 18year-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. The
‘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.
82

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.

Response Descriptions
Field Name

Information Date
Non-Cash Benefit from
Any Source

Supplemental Nutrition
Assistance Program
(SNAP) (Previously
known as Food Stamps)
Special Supplemental
Nutrition Program for
Women, Infants, and
Children (WIC)

Response/Data
Type
[Date]

Description
The date the information was collected

No
Yes
Client doesn't
know
Client prefers not
to answer
Data not collected
No

Previously known as Food Stamps

Yes
No

Yes

Assistance for low-income pregnant,
breastfeeding, and non-breastfeeding
postpartum women, infants, and children
up to age 5 who are found to be at
nutritional risk.

83

TANF Child Care
services (or use local
name)
TANF transportation
services (or use local
name)
Other TANF-funded
services
Other source
Specify Source

No
Yes
No
Yes
No
Yes
No
Yes
[Text]

4.04 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

Header
Data Collected About
Funder: Component - Program

Project Type Applicability

Instructions
All Clients
HUD: CoC – Collection required for all components
except SSO Coordinated Entry
HUD: ESG – Collection required for all components
except ES-NbN
HUD: ESG RUSH – Collection required for all
components except Emergency Shelter or Street
Outreach
HUD: HOPWA – Collection required for all
components
HUD: Unsheltered Special NOFO – Collection
required for all components except SSO
Coordinated Entry
HUD: Rural Special NOFO – Collection required for
all components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD
VASH Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all
components
HHS: RHY – Collection required for all components
VA: SSVF – Collection required for RRH and
Homelessness Prevention
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types
84

In separate fields, indicate whether 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 the client is covered by each of the listed insurance
types. If required by the 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 or Charity
Care funding received by a medical provider or hospital to cover healthcare 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).

Response Descriptions
Field Name

Information Date
Covered by Health
Insurance

Response/Data
Type
[Date]

Description
The date the information was collected.

No
Yes
Client doesn't know
85

Medicaid

Medicare
State Children's
Health Insurance
Program (or use local
name)

Client prefers not to
answer
Data not collected
No
Yes
Medicaid is a partnership between federal
and state funds. It should always be listed
as Medicaid, not State Health Insurance.
No
Yes
No

Yes
Veteran's Health
Administration (VHA)

No
Yes

Employer-Provided
Health Insurance

No
Yes

Health Insurance
obtained through
COBRA

Including TRICARE available to Veterans
based on military service.

No

Yes
Private Pay Health
Insurance

No
Yes

State Health Insurance
for Adults (or use
local name)

No

Yes
Indian Health Services
Program

No
Yes

Other

No
Yes

Specify Source

[Text]

If “No” for each of the
health insurance

Applied; decision
pending

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

86

sources “no” Reason
(HOPWA ONLY)
Applied; client not
eligible
Client did not apply
Insurance type N/A
for this client
Client doesn't know
Client prefers not to
answer

4.05 Physical Disability

Data not collected

Rationale

To indicate whether clients have a physical disability that contributes to their experience of
homelessness or may be a factor in housing.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

Instructions
All Clients
HUD: CoC – Collection required for all components
except SSO Coordinated Entry
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all
components except Emergency Shelter or Street
Outreach
HUD: HOPWA – Collection required for all
components
HUD: Unsheltered Special NOFO – Collection
required for all components except SSO Coordinated
Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD
VASH Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
HHS: RHY – Collection required for all components
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types
Project Start, Update, Project Exit

In separate fields, indicate:
87

1. If each client has a physical disability; and
2. If there is an indication that the physical disability is expected to be of long-continued
and indefinite duration and substantially impair the client's ability to live independently.
Individual Physical 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. ‘Physical Disability’
update records should be created at any time during a project stay if a client's 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 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 record-keeping purposes, clients are not
required to provide documentation of the disability, nor does entering the information in the
HMIS constitute a “diagnosis” by the staff 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.08 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 disability, and also answer "No," that the disability is not expected to be of longcontinued, and indefinite duration and substantially impair the ability to live independently,
although a disability of such type may not qualify clients for programs meant for people with
severe disabilities and may not indicate a “disabling condition” according to data element 3.08.
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.
The system must record the appropriate Data Collection Stage for each record of this data
element. Systems must allow users to create 'update' records to document changes between
required collection points. Allow corrections for data entry errors at all stages.

Response Descriptions
Field Name

Response
Category/ Data
Type

Descriptions

Information Date

[Date]

The date the information was collected.

Physical Disability

No
Yes

For the purposes of these Data Standards, a
physical disability means a physical impairment.

Client doesn't
know
88

Client prefers not
to answer
Data not
collected
If Yes for
“Physical
Disability”

No

Expected to be of
long-continued
and indefinite
duration and
substantially
impairs ability to
live independently
Yes

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.

Client doesn't
know
Client prefers not
to answer
Data not
collected

4.06 Developmental Disability
Rationale

To indicate whether clients have a developmental disability which contributes to their experience
of homelessness or may be a factor in housing.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Instructions
All Clients
HUD: CoC – Collection required for all components
except SSO Coordinated Entry
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all
components except Emergency Shelter or Street
Outreach
HUD: HOPWA – Collection required for all
components
89

Header

Instructions
HUD: Unsheltered Special NOFO – Collection
required for all components except SSO Coordinated
Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD
VASH Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
HHS: RHY – Collection required for all components
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
Project Type Applicability
All HMIS Project Types
Collection Point
Project Start, Update, Project Exit
Indicate if each client has a developmental disability.
Individual ‘Developmental 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. ‘Developmental
Disability’ update records should be created at any time during a project stay if a client's
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 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 record-keeping purposes, clients are not
required to provide documentation of the disability, nor does entering the information in the
HMIS constitute a “diagnosis” by the staff who did the data collection or recording.
If the disability is present, the corresponding element 3.08 Disabling Condition should also be
“Yes” whether by manual data entry or in some systems, automatic population.
For residential homeless assistance programs, client intake as part of the program admission
process must be separated from the collection of disability information 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 an adult in the household.
The system must record the appropriate Data Collection Stage for each record of this data
element. Systems must allow users to create 'update' records to document changes between
required collection points. Allow corrections for data entry errors at all stages.

Response Descriptions
Field Name

Response
Category/ Data
Type

Descriptions

90

Information
Date

[Date]

The date the information was collected.

Developmental No
Disability
Yes

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 self-sufficiency.

Client doesn't
know
Client prefers not
to answer
Data not
collected

4.07 Chronic Health Condition
Rationale

To indicate whether clients have any disabling special needs that contribute to their experience
of homelessness or may be a factor in housing.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Project Type Applicability

Instructions
All Clients
HUD: CoC – Collection required for all components except SSO
Coordinated Entry
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all components
except Emergency Shelter or Street Outreach
HUD: HOPWA – Collection required for all components
HUD: Unsheltered Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
HHS: RHY – Collection required for all components
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types
91

Header
Collection Point
In separate fields, record:

Instructions
Project Start, Update, Project Exit

1. If the client has a chronic health condition; and
2. If there is an indication that the disability is expected to be of long-continued and
indefinite duration and substantially impair the client's ability to live independently.
Individual Chronic Health Condition records created at project start, update, and project exit are
to reflect the information as of the date of each phase of data collection. ‘Chronic Health
Condition’ update records should be created at any time during a project stay if a client's
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 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 record keeping purposes, clients are not
required to provide documentation of the disability, nor does entering the information in the
HMIS constitute a “diagnosis” by the staff 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.08 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 disability, and also answer "No," that the disability is not expected to be of longcontinued, and indefinite duration and substantially impair ability to live independently, although
a disability of such type may not qualify clients for programs meant for people with severe
disabilities and may not indicate a “disabling condition” according to the universal data element
3.08.
For residential homeless assistance programs, client intake as part of the program admission
process must be separated from the collection of disability information 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 an adult in the household.

Response Descriptions
Field Name

Response
Category/
Data Type

Descriptions

Information Date

[Date]

The date the information was collected.

Chronic Health
Condition

No

92

Yes

For the purposes of these Data Standards, a
chronic health condition means a diagnosed
condition that is more than three (3) months in
duration and is either not curable or has residual
effects that limit daily living and required
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; arthritis-related
conditions (including arthritis, rheumatoid arthritis,
gout, lupus, or fibromyalgia); adult onset cognitive
impairments (including traumatic brain injury, posttraumatic stress syndrome, dementia, and other
cognitive related conditions); severe
headache/migraine; cancer; chronic bronchitis;
liver condition; stroke; or emphysema.

Client doesn't
know
Client prefers
not to answer
Data not
collected
If Yes for “Chronic
Health Condition”
Expected to be of
long-continued and
indefinite duration
and substantially
impairs ability to live
independently

No

Yes

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.

Client doesn't
know

93

Client prefers
not to answer
Data not
collected

4.08 HIV/AIDS
Rationale

To indicate whether clients have HIV/AIDS, which contributes to their experience of
homelessness or may be a factor in housing.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

Instructions
All Clients
HUD: CoC – Collection required for all components except SSO
Coordinated Entry
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all components except
Emergency Shelter or Street Outreach
HUD: HOPWA – Collection required for all components
HUD: Unsheltered Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: Rural Special NOFO – Collection required for all components
except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all components
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types
Project Start, Update, Project Exit

94

Indicate if the client has HIV/AIDS.
HIV-related information is sensitive and may be protected by federal, state, and local privacy
protections. The client’s HIV/AIDS information should be recorded only when a project has data
confidentiality protections that conform to the CoC Privacy Notice and these legal requirements.
Individual HIV/AIDS records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. ‘HIV/AIDS’ update records should be
created at any time during a project stay if a client's 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 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 record-keeping purposes, clients are not
required to provide documentation of the disability, nor does entering the information in the
HMIS constitute a “diagnosis” by the staff who did the data collection or recording.
If the disability is present, the corresponding element 3.08 Disabling Condition should also be
“Yes” whether by manual data entry or in some systems, automatic population.
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 an adult in the household.

Response Descriptions
Field Name

Information Date
HIV/AIDS

Response Category/ Data
Type
[Date]
No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

Descriptions
The date the information was
collected.

4.09 Mental Health Disorder
Rationale

To indicate whether clients have any mental health disorders that contribute to their experience
of homelessness or may be a factor in housing.

95

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

Instructions
All Clients
HUD: CoC – Collection required for all components except
SSO Coordinated Entry
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all components
except Emergency Shelter or Street Outreach
HUD: HOPWA – Collection required for all components
HUD: Unsheltered Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
HHS: RHY – Collection required for all components
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types
Project Start, Update, Project Exit

In separate fields, indicate:
1. If each client has a mental health disorder; and
2. If there is an indication that the disability is expected to be of long-continued and
indefinite duration and substantially impair the client's ability to live independently.
Individual Mental Health Disorder records created at project start, update, and project exit are to
reflect the information as of the date of each phase of data collection. ‘Mental Health Disorder’
update records should be created at any time during a project stay if a client's 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 ‘Mental Health Disorder’ status was recorded
incorrectly at entry, update, or exit, correct the existing record rather than create a new update
record.
Unless the project funder requires documentation for record-keeping purposes, clients are not
required to provide documentation of the disability, nor does entering the information in the
HMIS constitute a “diagnosis” by the staff who did the data collection or recording.
If the ‘Mental Health Disorder’ is present and is expected to be of long-continued and indefinite
duration, the corresponding element 3.08 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 disability, and also answer "No", that the disability is not expected to
be of long-continued and indefinite duration and substantially impair the ability to live
independently, although a disability of such type may not qualify clients for programs meant for
96

people with severe disabilities and may not indicate a “disabling condition” according to the
universal data element 3.08.
For residential homeless assistance programs, client intake as part of the program admission
process must be separated from the collection of disability information 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 an adult in the household.

Response Descriptions
Field Name

Response Category/
Data Type

Descriptions

Information Date

[Date]

The date the information was
collected.

Mental Health
Disorder

No
Yes

For the purposes of these Data
Standards, a mental health disorder
may range from situational
depression to serious mental
illnesses. The dependent field is
designed to gauge the severity of the
mental health disorder.

Client doesn't know
Client prefers not to
answer
Data not collected
If Yes for “Mental
Health Disorder”
Expected to be of
long-continued
and indefinite
duration and
substantially
impairs ability to
live independently

No

97

Yes

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.

Client doesn't know
Client prefers not to
answer
Data not collected

4.10 Substance Use Disorder
Rationale

To indicate whether clients have a substance use disorder that contributes to their experience of
homelessness or may be a factor in housing.

Data Collection Instruction
Header
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

Instructions
All Clients
HUD: CoC – Collection required for all components except
SSO Coordinated Entry
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all components
except Emergency Shelter or Street Outreach
HUD: HOPWA – Collection required for all components
HUD: Unsheltered Special NOFO – Collection required for
all components except SSO Coordinated Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
HHS: RHY – Collection required for all components
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types
Project Start, Update, Project Exit

98

In separate fields, indicate:
1. If each client has the indicated disability; and
2. If there is an indication that the disability is expected to be of long-continued and
indefinite duration and substantially impair the client's ability to live independently.
Individual Substance Use Disorder records created at project start, update, and project exit are
to reflect the information as of the date of each phase of data collection. ‘Substance Use
Disorder’ update records should be created at any time during a project stay if a client's
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 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 record-keeping purposes, clients are not
required to provide documentation of the ‘Substance Use Disorder’, nor does entering the
information in the HMIS constitute a “diagnosis” by the staff 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.08 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 disability, and also answer "No," that the disability is not expected to be of longcontinued and indefinite duration and substantially impair the ability to live independently,
although a disability of such type may not qualify clients for programs meant for people with
severe disabilities and may not indicate a “disabling condition” according to the universal data
element 3.08.
For residential homeless assistance programs, client intake as part of the program admission
process must be separated from the collection of disability information 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 an adult in the household.

Response Descriptions
Field Name

Response
Category/ Data
Type

Descriptions

Information Date

[Date]

The date the information was collected.

Substance Use
Disorder

No
Alcohol use
disorder

Alcohol use disorder, without drug use disorder

99

Drug use disorder

Drug use disorder, without alcohol use disorder

Both alcohol and
drug use disorders
Client doesn’t know
Client prefers not to
answer
Data not collected
If Alcohol use
disorder, Drug
use disorder, or
Both alcohol and
drug use
disorders for
“Substance Use
Disorder”
Expected to be of
long-continued
and indefinite
duration and
substantially
impair ability to
live
independently

No

Yes

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.

Client doesn't know
Client prefers not to
answer
Data not collected

4.11 Domestic Violence
Rationale

To indicate whether the Head 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
100

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

Header
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

Instructions
Head of Household and Adult(s)
HUD: CoC – Collection required for all components except
SSO Coordinated Entry
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all components
except Emergency Shelter or Street Outreach
HUD: HOPWA – Collection required for all components
HUD: Unsheltered Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: Rural Special NOFO – Collection required for all
components except SSO Coordinated Entry
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all components
HHS: PATH – Collection required for all components
VA: SSVF – Collection required for RRH and Homelessness
Prevention
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
All HMIS Project Types
Project Start, Update

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. Verification of
domestic violence experience is not required.
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.
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
101

•

Choosing not to disclose data about clients with a history of domestic violence to other
homeless projects.

Projects are encouraged 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 staff. Staff can help clients understand that the HEARTH Act
definition of a DV includes “when a person is experiencing trauma or lack of safety related to, or
fleeing to attempting to flee, domestic violence, dating violence, sexual assault, stalking, or
other dangerous, traumatic, or life-threatening conditions related to the violence against the in
the individual's or family's current housing situation, including where the health and safety of
children are jeopardized” which is broader than a specific violent episode. The definition also
includes people who have no safe residence and lack the resources to obtain other safe
permanent housing. 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.'

Response Descriptions
Field Name

Response
Category/ Data
Type

Descriptions

Information Date

[Date]

The date the information was collected.

Survivor of
Domestic Violence

No
Yes
Client doesn’t
know
Client prefers not
to answer
Data not collected

If Yes for “Survivor
of Domestic
Violence”
When experience
occurred

Within the past
three months

Three to six
months ago
(excluding six
months exactly)
102

Six months to one
year ago
(excluding one
year exactly)
One year ago, or
more
Client doesn't
know
Client prefers not
to answer
Data not collected
If Yes for “Survivor
of Domestic
Violence”
Are you currently
fleeing?

No

Yes

Client doesn't
know
Client prefers not
to answer
Data not collected

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 Current Living Situation
Rationale

To record each contact with people experiencing homelessness by street outreach and other
projects. This element provides information on the number of contacts required to engage the
client as well as to document a current living situation each time the client is contacted.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Instructions
Head of Household and Adult(s)
HUD: CoC – Collection required for SSO – Street
Outreach, SSO – Coordinated Entry, and any YHDPfunded project type serving clients who meet Category
2 or 3 of the homeless definition
HUD: ESG – Collection only required for Street
Outreach and NbN shelter
HUD: ESG RUSH – Collection required for Street
Outreach, Coordinated Entry, and ES – NbN
HUD: Unsheltered Special NOFO – Collection required
for SSO – Street Outreach, SSO – Coordinated Entry
103

Project Type Applicability

Collection Point

HUD: Rural Special NOFO – Collection required for
SSO – Street Outreach, SSO – Coordinated Entry
HHS: PATH – Collection required for all components
HHS: RHY – Collection only required for Street
Outreach
1: Emergency Shelter – Night-by-Night
4: Street Outreach
6: Services Only
14: Coordinated Entry (or other depending on CoC
design of Coordinated Entry system)
Occurrence Point (At the Time of Contact)

Record the date and location of each interaction with a client by recording their Current Living
Situation. The first Current Living Situation with the client will occur at the same point as ‘Project
Start Date’ (and recording of client's Prior Living Situation) and therefore requires a client record
and project enrollment in the HMIS for the client. Refer to guidance in HMIS Program Manuals
(PATH, CoC, ESG, VA or RHY) for more details.
If the client’s Current Living Situation is in a temporary or permanent situation from the Living
Situation Options List of headers (See Appendix A), record additional housing status information
to calculate imminent and at-risk of homelessness housing statuses based on HUD's definition
of homelessness.
Street outreach projects are expected to record every contact made with each client by
recording their Current Living Situation, 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.
If a client meets CoC requirements for an automatic exit, their ‘Project Exit Date’ would be
backdated to the date of their most recent contact date, according to their Current Living
Situation record.
Contacts that require the collection of Current Living Situation include activities such as a
conversation between a street outreach staff 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 where a
conversation with the client occurred as the referral was being made.
For Coordinated Entry projects, record a Current Living Situation anytime any of the following
occurs:
1.
2.
3.
4.

A Project Start associated with Coordinated Entry; or
A Coordinated Entry Event is recorded; or
The client's living situation changes; or
If a Current Living Situation hasn't been recorded for longer than a community-defined
length of time (i.e., longer than 90 days). The CoC must be involved in the determination
of "community-defined length of time.”

Night-by-Night shelters should only record a Current Living Situation if the interaction between
the shelter personnel and client goes beyond a basic provision of shelter services. A Current
Living Situation for emergency shelter does not include activities of daily sheltering (e.g., bed
104

registration, request for personal care items, dinner sign-up, meals, etc.), nor should it be
redundant with data element 4.14 Bed-Night Date.
PATH-specific data collection instruction
Data Collection requirements for PATH-funded components are limited to the following fields
from the Living Situation Options List:
•
•
•
•
•

Place not meant for habitation (e.g., a vehicle, an abandoned building, bus/train/subway
station/airport or anywhere outside) (116)
Emergency shelter, including hotel or motel paid for with emergency shelter voucher, or
Host Home shelter (101)
Safe Haven (118)
Other (17)
Worker unable to determine (37)

Mobile HMIS data entry can be helpful when working in the field. If mobile data entry is not
possible, then client’s data will need to be securely recorded and transported for entry at an
office or it can be provided to a colleague by phone from a private setting for entry into HMIS.

Response Descriptions
Field Name

Response
Category/ Data
Type

Descriptions

Information Date

[Date]

The date the information was
collected.

Current Living Situation

See Appendix A

See Appendix A - Living Situation
Option List for a complete list of
Living Situation Responses and
Destinations

Rental Subsidy Type

See Appendix A

See Appendix A - Living Situation
Option List for a complete list of
Living Situation Responses and
Destinations

Living Situation verified by
Is client going to have to
leave their current living
situation within 14 days?

No

This field and subsequent
dependencies are applicable only to
CE projects.

Yes
Client doesn't know

105

Client prefers not to
answer
Data not collected
Has a subsequent residence
been identified?

Does individual or family
have resources or support
networks to obtain other
permanent housing?

No
Yes
Client doesn't know
Client prefers not to
answer
Data not collected
No

Yes
Client doesn't know
Client prefers not to
answer
Data not collected

Has the client had a lease or
ownership interest in a
permanent housing unit in
the last 60 days?

No

Yes
Client doesn't know
Client prefers not to
answer
Data not collected

Has the client moved 2 or
more times in the last 60
days?

No
Yes
Client doesn't know
Client prefers not to
answer
Data not collected

Location details

[text]

106

4.13 Date of Engagement
Rationale

To record the date the client became 'engaged' in project services after one or more contacts
with a street outreach project or night-by-night shelter.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

Instructions
Head of Household and Adults
HUD: CoC – Collection only required for Street
Outreach
HUD: ESG – Collection only required for Street
Outreach and ES – NbN
HUD: Unsheltered Special NOFO – Collection required
for Street Outreach
HUD: Rural Special NOFO – Collection required for
Street Outreach
HHS: PATH – Collection required for all components
HHS: RHY – Collection only required for Street
Outreach
Emergency Shelter – Night-by-Night
Street Outreach
Services Only
Occurrence Point (At the Point of Engagement)

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 project 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 once the criteria for “engagement” has been met.
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 Federal partner HMIS Program Manuals (PATH, CoC, ESG, and RHY) for
more details.

Response Descriptions
Field Name

Response
Category/ Data
Type

Descriptions

Date of
Engagement

[Date]

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

4.14 Bed-Night Date
Rationale

To determine each bed-night utilized by a client in a night-by-night shelter.

Data Collection Instruction

Header
Data Collected About
Funder: Component - Program

Instructions
All Clients
HUD: ESG - Collection required for ES – NbN
HUD: ESG RUSH – Collection required for ES - NbN
Project Type Applicability
Emergency Shelter – Night-by-Night
(Applicability extends to all NbN type emergency
shelters that participate in HMIS, regardless of funding
source)
Collection Point
Occurrence Point (as Provided)
A Bed-Night Date record indicates that the client has utilized a bed in a night-by-night (NbN)
shelter on that date. CoCs are reminded that all household members should have a bed night
recorded, not just the Head of Household as the "Data Collected About" specification requires.
Use the methodology built into the HMIS software to record the date of each night a client stays
in a bed. This may be a manual data entry, scan card system, check off, etc. Collect once for
each bed night utilized.
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’.
4.14 Bed Night is critical for auto-exit policies for NbN shelters, and guidance in 3.11 Project
Exit Date and data collection guidance by project type for NbN shelters should be strictly
enforced.
A bed night date indicates that the client has utilized a bed in a night-by-night shelter on that
date. The HMIS must be able to store a theoretically unlimited number of bed night dates for
any Enrollment ID associated with a night-by-night shelter.

Response Descriptions
Field Name

Response
Category/ Data
Type

Descriptions

Bed-Night
Date

[Date]

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

4.19 Coordinated Entry Assessment
Rationale

The CE Assessment element is a flexible data element that collects an assessment date,
location, and result. It allows CoCs to define their own assessment questions and responses
and categorizes each assessment into different types: Crisis Needs or Housing Needs. This
data element is intended to standardize data collection on core components of Coordinated
Entry like access, assessment, referral, and prioritization.
108

Data Collection Instruction
Header

Instructions

Funder: Program-Component 

HUD: CoC – Collection required for all components
providing Coordinated Entry 
HUD: ESG – Collection required for all components
providing Coordinated Entry
Coordinated Entry (or other depending on CoC design
of Coordinated Entry system)
Head of Household 
At occurrence  

Project Type Applicability 
Data Collected About 
Collection Point 

Indicate the 'Date of Assessment', 'Assessment Location,’ 'Assessment Type,’ 'Assessment
Level,’ assessment questions and results, and the 'Prioritization Status' of the coordinated entry
assessment.
CoCs may set up as many versions of assessments as is necessary for the Coordinated Entry
structure they operate (e.g., different sets of questions for families than individuals), as long as
each assessment is indicated as being either a Crisis Needs Assessment or a Housing Needs
Assessment.
The Coordinated Entry Assessment element is only used in 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 includes Coordinated Entry activities that
are conducted at a specified, centralized location within a CoC and those activities that are
conducted as a formal part of the Coordinated Entry system on-site in organizations that also
operate other project types (e.g., Homelessness Prevention, Services Only, or others),
depending on the particular setup in each CoC.

Response Descriptions
Field Name

Date of
Assessment
Assessment
Location
Assessment Type

Response Category/Data
Type
[Date]

Description

Administrator-managed list
of locations
Phone
Virtual

Community-defined values; Could
derive from HMIS Project List.
Assessment was conducted by phone.
Assessment was conducted virtually,
not face-to-face (i.e., website or app).
Assessment was conducted in person
(face-to-face).
Assessment conducted for immediate,
crisis-based needs; initial, short,
focused assessment to help case
workers identify immediate resolutions
to address emergency needs, including
shelter.
Assessment conducted for housing
needs; more in-depth, housing focused

In Person
Assessment Level

Crisis Needs Assessment

Housing Needs
Assessment

The date the assessment occurred.

109

Assessment
Questions

Locally determined fields

Assessment
Answers
Assessment Result
Type
Assessment Result

Locally determined fields

Prioritization Status

Placed on prioritization list

Locally determined fields
Locally determined fields

Not placed on prioritization
list

assessment to help case workers direct
clients to resources for stabilization of
their housing situation.
Assessment Questions and Assessment
Answers are a list of key-value (question
and response) pairs for every question
in the assessment, e.g. “Where did you
sleep last night”/ “On the streets.”
Responses to Questions asked in
”Assessment Questions” field.
Results structured as defined by the
community
Results for each result type defined in
“Assessment Result Type”
The result of the assessment is the
client was placed on the community’s
prioritization list for housing resources.
The result of the assessment is the
client was not placed on the
community’s prioritization list for housing
resources.

4.20 Coordinated Entry Event
Rationale

The Coordinated Entry Event element is designed to capture key referral and placement events,
as well as the results of those events. It will help communities understand the events that go
into achieving desired (and undesired) results through the Coordinated Entry system. This data
element is intended to standardize data collection on core components of Coordinated Entry like
access, assessment, referral, and prioritization.

Data Collection Instruction

Header
Funder: Program-Component 

Instructions
HUD: CoC – Collection required for all components
providing Coordinated Entry 
HUD: ESG – Collection required for all components
providing Coordinated Entry

Project Type Applicability 

Coordinated Entry (or other depending on CoC design
of Coordinated Entry system)
Head of Household 
At occurrence  

Data Collected About 
Collection Point 

In separate fields, record the 'Date' and relevant 'Event.’ When known, return to the record and
record the appropriate result for each 'Event' recorded. Record, in separate Event records, as
many ‘Events’ as is necessary for each client for the duration of their enrollment in the
Coordinated Entry project. Coordinated Entry Events may be recorded at the same time as a

110

Coordinated Entry Assessment, or they may be independent of any Coordinated Entry
Assessment that has occurred.
Recording any event in Field 2, Responses 10 through 15, 17 and 18 indicates there is an
opening for the client to be housed by the project.

Response Descriptions
Field Name

Date of Event
Event

Response
Category/Data Type
[Date]
Header: Access
Events
Referral to a
Prevention
Assistance project
Problem Solving/
Diversion/ Rapid
Resolution
intervention or
service

Description

Referral to a
scheduled
Coordinated Entry
Crisis Needs
Assessment

The client received a referral to a
Coordinated Entry Crisis Needs Assessment;
or other local equivalent assessment. For a
description of Crisis Needs Assessment,
please see Data Element 4.19 CE
Assessment.
The client received a referral to a
Coordinated Entry Housing Needs
Assessment; or other local equivalent
assessment. For a description of Housing
Needs Assessment, please see Data
Element 4.19 CE Assessment.
[Not a response option]

Referral to a
scheduled
Coordinated Entry
Housing Needs
Assessment
Header: Referral
Events
Referral to postplacement/ follow-up
case management

Referral to a Street
Outreach project or
services

The date the event occurred.
[Not a response option]
The client received a referral to a
homelessness prevention assistance project;
or other local equivalent project.
The client participated in a diversion or rapid
resolution problem –solving conversation and
received assistance, or other local equivalent.

The client received a referral to a postplacement service or follow-up case
management, or other local equivalent.
Post-placement/follow-up case management
services are services provided to clients after
they have exited a residential project. These
types of services are not limited to any
particular project type.
The client received a referral to a Street
Outreach project or services, or other local
equivalent referral. See 2.02 Project
Information for the definition of a Street
Outreach project.

111

Referral to a Housing
Navigation project or
services

Referral to Noncontinuum services:
Ineligible for
continuum services

Referral to Noncontinuum services:
No availability in
continuum services
Referral to
Emergency Shelter
bed opening
Referral to
Transitional Housing
bed/unit opening

Referral to Joint THRRH
project/unit/resource
opening
Referral to RRH
project resource
opening
Referral to PSH
project resource
opening

The client received a referral to an SSO or
other service only project or service for the
purpose of receiving Housing Navigation
services, or other local equivalent referral
because a specific bed or unit in another
project is not immediately available.
Housing navigation services include
assistance with identifying, preparing
documentation for, or applying for appropriate
housing, including subsidized and nonsubsidized housing.
The client received a referral to noncontinuum services because they were
ineligible for continuum services, or other
local equivalent referral. Non-continuum
services may include emergency assistance
projects for those not at-risk of or
experiencing homelessness.
Eligible clients who could not be referred to
continuum services because there is no
availability in continuum services, or because
client was eligible but was not prioritized for
continuum services or other local equivalent
referral.
The client was provided with information
regarding how to access an emergency
shelter bed or opening. A “referral” indicates
there is an opening for the client to be
housed by this project (or local equivalent).
The client was provided with information
regarding how to access a TH bed/unit
opening. A “referral” indicates there is an
opening for the client to be housed by this
project (or local equivalent).
The client was provided with information
regarding how to access a joint component
project bed/unit opening. A “referral” indicates
there is an opening for the client to be
housed by this project (or local equivalent).
The client was provided with information
regarding how to access a RRH bed/unit
opening. A “referral” indicates there is an
opening for the client to be housed by this
project (or local equivalent).
The client was provided with information
regarding how to access a PSH bed/unit
opening. A “referral” indicates there is an
opening for the client to be housed by this
project (or local equivalent).
112

Referral to Other PH
project/unit/resource
opening
Referral to
emergency
assistance/flex
fund/furniture
assistance
Referral to a Housing
Stability Voucher

Problem
Solving/Diversion/R
apid Resolution
intervention or
service result Client housed/rehoused in a safe
alternative

No

Referral to postplacement/followup case
management result
- Enrolled in
Aftercare project

No

Yes

Yes

Location of Crisis
Housing or
Permanent Housing
Referral [Project
name and/or Project
ID]

System-generated
list of project IDs
accepting referrals
from CE

The client was provided with information
regarding how to access an “other PH”
bed/unit opening. A “referral” indicates there
is an opening for the client to be housed by
this project (or local equivalent).
The client was referred to a one-time,
nominal financial assistance service to assist
in securing or maintaining housing.
The client was referred to a Housing Stability
Voucher that is targeted to people
experiencing homelessness funded through
public housing agencies. A “referral” indicates
there is an opening for the client to be
housed by this project (or local equivalent).
The result of the diversion or rapid resolution
problem – solving conversation and
assistance or other local equivalent was that
the client did not get housed/rehoused in a
safe alternative and requires additional
assistance.
The result of the diversion or rapid resolution
problem – solving conversation and
assistance, or other local equivalent was that
the client was housed/rehoused in a safe
alternative. The client should be exited from
the CE project at this point.
If the client received a referral to a postplacement service or follow-up case
management, or other local equivalent
referral, subsequent follow-up with the client
or project indicates the client did not enroll
into the referred project.
If the client received a referral to a postplacement service or follow-up case
management, or other local equivalent
referral, subsequent follow-up with the client
or project indicates the client did enroll into
the referred project. .
If a client was referred to an opening in a
continuum crisis housing or permanent
housing project, select the Project Name and
HMIS Project ID of the referred project.

113

Referral Result

Successful referral:
client accepted

Unsuccessful
referral: client
rejected
Unsuccessful
referral: provider
rejected

Date of Result

If a client was referred to an opening in a
continuum crisis housing or permanent
housing project, subsequent follow-up with
the client or provider indicates the client was
accepted into the project opening.
If a client was referred to an opening in a
continuum crisis housing or permanent
housing project, subsequent follow-up with
the client or provider indicates the client
decided to reject the referral to the project.
If a client was referred to an opening in a
continuum crisis housing or permanent
housing project, subsequent follow-up with
the client or provider indicates the client
referral was rejected by the provider.
A provider may determine, after meeting with
the client and reviewing eligibility
documentation, that a client is not eligible for
a project and reject the referral. Or a provider
may reject a client referral if the client failed
to respond to the provider requests for
eligibility information or otherwise failed to
follow through with the requirements of the
referral.
The date the client or project indicates the
referral was successful or unsuccessful.

[Date]

Federal Partner Program Specific Data Elements

Additional guidance about data collection rationale and specific project setup and data collection
instructions can be found in the federal partner program HMIS Manuals available on the HUD
Exchange. This manual contains only general information about the element and basic
minimum data collection instructions.

CoC

Please see the CoC Program HMIS Manual for additional guidance on the rationale and data
collection instructions for C2 Moving on Assistance Provided and C4 Translation Assistance
Needed. Additional instructions for C3 Youth Education Status can be found in the YHDP HMIS
Manual.

C2 Moving On Assistance Provided
Rationale

To understand the type of moving on assistance provided to PSH participants.

Data Collection Instruction
Header
Funder: Component Program

Instructions
HUD: CoC – Collection required for Permanent Supportive
Housing
114

Header

Project Type Applicability
Data Collected About
Collection Point

Response Descriptions

Instructions
HUD: Unsheltered Special NOFO – Collection required for
Permanent Supportive Housing
HUD: Rural Special NOFO – Collection required for Permanent
Supportive Housing
PH-Permanent Supportive Housing (disability required for
entry)
Head of Household
Occurrence Point (as provided)

Field Name

Response Category/ Data Type

Date of Moving On
Assistance

[Date]

Moving On Assistance

Subsidized housing application assistance
Financial assistance for Moving On (e.g., security deposit,
moving expenses)
Non-financial assistance for Moving On (e.g., housing
navigation, transition support)
Housing referral/placement
Other (please specify)

Other (please specific)

[text]

C3 Youth Education Status
Rationale

To determine whether youth heads of household are accessing educational programs at the
time of project start and exit, and to allow for analyzing changes in education status of youth
between project start and exit.

Data Collection Instruction
Header
Funder: Component Program
Project Type Applicability

Data Collected About
Collection Point

Instructions
HUD: CoC – Youth Homeless Demonstration Program
(YHDP)
Transitional Housing
PH – Permanent Supportive Housing (disability required for
entry) Services Only
Other
PH: Rapid Re-Housing
Head of Household
Project Start, Project Exit
115

Response Descriptions
Field Name

Response Category/ Data Type

Information Date

[Date]

Current school enrollment Not currently enrolled in any school or educational course
and attendance
Currently enrolled but NOT attending regularly (when school or
the course is in session)
Currently enrolled and attending regularly (when school or the
course is in session)
Client doesn't know
Client prefers not to answer
Data not collected
Most recent Educational
Status

K12: Graduated from high school
K12: Obtained GED
K12: Dropped out
K12: Suspended
K12: Expelled
Higher Education: Pursuing a credential but not currently
attending

Current educational
status

Higher Education: Dropped out
Higher education: Obtained a credential/degree
Client doesn't know
Client prefers not to answer
Data not collected
Pursuing a high school diploma or GED
Pursuing Associate's Degree
Pursuing Bachelor's Degree
Pursuing Graduate Degree
Pursuing other post-secondary credential
Client doesn't know
Client prefers not to answer
Data not collected
116

C4 Translation Assistance Needed
Rationale

This data element is used to understand how many clients need access to translation services,
and if so, which languages are most often cited as needing translation.

Data Collection Instruction

Header
Funder: Component - Program

Project Type Applicability
Data Collected About
Collection Point

Response Descriptions

Field Name
Translation Assistance Needed

Preferred Language

If Different Preferred Language,
please specify

Instructions
HUD: CoC – Collection required for all components
HUD: ESG – Collection required for all components
HUD: ESG RUSH – Collection required for all
components except Emergency Shelter and Street
Outreach
HUD: Unsheltered Special NOFO – Collection
required for all components
HUD: Rural Special NOFO – Collection required for
all components
HUD: HOPWA – Collection required for all
All Project Types
Head of Household
Project Start

Response Category/ Data Type
No
Yes
Client doesn’t know
Client prefers not to answer
Data not collected
[up to twenty languages selected by the HMIS
Lead]
Different Preferred Language
Client Doesn’t Know
Client prefers not to answer
Data not collected
[Text]

HOPWA

Please see the HOPWA Program HMIS Manual for additional guidance on the rationale, data
collection instructions, and response descriptions for all HOPWA data elements.

W1 Services Provided – HOPWA
Rationale

To determine the services provided to clients during project participation.

117

Data Collection Instruction
Header

Instructions

Funder: ProgramComponent
Project Type
Applicability

HUD: HOPWA – Collection required for all components

Data Collected About

Emergency Shelter - Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for
entry)
Services Only
Homelessness Prevention
All clients receiving services

Collection Point

Occurrence Point (As Provided)

Response Descriptions
Field Name

Response Category/ Data Type

Date of Service

[Date]

Type of Service

Adult day care and personal assistance
Case management
Child care
Criminal justice/legal services
Education
Employment and training services
Food/meals/nutritional services
Health/medical care
Life skills training
Mental health care/counseling
Outreach and/or engagement
Substance use services/treatment
Transportation
Other HOPWA funded service

W2 Financial Assistance – HOPWA
Rationale

To track HOPWA financial assistance provided to clients in Permanent Housing Placement,
Tenant-Based Rental Assistance (TBRA) or Short-Term Rent, Mortgage, and Utilities (STRMU)
during project participation.

118

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type Applicability
Data Collected About
Collection Point

Instructions
HUD: HOPWA – Collection required for PHP and STRMU
only as indicated above
Services Only
Homelessness Prevention
Head of Household
Occurrence Point (As Provided)

Response Descriptions
Field Name

Response Category/ Data Type

Date of Financial
Assistance

[Date]

Financial Assistance Type

Rental assistance
Security deposits
Utility deposits
Utility payments
Mortgage assistance

Financial Assistance
Amount

[Currency/Decimal]

W3 Medical Assistance
Rationale

Medical assistance information is important to determine whether HIV positive clients in
households served by all HOPWA component types are accessing medical assistance benefits
for which they may be eligible. Medical Assistance (W3) is designed to collect information on
assistance provided to clients with HIV/AIDS.

Data Collection Instruction
Header

Instructions

Funder: ProgramComponent
Project Type
Applicability

HUD: HOPWA – Collection required for all components

Data Collected About

Emergency Shelter – Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for entry)
Services Only
Homelessness Prevention
All Household Members with HIV/AIDS

Collection Point

Project Start, Update, Project Exit

119

Response Descriptions
Field Name

Response Category/ Data Type

Information Date

[Date]

Receiving AIDS Drug Assistance
Program (ADAP)

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

If No for “Receiving AIDS Drug
Assistance Program (ADAP)”

Applied; decision pending

Reason
Applied; client not eligible
Client did not apply
Insurance type N/A for this client
Client doesn't know
Client prefers not to answer
Data not collected
Receiving Ryan White-funded
Medical or Dental Assistance

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

If No for “Receiving Ryan Whitefunded Medical or Dental
Assistance”

Applied; decision pending

Reason
Applied; client not eligible
Client did not apply
Insurance type N/A for this client
Client doesn't know
Client prefers not to answer
Data not collected

120

W4 T-cell (CD4) and Viral Load
Rationale

To measure the extent to which housing impacts the health of persons with HIV/AIDS in
households served by all HOPWA component types.

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type
Applicability

Data Collected About
Collection Point

Instructions
HUD: HOPWA – Collection required for all components
Emergency Shelter – Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for entry)
Services Only
Homelessness Prevention
All Household Members with HIV/AIDS
Project Start, Update, Annual Assessment, Project Exit

Response Descriptions
Field Name

Response Category/ Data Type

Information Date

[Date]

T-Cell (CD4) Count Available

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

If a yes to “T-Cell (CD4) Count
Available” then

[Integer between 0-1500]

T-cell Count (integer between 0 –
1500)
If a number is entered in the TCell (CD4) count, then

Medical Report

How was the information
obtained
Client Report
Other
Viral Load Information Available

Not Available
Available
Undetectable
Client doesn't know
121

Client prefers not to answer
Data not collected
If “Viral Load Information
Available” then

[Integer between 0-999999]

Count (integer between 0 –
999999)
If a number is entered in the Viral
Load count, then

Medical report

How was the information
obtained
Client report
Other

W5 Housing Assessment at Exit
Rationale

To determine whether clients exiting all HOPWA component types have remained stably housed.

Data Collection Instruction
Header
Funder: ProgramComponent

Project Type
Applicability

Data Collected About
Collection Point

Instructions
HUD: CoC – Collection required only for Homelessness Prevention
component
HUD: ESG – Collection required only for Homelessness
Prevention component
HUD: ESG-RUSH – Collection required for Homelessness
Prevention component
HUD: HOPWA – Collection required for all components
Emergency Shelter – Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for entry)
Services Only
Homelessness Prevention
All Clients
Project Exit

Response Descriptions
Field Name

Response Category/ Data Type

Housing Assessment
at Exit

Able to maintain the housing they had at project entry
Moved to new housing unit
Moved in with family/friends on a temporary basis
Moved in with family/friends on a permanent basis
122

Moved to a transitional or temporary housing facility or program
Client became homeless – moving to a shelter or other place unfit
for human habitation
Jail/prison
Deceased
Client doesn't know
Client prefers not to answer
Data not collected
If Able to maintain the
housing they had at
project entry for
“Housing Assessment
at Exit”

Without a subsidy

Subsidy information
With the subsidy they had at project entry
With an on-going subsidy acquired since project entry
Only with financial assistance other than a subsidy
If Moved to new
housing unit for
“Housing Assessment
at Exit”

With on-going subsidy

Subsidy information
Without an on-going subsidy

W6 Prescribed Anti-Retroviral
Rationale

To measure the extent to which housing impacts participation in care for persons with HIV/AIDS
in households served by all HOPWA component types.

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type
Applicability

Data Collected About
Collection Point

Instructions
HUD: HOPWA – collection required for all components
Emergency Shelter – Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for entry)
Services Only
Homeless Prevention
All Household Members with HIV/AIDS
Project Start, Update, Project Exit

123

Response Descriptions
Field Name
Information Date
Has the participant
been prescribed antiretroviral drugs?

Response Category/ Data Type
[date]
No
Yes
Client doesn't know
Client prefers not to answer
Data Not Collected

PATH

Please see the PATH Program HMIS Manual for additional guidance on the rationale, data
collection instructions, and response descriptions for all PATH data elements.

P1 Services Provided – PATH Funded
Rationale

To determine the PATH-funded services that are provided to a client during and throughout
project enrollment and prior to project exit.

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type
Applicability
Data Collected About
Collection Point

Instructions
HHS: PATH – Collection required for all components
Street Outreach
Services Only
Head of Household and Adults
Occurrence Point (As Provided)

Response Descriptions
Field Name

Response Category/ Data Type

Date of Service

[Date]

Type of PATH FUNDED
Service Provided

Re-engagement
Screening
Clinical assessment
Habilitation/rehabilitation
Community Mental Health
Substance use treatment
Case management
124

Residential supportive services
Housing minor renovation
Housing moving assistance
Housing eligibility determination
Security deposits
One-time rent for eviction prevention

P2 Referrals Provided – PATH
Rationale

To determine the referrals that are made on behalf of a client during project enrollment.

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type
Applicability
Data Collected About
Collection Point

Instructions
HHS: PATH – Collection required for all components
Street Outreach
Services Only
Head of Household and Adults
Occurrence Point (As Provided)

Response Descriptions
Field Name

Response Category/ Data Type

Date of Referral

[Date]

Type of Referral

Community Mental Health
Substance Use Treatment
Primary Health/ Dental Care
Job Training
Educational Services
Housing Services
Temporary Housing
Permanent Housing
Income Assistance
Employment Assistance
Medical Insurance

If any “Type of Referral”
made

Attained

Select Outcome for each
125

Not Attained
Unknown

P3 PATH Status
Rationale

To determine whether a client is eligible for the PATH program.

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type
Applicability
Data Collected About
Collection Point

Instructions
HHS: PATH – Collection required for all components
Street Outreach
Services Only
Head of Household and Adults
Occurrence Point (At Determination; collect once, at or before exit,
when the status is determined)

Response Descriptions
Field Name

Response Category/ Data Type

Date of Status
Determination

[Date]

Client Became Enrolled in
PATH

No
Yes

If No for “Client Became
Enrolled in PATH”

Client was found ineligible for PATH

Reason not enrolled
Client was not enrolled for other reason(s)
Unable to locate client

P4 Connection with SOAR
Rationale

Connection with SOAR is intended to determine if the client has been connected to the
SSI/SSDI Outreach, Access, and Recovery (SOAR) program, regardless of whether that
connection was established by the PATH provider or not.

Data Collection Instruction

Header
Funder: Program-Component

Instructions
HHS: PATH – Collection required for all components
126

Header
Project Type Applicability

Data Collected About
Collection Point

Instructions
VA: SSVF – Collection required for RRH and
Homelessness Prevention
Street Outreach
Services Only
12: Homelessness Prevention
13: PH – Rapid Re-Housing
Head of Household and Adults
Project Start, Update, Annual Assessment, and Exit

Response Descriptions
Field Name

Response Category/ Data Type

Connection with SOAR

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

RHY

The RHY Program HMIS Manual contains HMIS data collection instructions and the RHY Data
Collection User Guide contains all RHY data element rationale and response description
information.

R1 Referral Source
Rationale

Referral sources indicate the person, place or organization that referred the youth to the project
they are entering.

Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

Instructions
HHS: RHY – Collection required for all components
except for Street Outreach
Emergency Shelter –- Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Start

Response Descriptions
Field Name

Response Category/ Data Type

Referral Source

Self-Referral
127

Individual: Parent/Guardian/Relative/ Friend/Foster
Parent/ Other Individual
Outreach Project
Temporary Shelter
Residential Project
Hotline
Child Welfare/ CPS
Juvenile Justice
Law Enforcement / Police
Mental Hospital
School
Other Organization
Client doesn't know
Client prefers not to answer
Data not collected
If Outreach Project: FYSB for
“Referral Source” is selected,
number of times approached by
outreach prior to entering the
project

[Integer]

R2 RHY – BCP Status
Rationale

This element serves a three-fold purpose:
A. Enables a BCP emergency shelter to record a youth that is not eligible under the FYSBRHY program and collect information about them. Upon reporting to RHY for the federal
transfer, RHY is then able to remove these youth from their program and congressional
reports.
B. Facilitates the local CoC and HMIS to utilize participation in BCP as part of their point-intime and other counts and measures.
C. Identifies the number of runaway youth.

Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

Instructions
HHS: RHY – Collection required for BCP Only
Emergency Shelter – Entry Exit
Homelessness Prevention
All clients
Project Start

128

Response Descriptions
Field Name

Response Category/ Data Type

Date of Status Determination

[Date]

Youth Eligible for RHY Services

No
Yes

If No for “Youth Eligible for RHY
Services”

Out of age range

Reason why services are not
funded by BCP grant
Ward of the State – Immediate Reunification
Ward of the Criminal Justice System - Immediate
Reunification
Other
If Yes for “Youth Eligible for
RHY Services”

No

Runaway youth
Yes
Client doesn't know
Client prefers not to answer
Data not collected

R4 Last Grade Completed
Rationale

The purpose is to identify the educational attainment of youth served in RHY projects as well as,
when appropriate, measure a change in education from project start to project exit for all Head
of Households and youth.

Data Collection Instruction
Header

Instructions

Funder: Program-Component

HUD: HUD-VASH – Collection required for HUD/VASHContinuum
HHS: RHY – Collection required for all components except
for Street Outreach

129

Header

Instructions
VA: SSVF – Collection required for RRH and
Homelessness Prevention

Project Type Applicability

Data Collected About
Collection Point

Emergency Shelter - Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required
for entry)
Homelessness Prevention
PH – Rapid Re-Housing
Head of Household and Adults
Project Start, Project Exit

Response Descriptions
Field Name

Response Category/ Data Type

Last Grade Completed

Less than Grade 5
Grades 5-6
Grades 7-8
Grades 9-11
Grade 12/High school diploma
School program does not have grade levels
GED
Some college
Associate's degree
Bachelor's degree
Graduate degree
Vocational Certification
Client doesn't know
Client prefers not to answer
Data not collected

R5 School Status
Rationale

The purpose is to identify the educational status of youth served in RHY projects as well as,
when appropriate, measure a change in school status from project start to project exit for all
Head of Households and youth.

130

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type
Applicability

Data Collected About
Collection Point

Instructions
HHS: RHY – Collection required for all components except for
Street Outreach
Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Start, Project Exit

Response Descriptions
Field Name

Response Category/ Data Type

School Status

Attending school regularly
Attending school irregularly
Graduated from high school
Obtained GED
Dropped out
Suspended
Expelled
Client doesn't know
Client prefers not to answer
Data not collected

R6 Employment Status
Rationale

The purpose is to assess a client’s employment status and need for employment services as
well as, when appropriate, measure a change in employment from project start to project exit for
all Head of Households and adults.

Data Collection Instruction
Header
Funder: ProgramComponent

Project Type
Applicability

Data Collected About

Instructions
HUD: HUD-VASH – Collection required for HUD/VASH-Continuum
HHS: RHY – Collection required for all components except for
Street Outreach
VA: SSVF – Collection required for RRH and Homelessness
Prevention
VA: GPD – collection required for all components
Emergency Shelter - Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for entry)
Safe Haven
PH – Housing Only
Homelessness Prevention
PH – Rapid Re-Housing
SSO – Supportive Services Only
Head of Household and Adults
131

Header
Collection Point

Instructions
Project Start, Project Exit

Response Descriptions
Field Name

Response Category/ Data Type

Information Date

[Date]

Employed

No
Yes
Client doesn’t know
Client prefers not to answer
Data not collected

If Yes for “Employed”

Full-time

Type of Employment
Part-time
Seasonal / Sporadic (including day labor)
If No for “Employed”

Looking for work

Why Not Employed
Unable to work
Not looking for work

R7 General Health Status
Rationale

Information on health status (general health, dental health, and mental health) is a first step to
identifying what types of health services a client may need. This element permits comparison
between homeless youth to other youth their age as well as measure a change in status from
project start to project exit for all heads of household and adults.

Data Collection Instruction
Header

Instructions

Funder: ProgramComponent

HUD: HUD-VASH – Collection required for HUD/VASHCollaborative Case Management
HHS: RHY – Collection required for all components except
for Street Outreach

Project Type Applicability

Emergency Shelter - Entry Exit
Transitional Housing
PH - Permanent Supportive Housing (disability required for
entry)
Homelessness Prevention
132

Header

Instructions

Data Collected About
Collection Point

Head of Household and Adults
Project Start, Project Exit

Response Descriptions
Field Name
General Health Status

Response Category/ Data Type
Excellent
Very Good
Good
Fair
Poor
Client doesn't know
Client prefers not to answer
Data not collected

R8 Dental Health Status
Rationale

Information on health status (general health, dental health, and mental health) is a first step to
identifying what types of health services a client may need. This element permits comparison
between homeless youth to other youth their age as well as measure a change in status from
project start to project exit for all heads of household and adults.

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type Applicability
Data Collected About
Collection Point

Response Descriptions

Instructions
HHS: RHY – Collection required for all components except
for Street Outreach
Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Start, Project Exit

Field Name

Response Category/ Data Type

Dental Health Status

Excellent
Very Good
Good
Fair
Poor
Client doesn't know
Client prefers not to answer
Data not collected
133

R9 Mental Health Status
Rationale

Information on health status (general health, dental health, and mental health) is a first step to
identifying what types of health services a client may need. This element permits comparison
between homeless youth to other youth their age as well as measure a change in status from
project start to project exit for all heads of household and adults.

Data Collection Instruction
Header
Funder: ProgramComponent

Instructions
HHS: RHY – Collection required for all components except for
Street Outreach

Project Type
Applicability

Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Start, Project Exit

Data Collected About
Collection Point

Response Descriptions
Field Name

Response Category/ Data Type

Mental Health Status

Excellent
Very Good
Good
Fair
Poor
Client doesn't know
Client prefers not to answer
Data not collected

R10 Pregnancy Status
Rationale

The purpose is to determine the number of people starting projects while pregnant and to
determine eligibility for benefits and need for services.

Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability

Data Collected About
Collection Point

Instructions
HHS: RHY – Collection required for all components
Emergency Shelter - Entry Exit
Transitional Housing
Street Outreach
Homelessness Prevention
Head of Household and Adults
Project Start, Update
134

Response Descriptions
Field Name

Response Category/ Data Type

Pregnancy Status

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

If Yes for “Pregnancy Status”

[Date]

Due Date (date) [date field]

R11 Formerly a Ward of Child Welfare/Foster Care Agency
Rationale

The purpose is to identify clients with child welfare or foster care histories.

Data Collection Instruction
Header

Instructions

Funder: Program-Component

HHS: RHY – Collection required for all components except
for Street Outreach
Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Start

Project Type Applicability
Data Collected About
Collection Point

Response Descriptions
Field Name

Response Category/ Data Type

Formerly a Ward of Child Welfare/Foster
Care Agency

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

If Yes for “Formerly a Ward of Child
Welfare/Foster Care Agency”

Less than one year

Number of Years
1 to 2 years
3 to 5 years
135

If Less than one year for “Number of
Years”

[Integer 1-11]

Number of Months (1-11)

R12 Formerly a Ward of Juvenile Justice System
Rationale

The purpose is to identify clients with juvenile justice system responsibility histories.

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type Applicability
Data Collected About
Collection Point

Response Descriptions

Instructions
HHS: RHY – Collection required for all components except
for Street Outreach
Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Start

Field Name

Response Category/ Data Type

Formerly a Ward of Juvenile
Justice System

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

If Yes for “Formerly a Ward of
Juvenile Justice System”

Less than one year

Number of Years
1 to 2 years
3 to 5 years
If Less than one year for
“Number of Years”

[Integer 1-11]

Number of Months (1-11)

R13 Family Critical Issues
Rationale

The purpose is to identify specific family issues faced by youth in RHY programs that may have
contributed to the youth’s homelessness or is a factor in family reunification.

136

Data Collection Instruction
Header
Funder: ProgramComponent
Project Type Applicability

Instructions
HHS: RHY – Collection required for all components except
for Street Outreach
Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Start

Data Collected About
Collection Point

Response Descriptions
Field Name

Response Category/ Data Type

Unemployment – Family member

No
Yes

Mental Health Disorder – Family
member

No
Yes

Physical Disability – Family member

No
Yes

Alcohol or Substance Use Disorder
– Family member

No
Yes

Insufficient Income to Support Youth
– Family member

No
Yes

Incarcerated Parent of Youth

No
Yes

R14 RHY Service Connections
Rationale

The RHY service connections enable projects to report on the services that they either directly
provided youth through their project or at their organization or which they facilitated being
provided by another provider during the project stay for all heads of household and adults.

Data Collection Instruction
Header
Funder: Program Component
Project Type
Applicability

Instructions
HHS: RHY – Collection required for components – as outlined below
Emergency Shelter - Entry Exit
Transitional Housing
Services Only
137

Header
Data Collected About
Collection Point

Instructions
Homelessness Prevention
Head of Household and Adults
Occurrence Point (At First Service)

138

Response Descriptions
Field Name

Response Category/ Data
Type

BCPp

BCPes

TLP &
MGH

DEMO

Date of Service

[Date]

x

x

x

x

Type of RHY Service

Community service/service
learning (CSL)

x

x

Criminal justice /legal
services

x

x

x

x

Education

x

x

x

x

x

x

x

x

x

Employment and/or training
services
Health/medical care

x

Home-based services

x

Life skills training

x

x

x

x

Parenting education for youth
with children

x

x

x

x

Post-natal newborn care
(wellness exams;
immunizations)

x

x

Post-natal care for client
(person who gave birth)

x

x

Pre-natal care

x

x

STD Testing

x

x

Street-based services

x

Substance use disorder
treatment

x

x

x

x

Substance use disorder
Ed/Prevention services

x

x

x

x

R15 Commercial Sexual Exploitation/Sex Trafficking
Rationale

The purpose is to assess the extent of sexual exploitation among youth experiencing
homelessness.

139

Data Collection Instruction
Header
Funder: ProgramComponent

Instructions
HHS: RHY – Collection required for all components

Project Type
Applicability

Emergency Shelter - Entry Exit
Transitional Housing
Street Outreach
Homelessness Prevention
Head of Household and Adults
Project Exit

Data Collected About
Collection Point

Response Descriptions

Field Name
Ever received anything in
exchange for sex (e.g.,
money, food, drugs,
shelter)?

If Yes for “Ever received
anything in exchange for
sex”
In the last three months

If Yes for “Ever received
anything in exchange for
sex”
How many times

If Yes for “Ever received
anything in exchange for
sex”
Ever
made/persuaded/forced to
have sex in exchange for
something

Response Category/ Data Type
No

Yes
Client doesn't know
Client prefers not to answer
Data not collected
No

Yes
Client doesn't know
Client prefers not to answer
Data not collected
1-3

4-7
8-11
12 or more
Client doesn't know
Client prefers not to answer
Data not collected
No

Yes
Client doesn't know
140

If Yes for “Ever
made/persuaded/forced to
have sex in exchange for
something?”
In the last three months?

Client prefers not to answer
Data not collected
No

Yes
Client doesn't know
Client prefers not to answer
Data not collected

R16 Labor Exploitation/Trafficking
Rationale

The purpose is to assess the extent of labor exploitation among youth experiencing
homelessness.

Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability

Instructions
HHS: RHY – Collection required for all components
Emergency Shelter - Entry Exit
Transitional Housing
Street Outreach
Homelessness Prevention

Data Collected About
Collection Point

Head of Household and Adults
Project Exit

Response Descriptions

Field Name
Ever afraid to quit/leave work
due to threats of violence to
yourself, family, or friends?

Ever promised work where work
or payment was different than
you expected?

If Yes for either “Workplace
violence threats” OR
“Workplace promise difference”
– Felt forced, coerced,

Response Category/ Data Type
No
Yes
Client doesn't know
Client prefers not to answer
Data not collected
No
Yes
Client doesn't know
Client prefers not to answer
Data not collected
No

141

pressured, or tricked into
continuing the job

If Yes for either “Workplace
violence threats” OR
“Workplace promise actual
difference” – In the last 3
months

Yes
Client doesn't know
Client prefers not to answer
Data not collected
No

Yes
Client doesn't know
Client prefers not to answer
Data not collected

R17 Project Completion Status
Rationale

The purpose is to identify whether the youth completed the project or exited without completion.
This data is only collected on heads of household and adults at project exit.

Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

Response Descriptions

Field Name
Project Completion Status

If Client was expelled or otherwise
involuntarily discharged from project
for “Project Completion Status”
Select the major reason

Instructions
HHS: RHY – Collection required for all components
except for Street Outreach and BCP-Prevention
Emergency Shelter - Entry Exit
Transitional Housing
Head of Household and Adults
Project Exit

Response Category/ Data Type
Completed project
Client voluntarily left early
Client was expelled or otherwise involuntarily
discharged from project
Criminal activity/destruction of property/violence

Non-compliance with project rules
Non-payment of rent/occupancy charge
Reached maximum time allowed by project
Project terminated
Unknown/disappeared

142

R18 Counseling
Rationale

The purpose of this element is to identify the type and amount of counseling received by adults
and heads of households enrolled in RHY projects.

Data Collection Instruction
Header

Instructions

Funder: Program-Component

HHS: RHY – Collection required for all components
except for Street Outreach
Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Project Exit

Project Type Applicability
Data Collected About
Collection Point

Response Descriptions
Field Name

Response Category/ Data Type

Client received counseling

No
Yes

If Yes Identify the type(s) of
counseling received

Individual
Family
Group - including peer counseling

If yes, Identify the number of
sessions received by exit

[Integer 1-48+]

Total number of sessions planned in
client’s treatment or service plan

[Integer 1-48+]

A plan is in place to start or continue
counseling after exit

No
Yes

R19 Safe and Appropriate Exit
Rationale

The purpose of this element is to determine the number of youth who exited to safe and
appropriate destinations as determined by the youth (Head of Household and adult) themselves
and as determined by the project/caseworker.

143

Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

Instructions
HHS: RHY – Collection required for all components
except for Street Outreach and Homelessness
Emergency Shelter - Entry Exit
Transitional Housing
Head of Household and Adults
Project Exit

Response Descriptions
Field Name

Response Category/ Data Type

Exit destination safe - as determined
by the client

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

Exit destination safe - as determined
by the project/caseworker

No
Yes
Worker does not know

Client has permanent positive adult
connections outside of project

No
Yes
Worker does not know

Client has permanent positive peer
connections outside of project

No
Yes
Worker does not know

Client has permanent positive
community connections outside of
project

No

Yes
Worker does not know

144

R20 Aftercare Plans
Rationale
The purpose is to identify the extent of aftercare plans which were executed post-exit from the
project.

Data Collection Instruction

Header
Funder: Program-Component

Instructions
HHS: RHY – Collection required for all components
except for Street Outreach

Project Type Applicability

Emergency Shelter - Entry Exit
Transitional Housing
Homelessness Prevention
Head of Household and Adults
Post Exit

Data Collected About
Collection Point

Response Descriptions
Field Name

Response Category/ Data Type

Information Date

[Date]

Aftercare was provided

No
Yes
Client prefers not to answer

If yes – Identify the primary way it
was provided

Via email/social media
Via telephone
In person: one-on-one
In person: group

VA

The VA Programs HMIS Manual contains HMIS data collection instructions and the VA Provider
Data Guide contains all VA data element rationale and response description information. HUDVASH Project setup information can also be found in the HUD-VASH Program HMIS Manual.

145

V1 Veteran’s Information
Data Collection Instruction

Header
Funder: Program-Component

Project Type Applicability

Data Collected About
Collection Point

Response Descriptions

Instructions
HUD: HUD-VASH – Collection required for all
components
VA: SSVF – Collection required for RRH and
Homelessness Prevention
VA: GPD – Collection required for all components
VA: Community Contract Safe Haven
VA: CRS Contract Residential Services
Emergency Shelter - Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required
for entry)
Supportive Services Only
Safe Haven
PH – Housing Only
Homelessness Prevention
PH – Rapid Re-Housing
All Veterans
Record Creation

Field Name

Response Category/ Data Type

Year Entered Military Service

[Integer YYYY]

Year Separated from Military
Service

[Integer YYYY]

Theater of Operations: World War
II

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

Theater of Operations: Korean War

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected
146

Theater of Operations: Vietnam
War

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

Theater of Operations: Persian
Gulf War (Operation Desert Storm)

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

Theater of Operations: Afghanistan
(Operation Enduring Freedom)

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

Theater of Operations: Iraq
(Operation Iraqi Freedom)

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

Theater of Operations: Iraq
(Operation New Dawn)

No
Yes
Client doesn't know
Client prefers not to answer
Data not collected

147

Theater of Operations: Other
Peace-keeping Operations or
Military Interventions (such as
Lebanon, Panama, Somalia,
Bosnia, Kosovo)

No

Yes
Client doesn't know
Client prefers not to answer
Data not collected
Branch of the Military

Army
Air Force
Navy
Marines
Coast Guard
Space Force
Client doesn't know
Client prefers not to answer
Data not collected

Discharge Status

Honorable
General under honorable conditions
Under other than honorable conditions (OTH)
Bad conduct
Dishonorable
Uncharacterized
Client doesn't know
Client prefers not to answer
Data not collected

148

V2 Services Provided – SSVF
Data Collection Instruction

Header
Funder: Program-Component

Instructions
VA: SSVF – Collection required for RRH and
Homelessness Prevention

Project Type Applicability

Homelessness Prevention
PH – Rapid Re-Housing

Data Collected About

All Clients receiving services

Collection Point

Occurrence Point (As Provided)

Response Descriptions
Field Name

Response Category/ Data Type

Date of Service

[Date]

Type of Service

Outreach services
Case management services
Assistance obtaining VA benefits
Assistance obtaining/coordinating other public benefits
Direct provision of other public benefits
Other (non TFA) supportive service approved by VA
Shallow Subsidy
Returning Home
Rapid Resolution

If "Assistance obtaining VA
Benefits"

VA vocational and rehabilitation counseling
Employment and training services
Educational assistance
Health care services

If "Assistance obtaining/coordinating
other public benefits"

Health care services
Daily living services
Personal financial planning services
Transportation services
Income support services
Fiduciary and representative payee services
Legal services – child support
149

Legal services – eviction prevention
Legal services – outstanding fines and penalties
Legal services – restore/acquire driver's license
Legal services – other
Child care
Housing counseling
If "Direct provision of other public
benefits"

Personal financial planning services
Transportation services
Income support services
Fiduciary and representative payee services
Legal services – child support
Legal services – eviction prevention
Legal services – outstanding fines and penalties
Legal services – restore/acquire driver's license
Legal services – other
Child care
Housing counseling

If "Other (Non-TFA) Supportive
Service approved by VA"

[Text]

V3 Financial Assistance – SSVF
Data Collection Instruction

Header
Funder-Program Component
Project Type Applicability
Data Collected About
Collection Point

Instructions
VA: SSVF – Collection required for RRH and
Homelessness Prevention
Homelessness Prevention
PH – Rapid Re-Housing
All Clients receiving financial assistance
Occurrence Point (As Provided)

Response Descriptions
Field Name

Response Category/ Data Type

Start Date of Financial Assistance

[Date]

Financial Assistance Amount

[Amount]

Financial Assistance Type

Rental assistance
150

Utility fee payment assistance
Security deposit
Utility deposit
Moving costs
Transportation services: token/vouchers
Transportation services: vehicle repair/maintenance
Child care
General housing stability assistance
Emergency housing assistance
Shallow subsidy financial assistance
Food assistance
Landlord incentive
Tenant incentive
End Date of Financial Assistance

[Date]

V4 Percent of AMI (SSVF Eligibility)
Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

Instructions
VA: SSVF – Collection required for RRH and
Homelessness Prevention
PH – Rapid Re-Housing
Head of Household
Project Start

Response Descriptions
Field Name

Response Category/ Data Type

Household Income as a percentage 30% or less
of AMI
31% to 50%
51% to 80%
81% or greater

V6 VAMC Station Number
Data Collection Instruction

Header
Funder: Program-Component

Instructions
HUD: HUD-VASH – Collection required for all
components
151

Header

Project Type Applicability

Data Collected About
Collection Point

Response Descriptions

Instructions
VA: SSVF – Collection required for RRH and
Homelessness Prevention
VA: GPD – Collection required for all components
VA: CRS Contract Residential Services
VA: Community Contract Safe Haven Program
Emergency Shelter - Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required
for entry)
Services Only
Safe Haven
PH – Housing Only
Homelessness Prevention
PH – Rapid Re-Housing
Head of Household
Project Start

Field Name

Response Category/ Data Type

VAMC Station Number

VAMC Station Codes and Names can be found in the
CSV Specification Document

V7 HP Targeting Criteria
Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

Response Descriptions

Instructions
VA: SSVF – Collection required for Homelessness
Prevention
Homelessness Prevention
Head of Household
Project Start

Field Name

Response Category/Data Type

Is Homelessness Prevention
targeting screener required?

No
Yes

Housing loss expected within...

1-6 days
7-13 days
14-21 days

152

More than 21 days
Current household income

$0 (i.e., not employed, not receiving cash benefits, no
other current income)
1-14% of Area Median Income (AMI) for household size
15-30% of AMI for household size
More than 30% of AMI for household size

Past experience of Homelessness
(street/shelter/transitional housing)
(any adult)

Most recent episode occurred within the last year

Most recent episode occurred more than one year ago
None
Head of household is not a current
leaseholder/renter of unit.

No
Yes

Head of Household has never been
a leaseholder/renter of unit.

No
Yes

Currently at risk of losing a tenantbased housing subsidy or housing
in a subsidized building or unit
(household)

No

Yes
Rental Evictions within the past 7
years (any adult)

No prior rental evictions
1 prior rental eviction
2 or more prior rental evictions

Criminal record for arson, drug
dealing or manufacture, or felony
offense against persons or property
(any adult)

No

Yes
Incarcerated as adult (any adult in
household)

Not incarcerated

153

Incarcerated once
Incarcerated two or more times
Discharged from jail or prison
within last six months after
incarceration of 90 days or more
(adults)

No

Yes
Registered sex offender (any
household members)

No
Yes

Head of Household with disabling
condition (physical health, mental
health, substance use) that directly
affects ability to secure/maintain
housing

No

Yes
Currently pregnant (any household
member)

No
Yes

Single parent/guardian household
with minor child(ren)

No
Yes

Household includes one or more
young children (age six or under),
or a child who requires significant
care

No

Youngest child is under 1 year old
Youngest child is 1 to 6 years old and/or one or more
children (any age) require significant care
Household size of 5 or more
requiring at least 3 bedrooms (due
to demographic mix)

No

Yes
Households which may include one
or more members meeting other

No

154

criteria for targeting prevention
determined by the CoC
Yes
HP applicant total points

[Integer]

Grantee targeting threshold score

[Integer]

V8 HUD-VASH Voucher Tracking
Data Collection Instruction

Header
Funder: Program-Component

Instructions
HUD: HUD-VASH – Collection required for HUD/VASH
Collaborative Case Management

Project Type Applicability

PH – Permanent Supportive Housing (disability
required for entry)

Data Collected About
Collection Point

Head of Household/Veteran
Occurrence Point (as provided)

Response Descriptions
Field Name

Response Category/ Data Type

Information date

[Date]

Voucher change

Referral package forwarded to PHA
Voucher denied by PHA
Voucher issued by PHA
Voucher revoked or expired
Voucher in use – veteran moved into housing
Voucher was ported locally
Voucher was administratively absorbed by new PHA
Voucher was converted to Housing Choice Voucher
Veteran exited – voucher was returned
Veteran exited – family maintained the voucher
Veteran exited – prior to ever receiving a voucher
Other

If other, please specify

[Text]

155

V9 HUD-VASH Exit Information
Data Collection Instruction

Header
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

Instructions
HUD: HUD-VASH – Collection required for HUD/VASH
Collaborative Case Management
PH – Permanent Supportive Housing (disability
required for entry)
Head of Household/Veteran
Project Exit

Response Descriptions
Field Name

Response Category/ Data Type

Case Management Exit Reason

Accomplished goals and /or obtained services and
no longer needs CM
Transferred to another HUD-VASH program site
Found/chose other housing
Did not comply with HUD-VASH CM
Eviction and/or other housing related issues
Unhappy with HUD-VASH housing
No longer financially eligible for HUD-VASH voucher
No longer interested in participating in this program
Veteran cannot be located
Veteran too ill to participate at this time
Veteran is incarcerated
Veteran is deceased
Other

If other - please specify

[Text]

Metadata Elements

The Metadata Elements are intended to facilitate reporting from HMIS, to simplify the writing of
programming specifications, and to provide an audit trail.

5.01 Date Created
Field Name

Response Category/ Data Type

Date Created

[Date]

156

5.02 Date Updated
Field Name

Response Category/ Data Type

Date Updated

[Date]

5.03 Data Collection Stage
Field Name

Response
Category/ Data
Type

Descriptions

Data Collection
Stage

Project Start

Indicates the element is required to be collected at
every project start. Elements collected at project
start must have an ‘Information Date’ that matches
the client’s ‘Project Start Date.’ Information must be
accurate as of the ‘Project Start Date.’ When a
data element with multiple collection points is
collected at project start, it must be stored with a
Data Collection Stage of ‘project start.’ There
should be one and only one record with a Data
Collection Stage of ‘project start’ for each relevant
data element for any given project start. Data may
be edited by users associated with the project to
correct errors or omissions; such edits will not
change the Data Collection Stage associated with
the record.

Project Update

Indicates the element may be collected and
entered at any point during a project stay to track
changes over time or document the occurrence of
events (e.g., a service is provided). These types of
records must be able to be entered at any point
during the project stay. Some data elements are
collected once per project stay. For others, the
system must be able to support a theoretically
unlimited number of records per project stay, each
with a distinct ‘Information Date.’ The ‘Information
Date’ should reflect the date on which the
information is collected and/or the date for which
the information is relevant for reporting purposes.
Information must be accurate as of the ‘Information
Date,’ regardless of when it is collected or entered
into the HMIS. Data may be edited by users
associated with the project to correct errors or
omissions; such edits will change neither the Data
Collection Stage nor the information date unless it
is explicitly altered by the user.

Project Annual
Assessment

Data elements required for collection at annual
assessment must be entered with an Information
Date of no more than 30 days before or after the
anniversary of the Head of Household’s ‘Project
157

Start Date,’ regardless of the date of the most
recent ‘update’ or any other ‘annual assessment.’
Information must be accurate as of the ‘Information
Date.’ The Data Collection Stage may not be
inferred from the ‘Information Date,’ although the
field must have an ‘Information Date’ recorded with
it. To be considered reportable to HUD as an
annual assessment, data must be stored with a
Data Collection Stage of ‘annual assessment.’ The
Annual Assessment must include updating both the
Head of Household’s record and any other family
members at the same time. There should be one
and only one record for each data element
annually with a Data Collection Stage recorded as
‘annual assessment’ associated with any given
client and Enrollment ID within the 60-day period
surrounding the anniversary of the Head of
Household’s Project Start Date. Regardless of
whether the responses have changed since project
start or the previous annual assessment, a new
record must be created for each subsequent
annual assessment such that it is possible to view
a history, by date, of the values for each data
element. Data may be edited by users associated
with the project to correct errors or omissions; such
edits will change neither the Data Collection Stage
nor the information date unless they are explicitly
altered by the user.
Project Exit

Indicates the element is required to be collected at
every project exit. Elements collected at project exit
must have an ‘Information Date’ that matches the
client’s ‘Project Exit Date.’ Information must be
accurate as of the ‘Project Exit Date.’ When a data
element with multiple collection points is collected
at project exit, it must be stored with a Data
Collection Stage of ‘project exit.’ There should be
one and only one record with a Data Collection
Stage of ‘project exit’ for each relevant data
element for any given project exit. Data may be
edited by users associated with the project to
correct errors or omissions; such edits will not
change the Data Collection Stage or the
information.

Post Exit

Indicates the element may be collected after
project exit for a period of no longer than 180 days.

158

5.04 Information Date
Field Name

Response Category/ Data
Type
[Date]

Descriptions

Field Name

Response Category/ Data
Type

Descriptions

Project Identifier

[Integer]

Project Identifier (2.02) of the
project that entered or edited the
data

Information Date

5.05 Project Identifier

5.06 Enrollment Identifier
Field Name

Response Category/ Data
Type

Descriptions

Enrollment Identifier

[Integer]

A unique project start identifier
used to associate data with a
particular period of service.

Response Category/ Data
Type
[Integer]

Descriptions

5.07 User Identifier
Field Name

User Identifier

5.08 Personal Identifier
Field Name

Personal Identifier

Response Category/ Data
Type
[Integer]

A unique ID used to associate
data with the user who entered
and/or edited it
Descriptions
A Personal Identifier is an
automatically generated identifier
created by the HMIS software. A
Personal ID must be static and
unique to a single individual within
an HMIS implementation,
regardless of how many client
records exist for the individual

159

5.09 Household Identifier
Field Name

Household Identifier

Response Category/ Data
Type
[Integer]

Description
A Household Identifier is an
automatically generated identifier
created by the HMIS software. A
Household Identifier must be
permanent and unique to a single
household at each project start
within an HMIS.

5.10 Implementation Identifier
Field Name
Implementation
Identifier

Response
Implementation ID (Vendor
Generated)

Description
The Implementation ID is a
unique identifier used to
identify data affiliated with a
given HMIS implementation.

Appendix A – Living Situation Response Categories and
Descriptions
Response

Homeless Situations (100-199)
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, Host Home shelter

Safe Haven

Description

A facility, the
primary purpose
of which is to
provide
temporary
shelter for
individuals and
families
experiencing
homelessness.
A form of
supportive
housing that
serves hard-toreach persons
experiencing
homelessness
with severe
mental illness
and/or
substance use

Prior
Living
Situation
(3.917)

Current
Destination
Living
(3.12)
Situation
(4.12)

X

X

X

X

X

X

X

X

X

160

Institutional Situations (200-299)
Foster care home or foster care
group home
Hospital or other residential nonpsychiatric medical facility
Jail, prison, or juvenile detention
facility
Long-term care facility or nursing
home
Psychiatric hospital or other
psychiatric facility
Substance abuse treatment facility
or detox center
Temporary Housing Situations
(300-399)
Transitional housing for homeless
persons (including homeless youth)
Residential project or halfway house
with no homeless criteria

Hotel or motel paid for without
emergency shelter voucher
Host Home (non-crisis)
Staying or living with family,
temporary tenure (e.g., room,
apartment, or house)
Staying or living with friends,
temporary tenure (e.g., room,
apartment, or house)
Moved from one HOPWA funded
project to HOPWA TH
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 situation
(400-499)
Staying or living with family,
permanent tenure
Staying or living with friends,
permanent tenure

disorders who
are on the street
and have been
unable or
unwilling to
participate in
supportive
services.

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

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X
X
X

Limited to use by
HOPWA-funded
projects

X
X

X

X

X

X
X

161

Moved from one HOPWA funded
project to HOPWA PH
Rental by client, no ongoing housing
subsidy

Rental by client, with ongoing
housing subsidy
Owned by client, with ongoing
housing subsidy
Owned by client, no ongoing
housing subsidy
Other (1-99)
No exit interview completed

Other

Deceased
Worker unable to determine
Client doesn’t know
Client prefers not to answer
Data not collected

Limited to use by
HOPWA-funded
projects
A rental that the
client will pay for
on their own
(without a
subsidy of any
kind)
Any subsidized
rental housing.

X
X

X

X

X

X

X

X

X

X

X

X

X

This will be
considered
"missing data"
for data quality
and reporting
purposes. This
response should
not be used in
place of a valid
Living Situation
response
Any response of
"Other" in
Destination will
not count in any
HMIS-based
reporting as a
positive
outcome.

X

X

X
X
X

X
X
X
X

X

X
X
X
X

Subsidy Types – Dependent Field, relies on Living Situation = 435
Response
GPD TIP housing subsidy
VASH housing subsidy
RRH or equivalent subsidy
HCV voucher (tenant or project based) (not
dedicated)
Public housing unit
Rental by client, with other ongoing housing
subsidy
Housing Stability Voucher
Family Unification Program Voucher (FUP)
Foster Youth to Independence Initiative (FYI)

Description

Includes HCV with no paired services.

162

Permanent Supportive Housing
Other permanent housing dedicated for formerly
homeless persons

Appendix B Acronyms
Acronym
AHAR
AIDS
AMI
APR
ARP
BCP
CAPER
CE
CES
CH
CM
COBRA
CoC
CPS
CRS
CSL
CSV
DOB
DOJ
DV
E/E
EBT
EHV
ES
ESG
ESG – RUSH
ESG – CV
FY
GA
GED
GPD
HCHV
HCV
HEARTH
HHS

Description
Annual Homeless Assessment Report
Acquired Immune Deficiency Syndrome
Area Median Income
Annual Performance Report
American Rescue Plan
Basic Center Program
Consolidated Annual Performance Evaluation Report
Coordinated Entry
Coordinated Entry System
Chronically Homeless
Case Management
Consolidated Omnibus Budget Reconciliation Act (Continuation of health coverage)
Continuum of Care
Child Protective Services
Contract Residential Services
Community Service Learning
Comma-Separated Values
Date of Birth
Department of Justice
Domestic Violence
Entry/Exit Shelter
Electronic Benefits Transfer
Emergency Housing Voucher
Emergency Shelter
Emergency Solutions Grant
Emergency Solutions Grant – Rapid Unsheltered Survivor Housing
Emergency Solutions Grant – CARES Act
Fiscal Year
General Assistance
General Educational Development Test
Grant Per Diem
Health Care for Homeless Veterans
Housing Choice Voucher
Homeless Emergency Assistance and Rapid Transition to Housing Act
Department of Health and Human Services
163

Acronym
HIC
HIV
HMIS
HoH
HOPWA
HP
HSV
HUD
LSA
MGH
NbN
NOFO
OMB
OTH
PATH
PDDE
PH
PHA
PIH
PIT
PSH
RHY
RRH
SAMHSA
SH
SNAP
SNAPS
SO
SOAR
SPM
SRO
SSDI
SSI
SSN
SSO
SSVF
STD
STI
STRMU
TANF

Description
Housing Inventory Count
Human Immunodeficiency Virus
Homeless Management Information System
Head of Household
Housing Opportunities for Persons with AIDS
Homelessness Prevention
Housing Stability Voucher
Department of Housing and Urban Development
Longitudinal Systems Analysis
Maternity Group Homes for Parenting Youth
Night by Night Shelter
Notice of Funding Opportunity
Office of Management Budget
Other Than Honorable Discharge Conditions
Projects for Assistance in Transition from Homelessness
Project Descriptor Data Elements
Permanent Housing
Public Housing Agency
Public and Indian Housing
Point-in-Time
Permanent Supportive Housing
Runaway and Homeless Youth Program
Rapid Re-Housing
Substance Abuse and Mental Health Administration
Safe Haven
Supplemental Nutrition Assistance Program
Office of Special Needs Assistance Programs
Street Outreach
SSI/SSDI Outreach, Access, and Recovery
System Performance Measures
Single Room Occupancy
Social Security Disability Insurance
Supplemental Security Income
Social Security Number
Supportive Services Only
Supportive Services for Veteran Families
Sexually Transmitted Disease
Sexually Transmitted Infection
Short-Term Rent, Mortgage and Utility
Temporary Assistance for Needy Families
164

Acronym
TBRA
TFA
TH
TIP
TLP
VA
VAMC
VASH
VAWA
VSP
WIC
XML
YHDP

Description
Tenant Based Rental Assistance
Temporary Financial Assistance
Transitional Housing
Transition in Place
Transitional Living Program
Department of Veterans Affairs
Department of Veterans Affairs Medical Center
Veterans Affairs Supportive Housing
Violence Against Women Act
Victim Service Provider
Special Supplemental Nutrition Program for Women, Infants, and Children
Extensible Markup Language
Youth Homeless Demonstration Program

This material is based upon work supported, in whole or in part, by Federal award number H-21-NP-OH-0002
awarded to The Partnership center, Ltd by the U.S. Department of Housing and Urban Development. The substance
and findings of the work are dedicated to the public. Neither the United States Government, nor any of its employees,
makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use
would not infringe privately-owned rights. Reference herein to any individuals, agencies, companies, products,
process, services, service by trade name, trademark, manufacturer, or otherwise does not constitute or imply an
endorsement, recommendation, or favoring by the author(s), contributor(s), the U.S. Government or any agency
thereof. Opinions contained herein are those of the author(s) and do not necessarily reflect the official position of, or a
position that is endorsed by, HUD or any Federal agency.

165