HMIS-Data-Standards-Manual-2024

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.3
RELEASED: MAY 2023
UPDATED: AUGUST 2023

REVISION HISTORY................................................................................................................................................. 8
INTRODUCTION TO THE HMIS DATA STANDARDS ................................................................................................ 12
HMIS DATA STANDARDS OVERVIEW ...............................................................................................................................12
PERSON CENTERED APPROACHED TO HMIS DATA COLLECTION ............................................................................................12
HMIS IMPLEMENTATION ...............................................................................................................................................13
HMIS DOCUMENTS & RESOURCES ..................................................................................................................................13
HMIS FEDERAL PARTNER PROGRAM MANUALS.................................................................................................................13
HMIS DATA STANDARDS TERMS AND CONCEPTS ...............................................................................................................15
DATA ELEMENT STRUCTURE ...........................................................................................................................................16
PROJECT DESCRIPTOR DATA ELEMENTS ............................................................................................................... 19
HMIS PROJECT SETUP GUIDANCE ...................................................................................................................................20
MULTIPLE PROJECT SETUP .............................................................................................................................................20
PROJECTS THAT OPERATE IN MULTIPLE COCS ....................................................................................................................21
2.01 ORGANIZATION INFORMATION ................................................................................................................................22
Rationale .............................................................................................................................................................22
Project Setup Instruction .....................................................................................................................................22
Response descriptions .........................................................................................................................................23
2.02 PROJECT INFORMATION .........................................................................................................................................23
Rationale .............................................................................................................................................................23
Project Setup Instruction .....................................................................................................................................23
Project Setup Considerations ..............................................................................................................................25
Response descriptions .........................................................................................................................................27
2.03 CONTINUUM OF CARE INFORMATION .......................................................................................................................31
Rationale .............................................................................................................................................................31
Project Setup Instruction .....................................................................................................................................31
Response descriptions .........................................................................................................................................31
2.06 FUNDING SOURCES ...............................................................................................................................................32
Rationale .............................................................................................................................................................32
Project Setup Instruction .....................................................................................................................................32
Response descriptions .........................................................................................................................................34
2.07 BED AND UNIT INVENTORY INFORMATION .................................................................................................................36
Rationale .............................................................................................................................................................36
Project Setup Instruction .....................................................................................................................................37
Response descriptions .........................................................................................................................................39
2.08 HMIS PARTICIPATION STATUS ................................................................................................................................41
Rationale .............................................................................................................................................................41
Project setup Instruction .....................................................................................................................................41
Response Descriptions ........................................................................................................................................42
2.09 COORDINATED ENTRY PARTICIPATION STATUS ...........................................................................................................43
Rationale .............................................................................................................................................................43
Project Setup Instruction .....................................................................................................................................43
Response Descriptions ........................................................................................................................................44
UNIVERSAL DATA ELEMENTS ............................................................................................................................... 45
General Data Collection Guidance ......................................................................................................................46
Uses and Disclosures of Client Data ....................................................................................................................46
3.01 NAME ................................................................................................................................................................46

1

Rationale .............................................................................................................................................................46
Data Collection Instruction..................................................................................................................................46
Response descriptions .........................................................................................................................................47
3.02 SOCIAL SECURITY NUMBER .....................................................................................................................................48
Rationale .............................................................................................................................................................48
Data Collection Instruction..................................................................................................................................48
Response descriptions .........................................................................................................................................49
3.03 DATE OF BIRTH ....................................................................................................................................................49
Rationale .............................................................................................................................................................49
Data Collection Instruction..................................................................................................................................49
Response descriptions .........................................................................................................................................49
3.04 RACE AND ETHNICITY ............................................................................................................................................50
Rationale .............................................................................................................................................................50
Data Collection Instruction..................................................................................................................................50
Response Descriptions ........................................................................................................................................51
3.06 GENDER .............................................................................................................................................................52
Rationale .............................................................................................................................................................52
Data Collection Instruction..................................................................................................................................53
Response descriptions .........................................................................................................................................54
3.07 VETERAN STATUS .................................................................................................................................................54
Rationale .............................................................................................................................................................54
Data Collection Instruction..................................................................................................................................54
Response descriptions .........................................................................................................................................55
3.08 DISABLING CONDITION ..........................................................................................................................................55
Rationale .............................................................................................................................................................55
Data Collection Instruction..................................................................................................................................56
Response descriptions .........................................................................................................................................56
3.10 PROJECT START DATE ............................................................................................................................................57
Rationale .............................................................................................................................................................57
Data Collection Instruction..................................................................................................................................57
Response descriptions .........................................................................................................................................58
3.11 PROJECT EXIT DATE ..............................................................................................................................................59
Rationale .............................................................................................................................................................59
Data Collection Instruction..................................................................................................................................59
Auto-exits ............................................................................................................................................................60
Response descriptions .........................................................................................................................................60
3.12 DESTINATION.......................................................................................................................................................60
Rationale .............................................................................................................................................................60
Data Collection Instruction..................................................................................................................................60
Response descriptions .........................................................................................................................................62
3.15 RELATIONSHIP TO HEAD OF HOUSEHOLD...................................................................................................................62
Rationale .............................................................................................................................................................62
Data Collection Instruction..................................................................................................................................62
Response descriptions .........................................................................................................................................63
3.16 ENROLLMENT COC ...............................................................................................................................................64
Rationale .............................................................................................................................................................64
Data Collection Instruction..................................................................................................................................64
Response Descriptions ........................................................................................................................................65
3.20 HOUSING MOVE IN DATE.......................................................................................................................................65

2

Rationale .............................................................................................................................................................65
Data Collection Instruction..................................................................................................................................65
Response Descriptions ........................................................................................................................................66
3.917 PRIOR LIVING SITUATION .....................................................................................................................................66
Rationale .............................................................................................................................................................66
Data Collection Instruction..................................................................................................................................66
Response Descriptions ........................................................................................................................................71
PROGRAM SPECIFIC DATA ELEMENTS .................................................................................................................. 72
COMMON PROGRAM SPECIFIC DATA ELEMENTS ................................................................................................. 72
4.02 INCOME AND SOURCES ..........................................................................................................................................72
Rationale .............................................................................................................................................................72
Data Collection Instruction..................................................................................................................................72
Response Descriptions ........................................................................................................................................75
4.03 NON-CASH BENEFITS ............................................................................................................................................77
Rationale .............................................................................................................................................................77
Data Collection Instruction..................................................................................................................................77
Response Descriptions ........................................................................................................................................79
4.04 HEALTH INSURANCE ..............................................................................................................................................80
Rationale .............................................................................................................................................................80
Data Collection Instruction..................................................................................................................................80
Response Descriptions ........................................................................................................................................81
4.05 PHYSICAL DISABILITY .............................................................................................................................................82
Rationale .............................................................................................................................................................82
Data Collection Instruction..................................................................................................................................82
Response Descriptions ........................................................................................................................................84
4.06 DEVELOPMENTAL DISABILITY ..................................................................................................................................84
Rationale .............................................................................................................................................................84
Data Collection Instruction..................................................................................................................................85
Response Description ..........................................................................................................................................86
4.07 CHRONIC HEALTH CONDITION.................................................................................................................................86
Rationale .............................................................................................................................................................86
Data Collection Instruction..................................................................................................................................86
Response Descriptions ........................................................................................................................................87
4.08 HIV/AIDS ..........................................................................................................................................................89
Rationale .............................................................................................................................................................89
Data Collection Instruction..................................................................................................................................89
Response Descriptions ........................................................................................................................................90
4.09 MENTAL HEALTH DISORDER ...................................................................................................................................90
Rationale .............................................................................................................................................................90
Data Collection Instruction..................................................................................................................................90
Response Descriptions ........................................................................................................................................91
4.10 SUBSTANCE USE DISORDER ....................................................................................................................................93
Rationale .............................................................................................................................................................93
Data Collection Instruction..................................................................................................................................93
Response Descriptions ........................................................................................................................................94
4.11 DOMESTIC VIOLENCE ............................................................................................................................................95
Rationale .............................................................................................................................................................95

3

Data Collection Instruction..................................................................................................................................95
Response Descriptions ........................................................................................................................................96
4.12 CURRENT LIVING SITUATION ...................................................................................................................................97
Rationale .............................................................................................................................................................97
Data Collection Instruction..................................................................................................................................97
Response Descriptions ........................................................................................................................................99
4.13 DATE OF ENGAGEMENT .......................................................................................................................................100
Rationale ...........................................................................................................................................................100
Data Collection Instruction................................................................................................................................100
Response Descriptions ......................................................................................................................................101
4.14 BED-NIGHT DATE ...............................................................................................................................................101
Rationale ...........................................................................................................................................................101
Data Collection Instruction................................................................................................................................101
Response Descriptions ......................................................................................................................................102
4.19 COORDINATED ENTRY ASSESSMENT .......................................................................................................................102
Rationale ...........................................................................................................................................................102
Data Collection Instruction................................................................................................................................102
Response Descriptions ......................................................................................................................................103
4.20 COORDINATED ENTRY EVENT ................................................................................................................................103
Rationale ...........................................................................................................................................................103
Data Collection Instruction................................................................................................................................104
Response Descriptions ......................................................................................................................................104
FEDERAL PARTNER PROGRAM SPECIFIC DATA ELEMENTS.................................................................................. 107
COC .................................................................................................................................................................... 108
C2 MOVING ON ASSISTANCE PROVIDED .........................................................................................................................108
Rationale ...........................................................................................................................................................108
Data Collection Instruction................................................................................................................................108
Response ...........................................................................................................................................................108
C3 YOUTH EDUCATION STATUS ....................................................................................................................................108
Rationale ...........................................................................................................................................................108
Data Collection Instruction................................................................................................................................109
Response ...........................................................................................................................................................109
C4 TRANSLATION ASSISTANCE NEEDED ..........................................................................................................................110
Rationale ...........................................................................................................................................................110
Data Collection Instruction................................................................................................................................110
Response ...........................................................................................................................................................110
HOPWA.............................................................................................................................................................. 111
W1 SERVICES PROVIDED – HOPWA .............................................................................................................................111
Rationale ...........................................................................................................................................................111
Data Collection Instruction................................................................................................................................111
W2 FINANCIAL ASSISTANCE – HOPWA .........................................................................................................................112
Rationale ...........................................................................................................................................................112
Data Collection Instruction................................................................................................................................112
W3 MEDICAL ASSISTANCE ...........................................................................................................................................112
Rationale ...........................................................................................................................................................112
Data Collection Instruction................................................................................................................................112

4

W4 T-CELL (CD4) AND VIRAL LOAD ..............................................................................................................................114
Rationale ...........................................................................................................................................................114
Data Collection Instruction................................................................................................................................114
W5 HOUSING ASSESSMENT AT EXIT ..............................................................................................................................115
Rationale ...........................................................................................................................................................115
Data Collection Instruction................................................................................................................................115
W6 PRESCRIBED ANTI-RETROVIRAL ...............................................................................................................................116
Rationale ...........................................................................................................................................................116
Data Collection Instruction................................................................................................................................116
PATH .................................................................................................................................................................. 117
P1 SERVICES PROVIDED – PATH FUNDED ......................................................................................................................117
Rationale ...........................................................................................................................................................117
Data Collection Instruction................................................................................................................................117
P2 REFERRALS PROVIDED – PATH ................................................................................................................................118
Rationale ...........................................................................................................................................................118
Data Collection Instruction................................................................................................................................118
Response ...........................................................................................................................................................118
P3 PATH STATUS ......................................................................................................................................................119
Rationale ...........................................................................................................................................................119
Data Collection Instruction................................................................................................................................119
Response ...........................................................................................................................................................119
P4 CONNECTION WITH SOAR ......................................................................................................................................119
Rationale ...........................................................................................................................................................119
Data Collection Instruction................................................................................................................................119
Response ...........................................................................................................................................................120
RHY .................................................................................................................................................................... 120
R1 REFERRAL SOURCE .................................................................................................................................................120
Rationale ...........................................................................................................................................................120
Data Collection Instruction................................................................................................................................120
Response ...........................................................................................................................................................120
R2 RHY – BCP STATUS ..............................................................................................................................................121
Rationale ...........................................................................................................................................................121
Data Collection Instruction................................................................................................................................121
Response ...........................................................................................................................................................121
R3 SEXUAL ORIENTATION ............................................................................................................................................122
Rationale ...........................................................................................................................................................122
Data Collection Instruction................................................................................................................................122
Response ...........................................................................................................................................................122
R4 LAST GRADE COMPLETED........................................................................................................................................123
Rationale ...........................................................................................................................................................123
Data Collection Instruction................................................................................................................................123
Response ...........................................................................................................................................................123
R5 SCHOOL STATUS....................................................................................................................................................124
Rationale ...........................................................................................................................................................124
Data Collection Instruction................................................................................................................................124
Response ...........................................................................................................................................................124
R6 EMPLOYMENT STATUS............................................................................................................................................125

5

Rationale ...........................................................................................................................................................125
Data Collection Instruction................................................................................................................................125
Response ...........................................................................................................................................................125
R7 GENERAL HEALTH STATUS .......................................................................................................................................126
Rationale ...........................................................................................................................................................126
Data Collection Instruction................................................................................................................................126
Response ...........................................................................................................................................................126
R8 DENTAL HEALTH STATUS.........................................................................................................................................126
Rationale ...........................................................................................................................................................126
Data Collection Instruction................................................................................................................................126
Response ...........................................................................................................................................................127
R9 MENTAL HEALTH STATUS........................................................................................................................................127
Rationale ...........................................................................................................................................................127
Data Collection Instruction................................................................................................................................127
Response ...........................................................................................................................................................127
R10 PREGNANCY STATUS ............................................................................................................................................128
Rationale ...........................................................................................................................................................128
Data Collection Instruction................................................................................................................................128
Response ...........................................................................................................................................................128
R11 FORMERLY A WARD OF CHILD WELFARE/FOSTER CARE AGENCY ..................................................................................128
Rationale ...........................................................................................................................................................128
Data Collection Instruction................................................................................................................................128
Response ...........................................................................................................................................................129
R12 FORMERLY A WARD OF JUVENILE JUSTICE SYSTEM .....................................................................................................129
Rationale ...........................................................................................................................................................129
Data Collection Instruction................................................................................................................................129
Response ...........................................................................................................................................................129
R13 FAMILY CRITICAL ISSUES .......................................................................................................................................130
Rationale ...........................................................................................................................................................130
Data Collection Instruction................................................................................................................................130
Response ...........................................................................................................................................................130
R14 RHY SERVICE CONNECTIONS .................................................................................................................................131
Rationale ...........................................................................................................................................................131
Data Collection Instruction................................................................................................................................131
Response ...........................................................................................................................................................131
R15 COMMERCIAL SEXUAL EXPLOITATION/SEX TRAFFICKING .............................................................................................132
Rationale ...........................................................................................................................................................132
Data Collection Instruction................................................................................................................................132
Response ...........................................................................................................................................................132
R16 LABOR EXPLOITATION/TRAFFICKING........................................................................................................................133
Rationale ...........................................................................................................................................................133
Data Collection Instruction................................................................................................................................133
Response ...........................................................................................................................................................133
R17 PROJECT COMPLETION STATUS ..............................................................................................................................134
Rationale ...........................................................................................................................................................134
Data Collection Instruction................................................................................................................................134
Response ...........................................................................................................................................................134
R18 COUNSELING ......................................................................................................................................................134
Rationale ...........................................................................................................................................................134

6

Data Collection Instruction................................................................................................................................134
Response ...........................................................................................................................................................134
R19 SAFE AND APPROPRIATE EXIT.................................................................................................................................135
Rationale ...........................................................................................................................................................135
Data Collection Instruction................................................................................................................................135
Response ...........................................................................................................................................................135
R20 AFTERCARE PLANS ...............................................................................................................................................136
Rationale ...........................................................................................................................................................136
Data Collection Instruction................................................................................................................................136
Response ...........................................................................................................................................................136
VA ...................................................................................................................................................................... 137
V1 VETERAN’S INFORMATION.......................................................................................................................................137
Data Collection Instruction................................................................................................................................137
Response ...........................................................................................................................................................137
V2 SERVICES PROVIDED – SSVF ...................................................................................................................................139
Data Collection Instruction................................................................................................................................139
Response ...........................................................................................................................................................140
V3 FINANCIAL ASSISTANCE – SSVF ...............................................................................................................................141
Data Collection Instruction................................................................................................................................141
Response ...........................................................................................................................................................141
V4 PERCENT OF AMI (SSVF ELIGIBILITY)........................................................................................................................142
Data Collection Instruction................................................................................................................................142
Response ...........................................................................................................................................................142
V6 VAMC STATION NUMBER ......................................................................................................................................142
Data Collection Instruction................................................................................................................................142
Response ...........................................................................................................................................................143
V7 HP TARGETING CRITERIA ........................................................................................................................................143
Data Collection Instruction................................................................................................................................143
Response ...........................................................................................................................................................143
V8 HUD-VASH VOUCHER TRACKING............................................................................................................................145
Data Collection Instruction................................................................................................................................145
Response ...........................................................................................................................................................145
V9 HUD-VASH EXIT INFORMATION .............................................................................................................................146
Data Collection Instruction................................................................................................................................146
Response ...........................................................................................................................................................146
METADATA ELEMENTS ................................................................................................................................................147
5.01 Date Created .............................................................................................................................................147
5.02 Date Updated ............................................................................................................................................147
5.03 Data Collection Stage ................................................................................................................................147
5.04 Information Date.......................................................................................................................................149
5.05 Project Identifier........................................................................................................................................149
5.06 Enrollment Identifier .................................................................................................................................149
5.07 User Identifier ...........................................................................................................................................149
5.08 Personal Identifier .....................................................................................................................................150
5.09 Household Identifier ..................................................................................................................................150
5.10 Implementation Identifier .........................................................................................................................150
APPENDIX A – LIVING SITUATION RESPONSE CATEGORIES AND DESCRIPTIONS................................................. 151

7

APPENDIX B ACRONYMS .................................................................................................................................... 154

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"
8

• Add "Culturally Specific Identity (e.g., Two-Spirit)
• Add "Different Identity" and text box to add detail
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”
U1 Worst Housing Situation – RETIRE
V1 Veteran’s Information
• Add “Space Force” response option
9

June 2023
v. 1.1

July 2023
V. 1.2

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.
Appendix A – replaced “Emergency Housing Voucher” response option with “Housing
Stability Voucher”
10

August 2023
V. 1.3

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

11

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 HIV-AIDS Housing. It is also used by other federal partners
from the U.S. Department of Health and Human Services (HHS) and the U.S. Department of Veterans
Affairs (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 Approached to HMIS Data Collection
Black, Indigenous, People of Color, and other communities who have experienced systemic racism and
discrimination are overrepresented amongst individuals experiencing homelessness and within our
homelessness response systems. Ensuring that we address the disparities as caused by our systems
requires approaching all of our initiatives, practices, evaluation methods, and data collection with
equity.
Communities must engage in meaningful partnerships and shared decision making with individuals who
have navigated and/or are navigating the local homeless response system and also people experiencing
homelessness not engaged in the system to better understand potential homeless system barriers, so as
to meaningfully design their data collection processes and their overall homelessness response system
in ways that better meet the needs of those most impacted.
Communities must also employ a person-centered approach to the review and use of the HMIS Data
Manual with a clear foundational understanding of racial trauma and trauma informed practices,
cultural humility, and a person first, data informed perspective.
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.

12

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

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
13

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

VASH Program
HMIS Manual

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

VA Program information link

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

VASH Program link

14

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

15

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.
Data Collected About

Funder: Component - Program

Project Type Applicability
Collection Point

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

16

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.

17

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 provide responses to some fields,
18

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 data collection and
reporting requirements. Therefore, collaboration between HMIS Leads, CoC leadership, and agency staff
19

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 assure 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 set up is done
incorrectly.

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:

20

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: CoCTransitional 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.
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.

21

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

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 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
22

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
Yes

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

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 necessary. Finally, HOPWA-funded projects identify
whether they are 'Medically Assisted Living Facilities' at this stage of project setup.

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

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

23

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

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)

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

25

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-byNight" (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:
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)
Projects that target certain populations are advised that nothing in these standards allows for
circumventing fair housing laws. The Fair Housing Act (FHA) prohibits discrimination because of, among
26

other things, familial status. Except where otherwise permitted by the federal program statute, housing
covered under the FHA may not deny admission to households with children.
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

Response/Data
Type
System generated
number or code.

Description

Project Name

[Text]

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

Operating Start Date

[Date]

Operating End Date

[Date]

Continuum Project

No
Yes

Project ID

Project Type

Emergency Shelter
– Entry Exit

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

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 nonfederally funded projects functioning within the CoC.
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
27

Emergency Shelter
– Night-by-Night

Transitional
Housing

PH – Permanent
Supportive
Housing (disability
required for entry)
Street Outreach

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 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
28

must have two separate projects to be set up in HMIS, one
'Street Outreach' and the other 'Services Only'.
Services Only

Other

Safe Haven

PH – Housing Only

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

Coordinated Entry

If PH- Rapid ReHousing, identify sub
type

RRH: 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 short- and/or
medium-term rental assistance as necessary to 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 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.

29

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

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)

Target Population

HOPWA-Funded
Medically Assisted
Living Facility

[List of HMIS
Residential Project
IDs]

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.

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 - non-HOPWA
Funded Project

Project is not HOPWA funded.

30

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

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 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: XX-XXX]

Geocode

[6 digits]

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., XX999. The HMIS software may provide a dropdown list of valid CoC Codes or require manual
entry.
The geocode associated with the geographic
location of the project's principal site. HUD

31

Project street
address 1

[Text]

Project street
address 2
Project city

[Text]

Project state
Project ZIP code

[2 letters]
[5 digits]

Geography Type

Urban
Suburban
Rural

[Text]

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

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
a Grant Identifier
Grant Start Date
32

•

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 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 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
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
33

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

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

Description

34

Program and
Component

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
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
35

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
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]
Date
Grant End Date [Date]

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.

2.07 Bed and Unit Inventory Information
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.
36

Project Setup Instruction
Data Collected About
Funder: Component Program
Project Type Applicability

Collection Point

All Residential Projects, except for PH – Rapid Re-Housing subtype:
Services Only
All Programs - All Components
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 initial HMIS project
set up 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' = ‘‘Sitebased’’) 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
37

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 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 which 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
38

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.
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 Re- Housing, 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.

Response descriptions
Field Name
Inventory start
date

Response/Data
Type
[Date]

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

39

Inventory end
date

[Date]

The last date that an inventory record is relevant:
•

For current records, 'Inventory End Date' should be
blank.

•

For records that are being closed out because a
change that requires a new record has occurred,
'Inventory End Date' will be the day before the
effective date of the change.

•

CoC Code

[as identified in
data
element 2.03.1
Continuum Code]

Household type

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
Seasonal

Overflow

Beds dedicated to [Integer]
chronically
homeless (CH)
Veterans

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.
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 year-round
basis.
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.

40

Beds dedicated to [Integer]
youth Veterans
Beds dedicated to [Integer]
any other
Veterans
Beds dedicated to [Integer]
chronically
homeless youth
Beds dedicated to [Integer]
any other youth

Beds dedicated to [Integer]
any other CH

Non-dedicated
beds

[Integer]

Total bed
inventory

[Integer]

Total unit
inventory

[Integer]

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 non-dedicated 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.

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

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

41

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

Response Descriptions
Field Name
Participation Type

Response/Data Type
Not Participating

HMIS Participating

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
42

Comparable Database
Participating

Participation Status
Start Date
Participation Status
End Date

[Date]
[Date]

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.

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

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
43

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

Shelter assessments only

Y

1/1/2023

4/30/2023

Project A

Y

Both shelter and
prevention assessments

Y

5/1/2023

Response Descriptions
Field Name

Response/Data Type

Description

Project is a
Coordinated Entry
Access Point

No

This project conducts CE access activities.

Provided by CE Project

Homelessness Prevention
Assessment, Screening,
and/or Referral

CE access point conducts screenings,
assessments, or referrals for households at
risk of homelessness and seeking
homelessness prevention assistance.

Shelter Assessment,
Screening, and/or Referral

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

Yes

Housing Assessment,
Screening, and/or Referral

44

Direct Services (search
and/or placement support)

Project Receives CE
Referrals

No
Yes

CE Participation Status
Start Date
CE Participation Status
End Date

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.

[date]
[date]

This project accepts referrals and
placements from CE.
The date on which the participation status
began.
The date on which the participation status
ended.

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. UDEs also help local communities to better target resources and position programs to
end homelessness in an equitable and just manner/process.
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.06 Gender
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

45

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.

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

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, and HMIS records are
not expected to include “dead names” or otherwise unused legal names. However, each project should
46

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 on the accuracy and completeness of client data over time by editing data
in an HMIS as they engage the client. The initial entry may be as basic as the ‘Project 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 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 place holder 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.
47

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

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 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 projects may serve clients that do not have an SSN. In these cases, select “Client doesn't know”.
The federal statute at 5 U.S.C. Section 522a prohibits a government agency from denying shelter or
services to clients who refused to provide their SSN or do not know their SSN, unless the requirement
was in effect before 1975 or SSN is a statutory requirement for receiving services from the project. For
example, to receive Homelessness Prevention or Rapid Re-Housing services through Supportive Services
for Veteran Families (SSVF) grants, Veterans must provide their SSN to receive services because it's
relevant to verifying their eligibility. The Veteran's household members, however, may decline to
provide their SSN.

48

Response descriptions
Field Name
Social Security Number

Response/Data Type
[9 digits]

Description

SSN Data Quality

Full SSN reported
Approximate or partial 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

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

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

Response descriptions
Field Name
Date of Birth

Response/Data Type
[Date]

Description

49

Date of Birth Data
Quality

Full DOB reported
Approximate or partial DOB
reported
Client doesn't know

Client prefers not to answer

Data not collected

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.

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

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.

50

HMIS users and data entry staff should apply a Client-Centered Approach to Recognizing Race and
Ethnicity Identities in Data Collection. 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, drug
use, and cultural sensitivity (i.e., cultural norms of withholding information due to shame and stigma)
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 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.

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

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 Afro-Caribbean. Examples
include, but are not limited to, African
American, Jamaican, Haitian, Nigerian,
Ethiopian, and Somali.

51

Hispanic/Latina/e/o

Middle Eastern or North African

Native Hawaiian or Pacific
Islander

White

Client doesn’t know

Client prefers not to answer

Data not collected
Additional Race and
Ethnicity Detail

[Text]

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.
"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.06 Gender
Rationale
To indicate client’s self-identification with one or more of the gender categories. Supports system
planning, and local and national understanding of who is experiencing homelessness.

52

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

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

Record the self-reported gender of each client served. When enrolling a client who already has a record
in the HMIS, verify that gender information is complete and accurately reflects how the client identifies,
and correct if it does not. Gender identity is a person’s internal perception of themselves and may not
match the sex they were assigned at birth. This element records one’s gender identity and not sex
assigned at birth.
HMIS users and data entry staff should apply a Client-Centered Approach to Recognizing Gender
Identities in Data Collection. Staff observations should never be used to collect information on gender.
Provide all options to every client. Even if staff think they can guess a client's gender, every client must
be asked for their self-reported information. If they prefer not to provide it or say they don't know, do
not select any response other than “Client doesn’t know” or “Client prefers not to answer” on the
client’s behalf. Gender does not have to match legal documents and clients may not be asked about
medical history or other information to try to determine the person's gender. Simply asking, “Which of
these genders best describes how you identify?” is appropriate and focuses on the person's own internal
knowledge of their gender.
If a client does not understand what a particular gender response means, the descriptions below can be
provided. Clients may select as many of the seven responses to ‘Gender’ as they would like to for their
preferred identity, need, or situation. However, a response of “Client doesn't know” should not be used
interchangeably with the response option “Questioning”. “Questioning” is about exploring one’s gender
identity. “Client doesn't know” should only be selected when a client does not know their gender from
the options available, including “Questioning”. “Client doesn’t know”, “Client prefers not to answer”,
and “Data not collected” are not valid in conjunction with any other response.
If a client discloses being a culturally specific identity (e.g., Two-Spirit), transgender, non-binary,
questioning, or a different identity, staff should ask if the client prefers to have the HMIS record reflect
the client’s gender identity. For example, the availability of these options is not intended to indicate that
transgender individuals are expected to disclose their status; each response is provided as an option in
case an option (or more than one option) is better suited to a client’s identity, needs, or situation. For
instance, if a client identifies as a transgender man but they do not want their transgender identity
recorded in the HMIS, the staff person would select “Man (Boy, if child)” instead of both “Man (Boy, if
child)” and “Transgender”.
Clients may report different gender identities or present different gender expressions at different
projects within the same CoC. This may be because their gender identity has changed or because they
experience a different degree of safety at different projects. If staff are working with a client who
reports a gender identity that differs from the existing HMIS record, staff should ensure that the client
understands and is comfortable with their information being updated across all projects prior to making
any changes. Clients decide to which projects they will disclose potentially sensitive information. Project
staff should enter the self-reported information as directed by the client.
53

Response descriptions
Field Name
Gender

Response/Data Type
Woman (Girl, if
child)
Man (Boy, if child)
Culturally Specific
Identity (e.g., TwoSpirit)
Transgender
Non-Binary
Questioning

Different Identity
Client doesn't know

Client prefers not to
answer

Data not collected
If Different
Identity,
please specify

[Text]

Description
Client identifies as a woman, or girl in the case of a child
under the age of 18.
Client identifies as a man, or boy in the case of a child under
the age of 18.
Client identifies with an identity that is exclusive to a
particular culture. For example, Two-Spirit refers to a Native
North American gender identity.
Client identifies with a transgender history, experience, or
identity.
Client does not identify exclusively as a man or a woman.
Clients who may be unsure, may be exploring, or may not
relate to or identify with a gender identity at this time. Note
that “Client doesn’t Know” is different than “Questioning”.
“Questioning” is about exploring one’s gender identity.
“Client doesn’t Know” should only be selected when a client
does not know their gender from the options available.
Client identifies with another identity that is not listed as a
response. A text box is provided for additional detail.
"Client doesn't know" should only be selected when a client
does not know their gender from among the responses.
"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 gender from among the
responses. "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 gender.
For all clients that selected “Different Identity”, please
specify the identity.

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
understanding of Veterans' service needs.

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

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

54

Record whether the client is a Veteran. An HMIS should only have one record of ‘Veteran Status’ for
each client, no matter how many enrollments they have.
When enrolling a client who already has a record in the HMIS, verify that the Veteran status recorded is
accurate and correct it if it is not.
‘Veteran Status’ is not dependent on discharge status. A dishonorable discharge limits eligibility for
certain VA benefits and programs, but it does not mean that the person is not a Veteran for HMIS and
PIT purposes. Unless the project's funder has eligibility requirements for Veteran status, it is not
necessary to obtain documentation for users to record a “Yes” response to this data element.
Asking additional questions may result in more accurate information as some clients may not be aware
that they are considered Veterans. For example:
•
•
•

“Have you ever been on active duty in the military?”
“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.
55

Data Collection Instruction
Data Collected About
All Clients
Funder: Component - Program
All Programs - All Components
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;
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 NonService-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

Response/Data
Type

Description
56

Disabling
Condition

No
Yes

“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, posttraumatic stress disorder, or brain injury that:
• Is expected to be long-continuing or of indefinite
duration;
• 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 know “Client doesn't know” should only be selected when a client
does not know if they have a disabling condition.
Client prefers not
“Client prefers not to answer” should be selected when a
to answer
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
Data Collected About
Funder: Component - Program
Project Type Applicability
Collection Point

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

57

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.
Each individual client in a household will have their own ‘Project Start Date’. If a new client is added to a
household after the original household members' start dates, the new client's start date should reflect
the actual day that client started the project. If this client is a newborn baby, the ‘Project Start Date’
would reflect the date the 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 reenter 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 scattered-site subsidy) or expects to
have one in a reasonably short amount of time.
Other Service Projects (including but not limited to: Services Only,
Day Shelter, Homelessness Prevention, Coordinated Entry): Date the
client first began working with the project and generally received the
first provision of service.
58

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
Data Collected About
All Clients
Funder: Component - Program
All Programs - All Components
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 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 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
59

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

•

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/follow-up
services but does not extend the length of the client's enrollment in a project. Services provided “post
exit” will fall after the client's ‘Project Exit Date’. In residential projects that require use of this Data
Collection Stage, the client is still to be exited as of the date 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
Data Collected About

All Clients
60

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.
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 HMIS-based
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 militarysupplied housing, “Rental by Client, with other ongoing housing subsidy” can be selected, consistent
61

with the notion that these units are not owned by client, have conditions of tenancy, and have a value
ascribed to them. If the client is moving into housing with a relative during schooling, Living with Family,
Permanent Tenure can be selected, consistent with the notion that the client may stay with the family
member for as long as needed to complete school.
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

Response/Data
Type

Destination

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

Rental Subsidy Type

If Other for “Type of [Text]
Residence”

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

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

62

assistance and who live together in one dwelling unit, or, for persons who are not housed, who would
live together in one dwelling unit if they were housed.
There 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 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 retain 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

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

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

Grandchildren, nieces, nephews, cousins, or other
relatives, regardless of their age.

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

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.

64

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

Response/Data Type
[Text] [6 characters: XX-XXX]

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 which have already moved into permanent housing from households which 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
Data Collected About
Funder: Component - Program
Project Type Applicability

Collection Point

Head of Household
All Programs - All Permanent Housing Components
PH - Permanent Supportive Housing
PH - Housing Only
PH - Housing with Services (no disability required for entry)
PH - Rapid Re-Housing
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 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
65

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

Head of Household and Adult(s)
All Programs - All Components
All HMIS Project Types*
Project Start
66

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

67

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.

68

3.917 For Street Outreach, Emergency
Shelter, Safe Haven

Where was the client just before project
start?

How long ago did the client start staying
in that place?

How long has the client been in a ‘literal
homeless’ situation?

How many times has the client been in
‘literal homeless’ situations in the past 3
years?

How many months have been spent on
the street, in ES, or SH, in the past three
years?

69

70

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

Approximate
date this
episode of
homelessness
started

[Date]

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.

71

(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

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)

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

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

Program Specific Data Elements
Common Program Specific Data Elements
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 crosssystems connections to ensure access to additional income sources.

Data Collection Instruction
Data Collected About
Funder: Component - Program

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
72

Project Type Applicability

HUD: ESG RUSH – Collection required for all components
except Emergency Shelter or Street Outreach
HUD: HOPWA – Collection required for all components
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 permanent housing
projects
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
73

record must be created for the 18-year-old client reflecting any income associated with that client. If
some existing income transfers to the 18-year-old's new record, an additional update record would need
to be created for the Head of Household, reflecting the removal of that income from their record.
'Information Date' for those records must reflect the date of the data collection.
An ‘Income and Sources’ record must be created as part of an annual assessment for clients participating
in a project 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.

74

Response Descriptions
Field Name
Information Date

Response/Data Type
[Date]

Income from Any
Source

No

Earned Income (i.e.,
employment income)

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

Monthly amount
Unemployment
Insurance

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.

[Currency/decimal]
No

Yes

Monthly Amount
VA Service-Connected
Disability
Compensation

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.

[Currency/decimal]
No
Yes

Monthly amount
Social Security
Disability Insurance
(SSDI)

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

[Currency/decimal]
No
Yes

Monthly amount
Supplemental
Security Income (SSI)

Description
The date the information was collected

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.

[Currency/decimal]
No

75

Yes

Monthly Amount
VA Non-ServiceConnected Disability
Pension

[Currency/decimal]
No

Yes

Monthly Amount
Private disability
insurance

[Currency/decimal]
No
Yes

Monthly Amount
Worker's
Compensation

[Currency/decimal]
No
Yes

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

[Currency/decimal]
No
Yes

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 low-income
people.

Cash public assistance payments for low-income
people.

[Currency/decimal]
No
Yes

Monthly Amount
Pension or retirement
income from a former
job

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

[Currency/decimal]
No

Yes
Monthly Amount
Retirement Income
from Social Security

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 monthly cash benefit that replaces income
when one reduces their working hours or stops
working altogether.

[Currency/decimal]
No

Yes

Pension or retirement income includes payments
from the following sources: companies or
unions; federal government (Civil Service);
76

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.
Monthly Amount
Child support

Monthly Amount
Alimony and other
spousal support

[Currency/decimal]
No
Yes

[Currency/decimal]
No
Yes

Monthly Amount
Other Source
Monthly Amount
Specify Source
Total Monthly 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 onetime property settlements.

[Currency/decimal]
No
Yes
[Currency/decimal]
[text]
[Currency/decimal]

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
Data Collected About
Funder: Component - Program

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
HUD: HUD-VASH – Collection required for HUD VASH
Collaborative Case Management
HUD: PFS – Collection required for all permanent housing
projects
HHS: PATH – Collection required for all components

77

Project Type Applicability

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 Non-Cash 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 18-year-old client reflecting any benefits associated with that
client. If an existing benefit transfers to the 18-year-old's new record, an additional update record would
need to be created for the Head of Household, reflecting the removal of that benefit from their record.
'Information Date' for those records must reflect the date of the data collection.
A Non-Cash Benefits record must be created as part of an annual assessment for clients participating in a
project one year or more, even if there is no change in benefits. 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.
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.
78

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

Response/Data Type Description
[Date]
The date the information was collected

Non-Cash Benefit from Any
Source

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

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

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

Previously known as Food Stamps

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.

No
Yes
No
Yes
No
Yes
No
Yes
[Text]

79

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
Data Collected About
Funder: Component - Program

Project Type Applicability

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 permanent
housing projects
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

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

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

Response/Data Type

Description

Information Date

[Date]

The date the information was collected.

Covered by Health
Insurance

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

Medicaid

Medicare

No
Yes

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

No

Veteran's Health
Administration (VHA)

No

Employer-Provided
Health Insurance

No

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

Yes

Yes

Yes

Including TRICARE available to Veterans based
on military service.
81

Health Insurance
obtained through COBRA

No
Yes

Private Pay Health
Insurance

No
Yes

State Health Insurance for No
Adults (or use local name)
Yes
Indian Health Services
Program

No

Other

No

Yes

Yes

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

Specify Source

[Text]

If “No” for each of the
health insurance sources
“no” Reason (HOPWA
ONLY)

Applied; decision
pending
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

4.05 Physical Disability
Rationale
To indicate whether clients have a physical disability which contribute to their experience of
homelessness or may be a factor in housing.

Data Collection Instruction
Data Collected About
Funder: Component - Program

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
82

Project Type Applicability
Collection Point

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 permanent housing
projects
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 physical disability; and
2. If there is 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 long-continued, and
indefinite duration and substantially impair ability to live independently, although a disability of such
type may not qualify clients for programs meant for 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
83

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

Information Date

[Date]

Physical Disability

No
Yes

Descriptions

The date the information was collected.

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

Client doesn't
know
Client prefers not
to answer
Data not collected
If Yes for “Physical
Disability”

No
Yes

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

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.

84

Data Collection Instruction
Data Collected About
Funder: Component - Program

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 permanent housing
projects
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.

85

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 Description
Field Name

Response
Category/ Data
Type

Descriptions

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 which contribute to their experience of
homelessness or may be a factor in housing.

Data Collection Instruction
Data Collected About
All Clients
Funder: Component - Program
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 permanent housing projects
86

Project Type Applicability
Collection Point
In separate fields, record:

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

1. If the client has a chronic health condition; and
2. If there is 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 long-continued, and
indefinite duration and substantially impair ability to live independently, although a disability of such
type may not qualify clients for programs meant for 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

87

Information Date

[Date]

Chronic Health
Condition

No
Yes

The date the information was collected.

For the purposes of these Data Standards, a chronic
health condition means a diagnosed condition that is
more than 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, post-traumatic 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 longcontinued 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
Client prefers
not to answer
Data not
collected
88

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
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

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 permanent housing projects
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

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
89

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]

Descriptions
The date the information was
collected.

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

4.09 Mental Health Disorder
Rationale
To indicate whether clients have any mental health disorders which contribute to their experience of
homelessness or may be a factor in housing.

Data Collection Instruction
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

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 permanent housing projects
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

90

In separate fields, indicate:
1. If each client has a mental health disorder; and
2. If there is 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 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 ‘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 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.

No

91

Mental Health
Disorder

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

92

4.10 Substance Use Disorder
Rationale
To indicate whether clients have a substance use disorder which contributes to their experience of
homelessness or may be a factor in housing.

Data Collection Instruction
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

All Clients
HUD: CoC – Collection required for all components except SSO
Coordinated Entry
HUD: ESG – Collection required for all components except ESNbN
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 permanent housing
projects
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 the indicated disability; and
2. If there is 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.

93

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 long-continued and
indefinite duration and substantially impair ability to live independently, although a disability of such
type may not qualify clients for programs meant for 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

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

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

94

impairs ability to
live independently

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 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
Data Collected About
Funder: Component - Program

Project Type Applicability
Collection Point

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 permanent housing projects
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.

95

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

96

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

Within the past
three months
Three to six months
ago (excluding six
months exactly)
Six months to one
year ago (excluding
one year exactly)
One year ago, or
more
Client doesn't know
Client prefers not to
answer
Data not collected

If Yes for “Survivor of
Domestic Violence
Victim/Survivor”
Are you currently
fleeing?

No
Yes

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.

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

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
Data Collected About
Funder: Component - Program

Head of Household and Adult(s)
HUD: CoC – Collection required for SSO – Street Outreach,
SSO – Coordinated Entry, and any YHDP funded 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 all
components except SSO Coordinated Entry
97

Project Type Applicability

Collection Point

HUD: Rural Special NOFO – Collection required for all
components except 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
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 Activity 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 "communitydefined 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 registration, request for
personal care items, dinner sign-up, meals, etc.), nor should it be redundant with data element 4.14
Bed-Night Date.

98

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 - Living Situation Option List for a complete list
of Living Situation Responses and Destinations

Rental Subsidy Type

See Appendix A

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

This field and subsequent dependencies
are applicable only to CE projects.
No
Yes
Client doesn't know
Client prefers not to
answer
Data not collected

Has a subsequent residence been
identified?

No
Yes
Client doesn't know
99

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

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]

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
Data Collected About
Funder: Component - Program

Project Type Applicability

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
100

Collection Point

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.

4.14 Bed-Night Date
Rationale
To determine each bed-night utilized by a client in a night-by-night shelter.

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

All Clients
HUD: ESG - Collection required for ES – NbN
HUD: ESG RUSH – Collection required for ES - NbN
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.
101

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 night-bynight 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.

Data Collection Instruction
Funder: Program-Component 

Project Type Applicability 
Data Collected About 
Collection Point 

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  

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
102

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]
Administrator-managed list
of locations
Phone
Virtual
In Person

Assessment Level

Crisis Needs Assessment

Housing Needs Assessment

Assessment Questions

Locally determined fields

Assessment Answers

Locally determined fields

Assessment Result
Type
Assessment Result

Locally determined fields

Prioritization Status

Placed on prioritization list

Locally determined fields

Not placed on prioritization
list

Description
The date the assessment occurred.
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 (faceto-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 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
103

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
Funder: Program-Component 

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

Project Type Applicability 
Data Collected About 

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

Collection Point 

At occurrence  

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 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
Referral to a scheduled
Coordinated Entry
Crisis Needs
Assessment

Description
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 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.
Referral to a scheduled The client received a referral to a Coordinated
Coordinated Entry
Entry Housing Needs Assessment; or other local
Housing Needs
equivalent assessment. For a description of
Assessment
Housing Needs Assessment, please see Data
Element 4.19 CE Assessment.
Header: Referral Events [Not a response option]
104

Referral to postplacement/ follow-up
case management

Referral to a Street
Outreach project or
services
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

The client received a referral to a post-placement
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.
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 non-subsidized housing.
The client received a referral to non-continuum
services because they were ineligible for
continuum services, or other local equivalent
referral. Non-continuum services may include
emergency assistance projects for those not atrisk 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
105

project/unit/resource
opening
Referral to RRH project
resource opening

Referral to PSH project
resource opening

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/Rapi
d Resolution
intervention or service
result - Client
housed/re-housed in a
safe alternative

No

Yes

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

No

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

106

Yes

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

System-generated list
of project IDs accepting
referrals from CE

Successful referral:
client accepted

Unsuccessful referral:
client rejected

Unsuccessful referral:
provider rejected

Date of Result

[Date]

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

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.

107

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
Funder: Component Program

Project Type Applicability
Data Collected About
Collection Point

HUD: CoC – Collection required for Permanent Supportive Housing
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)

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

108

Data Collection Instruction
Funder: Component - Program
Project Type Applicability

Data Collected About
Collection Point

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

Response
Field Name

Response Category/ Data Type

Information Date

[Date]

Current school enrollment
and attendance

Not currently enrolled in any school or educational course
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

109

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

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
Funder: Component - Program

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 components

Project Type Applicability
Data Collected About
Collection Point

All Project Types
Head of Household
Project Start

Response
Field Name
Translation Assistance Needed

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

110

HOPWA
Please see the HOPWA Program HMS 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.

Data Collection Instruction
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)

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

111

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.

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

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

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
Funder: ProgramComponent
Project Type
Applicability

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

112

Data Collected About

All Household Members with HIV/AIDS

Collection Point

Project Start, Update, Project Exit

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)”
Reason

Applied; decision pending
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”
Reason

Applied; decision pending
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

113

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
Funder: ProgramComponent
Project Type
Applicability

Data Collected About
Collection Point

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

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 T-Cell
(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
Client prefers not to answer
114

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
How was the information obtained

Medical report
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
Funder: ProgramComponent

Project Type
Applicability

Data Collected About
Collection Point

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

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
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
115

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

Subsidy information
If Moved to new housing
unit for “Housing
Assessment at Exit”

With on-going subsidy
Without an on-going subsidy

Subsidy information

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
Funder: ProgramComponent
Project Type Applicability

Data Collected About
Collection Point
Field Name
Information Date
Has the participant been
prescribed anti-retroviral
drugs?

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
Response Category/ Data Type
[date]
No
Yes
Client doesn't know
Client prefers not to answer
Data Not Collected

116

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

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

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
Residential supportive services
Housing minor renovation
Housing moving assistance
Housing eligibility determination
Security deposits
One-time rent for eviction prevention

117

P2 Referrals Provided – PATH
Rationale
To determine the referrals that are made on behalf of a client during project enrollment.

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

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

Response
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

Not Attained
Unknown

118

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

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

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
Field Name

Response Category/ Data Type

Date of Status Determination

[Date]

Client Became Enrolled in
PATH

No

If No for “Client Became
Enrolled in PATH”

Client was found ineligible for PATH

Reason not enrolled

Yes

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
Funder: Program-Component

Project Type Applicability

Data Collected About
Collection Point

HHS: PATH – Collection required for all components
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

119

Response
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
Funder: Program-Component
Project Type Applicability

Data Collected About
Collection Point

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
Field Name

Response Category/ Data Type

Referral Source

Self-Referral
Individual: Parent/Guardian/Relative/ Friend/Foster Parent/
Other Individual
Outreach Project
Temporary Shelter
Residential Project
Hotline
Child Welfare/ CPS
Juvenile Justice
120

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 FYSB-RHY
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-in-time
and other counts and measures.
C. Identifies the number of runaway youth.

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

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

Response
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
Ward of the State – Immediate Reunification

121

Reason why services are not funded
by BCP grant

Ward of the Criminal Justice System - Immediate
Reunification
Other

If Yes for “Youth Eligible for RHY
Services”
Runaway youth

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

R3 Sexual Orientation
Rationale
The purpose is to identify the sexual orientation of all heads of household and adults served in RHY programs.

Data Collection Instruction
Funder: Program-Component

Project Type Applicability

Data Collected About
Collection Point

HHS: RHY – Collection required for all components
HUD: CoC – Youth Homeless Demonstration Program (YHDP)
– collection required for all components
HUD: CoC – Permanent Supportive Housing
HUD: Unsheltered Special NOFO – Collection required for
Permanent Supportive Housing
HUD: Rural Special NOFO – Collection required for all
Permanent Supportive Housing
Emergency Shelter - Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for
entry)
Street Outreach
PH – Housing Only
PH – Housing with Services (no disability required for entry)
Homelessness Prevention
PH – Rapid Re-Housing
Head of Household and Adults
Project Start

Response
Field Name

Response Category/ Data Type

Sexual Orientation

Heterosexual
Gay
Lesbian
Bisexual
122

Questioning/Unsure
Other
Client doesn't know
Client prefers not to answer
Data not collected
If other, please describe

[Text]

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
Funder: Program-Component

HUD: HUD-VASH – Collection required for HUD/VASHContinuum
HHS: RHY – Collection required for all components except for
Street Outreach
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
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
123

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.

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

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
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
124

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
Funder: ProgramComponent

Project Type Applicability

Data Collected About
Collection Point

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
Head of Household and Adults
Project Start, Project Exit

Response
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

125

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
Funder: Program-Component

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

Data Collected About
Collection Point

Head of Household and Adults
Project Start, Project Exit

Response
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
Funder: Program-Component
Project Type Applicability

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

Data Collected About
Collection Point

Head of Household and Adults
Project Start, Project Exit

Response
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

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
Funder: ProgramComponent

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
Field Name

Response Category/ Data Type

Mental Health Status

Excellent
Very Good
Good
Fair
Poor
Client doesn't know
127

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
Funder: Program-Component
Project Type Applicability

Data Collected About
Collection Point

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

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

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
128

Response
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”
Number of Years

Less than one year
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)

R12 Formerly a Ward of Juvenile Justice System
Rationale
The purpose is to identify clients with juvenile justice system responsibility histories.

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

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
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”
Number of Years

Less than one year
1 to 2 years
3 to 5 years
129

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.

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

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
Field Name

Response Category/ Data Type

Unemployment – Family member

No
Yes

Mental Health Disorder – Family
member

No

Physical Disability – Family member

No

Yes

Yes
Alcohol or Substance Use Disorder –
Family member

No

Insufficient Income to Support Youth –
Family member

No

Incarcerated Parent of Youth

No

Yes

Yes

Yes

130

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
Funder: Program Component
Project Type Applicability

Data Collected About
Collection Point

HHS: RHY – Collection required for components – as outlined below
Emergency Shelter - Entry Exit
Transitional Housing
Services Only
Homelessness Prevention
Head of Household and Adults
Occurrence Point (At First Service)

Response
Field Name

Response Category/ Data Type

BCP-p

BCP-es

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
131

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.

Data Collection Instruction
Funder: ProgramComponent

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

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
Client prefers not to answer
Data not collected
132

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

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

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

Response
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,
pressured, or tricked into continuing
the job
If Yes for either “Workplace violence
threats” OR “Workplace promise
actual difference” – In the last 3
months

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

133

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

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
Field Name
Project Completion Status

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

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

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
Funder: Program-Component
Project Type Applicability

Data Collected About
Collection Point

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

Response
Field Name

Response Category/ Data Type

Client received counseling

No
134

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.

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

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

Response

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
135

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

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
Funder: Program-Component

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

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

136

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. HUD-VASH Project
setup information can also be found in the HUD-VASH Program HMIS Manual.

V1 Veteran’s Information
Data Collection Instruction
Funder: Program-Component

Project Type Applicability

Data Collected About
Collection Point

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

Response
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

137

Client doesn't know
Client prefers not to answer
Data not collected
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
138

Theater of Operations: Other Peacekeeping 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

V2 Services Provided – SSVF
Data Collection Instruction
Funder: Program-Component

VA: SSVF – Collection required for RRH and Homelessness
Prevention

Project Type Applicability

Homelessness Prevention
PH – Rapid Re-Housing

139

Data Collected About

All Clients receiving services

Collection Point

Occurrence Point (As Provided)

Response
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
Legal services – eviction prevention
Legal services – outstanding fines and penalties
Legal services – restore/acquire driver's license
Legal services – other
Child care
140

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

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
Field Name

Response Category/ Data Type

Start Date of Financial Assistance

[Date]

Financial Assistance Amount

[Amount]

Financial Assistance Type

Rental assistance
Utility fee payment assistance
Security deposit
Utility deposit
Moving costs
Transportation services: token/vouchers
141

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

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

Response
Field Name

Response Category/ Data Type

Household Income as a percentage of
AMI

30% or less
31% to 50%
51% to 80%
81% or greater

V6 VAMC Station Number
Data Collection Instruction
Funder: Program-Component

Project Type Applicability

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: CRS Contract Residential Services
VA: Community Contract Safe Haven Program
Emergency Shelter - Entry Exit
Transitional Housing
PH – Permanent Supportive Housing (disability required for
entry)
142

Data Collected About
Collection Point

Services Only
Safe Haven
PH – Housing Only
Homelessness Prevention
PH – Rapid Re-Housing
Head of Household
Project Start

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

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

Response
Field Name

Response Category/Data Type

Is Homelessness Prevention targeting
screener required?

No

Housing loss expected within...

1-6 days

Yes

7-13 days
14-21 days
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

143

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

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

No

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

No

Rental Evictions within the past 7
years (any adult)

No prior rental evictions

Yes

Yes

Yes

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

Incarcerated as adult (any adult in
household)

Not incarcerated

Yes

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

Head of Household with disabling
condition (physical health, mental
health, substance use) that directly

No

Yes

Yes

144

affects ability to secure/maintain
housing
Currently pregnant (any household
member)

No

Single parent/guardian household
with minor child(ren)

No

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

No

Yes

Yes

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
age/gender mix)

No

Household includes one or more
members of an overrepresented
population in the homelessness
system when compared to the general
population

No

HP applicant total points

[Integer]

Grantee targeting threshold score

[Integer]

Yes

Yes

V8 HUD-VASH Voucher Tracking
Data Collection Instruction
Funder: Program-Component

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
Field Name

Response Category/ Data Type

Information date

[Date]
145

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]

V9 HUD-VASH Exit Information
Data Collection Instruction
Funder: Program-Component
Project Type Applicability
Data Collected About
Collection Point

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

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

146

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
5.01 Date Created
Field Name

Response Category/ Data Type

Date Created

[Date]

5.02 Date Updated
Field Name

Response Category/ Data Type

Date Updated

[Date]

5.03 Data Collection Stage
Field Name

Response
Category/ Data
Type

Data Collection
Stage

Project Start

Descriptions

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.

147

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 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
148

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.

5.04 Information Date
Field Name
Information Date

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

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

Descriptions

5.05 Project Identifier

5.06 Enrollment Identifier

5.07 User Identifier
Field Name

149

User Identifier

[Integer]

A unique ID used to associate data
with the user who entered and/or
edited it

5.08 Personal Identifier
Field Name
Personal Identifier

Response Category/ Data Type
[Integer]

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

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.09 Household Identifier
Field Name
Household Identifier

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.

150

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-to-reach persons
experiencing
homelessness with
severe mental illness
and/or substance use
disorders who are on
the street and have
been unable or
unwilling to
participate in
supportive services.

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 (300399)
Transitional housing for homeless
persons (including homeless youth)
Residential project or halfway house
A sober living or other
with no homeless criteria
residential project
with no lease or rights
of tenancy, with or
without time limits.
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)

Prior
Living
Situation
(3.917)

Current
Destination
Living
(3.12)
Situation
(4.12)

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

X

X

X

X

X

X

X
X

151

Staying or living with friends,
temporary tenure (e.g., room,
apartment, or house)
Moved from one HOPWA funded
project to HOPWA TH

X
Limited to use by
HOPWA-funded
projects

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 (400499)
Staying or living with family, permanent
tenure
Staying or living with friends,
permanent tenure
Moved from one HOPWA funded
Limited to use by
project to HOPWA PH
HOPWA-funded
projects
Rental by client, no ongoing housing
A rental that the client
subsidy
will pay for on their
own (without a
subsidy of any kind)
Rental by client, with ongoing housing
Any subsidized rental
subsidy
housing.
Owned by client, with ongoing housing
subsidy
Owned by client, no ongoing housing
subsidy
Other (1-99)
No exit interview completed
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
Other
Any response of
"Other" in Destination
will not count in any
HMIS-based reporting
as a positive outcome.
Deceased
Worker unable to determine
Client doesn’t know
Client prefers not to answer
Data not collected

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
X
X

Subsidy Types – Dependent Field, relies on Living Situation = 435
Response
GPD TIP housing subsidy
VASH housing subsidy
RRH or equivalent subsidy

Description

152

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)
Permanent Supportive Housing
Other permanent housing dedicated for formerly
homeless persons

Includes HCV with no paired services.

153

Appendix B Acronyms
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
HIC
HIV
HMIS
HoH
HOPWA

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
Housing Inventory Count
Human Immunodeficiency Virus
Homeless Management Information System
Head of Household
Housing Opportunities for Persons with AIDS
154

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
TBRA
TFA
TH
TIP
TLP
VA

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
Tenant Based Rental Assistance
Temporary Financial Assistance
Transitional Housing
Transition in Place
Transitional Living Program
Department of Veterans Affairs
155

VAMC
VASH
VAWA
VSP
WIC
XML
YHDP

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.

156