RHY Funded Grantees (data submission) – FY22 & FY23

FY 2020 HMIS Data Standards
September 2019
U.S. Department of Housing and Urban Development
Version 1.4

Table of Contents

Contents
Contents ...................................................................................................................................... 1
Revision History .......................................................................................................................... 1
1. INTRODUCTION TO THE HMIS DATA STANDARDS ...................................................................... 2
1.1 HMIS DATA STANDARDS OVERVIEW .................................................................................... 2
Related Documents................................................................................................................. 3
HMIS Federal Partner Program Manuals ................................................................................ 3
HMIS Data Standards Terms and Concepts ............................................................................ 4
Data Element Structure .......................................................................................................... 6
1.2 INTRODUCTION TO PROJECT DESCRIPTOR DATA ELEMENTS ............................................. 10
HMIS Project Setup Guidance ............................................................................................... 12
Multiple Funding Sources ..................................................................................................... 12
Multiple Project Setup .......................................................................................................... 13
Projects that Operate in Multiple CoCs ................................................................................ 14
1.3 INTRODUCTION TO UNIVERSAL DATA ELEMENTS .............................................................. 16
General Data Collection Guidance ........................................................................................ 17
Uses and Disclosures of Client Data...................................................................................... 17
1.4 INTRODUCTION TO PROGRAM SPECIFIC DATA ELEMENTS ................................................ 17
Federal Partner Program Data Elements .............................................................................. 19
1.5 INTRODUCTION TO METADATA ELEMENTS........................................................................ 20
1.6 DATA COLLECTION GUIDANCE BY PROJECT TYPE ............................................................... 21
Street Outreach..................................................................................................................... 21
Coordinated Entry ................................................................................................................. 22
'Night-by-Night' Emergency Shelters .................................................................................... 25
‘Entry/Exit’ Emergency Shelter and Transitional Housing .................................................... 26
Day Shelter ............................................................................................................................ 26
Permanent Housing: PSH and RRH ....................................................................................... 26
2. PROJECT DESCRIPTOR DATA ELEMENTS ................................................................................... 27
2.01 Organization Information........................................................................................... 27
2.02 Project Information .................................................................................................... 29
2.03 Continuum of Care Information ................................................................................. 42
2.06 Funding Sources ......................................................................................................... 45
2.07 Bed and Unit Inventory Information .......................................................................... 49
3. UNIVERSAL DATA ELEMENTS .................................................................................................... 58
Universal Identifier Elements (One and Only One per Client Record) ..................................... 58
3.01 Name .......................................................................................................................... 58
3.02 Social Security Number .............................................................................................. 60
3.03 Date of Birth ............................................................................................................... 62
i

Table of Contents
3.04 Race ............................................................................................................................ 63
3.05 Ethnicity...................................................................................................................... 66
3.06 Gender ........................................................................................................................ 67
3.07 Veteran Status ............................................................................................................ 69
Universal Project Stay Elements (One or More Value(s) Per Client or Household Project Stay)
................................................................................................................................................... 71
3.08 Disabling Condition ................................................................................................... 71
3.10 Project Start Date ...................................................................................................... 74
3.11 Project Exit Date ........................................................................................................ 76
3.12 Destination ................................................................................................................ 78
3.15 Relationship to Head of Household .......................................................................... 80
3.16 Client Location ........................................................................................................... 83
3.20 Housing Move-in Date............................................................................................... 85
3.917 Prior Living Situation ................................................................................................. 87
4. PROGRAM SPECIFIC DATA ELEMENTS ...................................................................................... 95
Common Program Specific Data Elements ............................................................................... 95
4.02 Income and Sources .................................................................................................. 95
4.03 Non-Cash Benefits ................................................................................................... 101
4.04 Health Insurance ..................................................................................................... 105
4.05 Physical Disability .................................................................................................... 109
4.06 Developmental Disability ........................................................................................ 112
4.07 Chronic Health Condition ........................................................................................ 114
4.08 HIV/AIDS .................................................................................................................. 117
4.09 Mental Health Problem ........................................................................................... 119
4.10 Substance Abuse ..................................................................................................... 122
4.11 Domestic Violence ................................................................................................... 125
4.12 Current Living Situation ........................................................................................... 129
4.13 Date of Engagement ................................................................................................ 133
4.14 Bed-Night Date ........................................................................................................ 134
4.19 Coordinated Entry Assessment ............................................................................... 135
4.20 Coordinated Entry Event ......................................................................................... 138
Federal Partner Program Data Elements ................................................................................ 145
HOPWA ................................................................................................................................... 145
W1 Services Provided - HOPWA ......................................................................................... 145
W2 Financial Assistance - HOPWA ...................................................................................... 146
W3 Medical Assistance ....................................................................................................... 147
W4 T-cell (CD4) and Viral Load ........................................................................................... 149
W5 Housing Assessment at Exit .......................................................................................... 151
PATH ........................................................................................................................................ 153
P1 Services Provided - PATH Funded .................................................................................. 153
P2 Referrals Provided - PATH .............................................................................................. 155
P3 PATH Status.................................................................................................................... 158
P4 Connection with SOAR ................................................................................................... 160
RHY .......................................................................................................................................... 161
ii

R1 Referral Source .............................................................................................................. 161
R2 RHY - BCP Status ............................................................................................................ 162
R3 Sexual Orientation ......................................................................................................... 164
R4 Last Grade Completed ................................................................................................... 165
R5 School Status.................................................................................................................. 167
R6 Employment Status........................................................................................................ 169
R7 General Health Status .................................................................................................... 170
R8 Dental Health Status ...................................................................................................... 171
R9 Mental Health Status ..................................................................................................... 172
R10 Pregnancy Status ......................................................................................................... 173
R11 Formerly a Ward of Child Welfare/Foster Care Agency .............................................. 174
R12 Formerly a Ward of Juvenile Justice System ............................................................... 175
R13 Family Critical Issues .................................................................................................... 177
R14 RHY Service Connections ............................................................................................. 178
R15 Commercial Sexual Exploitation/Sex Trafficking ......................................................... 182
R16 Labor Exploitation/Trafficking ..................................................................................... 185
R17 Project Completion Status ........................................................................................... 188
R18 Counseling.................................................................................................................... 190
R19 Safe and Appropriate Exit ............................................................................................ 191
R20 Aftercare Plans............................................................................................................. 193
RHSAP ...................................................................................................................................... 194
U1 Worst Housing Situation................................................................................................ 194
VA ............................................................................................................................................ 194
V1 Veteran Information ...................................................................................................... 194
V2 Services Provided - SSVF ................................................................................................ 197
V3 Financial Assistance - SSVF ............................................................................................ 199
V4 Percent of AMI (SSVF Eligibility) .................................................................................... 200
V5 Last Permanent Address ................................................................................................ 201
V6 VAMC Station Number .................................................................................................. 202
V7 SSVF HP Targeting Criteria ............................................................................................. 203
V8 HUD-VASH Voucher Tracking......................................................................................... 206
V9 HUD-VASH Exit Information .......................................................................................... 207
Metadata Elements..................................................................................................................... 208
5.01 Date Created ............................................................................................................... 208
5.02 Date Updated .............................................................................................................. 209
5.03 Data Collection Stage .................................................................................................. 210
5.04 Information Date ........................................................................................................ 214
5.05 Project Identifier ......................................................................................................... 215
5.06 Enrollment Identifier................................................................................................... 216
5.07 User Identifier ............................................................................................................. 217
5.08 Personal Identifier....................................................................................................... 218
5.09 Household Identifier ................................................................................................... 219
Appendix A. Living Situation Response Categories and Descriptions......................................... 221

iii

Revision History
Date

Version

Revision

April 2019
May 2019

1.1
1.2

FY 2020 Data Standards
•
•

Aligned to FY 2020 Dictionary
Fixed word “Unable” to “Able” in CE section on page 24

June 2019

1.3

•
•

Added Coordinated Entry Descriptions
Fixed incorrect field response # for “Worker unable to
determine” in the System Logic & Other System Issues section of
4.12.
R3 – added additional project type applicability (PH projects)
Removed “Information Date” from Unit Inventory instructions
on page 54.

•
•

September 2019

1.4

•

•
•
•
•
•
•

•
•
•
•
•
•

9/3/2019

Moved “Housing Type” and “Target Population” from 2.07 Bed
and Unit Inventory Information to 2.02 Project Information and
changed “Housing Type” to be dependent field to Residential
Project Types only
Updated “Dedicated Bed” field names
Corrected element level change summary throughout
Fixed Collection Point for 4.11 to “Project Start, Update”
Revised Client Uses and Disclosures
Revised HMIS Project Set Up Guidance
Field number updates
o 4.03
o 4.12
Corrected ESG Funder/Component in 4.12 Current Living
Situation
Updated SSVF Funder/Program Component Requirements
Corrections to Metadata elements
Corrected hyperlinks throughout
Corrected Funder/Program Component for W5 and 4.12
Added clarifying language to “Night by Night” shelter for exit

1

1. INTRODUCTION TO THE HMIS DATA STANDARDS

1. INTRODUCTION TO THE HMIS DATA STANDARDS
1.1 HMIS DATA STANDARDS OVERVIEW
A Homeless Management Information System (HMIS) is the information system designated by a
local Continuum of Care (CoC) to comply with the requirements of CoC Program interim rule 24
CFR 578. It is a locally-administered data system used to record and analyze client, service, and
housing data for individuals and families who are homeless or at risk of homelessness.
HMIS is administered by the U.S. Department of Housing and Urban Development (HUD)
through the Office of Special Needs Assistance Programs (SNAPS) as its comprehensive data
response to the congressional mandate to report annually on national homelessness. It is used
by all projects that target services to persons experiencing homelessness within SNAPS and the
office of HIV-AIDS Housing. It is also used by other Federal Partners from the U.S. Department
of Health and Human Services (HHS) and the U.S. Department of Veterans Affairs and their
respective programs to measure project performance and participate in benchmarking of the
national effort to end homelessness.
The HMIS Data Standards were first published by HUD in 2004. The original standards served as
the foundation for software developers in constructing HMIS applications. HUD, in
collaboration with its Federal Partners have 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.
An HMIS software 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.
Comparable databases are required for use by providers of services for victims of domestic
violence, as described in the Violence Against Women Act (VAWA).
There are many software products on the market that communities across the country have
chosen to use as their HMIS. Each product has unique features and was built to meet the
different data collection needs of each community. Each software vendor should provide the
guidance, support, and documentation necessary for the CoC to understand the system they
are using.
Communities may elect to add data elements, add response categories, or maintain historical
data element collection beyond what is specified in the Data Standards as long as it does not
impact the ability of the CoC to accurately collect and report on the required data elements. In
these cases, HMIS Leads should work directly with their HMIS software providers to meet their
individual needs.

9/3/2019

2

Related Documents
There are a variety of documents that comprise the suite of HMIS Data Standard resources.
Each of the documents has a specific purpose and intended audience. The HMIS Lead should be
familiar with all of the documents and collectively use them as their HMIS reference materials
along with any supplemental instructional materials provided by the software vendor.
•

FY2020 HMIS Data Standards represent the foundation for the data contained within an
HMIS, project setup instructions, and data collection instructions. This is a complete
document that merges what was formerly separated into the Dictionary and Manual
documents.
•

•

FY2020 HMIS Data Dictionary Table Shells contain the data element tables with
relevant programming instructions, system logic and other issues to be used by
vendors for HMIS programming. The information in the tables shells aligns with
the information contained herein.

Data Exchange Resources:
•

FY2020 CSV Programming Specifications

•

FY2020 XML Programming Specifications

•

HMIS Federal Partner Program Manuals

•

Federal Partner Reporting and Programming Specifications

HMIS Federal Partner Program Manuals
These manuals contain specific and detailed information on project setup for each of the
Federal Partners participating in HMIS including: HMIS project typing, the specific data
elements required for collection by that Federal Partner, program-specific meanings and
definitions, and key information that the Federal Partner has identified as required for their
program. Each manual was created jointly by HUD and the relevant Federal Partner, and
approved by both entities prior to publishing.

9/3/2019

3

1. INTRODUCTION TO THE HMIS DATA STANDARDS
Manual Name

Federal Partner

CoC Program HMIS
Manual

U.S. Department of Housing and Urban
Development - Office of Special Needs
Assistance Programs
CoC Program Information link
ESG Program HMIS U.S. Department of Housing and Urban
Manual
Development - Office of Special Needs
Assistance Programs
ESG Program Information link
HOPWA Program
U.S. Department of Housing and Urban
HMIS Manual
Development - Office of HIV/AIDS
Housing
HOPWA Program Information link
PATH Program HMIS U.S. Department of Health and Human
Manual
Services - Substance Abuse and Mental
Health Services Administration
PATH Program Information link
RHY Program HMIS U.S. Department of Health and Human
Manual
Services - Administration for Children
and Families - Family and Youth
Services Bureau
RHY Program Information Link
VA Program HMIS
Department of Veterans Affairs
Manual
VA Program information link

Program (s)

All Continuum of Care
(CoC) Program
component projects.
All Emergency Solution
Grant (ESG) Program
component projects.
All Housing Opportunities
for Persons with AIDS
(HOPWA) program
components.
All Projects for Assistance
in Transition from
Homelessness (PATH)
component projects.
All Runaway and
Homeless Youth program
component projects.

SSVF, GPD, and HCHV
Veteran homeless
programs.
VASH Program HMIS U.S. Department of Housing and Urban Veterans Affairs
Manual
Development - VASH and Department Supportive Housing
of Veterans Affairs
(VASH) program.
VASH Program link
HMIS Data Standards Terms and Concepts
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 providers,
victim service providers, faith-based organizations, governments, businesses, advocates,
public housing agencies, school districts, social service providers, mental health
agencies, hospitals, universities, affordable housing developers, and law enforcement,
and organizations that serve homeless and formerly homeless persons to the extent
that these groups are represented within the geographic area and are available to
participate.

9/3/2019

4

•

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 the homeless 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
then as a “CoC Program-funded continuum project.”

HMIS User means the individual who uses or enters data in an HMIS or a comparable database
approved by the CoC.
HMIS Lead means the entity designated by the Continuum of Care in accordance with the HMIS
Proposed Rule (24 CFR Part 580) to operate the Continuum's HMIS on the Continuum's behalf.
As of May 2019, the HMIS Rule is not in effect. When HUD publishes the final HMIS Rule communities
will be given time to come into compliance with the rule.

HMIS System Administrator means the individual(s) whose job it is to manage the HMIS
implementation at the local level: enrolling programs and managing appropriate use,
supporting users through connection to, or direct provision of, user training, and overseeing
system setup.
Project 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 project refers to a distinct
unit of an organization as set up in the HMIS.

9/3/2019

5

1. INTRODUCTION TO THE HMIS DATA STANDARDS
Data Element Structure
Every data element required by HUD and the Federal Partners to be stored within an HMIS is
specified in this document. The following format is used to describe each data element:
Rationale: provides a basic rationale for data collection for the element and describes how the
data are used in national or local reporting.
Data Collection Instruction: provides overall instructions for data collection and entry.
Additional 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.
System Logic and Other System Issues: describes logically required data collection or system
structure information for HMIS software development purposes and information on rationale,
conditions, constraints, etc. that may be applicable to a specific element and are important for
HMIS software development purposes.
FY2020 Revision Summary: documents the changes to the element from the 2017 Data
Standard to the FY2020 Data Standard.
Data Element Number and Name:
Table Section Information Contained in the Table
Field Number The numbers assigned to the element fields.
Field Name The names assigned to the element fields.
Dependency Dependent Fields and the Field/ Response category to which they are
dependent.
The dependencies outlined are expected to be visible to users on-screen. The
methods vendors use to make dependencies visible will vary by software
provider/developer.

9/3/2019

6

Table Section Information Contained in the Table
Response
All response options associated with the field, and their data type, if specified.
Category/
Data Type
CLIENT REFUSED AND CLIENT DOESN’T KNOW RESPONSE OPTIONS: Most
elements contain responses of “client doesn’t know” and “client refused.” It
is not the intention of the Federal Partners that clients be denied assistance
if they refuse or are unable to supply the information. However, some
information may be required by projects or public or private funders to
determine eligibility for housing or services, or to assess needed services.
The "Client doesn't know" or "Client refused" responses should not be used
to indicate that the case manager or data entry person does not know the
client's response. Nor are these responses to be assumed without first
asking the client to provide the information. Some clients may decline to
provide responses to some fields but case managers or data entry staff may
not make that decision for them. At a national level, in every project type, a
majority of clients are willing to provide identifying information. If a project
is experiencing a high rate of client refusals as compared to similar projects,
CoCs should consider implementing trainings around interviewing or trustbuilding 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.
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 were 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. It is not a response option necessary in every
system or in every element. The element is required for use by any HMIS
system which requires a response to an element before allowing the user to
move forward in the system. 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
systems which require entry of any 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.
Descriptions General definitions and descriptions of fields and responses. Detailed,
program- specific descriptions can be found in the HMIS Federal Partner
Program Manuals, as applicable.
9/3/2019

7

1. INTRODUCTION TO THE HMIS DATA STANDARDS
Data Element Number and Name:
Table Section Information Contained in the Table
Data
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
Collected
About
(e.g. all household members) but may be further limited in data reporting
specifications.
Funder/
The federal department, the program, and the program component which
Program
requires the collection of the element.
Component
Project Type The HMIS project type(s) required to collect and report the data element, as
Applicability specified in element 2.02 Project Information.
XML
The XML element in XML specifications where the data standard element is
located.
CSV
The primary file in the CSV specifications where the data standard element is
located.
Collection
The point(s) at which the data must be able to be collected in an HMIS. For
Point
data elements with multiple collection points, each record must be stored
with the appropriate Data Collection Stage (as listed in metadata element
5.03). Data elements with only a single collection point need not be stored
with any particular data collection stage, since their data collection point is
inherent in their requirements.
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. Data are collected
and entered into the HMIS, responses must be reviewed for accuracy at
each project start and edited as necessary to make corrections or to
improve data quality.

9/3/2019

8

Table Section Information Contained in the Table
Collection
Project start (stored with Data Collection Stage of “Project Start” for
Point
elements with multiple collection points) – Indicates the element is
(continued)
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.
Occurrence Point/Update (stored with a Data Collection Stage appropriate
to when they were collected) – 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. 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. While data may be edited by users associated with
the project to correct errors or omissions, accurate records should never be
overwritten or discarded when update records are created. Corrections to
existing records will change neither the data collection stage nor the
information date unless it is explicitly altered by the user.
Annual assessment (stored with Data Collection Stage of “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.

9/3/2019

9

1. INTRODUCTION TO THE HMIS DATA STANDARDS
Table Section Information Contained in the Table
Collection
There should be one and only one record for each data element annually
Point
with a Data Collection Stage recorded as ‘annual assessment’ associated
with any given client and Enrollment ID within the 60-day period
(continued)
surrounding the anniversary of the head of household’s Project Start Date.
Regardless of whether the responses have changed since project start or
the previous annual assessment, a new record must be created for each
subsequent annual assessment such that it is possible to view a history, by
date, of the values for each data element. Data may be edited by users
associated with the project to correct errors or omissions; such edits will
change neither the data collection stage nor the information date unless
they are explicitly altered by the user.
Project exit (stored with Data Collection Stage of “Project Exit” for
elements with multiple collection points) – 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 (stored with Data Collection Stage of “Post Exit” for elements
with multiple collection points) – Indicates the element may be collected
after project exit for a period of no longer than six months.
Relationship The cardinality of the element relative to an enrollment (Enrollment ID) and
to Enrollment the client (Personal ID). This will often indicate "One or more" even though
ID
the element is only applicable to certain project types or funders which
Relationship require the data element, and is further limited to clients described in the
to Personal ID "Data Collected About" standard. "One or more” does not inherently imply the
element should be collected on every client in HMIS. In general, elements
recorded at least once per enrollment are required at project start. Elements
recorded 0 or more times per enrollment might only be collected as needed or
at exit, e.g. a referral.
1.2 INTRODUCTION TO PROJECT DESCRIPTOR DATA ELEMENTS
Project descriptor data elements (PDDE) are intended to identify the organization, specific
project, and project details to which an individual client record in an HMIS is associated.
They enable the HMIS to:

9/3/2019

10

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), Annual Homeless Assessment Report
(AHAR), System Performance Measures, Housing Inventory Counts (HIC), Point-inTime (PIT) Counts, and utilization analysis.
This section describes the data to be recorded in HMIS for each project descriptor data element
and its relation to each project entering data. Correct use of the 2.02 Project Information and
2.06 Funding Sources data elements will help assure that projects are identified for correct
visibility and are able to generate reports required for each of the Federal Partners as reporting
parameters will be based off of one or both of these elements.
Project descriptor data are generally entered and managed in an HMIS by the HMIS Lead, not a
project end user. They are created at initial project setup within the HMIS and should be
reviewed at least once annually and as often as needed to ensure that reporting is accurate.
The HMIS Lead, in consultation with the CoC, should develop a plan and timeline for routine
review and updates to PDDEs. If any project descriptor data is entered or updated by project
end users, the HMIS Lead Agency must have oversight and data entry/edit ability along with
strong review procedures to assure timely, accurate and complete data.
At a minimum, HUD requires that the CoC (typically via the HMIS Lead Agency) collect project
descriptor information in the HMIS for:
• All continuum projects within its jurisdiction participating in HMIS by collecting and
entering client-level data.
• All residential continuum projects, regardless of their participation in HMIS.
This is to facilitate AHAR participation.
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.
The following Project Descriptor Data Elements are required for project setup in HMIS:
2.01 Organization Information
2.02 Project Information
2.03 Continuum of Care Information
2.06 Funding Sources
2.07 Bed and Unit Inventory Information
9/3/2019

11

1. INTRODUCTION TO THE HMIS DATA STANDARDS
HMIS Project Setup Guidance
One of the most critical steps in accurate data collection and reporting is ensuring that a project
is set up properly in an HMIS. If project setup is done incorrectly, this will jeopardize the ability
to produce accurate, reliable reports.
Prior to creating a new project in the HMIS, the HMIS Lead should consult with both the
organization administering the project and the CoC Lead Agency regarding appropriate
responses for the PDDEs. Project Type and 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 HIC and PIT guidance issued by HUD each year. Some HMIS applications
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, project type, and funding source combinations.
For additional information on Federal Partner programs and related project setup guidance,
refer to the applicable Federal Partner HMIS Program Manual.
Multiple Funding Sources
CoCs may have projects operating in their communities that receive funding from multiple
Federal Partners for the same project to serve the same clients. There are a few issues the
HMIS Lead will need to consider in these cases.
First, it is important that projects are set up in the system so all data elements needed for all
required reports are “visible” to the end users. For example, a youth shelter may be funded
through HUD's Emergency Solutions Grants Program (ESG) to support essential services and
through HHS's Runaway and Homeless Youth (RHY) Program as a Basic Center Program. In this
example, the project should be set up with a 'Project Type' (from data element 2.02 Project
Information) of "Emergency Shelter" using the "Entry/Exit Date" 'Method for Tracking Shelter
Utilization' (from data element 2.02 Project Information); it will show both "HUD:ESG
Emergency Shelter" (operating and/or essential services) and "HHS:RHY Basic Center Program"
as the 'Funder Program and Component' (from data element 2.06 Funding Sources). 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 and Funding Sources, the HMIS Lead should reference
the HMIS Data Standards to appropriately set the element visibility for the project.
Second, it is important to understand how projects are funded and what reports are required of
each funding source because some projects receive funding from multiple funding sources for
different eligible activities. For example, a project may receive a grant for residential
9/3/2019

12

operations/leasing costs and another grant for services. These two grants may be from the
same federal program or two different federal programs. In these cases, HMIS Leads and
project providers have two options:
1. Create one project in the HMIS that both the housing provider and the service
provider will jointly share and record data in, or
2. Create two separate projects in the HMIS, one for the housing provider and another
for the service provider.
Correct setup under either option is critically important to accurately record HIC/PIT
information and to support correct system wide performance measures.
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. Transitional Housing, Permanent Supportive
Housing, etc.), and the 'Funder Program Component' (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 comport with all data collection requirements associated with that project
type.

•

The services project will have a 'Project Type' of "Services Only." For services only
projects, the 'Project Type' data element includes a question asking if the services
only project is affiliated with a residential project. In this case, the response would
be "Yes," and the residential project would be identified so that data can be linked.

Multiple Project Setup
There may be other circumstances within the HMIS implementation where a project that
appears to be one project must be set up as two separate projects in an HMIS. Some common
examples of this are:
a. If one residential building has both emergency shelter beds and transitional housing
beds, this must be set up as two separate projects, with the 'Project Type' (from data
element 2.02 Project Information) 'Emergency Shelter' and 'Transitional Housing,'
respectively. Clients moving from the shelter bed to the transitional housing bed,
even if in the same building or funded by the same source, will require an exit from
the shelter project and an entry into the transitional housing project. Similarly, a
permanent housing facility may have both a permanent housing for persons with

9/3/2019

13

1. INTRODUCTION TO THE HMIS DATA STANDARDS
disabilities required for entry and other units without a disability requirement. Those
must be set up as separate projects in HMIS.
b. Projects that provide Homelessness Prevention and Rapid Re-Housing, whether
funded by HUD or by the VA (i.e., under the Supportive Services for Veteran Families
(SSVF) program) or another funding source, must be set up as two separate projects
in the HMIS with the two distinct project types, even if they are funded under a
single grant. In this case, the 'Grant Identifier' (from data element 2.06 Funding
Sources) will be the same in both project setups.
c. Permanent Housing projects are often created with a variety of rental subsidies.
Unless the HMIS has the ability to identify the source and specific grant for a rental
subsidy on a client-level basis, separate projects will have to be created in the HMIS
in order to be able to appropriately separate the client records for reporting
purposes. A common example of this is the “pre-HEARTH” McKinney Vento Shelter
Plus Care (S+C) program. Although operated as a unified project, different clients are
served using rental subsidies from multiple S+C grants, each with a different
operating year and grant number. In many systems, in order to accurately report
which and how many clients are served under each separate grant, the grants are set
up and maintained as separate projects in the HMIS unless or until the S+C grants are
consolidated under the CoC Program.
d. PATH projects may provide funding to one organization for both traditional street
outreach services and supportive services such as case management to persons atrisk 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
In general, site-based projects funded by one CoC but located in another CoC have special setup
requirements as described in this section. However, nothing about this instruction is intended
to suggest that occasional client placement in another CoC via tenant-based voucher programs
funded to serve a single CoC, for example, are required to set up projects and track clients at
the Continuum level.
Some projects are funded to provide lodging and/or services to clients in only one continuum
(e.g., CoC: Transitional Housing); others are funded to provide lodging and/or services across a
geographic area that includes more than one continuum (e.g., some VA-funded SSVF projects).
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
9/3/2019

14

providing exports of client-level data to each HMIS, with appropriate agreements in place
between the CoCs involved.
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. In order to do this, federally-funded projects that are funded to operate in
multiple CoCs but are entering data into a single HMIS implementation 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
Client Location’ for data element 3.16 Client Location.
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 continuum. 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
CoC Code relevant to the HMIS implementation need be entered.

9/3/2019

15

1. INTRODUCTION TO THE HMIS DATA STANDARDS
1.3 INTRODUCTION TO UNIVERSAL DATA ELEMENTS
HMIS Universal Data Elements are elements required to be collected by all projects
participating in HMIS, regardless of funding source. Projects funded by any one or more of the
Federal Partners must collect the Universal Data Elements, as do projects that are not funded
by any Federal Partner (e.g. missions) but have agreed to enter data as part of the Continuum
of Care's HMIS implementation.
The Universal Data Elements are the basis for producing unduplicated estimates of the number
of people experiencing homelessness, accessing services from homeless assistance projects,
basic demographic characteristics of people experiencing homeless, and patterns of service use,
including information on shelter stays and homelessness over time.
The Universal Data Elements are the foundation on which the Longitudinal System Analysis
(LSA) is developed. The LSA informs the AHAR, which provides Congress the 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 their specific homeless
information changes over time. Universal Data Elements also help local communities to better
target resources and position programs to end homelessness.
Universal Identifier Elements (One and Only One per Client Record)
3.01 Name
3.02 Social Security Number
3.03 Date of Birth
3.04 Race
3.05 Ethnicity
3.06 Gender
3.07 Veteran Status
Universal Project Stay Elements (One or More Value(s) Per Client or Household 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 Client Location
3.20 Housing Move-In Date
3.917 Prior Living Situation

9/3/2019

16

General Data Collection Guidance
Universal data elements are required to be collected by all projects participating in an HMIS,
regardless of funding source. Data elements 3.01 through 3.07 are required to be collected
once per client, regardless of how many project stays that client has in the system. If, upon
Project Start in a new project, the data in these elements are observed to be incorrect or
outdated, the data must be corrected in the client record. The remaining universal data
elements are to be collected at least once per project stay. The timing of when the data are to
be collected and about whom is noted in each data element.
Uses and Disclosures of Client Data
The Universal Data Elements in particular can lead to questions about what to enter in the
HMIS if a client does not complete a “consent form” for the HMIS. When considering client
consent in the context of HMIS, it is important to make a distinction between HMIS data entry
and HMIS data sharing. At this time, there is no requirement that client consent be obtained
to enter client information into HMIS. There is only a requirement that client consent be
obtained to share information entered into HMIS with one or more other HMIS participating
providers.
This means that it may not be necessary to obtain written consent from every client to simply
enter the data into your HMIS. However, if your HMIS is configured in such a manner that
information entered into HMIS is automatically shared with other HMIS participating projects,
then client consent is necessary. Consult with your Continuum of Care and HMIS Lead Agency
for more information. The privacy and security standards, as described in the 2004 Data and
Technical Standards Notice, seek to protect the confidentiality of personal information while
allowing for reasonable, responsible, and limited uses and disclosures of data.
Additionally, the Coordinated Entry Management and Data Guide offers the most recent
guidance on Privacy in Chapter 2.
1.4 INTRODUCTION TO PROGRAM SPECIFIC DATA ELEMENTS
To meet the statutory and regulatory requirements of federally funded programs using HMIS,
additional elements are required for different funding sources. The Program Specific Data
Elements are elements that are required by at least one of the HMIS Federal Partner programs.
Some of the program specific data elements are collected across most Federal Partner
programs. These are called “Common” Program Specific Data Elements.
The HMIS Federal Partners have cooperatively developed these elements. For each ProgramSpecific Data Element, multiple response categories are provided. Projects may choose to
capture more detailed information (or finer response categories), but only if this information
can be exactly mapped to the required response categories described in this section. For

9/3/2019

17

1. INTRODUCTION TO THE HMIS DATA STANDARDS
reporting purposes, an HMIS must be able to produce required reports using the response
categories exactly as they are presented in this section.
Local CoCs may elect to require all continuum projects participating in HMIS to collect a subset
of the data elements contained in this section to obtain consistent information across a range
of projects that can be used to plan service delivery, monitor the provision of services, and
identify client outcomes. CoCs and projects are encouraged to develop their own data
collection protocols and assessment tools to fully assess client service needs.
Common Program Specific Data Elements
4.02 Income and Sources
4.03 Non-Cash Benefits
4.04 Health Insurance
4.05 Physical Disability
4.06 Developmental Disability
4.07 Chronic Health Condition
4.08 HIV/AIDS
4.09 Mental Health Problem
4.10 Substance Abuse
4.11 Domestic Violence
4.12 Current Living Situation
4.13 Date of Engagement
4.14 Bed-Night Date
4.19 Coordinated Entry Assessment
4.20 Coordinated Entry Event

Many additional elements have been developed by the Federal Partners, but are limited to one
or two Federal Partner programs or a single component of one of the Federal Partner
programs. More detailed guidance about how to use these Federal Partner-specific data
elements can be found in the HMIS Federal Partner Program Manuals.
An HMIS must have the ability to enable and restrict visibility of elements for each project
based on the reporting requirements of the Federal Partner program funding the project. An
HMIS may do this in whatever manner the software provider chooses (hard coding,
customization via system administrators, etc.). HMIS vendors should note that no Federal
Partner expects that any project would have all elements visible to the user. The strong
preference among the Federal Partners is that only the elements required for the programs
that fund a specific project are visible to the users at that project.
Program specific guidance issued through HUD and the individual Federal Partner in the HMIS
Federal Partner Program Manuals provides program setup and visibility information and
definitions relevant for the partner.

9/3/2019

18

Federal Partner Program Data Elements
The Federal Partner Program Data Elements are intended to help HMIS Lead Agencies and their
Federal Partner programs to collect and report according to the HMIS Data Standards.
HOPWA
W1 Services Provided - HOPWA
W2 Financial Assistance - HOPWA
W3 Medical Assistance
W4 T-cell (CD4) and Viral Load
W5 Housing Assessment at Exit
PATH
P1 Services Provided - PATH Funded
P2 Referrals Provided - PATH
P3 PATH Status
P4 Connection with SOAR
RHY
R1 Referral Source
R2 RHY-BCP Status
R3 Sexual Orientation
R4 Last Grade Completed
R5 School Status
R6 Employment Status
R7 General Health Status
R8 Dental Health Status
R9 Mental Health Status
R10 Pregnancy Status
R11 Formerly a Ward of Child Welfare/Foster Care Agency
R12 Formerly a Ward of Juvenile Justice System
R13 Family Critical Issues
R14 RHY Service Connections
R15 Commercial Sexual Exploitation/Trafficking
R16 Labor Exploitation/Trafficking
R17 Project Completion Status
R18 Counseling
R19 Safe and Appropriate Exit
R20 Aftercare Plans
RHSAP
U1 Worst Housing Situation

9/3/2019

19

1. INTRODUCTION TO THE HMIS DATA STANDARDS
VA
V1 Veteran's Information
V2 Services Provided - SSVF
V3 Financial Assistance - SSVF
V4 Percent of AMI (SSVF Eligibility)
V5 Last Permanent Address
V6 VAMC Station Number
V7 SSVF HP Targeting Criteria
V8 HUD-VASH Voucher Tracking
V9 HUD-VASH Exit Information
1.5 INTRODUCTION TO METADATA ELEMENTS
The term metadata is often defined as 'data about data.' Instead of capturing information
about a project or a client, Metadata Elements capture information about the data itself: when
it was collected, when it was entered into HMIS, who entered it, and which project is
responsible for it.
The Metadata Elements are intended to facilitate reporting from HMIS, to simplify the writing
of programming specifications, and to provide an audit trail. These elements do not represent
an attempt to standardize the way that an HMIS stores data. As long as the HMIS is able to
accomplish the purposes identified for the Metadata Elements, the software is not required to
use the exact metadata elements listed here. Programming specifications for reports reference
these Metadata Elements. The Metadata Elements are:
5.01 Date Created
5.02 Date Updated
5.03 Data Collection Stage
5.04 Information Date
5.05 Project Identifier
5.06 Enrollment Identifier
5.07 User Identifier
5.08 Personal Identifier
5.09 Household Identifier

9/3/2019

20

1.6 DATA COLLECTION GUIDANCE BY PROJECT TYPE
Some project types are more complex and require additional data collection instruction.
Although the following information is also provided within each individual data element, it is all
collected here for ease of reference for HMIS Leads, System Administrators and End Users
managing these project types.
Street Outreach
•

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

•

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

•

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

1. INTRODUCTION TO THE HMIS DATA STANDARDS
•

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

•

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

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

•

The client is engaged with another outreach worker or project;

•

The client is deceased;

•

The outreach worker has been unable to locate the client for an extended length
of time (e.g. 90 days from last contact) and there are no contacts recorded in the
Current Living Situation field (4.12). The CoC must be involved in the
determination of “extended length of time” and to which projects the solution is
to be applied.

Coordinated Entry
Coordinated Entry (CE) data elements are expected to be available in HMIS on October 1, 2019.
However, HUD understands that some CoCs and vendors may need a little more time to
transition from their existing coordinated entry process to a new one. To allow for this, HUD is
making April 1, 2020 the CE data elements “go live” date, meaning that CoCs with HUD-funded
SSO-CE projects are required to collect CE data elements beginning April 1, 2020. Regardless of
funding source, all CoCs are strongly encouraged to collect CE data using these standardized
elements.
The specifics of implementation may vary, and CoCs should collaborate with HMIS Leads and
vendors to map the new CE data elements to existing data collection processes whenever
possible. HUD will provide various forums for HMIS system admins, CoCs, and vendors to
engage expert TA providers to help map and incorporate the new CE data elements into HMIS.
These forums will include affinity groups for system admins, regular meetings for system
admins and vendors plus ad hoc meetings as needed, and, if necessary, one-on-one TA
assistance to map the new elements to complex custom CE data collection. CoCs should

9/3/2019

22

collaborate with HMIS Leads and vendors to map the new CE data elements to existing data
collection processes whenever possible.
Until those resources are available, some general guidance is provided below:
•

Coordinated Entry (CE) Project Setup: Since coordinated entry is a process that may be
supported by multiple agencies and typically spans an extended period, CoCs will set up
a CE ‘project’ in HMIS that all relevant agencies can access. HUD acknowledges that the
terminology ‘project’ is problematic, as CE is a collaborative and community-wide
process and not a single ‘project’ in the traditional sense. Rather, CE is a system-level
project—meaning that as households are triaged and identified as experiencing
homelessness, they are enrolled in the CE project with the appropriate start date, and
then data can be collected by different agencies, at different points in time, to populate
their single enrollment record in the project.
A client’s CE project enrollment is expected to overlap with other continuum project
enrollments and to supplement the information collected by other project types.
Agencies that provide CE functions along with other services, e.g. Emergency Shelter,
would have HMIS access to their existing Emergency Shelter project and the CE project
so they can enroll clients in one or the other, or both.
Depending on whether a CoC’s system has a single front-door or multiple front-doors to
CE, the HMIS set-up may include one CE project or multiple CE projects representing
regional areas. Creating a CE ‘project’ is simply what allows for a boundary to be drawn
around the CE segment of the homeless system for reporting purposes.

•

CE Assessments: In addition to the Universal Data Elements, CE systems are expected to
record in the HMIS as many CE Assessments (4.19) as are conducted with each client.
This data element was designed to be used solely by CE projects and to collect, at
minimum, an assessment date, location, and assessment results. It allows CoCs to define
their own assessment questions and responses and to categorize multiple assessments
as either crisis needs assessments or housing needs assessments. This element helps
communities understand and monitor the assessment process in more detail and as it
relates to participant outcomes.

•

CE Events: Basic interactions in CE systems are expected to be captured using the CE
Event data element (4.20). This data element is designed to be used solely by CE
projects and to capture access and referral events, as well as the results of those events.
Specific referral categories are detailed in the data element; CoCs wishing to be more
granular in their referral and matching data collection may do so, as long as their data
can be rolled up to the specified categories for reporting purposes. Systematizing this
data collection will help communities understand the events that go into achieving
desired (and undesired) results through the CE system.

9/3/2019

23

1. INTRODUCTION TO THE HMIS DATA STANDARDS
•

Contacts: CE projects are expected to record every direct contact made with each client
in the HMIS via data element 4.12, Current Living Situation. A contact is defined as an
interaction between a worker and a client designed to engage the client. Contacts
include activities such as a conversation between the street outreach worker and the
client about the client's well-being or needs, an office visit to discuss their housing plan,
or a referral to another community service. A Current Living Situation (4.12) must be
recorded anytime a client is met, including when a CE Assessment (4.19) or CE Event
(4.20) is recorded on the same day.
On occasion, it is expected that a Continuum project that does not participate in HMIS
by collecting and entering client-level data will be a source of information about the
whereabouts of a client. The Current Living Situation data element will be one factor in
reporting to determine whether a CE client is still actively seeking assistance. As a result,
it may be necessary for the CE project to record that element on behalf of a
nonparticipating project. In those cases, the CE project will use the field ‘Living Situation
verified by’ to document the Project Name of the project that reported an updated
status for the client during case conferencing.

•

Data Quality: Reporting on data quality for CE projects is limited to clients with any
completed CE Assessment (4.19). Therefore, it is important that CE staff record the ‘Date
of Assessment,’ ‘Assessment Level,’ and ‘Assessment Result’ and also review all
Universal Data Elements and applicable Program Specific Data Elements for
completeness and accuracy. The Date of Assessment coincides with the requirement for
HMIS data quality, therefore all Universal Data Elements should be entered into HMIS
on or before the completion of the Crisis Needs CE Assessment.

•

Project Exit: Project exit represents the end of a client's participation with the CE
system. The exit date should coincide with the date that the client is no longer
considered to be actively seeking crisis or housing assistance from the CoC. Reasons to
exit a client include:

9/3/2019

•

The client has entered a permanent residential project type (e.g., PSH) or is
otherwise known to have found permanent housing;

•

The client is known to have left the CoC to pursue other assistance or resources;

•

The client is deceased;

•

No staff working in the CE system (via appropriate case conferencing) has been
able to locate the client for an extended length of time (e.g. 90 days from last
contact) and there are no Current Living Situation records. The CoC must be
involved in the determination of “extended length of time” and to which projects
the solution is to be applied.

24

'Night-by-Night' Emergency Shelters
•

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

•

Contacts: In addition to the Universal Data Elements, nbn shelters are expected to
record every contact made with each client in the HMIS via data element 4.12, Current
Living Situation (formerly “Contact”). A contact is defined as an interaction between a
worker and a client designed to engage the client; it does not refer to interactions that
are inherent in providing the shelter bed that is assumed to be part of the client’s bed
night. Contacts may include activities such as a conversation between the shelter
worker and the client about the client's well-being or needs, an office visit to discuss
their housing plan, or a referral to another community service. A Current Living Situation
(4.12) must be recorded anytime a client is met, including when a Date of Engagement
(4.13) or Project Start Date (3.10) is recorded on the same day.

•

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

•

Project Exit: Project exit represents the end of a client’s participation with a project. The
exit date should coincide with the date that the client is no longer considered to be
participating in the project. This standard should be applied consistently across all nbn
projects. The exit date should be set as the day after the client’s last bed night in the
project. Reasons to exit the client include:

9/3/2019

•

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

•

The client is deceased;

•

The client has not accessed the shelter for an extended length of time (e.g., 90
days from last contact). The CoC must be involved in the determination of
“extended length of time” and to which projects the solution is to be applied.

25

1. INTRODUCTION TO THE HMIS DATA STANDARDS
‘Entry/Exit’ Emergency Shelter and Transitional Housing
•

Entry/Exit (e/e) shelters and transitional housing should be set up to collect all data
required by the funding source.

•

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

•

During the project enrollment, record any assessments or other updated information as
required by the funding source and/or the FY 2020 Data Standards.

•

At project exit, record any other information required at project exit, including 3.12
Destination and 3.10 Project Exit Date.

Day Shelter
•

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

Permanent Housing: PSH and RRH
•

All types of Permanent Housing projects are able to collect data on assistance provided
to the client prior to the client entering housing.

•

For these project types, the Project Start Date (3.10) is the date that the client was
admitted into the project. To be admitted indicates the following factors have been
met:
• Information provided by the client or from the referral indicates they
meet the criteria for admission;
• The client has indicated they want to be housed in this project; and
• The client is able to access services and housing through the project.
• The expectation is the project has a housing opening (on-site, site-based,
or scattered-site subsidy) or expects to have one in a reasonably short
amount of time.

•

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

•

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

•

If the client loses their housing situation and the project stops paying rental
assistance, but the client remains enrolled in the project, staff should exit the client
from the project with an accurate Project Exit Date and Destination and create a new

9/3/2019

26

Project Start Date in a second enrollment for the client on the same or following day.
The project would continue working with the client until a new unit is found, at which
point a new housing move-in date would be recorded on the second project record. This
will ensure that the client’s history of housing is preserved. If the client moves directly
from one unit into another unit, with no days of homelessness in between, it is not
necessary to exit and re-enter them, because their housing move-in date would still
accurately reflect the day they entered permanent housing according to that enrollment
record.
•

In the event a client is transferred into a PSH or RRH 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 necessary or 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.

2. PROJECT DESCRIPTOR DATA ELEMENTS
2.01 Organization Information
Rationale: To uniquely identify organizations operating one or more projects that enter data
into HMIS, as well as any residential continuum projects not participating in HMIS.
Project Setup Instruction: Organization Information is assigned once for each organization.
Record the organization's legal name. The 'Organization Name' must be reviewed annually to
ensure accuracy. There must be only one organizational identifier and name for each
organization that has projects which operate in the HMIS implementation.
Many organizations operate multiple projects that participate in HMIS. Projects that are
operated by the same organization must all be associated with the same 'Organization ID.' Each
project in the HMIS must be associated with one and only one organization. If the project
moves from one organization to another (e.g. grant transfers to a new organization), an update
of the information to associate the project to the new organization must be made by the
system administrator in the HMIS.
An organization's legal name is not always the name by which it is commonly known in the
community. Some HMIS implementations include an additional field to track more familiar
“common names” for organizations, but this is not required.
System Logic and Other System Issues: An 'Organization ID' must be assigned to each project
via a system generated number or code. Each organization must receive a distinct identifier
that is consistently associated with that organization. Each organization must also be able to be
associated with one or more projects. The name of the organization must be captured in text
within the HMIS.

9/3/2019

27

2. PROJECT DESCRIPTOR DATA ELEMENTS
An HMIS must allow the HMIS Lead to activate and deactivate an organization. An HMIS
application may permit the creation of a common name field more familiar to users for use
within the application while retaining the legal name for use in reporting.
FY2020 Revision Summary: Renumber element (from 2.1 to 2.01), rename element from
Organization Identifier to Organization Information, add 'Victim Service Provider' field and
responses from 2.8 Additional Project Information.

9/3/2019

28

2.01 Data Element Fields and Responses:
Response
Field Number Field Name Dependency Category/
Data Type
1
Organization None
System
ID
generated
number or
code. There is
no specified
format for this
data element.
2
Organization None
[Text]
Name
3
Victim
None
0 No
Service
1 Yes
Provider

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

The organization's legal name.

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

2.01 Specifications:
Data Collected Funder/Program Project Type
XML
CSV
About
Component
Applicability
All
All Funders, All All HMIS
Organization
Organizations Program
Project Types
Components

Collection
Point
Record
creation,
update
annually

2.02 Project Information
Rationale: To uniquely identify each project entering data into the 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 also 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 or a noncontinuum project, the relationship of a 'Services Only' project to a housing project as
necessary, and the method for tracking emergency shelter utilization, if applicable.
9/3/2019

29

2. PROJECT DESCRIPTOR DATA ELEMENTS
Project Setup Instruction: The 'Project ID' must be automatically generated by the HMIS at the
time the project is created in the HMIS. Each project must receive a distinct identifier that is
consistently associated with that project.
In separate fields, record the project's name, operating start date, operating end date (if
applicable), whether the project is a continuum project, the project type, residential affiliation,
and ES tracking method. This information must be reviewed annually to ensure accuracy.
'Project Name' must be consistent with HUD and other federal reporting requirements and
should match grant agreements or other documentation. Often the project will have a common
name that is used by the community for the specific project but may also have different names
on formal grant agreements and perhaps even a different name in the HMIS. HMIS software
solutions may elect to create another field for the entry of additional names of the project for
ease of access purposes, but it is not required.
Residential projects that operate in multiple CoCs that cross HMIS systems must be
documented in each CoC's HMIS, even in cases where all client data are entered into a single
CoC's HMIS and the data provided to other CoC’s HMIS via data transfer. For more information
about setting up projects that operate in multiple CoCs, please refer to Section 1.2 Introduction
to Project Descriptor Data Elements.
Project identification can be difficult for HMIS Lead Agencies. A project in HMIS is often referred
to as a “program” by agency providers. When an organization designs a project to assist
persons in their community, they are generally not considering the data collection and
reporting requirements associated with it. Until funding is received for that project, they may
not even know the reporting requirements. Therefore, HMIS project set-up begins with the
determination by the System Administrator or HMIS Lead Agency, in cooperation with the
project's leadership, of whether a new project will be set up as a single or multiple projects in
the HMIS. For more guidance on project setup, please refer to Section 1.2 Introduction to
Project Descriptor Data Elements.
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. In the
event that the nature of a project changes such that the recorded project type is no longer
appropriate, very careful consideration must be given to whether it is more appropriate to edit
the project type for the existing project or to create an entirely new project with a different
type.
Record whether the project contributes client data to the HMIS in the 'HMIS Participating
Project' field. If a combination of non-HMIS participating clients and HMIS participating clients
are present in the project, the project must have two Project Information records in set up in
9/3/2019

30

HMIS, one with 'HMIS Participating Project' marked "Yes" and one with 'HMIS Participating
Project' marked "No." 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 method used to track the nights that a client stays at a project in 'Emergency Shelter
Tracking Method.' One method must be identified in an HMIS for each emergency shelter
project. Reporting and outcome requirements will differ depending on the method utilized by
the shelter.
•

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

•

The night-by-night (nbn) method requires the client have a full record created,
followed by a record of each night the client was sheltered. For example, a client's
Project Start Date is January 1. A full record is created reflecting the client's
information on that date. The client stays that night and then is not back until 5 days
later. On the night they return, assuming the client has not been exited from the
shelter, a simple record of the 'Bed Night Date' may be made for the client, using
4.14 Bed Night Date. This collection of scattered nights becomes the client's length of
stay in the shelter and the example above would give them a length of stay of 2
nights.

•

To the extent possible in a mass shelter environment, clients in a nbn shelter should
also have all elements required at exit for the project completed. The community
should establish a standard to “automatically exit” a client after a given length of
absence (e.g. 90 days from last bed night). The client's Project Exit Date would be
recorded as the last date the client appeared at the shelter and the Destination would
be marked as 'No exit interview completed.' The use of an automatic exit system
enables streamlined data collection for mass shelters, while at the same time
encouraging full exit information wherever possible.

The method used is important for the indication of length of stay in projects. Only projects
utilizing a project start/exit date comparison will be able to report on a continuous length of
stay.
If a shelter/continuum determines the method of tracking needs to be changed, the following
approach must be taken in order to minimize impact on the System Performance Measures and
other reports:
1. A new shelter project must be established in the HMIS using the new method of
tracking.
2. All clients in the closing HMIS shelter project must be exited.

9/3/2019

31

2. PROJECT DESCRIPTOR DATA ELEMENTS
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 prohibits discrimination because of,
among other things, familial status. Except where otherwise permitted by the federal program
statute, housing covered under the Fair Housing Act may not deny admission to households
with children.
System Logic and Other System Issues: 'Project ID' must be assigned to each project via a
system generated number or code. Each project must receive an identifier that is unique within
the HMIS and consistently associated with that project. Each project must be associated with an
organization (data element 2.01); separate projects operated by the same agency must be
associated with the same 'Organization ID.' The name of the project must be captured in text
within the HMIS. An HMIS application may permit the creation of a common name element
more familiar to users for use within the application while retaining the legal name for use in
reporting.
The system must allow edits if the data changes or corrections for data entry error. A project
can only have one project type assigned. A project must be able to identify multiple affiliated
residential projects if “yes” to Dependent A.
The system should ensure that an 'Emergency Shelter Tracking Method' is identified in an HMIS
for each Emergency Shelter project. The system must also have the capacity to accommodate
both types of tracking and change reporting and outcomes depending on the method utilized
by the shelter. Utilization of the night-by-night method does not mean that an HMIS must
identify a client in a specific bed. If the HMIS supports a custom module that identifies clients in
a bed, that module may continue to be used. However, use of that module does not necessarily
equate with the night-by-night model.
FY2020 Revision Summary: Renumber element (from 2.2 to 2.02), rename element from
Project Identifiers to Project Information, add all fields from 2.4 Project Type element
(Continuum Project, Project Type, Residential Affiliation), add HMIS Participating Bed from 2.7
Bed Inventory element and rename to HMIS Participating Project, add all fields from 2.5
Method for Tracking Emergency Shelter Utilization (Method), added "Target Population", and
“Housing Type” and renamed Project Type 14 from Coordinated Assessment to Coordinated
Entry. Corrected Dependent C field reference.

9/3/2019

32

2.02 Data Element Fields and Responses:
Response
Field Number Field Name Dependency
Category/
Data Type
1
Project ID None
System
generated
number or code.
There is no
specified format
for this data
element.
2
Project
None
[Text]
Name

3

Operating
Start Date

None

[Date]

4

Operating
End Date

None

[Date]

9/3/2019

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

The project's name. Where applicable,
project names must be consistent with
HUD and other federal reporting
requirements and should match grant
agreements or other documentation.
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.

33

2. PROJECT DESCRIPTOR DATA ELEMENTS
Field Number Field Name Dependency
5

6

9/3/2019

Continuum None
Project

Project Type None

Response
Category/
Data Type
0 No
1 Yes

Descriptions

A project within the geographic
boundaries of the Continuum(s) of
Care served by the HMIS whose
primary purpose is to meet the specific
needs of people who are homeless by
providing lodging and/or services. A
continuum project is not limited to
those projects funded by HUD and
should include all of the Federal
Partner projects and all other federally
or non-federally funded projects
functioning within the continuum.
12 Homelessness A project that offers services and/or
Prevention financial assistance necessary to
prevent a person from moving into an
emergency shelter or place not meant
for human habitation.
4 Street
A project that offers services necessary
Outreach
to reach out to unsheltered homeless
people, connect them with emergency
shelter, housing, or critical services,
and provide urgent, non-facility-based
care to unsheltered homeless people
who are unwilling or unable to access
emergency shelter, housing, or an
appropriate health facility. Only
persons who are "street homeless”
should be entered into a street
outreach project. Projects that also
serve persons other than “street
homeless” must have two separate
projects to be set up in HMIS, one
'Street Outreach' and the other
'Services Only.'

34

Field Number Field Name Dependency

Response
Category/
Data Type
1 Emergency
Shelter

Descriptions

A project that offers temporary shelter
(lodging) for the homeless in general
or for specific populations of the
homeless. Requirements and
limitations may vary by program, and
will be specified by the funder.
2 Transitional A project that provides temporary
Housing
lodging and is designed to facilitate the
movement of homeless individuals and
families into permanent housing within
a specified period of time, but no
longer than 24 months. Requirements
and limitations may vary by program,
and will be specified by the funder.
11 Day Shelter A project that offers daytime facilities
and services (no lodging) for persons
who are homeless.
8 Safe Haven A project that offers supportive
housing that (1) serves hard to reach
homeless persons with severe mental
illness who came from the streets and
have been unwilling or unable to
participate in supportive services; (2)
provides 24-hour residence for eligible
persons for an unspecified period; (3)
has an overnight capacity limited to 25
or fewer persons; and (4) provides low
demand services and referrals for the
residents.
13 PH - Rapid Re- A permanent housing project that
Housing
provides housing relocation and
stabilization services and short- and/or
medium-term rental assistance as
necessary to help a homeless
individual or family move as quickly as
possible into permanent housing and
achieve stability in that housing.

9/3/2019

35

2. PROJECT DESCRIPTOR DATA ELEMENTS
Field Number Field Name Dependency

Response
Category/
Data Type
3 PH Permanent
Supportive
Housing
(disability
required for
entry)
10 PH - Housing
with Services
(no disability
required for
entry)

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

A project that offers permanent
housing and supportive services to
assist homeless persons to live
independently, but does not limit
eligibility to individuations with
disabilities or families in which one
adult or child has a disability.
9 PH - Housing A project that offers permanent
Only
housing for persons who are homeless,
but does not make supportive services
available as part of the project.
14 Coordinated A project* that administers the
Entry
continuum's centralized or
coordinated process to coordinate
assessment and referral of individuals
and families seeking housing or
services, including use of a
comprehensive and standardized
assessment tool.
*This is not a “project” in the traditional sense
as it may more accurately reflects a system or
process, but project is used because that is how
data is typically collected in HMIS.

9/3/2019

36

Field Number Field Name Dependency

9/3/2019

Response
Category/
Descriptions
Data Type
6 Services Only A project that offers only stand-alone
supportive services (other than
outreach or coordinated entry) to
address the special needs of
participants (such as child care,
employment assistance, and
transportation services) and has
associated housing outcomes.
If the Services Only project is affiliated
with any one of the following:
• One residential project AND
• Does not offer to
provide services for all
the residential project
clients; OR
• Only serves clients for a
portion of their project
stay (e.g.: provides
classes; OR
• Information sharing is
not allowed between
residential project and
service provider.
• Multiple residential projects of
the same project type (e.g.
multiple PH:PSH) AND
• Does not serve all the
residential project
clients; OR
• Information sharing is
not allowed between
residential projects and
service provider.
• Multiple residential projects of
different project types (e.g.
PH:RRH and PH:PSH)
• Emergency Shelter(s)
Then the project type will be 'Services
Only' and 'Affiliated with a Residential
Project' will be 'Yes.' Each of the
residential projects with which the
Services Only project is associated
must be identified.
37

2. PROJECT DESCRIPTOR DATA ELEMENTS
Field Number Field Name Dependency

Response
Category/
Data Type

7 Other

9/3/2019

Descriptions
If the Services Only project provides
only services (other than outreach or
coordinated entry), has associated
housing outcomes, and is not limited
to serving clients of one or more
specific residential projects, then the
project type will be 'Services Only' and
'Affiliated with a Residential project'
will be 'No.'
A residential project that is funded
under one or more separate grants to
provide supportive services to 100% of
the clients of the residential project
will be set up as a single project with
the appropriate residential project
type. All federal funding sources must
be identified in 2.06 Funding Sources.
A project that offers services, but does
not provide lodging, and cannot
otherwise be categorized as another
project type, per above. Any project
that provides only stand-alone
supportive services (other than
outreach or coordinated entry) and
has no associated housing outcomes
should be typed as 'Other.' For
example, a project funded to provide
child care for persons in permanent
housing or a dental care project
funded to serve homeless clients
should be typed 'Other.' A project
funded to provide ongoing case
management with associated housing
outcomes should be typed 'Services
Only.'

38

Response
Category/
Data Type
Field 6,
0 No
Response 6 1 Yes

Field Number Field Name Dependency
A

B

C

9/3/2019

Affiliated
with a
residential
project

Project ID(s) Field A,
[List of HMIS
of
Response 1 Residential
residential
Project IDs]
project(s)
affiliated
with SSO
Emergency Field 6
0 Entry/Exit
Shelter
Response 1 Date (e/e)
Tracking
Method

Descriptions

For all projects typed 'Services Only,'
identify if the services that are being
provided are in conjunction with a
residential project which is a separate
project in the HMIS (e.g. a service only
project for case management that
services one or more PSH projects).
Residential Project Types are: 1, 2, 3, 8,
9, 10 13

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

39

2. PROJECT DESCRIPTOR DATA ELEMENTS
Field Number Field Name Dependency

9/3/2019

Response
Category/
Data Type
3 Night-byNight (nbn)

Descriptions
The night-by-night method may be
used by some high-volume shelters
and shelters where a significant
proportion of clients spend a night at
the shelter as needed on an irregular
basis. The night-by-night method relies
on creating a separate record of each
individual date on which a client is
present in the shelter as a means for
calculating length of stay and implies
that the emergency shelter is generally
unable to collect as much client data at
project exit as an emergency shelter
that uses an entry/exit method for
tracking utilization. In this method: (1)
entry information is collected the first
time that a client stays at the shelter
(2) the project records every discrete
date (or series of dates) that the client
utilizes a bed; (3) the HMIS maintains
historical data on the nights a client is
sheltered; (4) the client may be exited
when shelter staff has information that
indicates that the client is unlikely to
return to the shelter or the system
may be designed to automatically
generate an exit (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.

40

Response
Category/
Data Type
Field 6,
1 Site-based Responses
single site
1, 2, 3, 8, 9, 2 Site-based 10, 13
clustered/
multiple sites

Field Number Field Name Dependency
D

Housing
Type

3

7

HMIS
None
Participating
Project

0

1

8

Target
None
Population

1

3

4

9/3/2019

Descriptions

All clients are housed in a single
project facility.
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 Clients have leases or other occupancy
- scattered
agreements and are housed in
site
residences that are not owned or
managed by the project.
No
"No" 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 in the
Continuum's HMIS.
Yes
"Yes" indicates that all 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 in the
Continuum's HMIS.
DV: Domestic At least 75% of persons served by the
Violence
project must be victims of domestic
victims
violence.
HIV: Persons At least 75% of persons served by the
with HIV/AIDS project must be persons with
HIV/AIDS.
NA: Not
Neither of the other response
applicable
categories applies.

41

2. PROJECT DESCRIPTOR DATA ELEMENTS
2.02 Specifications:
Data Collected Funder/Program
About
Component

All Projects

All Funders, All
Program
Components

Project Type
Applicability

XML

CSV

All HMIS Project

Collection
Point

Record
creation,
update
annually

2.03 Continuum of Care Information
Rationale: To associate each project entering data into the HMIS, as well as any residential
continuum projects not participating in HMIS, with one or more Continuum of Care (CoC) for
reporting and data exchange purposes. For more information about setting up projects that
operate in multiple CoCs, please refer to Section 1.2 Introduction to Project Descriptor Data
Elements.
Project Setup Instruction: 'Continuum Codes' (or CoC Codes) are published annually by HUD in
the CoC Program NOFA and are associated with specific geographic areas. Each project must be
associated with the 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 continuum
(e.g., CoC: Transitional Housing); others are funded to provide lodging and/or services across a
geographic area that includes more than one continuum (e.g., some VA-funded SSVF projects).
For federally-funded projects operating in multiple CoCs but entering data into a single HMIS
implementation, the 'Continuum Code' selected for the project must be consistent with the
area served by the project according to their grant agreement with the federal funder. For
example, a VA SSVF project providing services to clients in both a balance of state and an urban
CoC must be associated with the 'Continuum Code' for both the balance of state AND the urban
continuum.
Information must be reviewed and updated at least annually. Data entry errors should be
edited to correct the error.
'Geocode,' 'Project ZIP code,' and 'Project Street Address' fields must reflect the location of the
project's principal lodging site or, for multiple site projects, the area in which most of the
project's clients are housed. Tenant-based scattered site projects and Victim Services Providers
are only required to complete the geocode and ZIP code fields and may use mailing or
administrative address information if they wish to complete the remainder of the address
fields. When there are multiple records 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.
9/3/2019

42

System Logic and Other System Issues: There is a many-to-one relationship between this data
element and 2.02 Project Information; there may be multiple current records of this data
element at any given time. Add, edit, or remove associations with CoCs as needed to reflect
changes. There must be a one-to-one relationship to Project Information if the project only
serves one CoC (most common).
Projects may be funded to provide for housing and/or services to clients residing in only one
CoC (e.g., CoC: Transitional Housing), or they may be funded for housing and/or services across
multiple CoCs (e.g.: VA: SSVF). The system must allow for multiple codes to be selected per
project. It must be possible to associate a project with the CoC code for every geographic area
in which the project operates and for which is will be entering data into the HMIS.
The system should set a default for the CoC Code, which should be the CoC Code for the
continuum operating the HMIS. The CoC Codes in this data element are expected to be used to
populate an option list of CoC Codes for data element 3.16 Client Location when one is
required.
It must be possible to leave address fields blank. HUD will release a regularly updated crosswalk
of ZIP codes and the associated geography type for each. 'Geography type' must correspond to
the HUD crosswalk; geography types may not be locally defined.
FY2020 Revision Summary: Renumber element (from 2.3 to 2.03), rename element from
Continuum of Care Code to Continuum of Care Information, add fields from 2.8 Additional
Project Information ('Geocode,' 'Project Zip Code,' 'Geography Type,' 'Project Street Address,'
'Project City,' and 'Project State').
2.03 Data Element Fields and Responses:
Field Number Field Name Dependency
1

9/3/2019

Continuum None
Code

Response Category/
Descriptions
Data Type
[Text][6 HUDCoC Codes as published by
characters: assigned CoC HUD annually. The format of
XX-XXX] codes for the these CoC codes is 2 letters
project
(state abbreviation), a dash,
location
and 3 numbers, e.g., XX- 999.
The HMIS software may
provide a drop- down list of
valid CoC Codes or require
manual entry.

43

2. PROJECT DESCRIPTOR DATA ELEMENTS

2

Geocode

None

Response Category/
Data Type
[6 digits]

3

Project
Street
Address 1

None

[Text]

4

Project
Street
Address 2
Project City
Project
State
Project ZIP
Code

None

[Text]

None
None

[Text]
[2 letters]

None

[5 digits]

Field Number Field Name Dependency

5
6
7

8

Geography None
Type

Descriptions
Geocode associated with the
geographic location of the
project's principal site. HUD
provides a list of geocodes as
part of the annual CoC
Program competition.
The street address of the
project's principal site or, for
scattered site projects, the
address in which most of the
project's clients are housed.
For tenant-based scattered
site projects, the field may be
left blank or the administrative
address may be used.

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

1

Urban

2
3

Suburban
Rural

2.03 Specifications:
Data Collected Funder/Program Project Type
XML
CSV
About
Component
Applicability
All Continuum All Funders, All All HMIS
ProjectCoC
Projects
Program
Project Types
Components

9/3/2019

Collection
Point
Record
creation,
update

44

2.06 Funding Sources
Rationale: To identify funding sources for each project entering data into the HMIS, as well as
any residential continuum projects not participating in HMIS, and associate projects with
corresponding data collection requirements and reporting specifications.
Project Setup Instruction: The funding sources listed in Field 1 are the Federal Partner
programs and their project components that have agreed either to participate in HMIS or are
otherwise considered continuum projects. There are also response options for 'Other funding
source' and 'NA.'
All continuum projects that receive funding from any of the funding sources identified in this
element must record: the name of the federal program and grant component; a grant
identifier; grant start date; and grant end date. Each project must include as many Funding
Source records as is necessary to identify all the funding sources for the project that appear on
the list. Identification of additional funding sources is not required.
When a project is funded by multiple grants and 100% of clients served by the project receive
lodging and/or services under each of the grants, a single project may be set up in HMIS as long
as it is configured such that data collection and reporting requirements for each funder are
satisfied.
When a project is funded by multiple grants and different clients receive lodging and/or
services under different grants, it must be possible to identify which clients were served by
which grant (or grants) and any grant-level reporting must exclude clients not specifically
served under the grant. In general, this is accomplished in one of two ways:
• There are separate projects set up in HMIS for each of the grants, and clients are
entered into those projects based on the source of funding for particular services
received; OR
• The HMIS has implemented additional data collection such that a client's enrollment
and/or specific services may be associated with the appropriate grant.
The 'Grant identifier' must uniquely identify the grant, although several projects may share the
same grant identifier if they are, in fact, funded under the same grant but split into separate
projects in HMIS. This may happen, for example, when a grant has multiple sub-grantees and
needs to be able to identify which clients were served by each of the subgrantees, or when a
single grant funds services that fall under different project types.
Correctly identifying each grant's 'Start Date' and 'End Date' allows for inclusion or exclusion of
certain projects in grant- or system-level reporting. For example, this information is critical in
the generation of income measures for the system performance measures.

9/3/2019

45

2. PROJECT DESCRIPTOR DATA ELEMENTS
The 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 found on the HUD Exchange.
System Logic and Other System Issues: This is a transactional data element, a single project
may have multiple current and historical records. Allow corrections for data entry errors. An
HMIS must allow projects with multiple Funder sources and multiple grants (with potentially
different grant terms) from the same funding source to record and store all funding sources for
the project.
FY2020 Revision Summary: Renumber element (from 2.6 to 2.06), rename element (from
Federal Partner Funding Sources to Funding Sources), add "VA:Grant Per Diem - Case
Management/Housing Retention" and "HUD:CoC - Joint Component TH/RRH" funding sources,
remove "VA:Compensated Work Therapy Transitional Residence" and add "Local or other
Funding Sources" and a dependent text box to record the name of the local or other funding.
2.06 Data Element Fields and Responses:
Response
Field Number Field Name Dependency Category/
Descriptions
Data Type
1
Funder
None
1
HUD: CoC - Homelessness Prevention
Program and
(High Performing Communities Only)
Components
2
HUD: CoC - Permanent Supportive
Housing
3
HUD: CoC - Rapid Re-Housing
4
HUD :CoC - Supportive Services Only
5
HUD: CoC - Transitional Housing
6
HUD: CoC - Safe Haven
7
HUD: CoC - Single Room Occupancy (SRO)
43
HUD: CoC - Youth Homeless
Demonstration Program (YHDP)
44
HUD: CoC - Joint Component TH/RRH
8
HUD: ESG - Emergency Shelter (operating
and/or essential services)
9
HUD: ESG - Homelessness Prevention
10
HUD: ESG - Rapid Re-housing
11
HUD: ESG - Street Outreach
9/3/2019

46

Response
Field Number Field Name Dependency Category/
Descriptions
Data Type
35
HUD: Pay for Success
36
HUD: Public and Indian Housing (PIH)
Programs
12
HUD: Rural Housing Stability Assistance
Program
13
HUD: HOPWA - Hotel/Motel Vouchers
14
HUD: HOPWA - Housing Information
15
HUD: HOPWA - Permanent Housing
Placement (facility based or TBRA)
16
HUD: HOPWA - Permanent Housing
Placement
17
HUD: HOPWA - Short-Term Rent,
Mortgage, Utility assistance
18
HUD: HOPWA - Short-Term Supportive
Facility
19
HUD: HOPWA - Transitional Housing
(facility based or TBRA)
20
HUD: HUD/VASH
21
HHS: PATH - Street Outreach &
Supportive Services Only
22
HHS: RHY - Basic Center Program
(prevention and shelter)
23
HHS: RHY - Maternity Group Home for
Pregnant and Parenting Youth
24
HHS: RHY - Transitional Living Program
25
HHS: RHY - Street Outreach Project
26
HHS: RHY - Demonstration Project
27
VA: CRS Contract Residential Services
37
VA: Grant Per Diem - Bridge Housing
45
VA: Grant Per Diem - Case
Management/Housing Retention
40
VA: Grant Per Diem - Clinical Treatment
39
VA: Grant Per Diem - Hospital to Housing
38
VA: Grant Per Diem - Low Demand
41
VA: Grant Per Diem - Service Intensive
Transitional Housing
42
VA: Grant Per Diem - Transition in Place
9/3/2019

47

2. PROJECT DESCRIPTOR DATA ELEMENTS
Response
Field Number Field Name Dependency Category/
Descriptions
Data Type
30
VA: Community Contract Safe Haven
Program
33
VA: Supportive Services for Veteran
Families
46
Local or Other Funding Source (Please
Specify)
34
N/A
A
If local or
Field 1
[Text]
other, please Response 46
specify
2
Grant
None
No
The 'Grant Identifier' may be the grant
Identifier
Specified number assigned by the Federal Partner
Format
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.
3
Grant Start None
[Date]
The start date of the grant
Date
4
Grant End
None
[Date]
The grant end date may remain empty
Date
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.06 Specifications:
Data Collected Funder/Program Project Type
XML
About
Component
Applicability
All Projects
All Funders, All All HMIS

Program
Project Types
Components

9/3/2019

CSV
Funder

Collection
Point
Record
Creation,
Occurrence,
Update

48

2.07 Bed and Unit Inventory Information
Rationale: To record bed and unit inventory information for each residential project entering
data into the HMIS, as well as any residential continuum projects not participating in HMIS, for
use in tracking utilization, data quality analysis, and reporting.
Project Setup Instruction: At a minimum, an HMIS must have an accurate record of bed and
unit inventory information for all continuum residential projects. These data must be finalized
and accurately entered by the time of the Housing Inventory Count date. The 'Inventory Start
Date' for these records should reflect the date on which they first became available under the
relevant project; if the precise date is not available, an estimate may be used.
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.' 'Bed Type' also should be logically consistent with
'Housing Type' at the project level, so if, for example, an Emergency Shelter has both
facility-based beds (Housing Type = Site based) and hotel/motel vouchers (Housing
Type = Tenant based) then two HMIS projects would be set up for that Emergency
Shelter.
• Projects that operate in more than one CoC must have separate Bed and Unit
Inventory Information records for each Continuum of Care Information record.
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.
A project may have multiple historical records of inventory. Changes over time should be
documented such that a historical record of inventory is retained. Minor day-to-day
fluctuations need not be recorded, but differences due to significant changes in project
operations should be entered as they occur.
• When a project adds inventory 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.

9/3/2019

49

2. PROJECT DESCRIPTOR DATA ELEMENTS
•

•

•

When a project reduces inventory but will continue to serve the same household
type with a smaller number of beds, a new record should be added. The 'Inventory
Start Date' should reflect the date the new 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 beds dedicated for chronically homeless, Veteran, or
youth clients should be documented by closing out the old record with an 'Inventory
End Date' that is the date before the effective date of the change. A new record
should be created with an 'Inventory Start Date' that is the effective date of the
change. 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.

System Logic and Other System Issues: A project may have multiple current and historical
records of inventory. For any inventory record, it must be possible to identify the CoC with
which the inventory is associated. For projects that operate in a single continuum, there is a
many-to-one relationship between this data element and 2.02 Project Information, although at
any given time, only one record for this data element will be current. For projects that operate
in multiple CoCs, there is a similar many-to-one relationship with 2.03 Continuum of Care
Information.
If the HMIS produces CoC-level reporting on 2.07 Bed and Unit Inventory Information for more
than one continuum (e.g., Longitudinal Systems Analysis or Housing Inventory Counts), records
of inventory must be separate and associated with the appropriate Continuum of Care
Information record.
Data entry errors should be corrected; a new record should be created to document a change
in information. A new record is only required if a change has occurred. Not all fields are
required for all projects.
FY2020 Revision Summary: Renamed (from Bed and Unit Inventory to Bed and Unit Inventory
Information), renumbered from 2.7 to 2.07, removed ‘Information Date,’ and revised dedicated
bed inventory for special populations.

9/3/2019

50

2.07 Data Element Fields and Responses:
Response
Field Number Field Name Dependency Category/ Data
Descriptions
Type
1
Inventory
None
[Date]
The date on which the inventory
Start Date
became available, or, for inventory
under development, the date on
which it is expected to become
available.
2
Inventory
None
[Date]
The last date that an inventory
End Date
record is relevant:
• For current records,
'Inventory End Date' should
be blank.
• For records that are being
closed out because a change
that requires a new record
has occurred, 'Inventory End
Date' will be the day before
the effective date of the
change.
• For inventory that is no
longer available, 'Inventory
End Date will be the last date
that beds were available.
3
CoC Code
None
[as identified in Projects that operate in more than
data
one CoC must have separate Bed and
element 2.03 Unit Inventory records for inventory
Continuum of located in each CoC. From the CoC
Care Code]
codes entered in data element 2.03,
indicate the CoC code associated
with the inventory record.
4
Household None
This specifies the household type (at project entry)
Type
served by beds and units in a given inventory record.
Projects that serve more than one household type
must have separate records of inventory for each
household type.
1 Households Beds and units typically serving
without
households with adults only. This
children
includes households composed of
unaccompanied adults and multiple
adults.
9/3/2019

51

2. PROJECT DESCRIPTOR DATA ELEMENTS
Response
Field Number Field Name Dependency Category/ Data
Descriptions
Type
3 Households Beds and units typically serving
with at least households with at least one adult
one adult and and one child.
one child
4 Households Beds and units typically serving
with only
households composed exclusively of
children
persons under age 18, including onechild households, multi-child
households or other household
configurations composed only of
children.
5
Emergency 2.02 Project 1 Facility Based Beds (including cots or mats) located
Shelter Bed Type =
Beds
in a residential homeless assistance
Types
'Emergency
facility dedicated for use by persons
Shelter'
who are homeless.
2 Voucher Beds Beds located in a hotel or motel and
made available by the homeless
assistance project through vouchers
or other forms of payment.
3 Other Beds Beds located in a church or other
facility not dedicated for use by
persons who are homeless.
6
Emergency 2.02 Project Availability is recorded to identify whether the beds
Shelter Bed Type =
and units are available on a planned basis year-round,
Availability 'Emergency seasonally, or on an ad hoc or temporary basis, as
Shelter'
demand indicates.
1 Year Round Year-round beds and units are
available on a year-round basis.
2 Seasonal
Seasonal beds are not available yearround, but instead are available on a
planned basis, with set start and end
dates, during an anticipated period of
higher demand.
3 Overflow
Overflow beds are available on an ad
hoc or temporary basis during the
year in response to demand that
exceeds planned (year-round or
seasonal) bed capacity.

9/3/2019

52

Response
Field Number Field Name Dependency Category/ Data
Descriptions
Type
7-12
Dedicated All beds that have been funded by HUD or another Federal Partner
Bed
that are dedicated to one or more of the following subpopulations
Inventory
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 in fields 7-13 are expected to be mutually
exclusive and should sum to the total beds provided in field 14. A
dedicated bed is a bed that must be filled by a person in the
subpopulation category (or a member of their household) unless
there are no persons from the subpopulation who qualify for the
project located within the geographic area. DedicatedPLUS beds do
not qualify as Dedicated beds and should not be included in the
Dedicated Bed Inventory unless the project has a subset of the
DedicatedPLUS beds that are dedicated per the definitions below.
7
Beds
The number of beds that are
None
[Integer]
dedicated to
dedicated to house chronically
chronically
homeless veterans and their
homeless
household members.
(CH)
Veterans
None
[Integer]
8
Beds
The number of beds that are
dedicated to
dedicated to house homeless youth
youth
(persons up to age 24) veterans and
Veterans
their household members.
9
Beds
None
[Integer]
The number of beds that are
dedicated to
dedicated to house non-CH and nonany other
youth veterans and their household
Veterans
members.
10
Beds
None
[Integer]
The number of beds that are
dedicated to
dedicated to house chronically
chronically
homeless youth (persons up to age
homeless
24) and their household members.
youth
11
Beds
None
[Integer]
The number of beds that are
dedicated
dedicated to house non-CH and nonany other
veteran homeless youth (persons up
youth
to age 24) and their household
members.

9/3/2019

53

2. PROJECT DESCRIPTOR DATA ELEMENTS
Response
Field Number Field Name Dependency Category/ Data
Descriptions
Type
None
[Integer]
12
Beds
Beds dedicated to non-youth, nondedicated to
Veteran chronically homeless. The
any other
number of beds that are dedicated to
chronically
house chronically homeless persons
homeless
and their household members.
None
[Integer]
13
NonAll other (non-dedicated) beds not
dedicated
already accounted for in fields 7-12.
beds
The number of non-dedicated to CH,
youth or veteran beds used to house
homeless persons and their
household members.
14
Total Bed
None
The sum total The 'Bed Inventory' is a count of the
Inventory
of the
total number of beds available for
[integers] from occupancy as of the ‘Inventory Start
fields 7 through Date.' The number of beds is
13 [Integer]
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:

9/3/2019

54

Response
Field Number Field Name Dependency Category/ Data
Type

Descriptions
Divide the beds based on how
the bed(s) were used on the
night of the HIC. If the facility
is not at full capacity on the
night of the count, then
extrapolate the distribution
based on the prorated
distribution of those who are
served on the night of the
count.
• Divide the beds based on
average utilization. For
example, a project has 100
beds that could be used by
either households with only
children or households with
at least one adult and one
child. If one-half of the beds
are used by persons in
households with only children
on average and the other half
are used by persons in
households with at least one
adult and one child, then
record 50 beds for
households with only
children, and for the 50 beds
for households with at least
one adult and one child in the
HIC.
Projects that only have units and no
fixed number of beds can estimate
the number of beds based on
average household size using a
multiplier factor (e.g., a project with
30 family units and an average family
size of 3 would record 90 beds).
•

9/3/2019

55

2. PROJECT DESCRIPTOR DATA ELEMENTS
Response
Field Number Field Name Dependency Category/ Data
Type

15

9/3/2019

Total Unit
Inventory

None

[Integer]

Descriptions
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 Shelterhotel/motel project, Rapid ReHousing, some scattered site PHPermanent 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.
The 'Unit Inventory' is a count of the
total number of units available for
occupancy as of the ‘Inventory Start
Date.' Projects that do not have a
fixed number of units (e.g., a
congregate shelter project) may
record the bed inventory, the
number of residential facilities
operated by the project, or the
number of rooms available as the
unit integer. For
additional instructions, see 'Bed
Inventory,' above.

56

2.07 Specifications:
Data
Funder/Prog
Collected
ram
About
Component
All Residential All Funders,
projects
All Program
Components

Project Type
Applicability
•
•
•
•
•
•
•

9/3/2019

XML

CSV

Collection
Point

Emergency Shelter
Transitional
Housing
PH - Permanent
Supportive Housing
Safe Haven
PH - Housing Only
PH - Housing with
Services
PH - Rapid ReHousing

Record
Creation,
Occurrence,
Update

57

3. UNIVERSAL DATA ELEMENTS

3. UNIVERSAL DATA ELEMENTS
Universal Identifier Elements (One and Only One per Client Record)
3.01 Name
Rationale: To support the unique identification of each person served.
Data Collection Instruction: When creating a new client record, enter the client's name and
select the appropriate data quality indicator. When enrolling a client who already has a record
in the HMIS, verify that the name in the system is accurate and as complete as possible and
correct or complete it if it is not.
HMIS records should use a client's full, legal name whenever possible. Doing this as a standard
practice makes it easier to find records when searching and avoid creating duplicate records.
Generally, projects are not required to verify that the information provided matches legal
documents. However, each project should be aware of funders' record keeping requirements,
and if maintaining copies of legal documents is a requirement, they should be collected and
pertinent information updated in HMIS accordingly.
Street Outreach 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 entry date, a “made-up” name (e.g., “Redhat Tenthstreetbridge”) 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 that detail.
System Logic and Other System Issues: Associated project users must be able to edit data to
correct errors or reflect changes in client responses. Systems may elect to utilize an extra
field(s) for alias or "preferred names" or for notes on name changes.
FY2020 Revision Summary: Renumbered from 3.1 to 3.01.
3.01 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/ Data
Name
Type

1

First

None

[Text]

2

Middle None

[Text]

9/3/2019

Descriptions

To avoid duplicate record creation, the full
first name should be used (e.g., James instead
of Jim)

58

Response
Field
Field Number
Dependency Category/ Data
Name
Type

3

Last

4
5

Suffix None
Name None
Data
Quality

9/3/2019

None

[Text]

Descriptions

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

[Text]
1 Full name
reported

Select 'Full name reported' for Name Data
Quality as long as complete, full first and last
names have been recorded.
2 Partial,
Select 'Partial, street name, or code name
street
reported' in any of the following
name, or
circumstances: 1) a partial, short, or nickname
code name was used instead of the full first name; 2) a
reported
street name or code name was used for street
outreach clients at initial intake and until the
client was able to supply their full legal name;
3) a name modification was used for security
reasons; or 4) for any other reason the name
does not match the clients full name as it
would appear on identification.
8 Client
Select 'Client doesn't know' when client does
doesn't
not know their name. Use 'Client doesn't
know
know' rather than 'Partial, street name or
code name reported' if a false name/made up
name was entered in order to create a record
in the system solely because the client did not
know or was unable to provide their name.
9 Client
Select 'Client refused' when client refuses to
refused
provide their name. Use 'Client refused' rather
than 'Partial, street name, or code name
reported' if a false name/made up name was
entered in order to create a record in the
system solely because the client refused to
tell staff their name.
99 Data not
collected

59

3. UNIVERSAL DATA ELEMENTS
3.01 Specifications:
Data
Funder/Program Project Type
Collected
Component Applicability
About

All
All Funders, All All HMIS
Clients Program
Project
Components Types

Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point Enrollment
ID
ID
<...> Client Record
N/A
One Name
creation
record per
client

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

60

System Logic and Other System Issues: System stores collected nine-digit SSN in one field and
the appropriate SSN data quality in another. Associated project users must be able to edit data
to correct errors or reflect changes in client responses.
The HMIS may include hyphens or other punctuation within the SSN to improve readability, but
the SSN must be exportable as a single alphanumeric field containing a maximum of nine
characters and no punctuation.
HMIS solutions may designate special non-numeric characters (e.g., the letter x) to indicate
missing digits and otherwise devise methodologies to allow entry and effective matching of
partial SSNs. Because missing digits may appear in any one of the nine placeholders, it is critical
for the system to have a mechanism to indicate which digits were missing when entering partial
SSNs, an alphabetic character must be interpreted as a placeholder.
The HMIS may elect to add an additional field, in a manner defined by the system, for clients
who do not have an SSN to facilitate merging duplicated records.
FY2020 Revision Summary: Renumbered from 3.2 to 3.02.
3.02 Data Element Fields and Responses:
Response Category/
Field Number Field Name Dependency
Data Type
1
Social
None
[9 digits]
Security
Number
2
SSN Data None
1 Full SSN Reported
Quality
2 Approximate or
partial SSN
reported
8 Client doesn't
know
9 Client refused

Descriptions

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 a SSN.
A client refuses to provide any
part of their SSN, regardless of the
reason.

99 Data not collected

9/3/2019

61

3. UNIVERSAL DATA ELEMENTS
3.02 Specifications:
Data
Funder/Program Project Type
Collected
Component Applicability
About

All
All Funders, All All HMIS
Clients Program
Project
Components Types

XML
<...>

Relationship
Relationship
Collection
to
CSV
to Personal
Point Enrollment
ID
ID
Client Record N/A
One Social
creation
Security
Number per
client

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: Record the month, day, and year of birth for every person served.
When enrolling a client who already has a record in the HMIS, verify that the date of birth on
the record is accurate and correct it if it is not.
If the client cannot remember their birth year, it may be estimated by asking the person's age
and calculating the approximate year of birth. If a client cannot remember the month or day of
birth, record an approximate date of '01' for month and '01' for day. CoCs that already have a
policy of entering another approximate date may continue to use their existing policy. Select
‘approximate or partial date of birth.’
If a client is not able to estimate their age within one year of their actual age, select 'Client
doesn't know.' If the client is able to provide their birth year, but refuses to provide their birth
day and month, record an approximate date as indicated above and indicate that the response
is ‘Approximate or partial.’ Select ‘Client refused’ when a client refuses to provide their birth
year. ‘Client doesn't know,’ ‘Client refused,’ and ‘Data not collected’ are explanations for
missing DOB data. None of these three responses are valid in conjunction with a valid or
approximated date entered in ‘Date of Birth.’
System Logic and Other System Issues: System stores collected DOB in one field and the
appropriate DOB data quality type in another. Associated project users must be able to edit
data to correct errors or reflect changes in client responses. One date format field for birth
dates should be created in the HMIS database. Date of birth must be exportable in the [date
field] format.
FY2020 Revision Summary: Renumbered from 3.3 to 3.03

9/3/2019

62

3.03 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/ Data
Name
Type
1
Date of None
[Date]
Birth
2
DOB
None
1 Full DOB
Data
reported
Quality
2 Approximate or
partial DOB
reported
8 Client doesn't
know

9 Client refused

Descriptions

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.
Use 'Client refused' rather than
'Approximate or partial DOB reported'
if the client refused to provide their
date of birth or their age for staff to
approximate.

99 Data not
collected
3.03 Specifications:
Project
Data
Funder/Program
Collected
Type
Component
About
Applicability
All
All Funders, All All HMIS
Clients Program
Project
Components Types

XML

CSV

<...> Client

Relationship
Relationship
Collection
to
to Personal
Point Enrollment
ID
ID
Record N/A
One Date of
creation
Birth per
client

3.04 Race
Rationale: To indicate clients' self-identification of one or more of five different racial
categories. Supports system planning, and local and national understanding of who is
experiencing homelessness. In the October 30, 1997 issue of the Federal Register (62 FR
58782), the Office of Management and Budget (OMB) published “Standards for Maintaining,
Collecting, and Presenting Federal Data on Race and Ethnicity.” All existing federal
recordkeeping and report requirements must be in compliance with these Standards as of
January 1, 2003. These data standards follow the OMB guidelines.

9/3/2019

63

3. UNIVERSAL DATA ELEMENTS
Data Collection Instruction: In separate data fields, record the self-identified race(s) of each
client served. Help the client select the race or races that they most identify with. Allow clients
to identify as many racial categories as apply (up to five).
When enrolling a client who already has a record in the HMIS, verify that race information is
complete and accurate and correct it if it is not.
Staff observations should never be used to collect information on race. Provide all options to
every client. Even if staff believes they can guess a client's race, every client must be asked for
their self-reported information. No documentation is required to verify a client's response.
‘Client doesn't know,’ ‘Client refused,’ and ‘Data not collected’ are explanations for missing race
data. None of these three responses are valid in conjunction with any other response.
This data element can be challenging to separate from ethnicity. As one example, some people
of Latin American descent often indicate their race is ‘Hispanic,’ and would not be referred to in
casual conversation or seen in their communities or by themselves as ‘White’ or ‘Black or
African American.’ Unless the person is from an original people's group that is indigenous or
American Indian, in which case they would select that option, the staff will have to ask followup questions to ascertain the best response for Race. Staff may ask something like "do you
know if your ancestors were originally from a country like Spain, somewhere in Africa, or are
you part of an indigenous group?” The response is tied to where their ancestors came from, not
necessarily where they were born or lived during their lifetime.
By the time clients get to data element 3.05 Ethnicity, they may have already responded to Race
with something like 'Hispanic,' 'Guatemalan,' or 'Latino,' so staff should be able to clearly
distinguish between these two data elements and select responses accordingly, even if the
answers are provided out of order.
Projects are cautioned against providing a default answer. It is important to ask about all
household members' race and identity because it is impossible to tell just based on a person's
appearance or name. If the client does not know their race or ethnicity, or refuses to disclose it,
use ‘Client doesn't know’ or ‘Client refused,’ rather than making an appearance or name-based
assumption.
System Logic and Other System Issues: Associated project users must be able to edit data to
correct errors or reflect changes in client responses.
The HMIS must accommodate the recording of up to five race response categories per client,
except ‘Client doesn't know,’ ‘Client refused,’ and ‘Data not collected.’ These are not races;
they are explanations for missing race data. None of these three responses are valid in
conjunction with any other response.
FY2020 Revision Summary: Renumbered from 3.4 to 3.04.
9/3/2019

64

3.04 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/ Data
Descriptions
Name
Type
1
Race None
1 American
A person having origins in any of the original
Indian or
peoples of North and South America,
Alaska Native including Central America, and who maintains
tribal affiliation or community attachment.
2 Asian
A person having origins in any of the original
peoples of the Far East, Southeast Asia or the
Indian subcontinent including, for example,
Cambodia, China, India, Japan, Korea,
Malaysia, Pakistan, the Philippine Islands,
Thailand and Vietnam.
3 Black or
A person having origins in any of the black
African
racial groups of Africa. Terms such as 'Haitian'
American
can be used in addition to 'Black or African
American.'
4 Native
A person having origins in any of the original
Hawaiian or peoples of Hawaii, Guam, Samoa, or other
Other Pacific Pacific Islands.
Islander
5 White
A person having origins in any of the original
peoples of Europe, the Middle East or North
Africa.
8 Client doesn't ‘Client doesn't know’ should only be selected
know
when a client does not know their race(s)
from among the five listed races. ‘Client
doesn't know’ should not be used in
conjunction with any other response.
9 Client refused ‘Client refused’ should only be selected when
a client refuses to identify their race(s) from
among the five listed races. ‘Client refused’
should not be used in conjunction with any
other response.
99 Data not
collected

9/3/2019

65

3. UNIVERSAL DATA ELEMENTS
3.04 Specifications:
Data
Collected
About

All
Clients

Funder/
Project Type
Program
Applicability
Component

All Funders,
All Program
Components

All HMIS
Project
Types

Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point Enrollment
ID
ID
Client Record
N/A
One Race
creation
record per
Client

3.05 Ethnicity
Rationale: To indicate clients who do and do not identify themselves as Hispanic or Latino.
Supports system planning, and local and national understanding of who is experiencing
homelessness.
Data Collection Instruction: Record the self-identified ethnicity of each client served. Help the
client select the ethnicity that they most identify with.
When enrolling a client who already has a record in the HMIS, verify that ethnicity information
is complete and accurate and correct it if it is not.
Staff observations should never be used to collect information on Ethnicity. Even if a staff
person believes they can guess a client's ethnicity, every client must be asked for their selfreported information. No documentation is required to verify a client's response.
Additional instruction about assisting clients to differentiate between Race and Ethnicity can be
found under data element 3.04 Race.
System Logic and Other System Issues: Associated project users must be able to edit data to
correct errors or reflect changes in client responses.
FY2020 Revision Summary: Renumbered from 3.5 to 3.05.
3.05 Data Element Fields and Responses:
Response Category/
Field
Field Number
Dependency
Descriptions
Name
Data Type
1
Ethnicity None
1 NonHispanic/NonLatino
2 Hispanic/Latino A person of Cuban, Mexican, Puerto
Rican, South or Central American or
other Spanish culture of origin,
regardless of race.

9/3/2019

66

Field Number

Response Category/
Field
Dependency
Name
Data Type

Descriptions

8 Client doesn't
know
9 Client refused
99 Data not collected
3.05 Specifications:
Relationship Relationship
Collection
XML
CSV
to Enrollment to Personal
Point
ID
ID
All HMIS

creation
record per
Client

Data
Funder/
Project Type
Collected Program
Applicability
About Component

All Clients All
Funders,
All
Program
Componen
ts
3.06 Gender

Rationale: To indicate whether clients self-identify as male, female, transgender female,
transgender male, or gender non-conforming. Supports system planning, and local and national
understanding of who is experiencing homelessness.
Data Collection Instruction: Record the self-reported gender of each client served. Users
should be sensitive to persons who do not identify as male or female.
When enrolling a client who already has a record in the HMIS, verify that gender information is
complete and accurate -- and correct it if it is not. Update the gender previously recorded in
HMIS if it does not match the person's current gender.
Staff observations should never be used to collect information on gender. Provide all options to
every client. Even if staff thinks they can guess a client's gender, every client must be asked for
their self-reported information. If they refuse to give it or say they don't know, do not select a
response for the client. Gender does not have to match legal documents and clients may not be
asked about medical history or other information to try to determine the person's gender.
Simply asking, “Which of these genders best describes how you identify?” is appropriate and
focuses on the person's own internal knowledge of their gender.
Clients reporting different gender identities or presenting different gender expressions at
multiple projects within the same CoC are not violating standards for accurate collection of
information. Clients decide to which projects they will disclose potentially sensitive
information. Project staff should enter the self-reported information as directed by the client.
9/3/2019

67

3. UNIVERSAL DATA ELEMENTS
If a client does not understand what Transgender Female and Transgender Male mean, the
definitions below can be provided. The availability of these options is not intended to indicate
that transgender individuals are expected to disclose their status; they are merely provided as
additional options in case they are better suited a client’s preferred terminology, needs, or
situation.
A transgender client may elect to share their transgender status with project staff, or not. In the
event that a client discloses being transgender, staff should consult that client about whether
the client prefers to have the HMIS record reflect their transgender status or not. For instance,
if a client identifies as a transgender man but would prefer not to have this reflected in his
HMIS record, or he would simply prefer to identify as male, then the staff person would select
‘male’ instead of ‘transgender female to male.’ Staff can still note in a confidential case
management file an individual's transgender status if it is appropriate and necessary to the
provision of services.
System Logic and Other System Issues: Associated project users must be able to edit data to
correct errors or reflect changes in client responses.
FY2020 Revision Summary: Renumbered from 3.6 to 3.06.
3.06 Data Element Fields and Responses:
Response Category/
Field
Field Number
Dependency
Descriptions
Name
Data Type
1
Gender None
0 Female
Clients who live or identify as
women
1 Male
Clients who live or identify as men
2 Trans Female (MTF or Clients who live or identify as
Male to Female)
women, even though they were
assigned male at birth.
3 Trans Male (FTM or Clients who live or identify as men,
Female to Male)
even though they were assigned
female at birth.
4 Gender NonClients who identify as non-binary
Conforming (i.e. not or who otherwise do not identify
exclusively male or exclusively as male or female or
female)
trans female or trans male.
8 Client doesn't know
9 Client refused
99 Data not collected

9/3/2019

68

3.06 Specifications:
Project
Data
Funder/Program
Collected
Type
Component
About
Applicability
All
All Funders, All All HMIS
Clients Program
Project
Components Types

XML

CSV

<...> Client

Relationship
Relationship
Collection
to
to Personal
Point Enrollment
ID
ID
Record N/A
One Gender
creation
record per
Client

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

9/3/2019

69

3. UNIVERSAL DATA ELEMENTS
automatically create a response for clients who turn 18 while enrolled; the auto-generated
response should be ‘No.’
FY2020 Revision Summary: Renumbered from 3.7 to 3.07.
3.07 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/
Descriptions
Name
Data Type
1
Veteran None
0 No
Veteran Status should be ‘No’ for anyone
Status
who has not been on active duty. 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.
1 Yes
Anyone who has ever been on active duty in
the armed forces of the United States,
regardless of discharge status or length of
service.
Army, Navy, Air Force, Marine Corps, and
Coast Guard: active duty begins when a
military member reports to a duty station
after completion of training.
Reserves and National Guard: active duty
is any time spent activated or deployed,
either in the United States or abroad.
Or
Anyone who was disabled in the line of duty
during a period of active duty training.
Or
Anyone who was disabled from an injury
incurred in the line of duty or from acute
myocardial infarction, a cardiac arrest, or a
cerebrovascular accident during a period of
inactive duty training.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected

9/3/2019

70

3.07 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
All Funders, All All HMIS
Client Record
N/A
One Veteran
Program
Project Types

Data
Funder/Program Project Type
Collected
Component
Applicability
About

All
Clients

Universal Project Stay Elements (One or More Value(s) Per Client or Household Project Stay)
3.08

Disabling Condition

Rationale: To indicate whether or not clients have a disabling condition. This data element is to
be used with other information to identify whether a client meets the criteria for chronic
homelessness.
Data Collection Instruction: Record whether the client has a disabling condition at the time of
each project start. A disabling condition is one or more of the following:
•

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

•

A developmental disability, as defined in section 102 of the Developmental
Disabilities Assistance and Bill of Rights Act of 2000 (42 U.S.C. 15002); or

•

The disease of acquired immunodeficiency syndrome (AIDS) or any condition arising
from the etiologic agency for acquired immunodeficiency syndrome (HIV).

Additionally, if the client is a veteran who is disabled by an injury or illness that was incurred or
aggravated during active military service and whose disability meets the disability definition
defined in Section 223 of the social security act, they should be identified as having a disabling
condition.
It is not necessary to provide documentation to complete this data element. If the client reports
that they have a disabling condition, enter ‘Yes.’ Only projects that receive funding with

9/3/2019

71

3. UNIVERSAL DATA ELEMENTS
eligibility criteria that require documentation of the disabling condition should require
documentation for enrollment, consistent with those funding requirements.
There should be one and only one value for Disabling Condition for each project stay. If the status
changes over the course of the project stay, or the information was recorded incorrectly at the
time of the project start, correct the record. The value should always reflect the known status
of a client's disabling condition. 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).
Sharing information about a client's disabling condition between agencies should be handled
consistent with the continuum's policies and procedures.
In addition, a client indicating the following sources of Income (data element 4.02) can be
considered to have a disabling condition: Supplemental Security Income (SSI), Social Security
Disability Insurance (SSDI), VA Service-Connected Disability Compensation or VA Non-ServiceConnected Disability Pension.
For residential homeless assistance programs, client intake as part of the program admission
process must be separated from the collection of disability information in order to comply with
Fair Housing laws and practices, unless this information is required to determine program
eligibility or is needed to determine whether applicants need units with special features or if
they have special needs related to communication.
System Logic and Other System Issues: Disabling Condition may either be entered by the user
independently of any other special need field (4.05 - 4.10), or data in this field may be autopopulated based on the responses to ‘ability to live independently’ for 4.05, 4.07, 4.09 or 4.10
or an answer of ‘Yes’ to 4.06 or 4.08.
If the system auto-populates Disabling Condition, a user must be able to override a systemgenerated ‘No’ with ‘Yes.’ Further, if Disabling Condition is auto-populated with ‘Yes’ based
solely on a qualifying record for data elements 4.05 - 4.10 (i.e., the user-entered response to
Disabling Condition was something other than ‘Yes’ but was changed to ‘Yes’ by the system due
to an answer in the special needs fields (4.05-4.10)) and the special needs record is later
deleted or edited such that it doesn’t meet the criteria for Disabling Condition, the autopopulated ‘Yes’ response must revert to the user’s original response.
Regardless of the response to this data element, if a client has a Physical Disability, Chronic
Health Condition, Mental Health Problem, and/or Substance Abuse issue (data elements 4.05,
4.07, 4.09, 4.10) that meets the criteria for a disabling condition (Dependent Field A = ‘Yes’), OR
4.06 Developmental Disability or 4.08 HIV/AIDS = ‘Yes,’ reporting should always count the client
as having a Disabling Condition.

9/3/2019

72

FY2020 Revision Summary: Renumbered from 3.8 to 3.08. Clarification in System Logic for
auto-calculating Disabling Condition based on 4.06 Developmental Disability and 4.08 HIV/AIDS.
3.08 Data Element Fields and Responses:
Response
Field
Field
Dependency Category/
Descriptions
Number Name
Data Type
1
Disabling None
0 No
Condition
1 Yes
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.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
9/3/2019

73

3. UNIVERSAL DATA ELEMENTS
3.08 Specifications:
Data
Funder/Program Project Type
Collected
Component
Applicability
About

XML

All
All Funders, All All HMIS

3.10

Relationship Relationship
Collection
to Enrollment to Personal
Point
ID
ID
Enroll Project
No more than One or more
ment Start (and One Disabling Disabling
edit as
Condition per Condition per
necessary Enrollment
Client
to reflect
new
informatio
n)
CSV

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. Paired
with 3.20 Housing Move-In Date, it becomes possible to determine the length of time from
project start to housing placement for all PH clients, including those in RRH projects.
Data Collection Instruction: Record the month, day, and year of each client's project start. The
project start date indicates a client is now being assisted by the project.
For each client's enrollment in a project, there must only be one Project Start Date. Any errors
in entering the date should be corrected as soon as they are noticed.
Different project types use Project Start Date differently, to address the difference in meaning
associated with “starting” residential, service, and permanent housing projects. See
descriptions below for more information.
Each individual client in a household will have their own project start date. If a new client is
added to a household after the original household members' start dates, the new client's start
date should reflect the actual day that client started the project. If this client is a newborn baby,
the project start date would reflect the date the 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.
System Logic and Other System Issues: The Project Start Date must be exportable in the [date
field] format.
FY2020 Revision Summary: None.

9/3/2019

74

3.10 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/
Descriptions
Name
Data Type
1
Project None
[Date]
Street Outreach: Date of first contact with the
Start
client.
Date
Emergency Shelter: Night the client first stayed
in the shelter. Night by night shelters will have a
project start date and will allow clients to 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 ReHousing: 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;
3) The client is able to access services and
housing through the project. The
expectation is the project has a housing
opening (on-site, site-based, or scatteredsite subsidy) or expects to have one in a
reasonably short amount of time.
Other Service Projects (including but not limited
to: Services Only, Day Shelter, Homelessness
Prevention, Coordinated Entry): Date the client
first began working with the project and
generally received the first provision of service.

9/3/2019

75

3. UNIVERSAL DATA ELEMENTS
3.10 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
All
All Funders, All All HMIS
< ent
Start
than One
Project Start
Components
EntryDat
Project Start Date per
e>
Date per
Client
Enrollment
Data
Funder/Program Project Type
Collected
Component
Applicability
About

3.11

Project Exit Date

Rationale: To determine the end of a client's period of participation with a project. All projects
need this data element for reporting time spent participating in the project.
Data Collection Instruction: Record the month, day and year of last day of occupancy or
service. For each client's enrollment in a project, there should only be one Project Exit Date. Any
errors in entering the date should be corrected as soon as they are noticed.
Different project types use Project Exit Date differently, to address the difference in meaning
associated with “ending” residential and service projects.
Each individual client in a household will have their own Project Exit Date. If one member of a
household leaves the project before the rest of the household, the leaver's exit date should
reflect the actual day that client left the project.
For residential projects, this date represents the last day of a continuous stay in the project
before the client transfers to another residential project or otherwise stops participating in the
project. For example, if a person checked into an overnight shelter on January 30, 2019, stayed
overnight and left in the morning, the exit date for that shelter stay would be January 31, 2019.
To minimize staff and client burden at shelters that require most (or all) clients to reapply for
service on a nightly basis, the project can record the Project Start and Project Exit Date at the
same time or an HMIS application can automatically record the Project Exit Date as the day
after the Project Start Date for clients of the overnight project.
Clients in rapid re-housing projects are to be exited after the last RRH service is provided. If
eligible RRH case management services are provided past the final date of receiving rental
assistance, for example, the client must not be exited until those services cease.
For non-residential projects, the exit date must represent the last day a contact was made or a
service was provided. The exit date should coincide with the date the client is no longer
considered a participant in the project. Projects must have a clear and consistently applied
9/3/2019

76

procedure for determining when a client who is receiving supportive services is no longer
considered to be participating in the project. For example, if a person has been receiving weekly
counseling as part of an ongoing treatment project and either formally terminates their
involvement or fails to return for counseling, the last date of service is the date of the last
counseling session.
In a street outreach services project, similarly, clients may be exited when the outreach worker
has been unable to locate the client for an extended length of time and there are no recorded
contacts. The CoC must be involved in the determination of “extended length of time” and to
which projects the solution is to be applied.
In addition, the client may be exited upon entering another project type, finding housing,
engaging with another outreach project, or passing away. In those cases, the client would be
exited as of the date of the last contact recorded in 4.12 Current Living Situation.
If a client uses a service for just one day (i.e., starts and stops before midnight of same day),
then the Project Exit Date may be the same as the Project Start Date.
In the 2017 HMIS Data Standards, a new data collection stage was added: “Post Exit.” This data
collection stage is relevant for project types that provide aftercare/follow-up services but does
not extend the length of the client's enrollment in a project. Services provided “post exit” will
fall after the client's Project Exit Date. In residential projects that require use of this data
collection stage, the client is still to be exited as of the date described above, appropriate to the
project type.
System Logic and Other System Issues: The Project Exit Date must be exportable in the [date
field] format.
FY2020 Revision Summary: None.

9/3/2019

77

3. UNIVERSAL DATA ELEMENTS
3.11 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/ Data
Descriptions
Name
Type
1
Project None
[Date]
Site-based Residential projects: The last
Exit
day of continuous stay in the project
Date
before the client transfers to another
residential project or otherwise stops
residing in the project.
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.11 Specifications:
Relationship
Relationship
Collection
to
XML CSV
to Personal
Point
Enrollment
ID
ID
All HMIS

Exit
Project Exit Project Exit
Date per
Date per
Enrollment Client

Data
Funder/Program Project Type
Collected
Component
Applicability
About

All
Clients

3.12

All Funders, All
Program
Components
Destination

Rationale: To identify where a client will stay just after exiting a project for purposes of tracking
and outcome measurement.
Data Collection Instruction: Record where the client is expected to stay after they complete or
stop participating in project activities.
For residential projects that expect a client to move out upon exit (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

9/3/2019

78

expected to relocate upon exit (Homelessness Prevention, Rapid Re-housing, transition in place,
or SSO projects), record where the client is expected to stay after they complete or stop
participation in project activities. This may be the same place that they were staying during
their project enrollment or prior to starting in the project.
Select the Destination response category that most closely matches where the client will be
staying after exiting the project.
If a client moves into rental housing with a subsidy to help them maintain the housing, select
the response that includes the type of housing subsidy. A housing subsidy may be tenant-,
project-, or sponsor-based and provides ongoing assistance to reduce rent burden. This
includes housing subsidies provided through HUD-funded subsidies (e.g., public housing,
Housing Choice Voucher or “Section 8”) or other housing subsidy (e.g., state rental assistance
voucher).
If a client moves in with family or friends, select the response that includes the expected tenure
of the destination (permanent or temporary). There is no specific timeframe used to
differentiate between 'permanent' or 'temporary.' Rather, the determination should be made
based on whether the situation reflects family reunification or whether the family member or
friend has placed any limitation that indicates the stay is intended to be temporary (e.g. a
specific time limit).
'Other' should be used only as a last resort if the client's destination truly cannot be even
loosely described by any of the available options. Any response of 'Other' will not count in any
HMIS-based reporting as a positive outcome. If a client is moving into a situation that cannot be
accounted for by the guidance provided, please submit an HMIS Ask-A-Question on the HUD
Exchange with the specific circumstances. HUD and other federal partners can assist in
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 that are exiting to school, to 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 Army-supplied housing, 'Rental by Client, with other ongoing
housing subsidy' can be selected, consistent with the notion that these units are not owned by
client, have conditions of tenancy, and have a value ascribed to them. If the client is moving
into housing with a relative during schooling, 'Living with Family, Permanent Tenure' can be
selected, consistent with the notion that the client may stay with the family member for as long
as needed to complete school.
Mass shelters that track bed nights using the night by night method may have high rates of
missing Destination data when the client is exited. Often, in this model, a client is exited after a
period of time of not coming into the shelter, at which point the opportunity to ask clients
9/3/2019

79

3. UNIVERSAL DATA ELEMENTS
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.
If data collection 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.
Prior Living Situation data should not be used as the source for Destination, Destination should
not be pre-filled at project start, and unconfirmed, word of mouth-type information should not
be used as a source for Destination responses in HMIS.
System Logic and Other System Issues: Display using the same screen order as indicated in the
Living Situation Option list below.
FY2020 Revision Summary: Assigned to the same Living Situation list as Prior Living Situation
and Current Living Situation. Responses updated.
3.12 Data Element Fields and Responses:
Field Number

Field Name

1

Destination

A

If Other for "Living
Situation" Please
Specify

Response Category/
Descriptions
Data Type
None
See Appendix A for complete list of
Living Situation Responses and
Destinations
Field 1 Response 17 Text
Dependency

3.12 Specifications:
Project
Data
Funder/Program
Collected
Type
Component
About
Applicability
All
Clients

3.15

All Funders, All All HMIS
Program
Project
Components Types

XML

CSV

<...> Exit

Relationship
Relationship
Collection
to
to Personal
Point Enrollment
ID
ID
Project Zero or One Zero or
Exit
Destination more
per
Destination
Enrollment per Client

Relationship to Head of Household

9/3/2019

80

Rationale: To identify one person to whom all other household members can be linked to at
the time they enter a project. This facilitates the identification and enumeration of households.
In addition, specifying the relationship of household members to the head of household
facilitates reporting on household composition.
Data Collection Instruction: Identify one member of a household to whom all other household
members can be associated. A household is a single individual or a group of persons who apply
together to a continuum project for assistance and who live together in one dwelling unit, or,
for persons who are not housed, who would live together in one dwelling unit if they were
housed.
There 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) and the other
members' relationship to head of household should be corrected to reflect each individual's
relationship to the newly designated head of household (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 the HMIS over
the course of a project stay; the head of household is simply swapped out for the duration of
the household’s enrollment.
In a household of a single individual, that person must be identified as the head of household.
In multi-person households, the term “Head of Household” is not intended to mean the
"leader" of the house. When a group of persons present together as a household or family unit,
no matter the configuration or whether or not a minor is among the members, one of those
persons must be designated as the head of household and the rest must have their relationship
to the head of household recorded.
If the group of persons is composed of adults and children, an adult must be indicated as the
head of household. Other than this restriction, each CoC must develop guidelines for defining
and designating a household member as the head of household and seek to ensure that those
guidelines are applied consistently across participating continuum projects. A particular funder
may provide instructions for determining which household member should be designated as
the head of household in projects that they fund; in the event that the funder's instructions are
in conflict with CoC guidance, the requirements of the funder should supersede CoC guidance
for the relevant projects.
Where two or more people under age 18 present at a project together (where none of the
people presenting are the child of the client being served by a project), 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.
9/3/2019

81

3. UNIVERSAL DATA ELEMENTS
Entering them separately is not permitted to be a barrier to or impact the receipt of future
interventions.
System Logic and Other System Issues: It is expected that both the Head of Household and the
household member are always in the database together in the same household at a particular
project. The system must allow for the Head of Household to leave the household and have the
household maintain the same Household ID while assigning a new Head of Household. The
system must allow for persons to enter or exit the household without having to complete a full
program exit and new project start of the entire household.
FY2020 Revision Summary: None.
3.15 Data Element Fields and Responses:
Field Number Field Name Dependency

1

Relationship None
to Head of
Household

Response
Category/ Data
Type
1 Self

2

Head of
household's
child

3

Head of
household's
spouse or
partner
Head of
household's
other relation
member (other
relation to head
of household)

4

9/3/2019

Descriptions
Heads of household may be
alternatively thought of as the
“primary client,” the “eligible
individual” etc., rather than as a
fixed designation.
Sons and daughters, including
step-, adopted, and foster children
of the head of household,
regardless of their age.

82

Field Number Field Name Dependency

Response
Category/ Data
Type
5 Other: nonrelation
member

Descriptions
Groups of people may self-define
their households or families,
which may include other nonrelations. 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.15 Specifications:
Data
Funder/Program Project Type
Collected
Component
Applicability
About

XML

All
All Funders, All All HMIS

3.16

Relationship
Relationship
Collection
to
CSV
to Personal
Point
Enrollment
ID
ID
Enroll Project
No more
One or more
ment Start
than one
Relationship
Relationship to Head of
to Head of Household
Household per Client
per
Enrollment

Client Location

Rationale: To link client household data to the relevant CoC. Necessary for projects that
operate across multiple CoCs for data export purposes and to ensure accurate counts of
persons who are served within a CoC. For more information about setting up projects that
operate in multiple CoCs, please refer to Section 1.2 Introduction to Project Descriptor Data
Elements.
Data Collection Instruction: Select or enter the CoC code assigned to the geographic area for
the project site where the head of household is being served.
'Information Date' for Client Location information collected at project start must reflect the date
of project start.

9/3/2019

83

3. UNIVERSAL DATA ELEMENTS
A new Client Location record must be created any time a client moves to a project location in a
different CoC while enrolled. 'Information Date' for those records must reflect the date of the
data collection.
If Client Location information was recorded incorrectly at project start or update, correct the
existing record.
System Logic and Other System Issues: It must be possible to associate all project stays with
one or more (for clients who move while enrolled) Continuum of Care (CoC) Codes. This data
element must be user-entered for all projects with more than one 'CoC 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 'CoC Code' identified in 2.03 Continuum of Care Information. For data
quality purposes, the 'CoC Code(s)' for this data element should be limited to the same 'CoC
Code(s)' used for element 2.03 Continuum of Care Information.
System must allow for updated information collection if change occurs because a client has
moved to another project location and must record the date the information was collected as
'Information Date' with a data collection stage of ‘Project Update.’ System must retain all
updates for historical purposes.
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 change based on the HOH identified Client Location.
FY2020 Revision Summary: None.
3.16 Data Element Fields and Responses:
Field Number

Field Name

Dependency

1

Information Date

2

CoC Code for Client None
Location

9/3/2019

None

Response Category/
Descriptions
Data Type
[Date]
The date the information
was collected.
[Text 6 characters] HUD assigned CoC code for
the client's location

84

3.16 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
Head Of All Funders, All All HMIS
< entCoC Start,
Client
Client
d Only Components
Enrollm
Update
Location per Location per
entCoC
Enrollment Client
>
Data
Funder/Program Project Type
Collected
Component
Applicability
About

3.20

Housing Move-in Date

Rationale: To document the date that a household admitted into a Permanent Housing project
moves into housing. This data is critical to point-in-time and housing inventory counts as it
differentiates households which have already moved into permanent housing from households
which are enrolled in a Permanent Housing project but are still literally homeless (in Emergency
Shelter, Safe Haven, Transitional Housing or on the street) as they prepare to move into an
available unit.
Data Collection Instruction: For clients with a Project Start Date in a permanent housing project
of any kind (see criteria for recording a Project Start Date under data element 3.10), record the
date a client or household moves into a permanent housing unit.
For RRH projects only, a Housing Move-in Date must be entered regardless of whether or not
the RRH project is providing the rental assistance for the unit. For example, if an RRH project
provides supportive services, but is not providing the rental assistance for the unit, a Housing
Move-in Date must still be entered to differentiate RRH clients in housing from those still
experiencing homelessness.
For any other project types that are typed as 'Permanent Housing' in the HMIS, clients who are
receiving pre-housing placement services but are ultimately housed by another project or
subsidy source should be exited from the PH project to the appropriate permanent Destination.
If the client exits the permanent housing project for a different housing opportunity without
physically moving into a housing unit associated with the project, do not enter a housing movein date, simply exit the client and record the exit destination.
For purposes of the Housing Inventory Count and other point-in-time reporting, households
with a Project Start Date which do not have a Housing Move-In Date at the point in time of the
report must be excluded from counts of persons in permanent housing.
In the event that 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
9/3/2019

85

3. UNIVERSAL DATA ELEMENTS
same or following day. The project would continue working with the client until a new unit is
found, at which point a new housing move-in date would be recorded on the second project
record. This will ensure that the client’s history of housing is preserved.
If the client moves directly from one unit into another unit, with no days of homelessness in
between, it would not be necessary to exit and re-enter them, because their housing move-in
date would still accurately reflect the day they entered permanent housing according to that
enrollment record.
In the event a client is transferred into a PSH or RRH 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 necessary or 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.
System Logic and Other System Issues: Housing Move-in Date must be between the Project
Start Date and Project Exit Date. It may be the same as the Project Start Date if the client moves
into housing on the date they were accepted into the program (or was already in housing when
they entered the project, e.g. due to a project transfer). There can be no more than one
Housing Move-in Date per enrollment. Once a Housing Move-in Date has been recorded for an
enrollment, it should 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.
FY2020 Revision Summary: None.
3.20 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/ Data
Descriptions
Name
Type
1
Housing None
[Date]
The date the client moved into permanent
Movehousing.
In Date

9/3/2019

86

3.20 Specifications:
Data
Funder/Program Project Type
Collected
Component
Applicability
About

Head Of All Funders, All
Househ Permanent
old Only Housing
Components

3 - PH Permanent
Supportive
Housing
9 - PH Housing Only
10 - PH Housing with
Services
13 - PH Rapid ReHousing

Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID

Date per
Date per
Enrollment Client

3.917 Prior Living Situation
Rationale: To identify the type of living situation and length of stay in that situation just prior to
project start for all adults and heads of households. This data element is to be used with other
information to identify whether a client appears to meet the criteria for chronic homelessness
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).
The element has been constructed to avoid collecting information which is irrelevant or
inappropriate for the client population being served in a particular situation. For example,
eligibility for Homelessness Prevention requires that a client be in housing. By definition, a
person in housing is not chronically homeless at that point in time, so some of the fields in this
data element used to determine chronic homeless status are not required in that situation.
Data Collection Instruction: Intake staff should ask clients about their homeless history,
including specific instances the client spent on the street, in an Emergency Shelter, or in a Safe
Haven project. This may require defining or explaining each field to the client.
Although documentation is required by some funders for programs targeting chronic homeless
persons, completing the data fields in HMIS does not require documentation -- a client's
responses are all that is required. Different project types have different realities they are
working in when it comes to interviewing clients. Some high-volume shelters may simply ask
people to quickly “ballpark” their responses to the required fields. Other project types are able
to have more complex intake processes that allow staff to sit with the client and get a clearer
picture of the client's housing history and their official “breaks” in homelessness, according to
the definition of chronic homelessness.
9/3/2019

87

3. UNIVERSAL DATA ELEMENTS
PSH projects with documentation requirements are expected to spend time with clients' HMIS
records and files to gather information for documentation purposes, which they can use to
improve data quality in this field. All of these strategies are acceptable, and HUD anticipates
that the data quality will vary from project type to project type. This data element is intended
to provide a consistent way to capture information about individuals who are likely
experiencing chronic homelessness in the HMIS for HUD and CoCs to use for planning purposes.
Note that this data element does not constitute third-party documentation of chronic
homelessness for projects that require such documentation (HMIS reports of actual
enrollments in ES, SH, or SO projects may be used to meet third-party documentation
requirements).
The responses are intended to reflect from the client's last living situation immediately prior to
the Project Start Date. For projects that do not provide lodging, the 'prior' living situation may be
the same as the client's current living situation.
1. Select the 'Type of Residence' from the Living Situation Option List that most closely
matches where the client was living prior to project start. Adult members of the same
household may have different prior living situations.
2. Record the length of time the client was residing in their previous place of stay.
a. (3.917B) If the client is entering Transitional Housing, any form of
Permanent Housing including Permanent Supportive Housing and
Rapid Re-Housing, Services Only, Other, Day Shelter, Homelessness
Prevention, and Coordinated Entry from an institutional setting:
i. Indicate if the client was in the institution for less than
90 days and if so, indicate if the client's living situation
immediately prior to entering the institution was on the
streets, in an emergency shelter or a safe haven.
ii. If 'Yes' to both, proceed to step 3. If 'No' to either, stop
collecting data for this element.
b. (3.917B) If the client is entering Transitional Housing, any form of
Permanent Housing including Permanent Supportive Housing and
Rapid Re-Housing, Services Only, Other, Day Shelter, Homelessness
Prevention, and Coordinated Entry from any type of transitional or
permanent housing:
i.
Indicate if the client was in the transitional or permanent housing
situation for less than 7 nights and if so, indicate if their living
situation immediately prior to entering the transitional or
permanent housing was on the streets, in an emergency shelter
or a safe haven.
ii.
If 'Yes' to both, proceed to step 3. If 'No' to either, stop.
c. If the client is entering Emergency Shelter, Safe Haven, or Street
Outreach, proceed to step 3.
3. Record the actual or approximate date this homeless situation began (i.e. the
beginning of the continuous period of homelessness on the streets, in
9/3/2019

88

emergency shelters, in safe havens, or moving back and forth between those
places).
4. Record the number of times the client has been on the streets, in emergency
shelters, or in safe havens in the past three years, including today.
5. Record the cumulative total number of months the client has been homeless on
the streets, in emergency shelters, or in safe havens in the past three years.

9/3/2019

89

3. UNIVERSAL DATA ELEMENTS
System Logic and Other System Issues: 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, the 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 the 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 darkened or in some other way
identified as not to be completed.
FY2020 Revision Summary: Renamed to 'Prior Living Situation' and assigned to the same Living
Situation List as Destination and Current Living Situation.
3.917 Data Element Fields and Responses:
Field
Number

1
2

Field
Name

Dependency

Living
None
Situation
Length of None
stay in
prior
living
situation

9/3/2019

Response Category, Data Type, Descriptions
See Appendix A – Living Situation Option List
10 One night The length of time the client was residing in
or less
the living situation selected in Field 1. If the
client move around, but in the same type of
situation, include the total time in that type
of situation. If the client moved around from
one situation to another, only include the
time in the situation selected in Field 1.
11 Two to six
nights
2 One week
or more,
but less
than one
month
3 One month
or more,
but less
than 90
days
4 90 days or
more, but
less than
one year

90

Field
Number

Field
Name

Dependency

Response Category, Data Type, Descriptions
5

A

B

C

One year
or longer
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
0 No

2.02 Project
Type is not 1,
4, or 8, and
3.917 Prior
Living Situation 1
Field 1 is any
'Institutional
Response'
Did the 2.02 Project
0
client
Type is not 1,
stay less 4, or 8, and
than 7
3.917 Prior
nights? Living Situation
Field 1 is any 1
'Transitional
and
Permanent
Housing'
Response
On the 2.02 Project
0
night
Type is not 1,
before, 4, or 8, and
1
did the 3.917 Prior
client
Living Situation
stay on Field A or B,
the
Response 1
streets,
ES or SH?
Did the
client
stay less
than 90
days?

9/3/2019

Yes

No

Yes

No
Yes

90 days or more in an institutional setting is
considered a "break" according to the
definition of chronic homelessness; stop data
collection for 3.917 Prior Living Situation.
Ask Field C

7 nights or more in transitional or permanent
housing situations is considered a "break"
according to the definition of chronic
homelessness; stop data collection for 3.917
Prior Living Situation.
Ask Field C

Stop data collection for 3.917 Prior Living
Situation.
"The streets" is being used as short-hand for
any place unfit for human habitation (a
public or private place not designed for or
ordinarily used as a regular sleeping
accommodation for human beings, including
a car, park, abandoned building, bus or train
station, airport, or camping ground.
If 'Yes' to both Fields A and C or Fields B and
C, proceed to Field 3. Otherwise, stop data
collection for 3.917 Living Situation.

91

3. UNIVERSAL DATA ELEMENTS
Field
Number

Field
Name

Dependency

Response Category, Data Type, Descriptions

3

Date
None
homeless
ness
started

[Date]

4

Number None
of times
the client
has been
on the
streets, in
ES, or SH
in the
past
three
years.

1

One time

2

Two times

9/3/2019

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. Remember
that "the streets" is being used as short-hand
for any place unfit for human habitation (a
public or private place not designed for or
ordinarily used as a regular sleeping
accommodation for human beings, including
a car, park, abandoned building, bus or train
station, airport, or camping ground.
Including the situation the client was in right
before entering, plus any continuous time
moving around between the streets, an
emergency shelter, or a safe haven,
determine the date this period of the client's
“literal” homelessness began.
The look back time would not be broken by a
stay of less than 7 consecutive nights in any
permanent or temporary housing situation
nor would it be broken by an institutional
stay of less than 90 days (i.e. jail, substance
abuse or mental health treatment facility,
hospital, or other similar facility).
Approximations are permitted.
Remember that "the streets" is being used as
short-hand for any place unfit for human
habitation (a public or private place not
designed for or ordinarily used as a regular
sleeping accommodation for human beings,
including a car, park, abandoned building,
bus or train station, airport, or camping
ground.
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).

92

Field
Number

Field
Name

Dependency

Response Category, Data Type, Descriptions
3

5

Total
None
number
of
months
homeless
on the
street, in
ES, or SH
in the
past
three
years

9/3/2019

Three
times
4 Four or
more times
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
10 One month Remember that "the streets" is being used as
1 (this time is short-hand for any place unfit for human
the first
habitation (a public or private place not
month)
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.
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.
Round the number of months up to the next
highest number of full months. The current
month, even if a partial month, can be
counted as a full month.
10 [Integers 2
2 through
thr 12]
ou
gh
11
2
11 More than
3 12 months
8 Client
doesn't
know

93

3. UNIVERSAL DATA ELEMENTS
Field
Number

Field
Name

Dependency

Response Category, Data Type, Descriptions
9

Client
refused
99 Data not
collected
3.917 Specifications:

Relationship
Relationship
Collection
to
Funder/Program Project Type
XML CSV
to Personal
Component
Applicability
Point
Enrollment
ID
ID
Head of
All Funders, All All HMIS
ment Start
Living
Prior Living
and Other Components
<...>
Situation per Situation per
Adults
Enrollment Client
Data
Collected
About

9/3/2019

94

4. 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 the composition of
income between project start and exit.
Increase in income is a key performance measure of most Federal Partner programs. Collecting
income information throughout a project stay supports plans to link clients with all income
sources and benefits for which they are eligible and helps CoCs improve system design and
partnerships by analyzing cross-systems connections to ensure access to additional income
sources.
Data Collection Instruction: Indicate whether each head of each household served (including
minor heads of their own household) and each adult household member have income and the
sources of that income.
Income data should be entered in HMIS consistent with guidelines for calculating household
income provided by a project funder, if such guidelines exist. For example, for eligibility
purposes, both CoC and ESG-funded projects are instructed to exclude income from the
employment of a minor child from calculations of household income. The same is true for SSVF.
However, recording income in an HMIS is not the same as performing an income evaluation for
purposes of project eligibility determination or a rent calculation for the purpose of
determining rental subsidy (24 CFR 5.609 and 24 CFR 5.611(a)). Data recorded in HMIS also
does not replace required income verification documentation that may be required by a funder.
In the absence of income calculation guidelines provided by a funder, as a general rule, any
income associated with a minor used for household expenses and support should be included
in the head of households Income and Sources record. Where the income is not relevant for
household expenses, it could reasonably be excluded from entry. Projects may choose to collect
income information for all household members including minor children within households, as
long as this does not interfere with accurate reporting per funder requirements.
Income and Sources collected at project start and project exit are to reflect the information as
of the date of project start and the date of project exit. 'Information Date' for those records
must reflect the date of project start and the date of project exit, respectively.
An Income and Sources record must be created at any time during a project stay if income or
sources change. This would include the situation when a minor child enters or leaves the
household and the income received by the household changes as a result. In that case, a new
Income and Sources record must be created for the head of household, reflecting the additional
9/3/2019

95

4. PROGRAM SPECIFIC DATA ELEMENTS
(or lost) income. This would also include the situation when a minor child in a household turns
18. In that case, a new Income and Sources record must be created for the 18-year-old client
reflecting any income associated with that client. If some existing income transfers to the 18year-old's new record, an additional update record would need to be created for the Head of
Household, reflecting the removal of that income from their record. 'Information Date' for
those records must reflect the date of the data collection.
An Income and Sources record must be created as part of an annual assessment for clients
participating in a project one year or more, even if there is no change in either the income or
sources. 'Information Date' for those records must reflect the date of the data collection, which
must be no more than 30 days before or after the anniversary of the head of household's
Project Start Date. Annual assessments are based solely on the head of household's anniversary
date. The annual assessment must include updating both the head of household's record and
any other family member's at the same time.
If a client's income information was recorded incorrectly at project start, update, assessment,
or exit, correct the existing record, rather than adding an ‘update’ record.
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.

9/3/2019

96

Student financial aid is not to be considered income unless the financial aid includes a cash
stipend. The source for such income would be considered ‘Other,’ and the source can be
described in a text field. Be sure to check your funder's requirements, however. For example,
SSVF does not allow grantees to include any student financial aid, including GI Bill Student
Financial Aid.
Lump sum amounts received by a family, such as inheritances, insurance settlements, or
proceeds from sale of property, or back pay from Social Security are considered assets, not
income, and are not recorded in HMIS.
System Logic and Other System Issues: 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. Data for the fields of this element should be logically consistent. It is
recommended that the HMIS is programmed to enforce these rules or to notify users when
inconsistent data has been entered.
•

If there is a ‘Yes’ response to 'Income from Any Source' then at least one source of
income must be identified.

•

If a source is identified, then a 'Monthly Amount' must be entered.

•

If a 'Monthly Amount' is entered for any source, then a 'Total Monthly Income' amount
is required

•

If there is a ‘No’ response to 'Income from Any Source' then the HMIS must
automatically record all sources as ‘No’ and leave dollar amounts null of $0.00.

To reduce data collection and reporting burden: 1) Systems are encouraged to auto-calculate
total monthly income to avoid mathematical errors and reduce data collection (generate a
$0.00 for total monthly income if 'Income from Any Source' = ‘No’); and 2) If a client report
receiving income, an HMIS may be designed such that projects only need to directly enter ‘Yes’
for the income source the client receives and have the HMIS automatically generate a ‘No’
response for the other income sources.
The HMIS may facilitate data accuracy by automatically changing a ‘No’ in 'Income from Any
Source' to a ’Yes’ if source(s) and dollar amount(s) are indicated. Updates are required for
persons aging into adulthood.
FY2020 Revision Summary: Renumbered element from 4.2 to 4.02.

9/3/2019

97

4. PROGRAM SPECIFIC DATA ELEMENTS
4.02 Data Element Fields and Responses:
Field Number

Field Name

Response
Dependency Category/ Data
Type
None
[Date]

Descriptions

1

Information Date

2

Income from Any
Source

3

Earned Income (i.e. None
employment
income)
Monthly Amount Field 3,
[Currency/decimal]
Response 1
Unemployment
None
0 No
Insurance
1 Yes
Monthly Amount Field 4,
[Currency/decimal]
Response
Supplemental
None
0 No
Security Income
1 Yes
(SSI)
Monthly Amount Field 5,
[Currency/decimal]
Response 1
Social Security
None
0 No
Disability Insurance
1 Yes
(SSDI)
Monthly Amount Field 6,
[Currency/decimal]
Response 1
VA ServiceNone
0 No
Connected
1 Yes
VA service-connected
Disability
disability compensation
Compensation
refers to a benefit paid to
veterans with a serviceconnected disability
Monthly Amount Field 7,
[Currency/decimal]
Response 1

A
4
B
5

C
6

D
7

E

9/3/2019

None

The date the information
was collected

0
1
8

No
Yes
Client doesn't
know
9 Client refused
99 Data not
collected
0 No
1 Yes

98

Field Number

8

Field Name

Dependency

VA Non-ServiceNone
Connected
Disability Pension

F

Monthly Amount

9

Private disability
insurance

G

Monthly Amount

10

Worker's
Compensation

H

Monthly Amount

11

Temporary
Assistance for
Needy Families
(TANF) [or use local
name]
Monthly Amount Field 11,
Response 1
General Assistance None
(GA) [or use local
name]
Monthly Amount Field 12,
Response 1
Retirement Income None
from Social
Security

I
12

J
13

K

Monthly Amount

14

Pension or

9/3/2019

Response
Category/ Data
Type
0 No
1 Yes

Descriptions

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

Field 8,
[Currency/decimal]
Response 1
None
0 No
1 Yes
Field 9,
[Currency/decimal]
Response 1
None
0 No
1 Yes
Field 10,
[Currency/decimal]
Response 1
None
0 No
1 Yes

[Currency/decimal]
0
1

No
Yes

[Currency/decimal]
0
1

No
Yes

Social Security Survivor
benefits are Retirement
Income from Social Security

Field 13,
[Currency/decimal]
Response 1
None
0 No
99

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field Name

retirement income
from a former job

L
15
M
16
N
17
O
P
18

9/3/2019

Dependency

Response
Category/ Data
Type
1 Yes

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

Monthly Amount

Field 14,
[Currency/decimal]
Response 1
Child support
None
0 No
1 Yes
Monthly Amount Field 15,
[Currency/decimal]
Response 1
Alimony and other None
0 No
spousal support
1 Yes
Monthly Amount Field 16,
[Currency/decimal]
Response 1
Other Source
None
0 No
1 Yes
Monthly Amount Field 17,
[Currency/decimal]
Response 1
Specify Source
Field 17,
[Text]
Response 1
Total Monthly
None
[Currency/decimal]
Income

100

4.02 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
HUD:CoC
All HMIS

fits
Update, Sources
Sources
except ES-nbn
Annual
record per record per
HUD:HOPWA
Assessme Enrollment Client
HUD:HUD-VASH
nt, Project
HUD:PFS - all PH
Exit
projects
HUD:RHSAP
HHS:PATH
HHS:RHY collection
required only
for MGH, TLP
and Demo
VA:SSVF collection
required only
for RRH & HP
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

HOH
and
Other
Adults

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: Indicate whether each head of each household served (including
minor heads of their own household) and each adult household member are receiving any of
the listed benefits.
Non-cash benefits data should be entered in HMIS consistent with guidelines provided by a
project funder, if such guidelines exist. In the absence of guidelines provided by a funder, as a
general rule, any benefits received by or on behalf of a minor household member or on behalf
of the household as a whole (such as SNAP) should be included in the head of households Non9/3/2019

101

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

9/3/2019

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

102

•

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.
System Logic and Other System Issues: 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. Data for the fields of this element should be logically consistent. It is
recommended that the HMIS is programmed to enforce these rules or to notify users when
inconsistent data has been entered.
•

If there is a ‘Yes’ response to 'Non-Cash Benefits from Any Source' then at least one
source of non-cash benefit must be identified.

•

If there is a ‘No’ Response to 'Non-Cash Benefits from Any Source' then the HMIS must
automatically record all sources as ‘No.’

To reduce data collection and reporting burden, if a client reports receiving non-cash benefits,
an HMIS may be designed such that projects only need to directly enter ’Yes’ for the benefit
source the client receives and have the HMIS automatically generate a ’No’ response for the
other benefit sources.
The HMIS may facilitate data accuracy by automatically changing a ’No’ in 'Non-Cash Benefits
from Any Source' to a ’Yes’ if source(s) are indicated. Updates are required for persons aging
into adulthood. Non-cash benefits may be entered into more detailed categories as long as
these categories can be aggregated into the above-stated non-cash benefits.
FY2020 Revision Summary: Corrected field response numbers for 'Other Source' (from 9 to 8).
Renumbered element from 4.3 to 4.03.
4.03 Data Element Fields and Responses:
Field Number

1
2

9/3/2019

Response
Dependency Category/ Data
Descriptions
Type
Information None
[Date]
The date the information was
Date
collected.
Non-Cash
None
0 No
Benefits from
1 Yes
Field Name

103

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

3

4

5

6

7

8
A

9/3/2019

Response
Dependency Category/ Data
Type
Any Source
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Supplemental None
0 No
Nutrition
1 Yes
Assistance
Program
(SNAP)
(Previously
known as
Food Stamps)
Special
None
0 No
Supplemental
1 Yes
Nutrition
Program for
Women,
Infants, and
Children
(WIC)
TANF Child
None
0 No
Care services
1 Yes
(or use local
name)
TANF
None
0 No
transportation
1 Yes
services (or
use local
name)
Other TANF- None
0 No
funded
1 Yes
services
Other source None
0 No
1 Yes
Specify source Field 8;
[Text]
Response 1
Field Name

Descriptions

104

4.03 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
HUD:CoC
All HMIS

s
Update, Benefits
Benefits
except ES-nbn
Annual
record per record per
HUD:HOPWA
Assessme Enrollment Client
HUD:HUD-VASH
nt, Project
HUD:PFS - all PH
Exit
projects
HUD:RHSAP
HHS:PATH
HHS:RHY collection
required only
for BCP (HP &
ES), MGH, TLP
and Demo
VA:SSVF collection
required only for
RRH & HP
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

HOH
and
Other
Adults

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: In separate fields, indicate whether or not clients are receiving
health insurance from any of the listed sources.

9/3/2019

105

4. PROGRAM SPECIFIC DATA ELEMENTS
Health Insurance data collected at project start and project exit are to reflect the information as
of the date of project start and the date of project exit. 'Information Date' for those records
must reflect the date of project start and the date of project exit, respectively.
A Health Insurance record must be created at any time during a project stay if health insurance
coverage information changes. 'Information Date' for those records must reflect the date of the
data collection. A Health Insurance record must be created as part of an annual assessment for
all clients residing in a project one year or more, even if there is no change in coverage.
'Information Date' for those records must reflect the date of the data collection, which must be
no more than 30 days before or after the anniversary of the head of household's Project Start
Date. The annual assessment must include updating both the head of household's record and
any other family members at the same time.
If a client's health insurance information was recorded incorrectly at project start, update,
assessment, or exit, correct the existing record.
If the response to 'Covered by Health Insurance' is ‘No,’ no further data collection is required. If
the response is 'Yes,' record whether or not the client is covered by each of the listed insurance
types. If required by a funder, enter the reason why such insurance is not being received for
each health insurance source.
Applying for coverage through a healthcare exchange could result in a person receiving
subsidized private health insurance or it could result in the person receiving Medicaid. If the
client's health coverage is through a private provider (even if it is heavily subsidized), record it
as Private Pay Health Insurance. If the client's health coverage is through Medicaid (even if it
was accessed through a healthcare exchange website), record it as Medicaid.
Health Insurance is intended to identify actual health insurance sources. Indigent care received
by a medical provider or hospital to cover a health care costs does not constitute health
insurance coverage and should not be recorded in HMIS.
Medical and dental health coverage provided through Ryan White funding is not considered
health insurance. If this is the only health coverage a client has, record ‘No’ in the field 'Covered
by Health Insurance.' Housing Opportunities for Persons With AIDS (HOPWA) providers record
Ryan White health services in data element W3 Medical Assistance (see HOPWA Program HMIS
Manual).
System Logic and Other System Issues: 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. Data for the fields of this element should be logically consistent. It is
recommended that the HMIS is programmed to enforce these rules or to notify users when
inconsistent data has been entered.

9/3/2019

106

•

If there is a ‘Yes’ response to 'Covered by Health Insurance' then at least one source of
health insurance must be identified.

•

If there is a ‘No’ response to 'Covered by Health Insurance' then the HMIS must
automatically record all sources as ‘No.’

To reduce data collection and reporting burden, if a client reports 'Covered by Health Insurance'
as a ‘Yes’ an HMIS may be designed such that projects only need to directly enter ‘Yes’ for the
health insurance the client is covered by and have the HMIS automatically generate a ‘No’
response for the other health insurance sources.
The HMIS may facilitate data accuracy by automatically changing a ‘No’ in 'Covered by Health
Insurance' to a ‘Yes’ if source(s) are indicated. Updates are required for persons aging into
adulthood.
FY2020 Revision Summary: Renumbered element from 4.4 to 4.04.
4.04 Data Element Fields and Responses:
Field Number

Field Name

1

Information Date

2

Covered by Health
Insurance

3

Medicaid

4

Medicare

5

State Children's

9/3/2019

Response
Dependency Category/ Data
Descriptions
Type
None
[Date]
The date the information
was collected.
None
0 No
1 Yes
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
None
0 No
1 Yes
Medicaid is a partnership
between federal and state
funds. It should always be
listed as Medicaid, not State
Health Insurance.
None
0 No
1 Yes
None
0 No

107

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

6

7

8

9
10

11
12

Field Name

Health Insurance
Program (or use local
name)
Veteran's
None
Administration (VA)
Medical Services
Employer-Provided None
Health Insurance

Health Insurance
obtained through
COBRA
Private Pay Health
Insurance

None

None

State Health
None
Insurance for Adults
(or use local name)
Indian Health
None
Services Program
Other

12A

Specify Source

A

Reason (HOPWA
ONLY)

9/3/2019

Response
Dependency Category/ Data
Type
1 Yes

None

Descriptions

0 No
1 Yes
0 No
1 Yes

Including TRICARE available
to veterans based on
military service

0 No
1 Yes
0
1
0
1

No
Yes
No
Yes

0 No
1 Yes
0 No

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

1 Yes
[Text]

Field 12;
Response 1
If "No" for each 1
of the Insurance
sources
2

Applied;
decision
pending
Applied;
client not
eligible
3 Client did
not apply
4 Insurance
type N/A for
this client

108

Field Number

Field Name

Response
Dependency Category/ Data
Type
8 Client
doesn't
know
9 Client
refused
99 Data not
collected

Descriptions

4.04 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
All
HUD:CoC
All HMIS

s
Update, Health
Health
except ES-nbn
Annual
Insurance
Insurance
HUD:HOPWA
Assessme record per record per
HUD:HUD-VASH
nt, Project Enrollment Client
HUD:PFS
Exit
HUD:RHSAP
HHS:PATH
HHS:RHY
VA:SSVF collection
required only
for RRH & HP
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven
Data
Funder/Program Project Type
Collected
Component
Applicability
About

4.05

Physical Disability

Rationale: To indicate whether clients have any disabling special needs which contribute to
their experience of homelessness or may be a factor in housing.
Data Collection Instruction: In separate fields, indicate:

9/3/2019

109

4. PROGRAM SPECIFIC DATA ELEMENTS
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 (applicable to 4.05, 4.07, 4.09, and 4.10 only).
Individual Disability records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. Disability update records should be
created at any time during a project stay if a client's 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 worker who did the data collection or recording.
If the disability is present and is expected to be of long-continued and indefinite duration, the
corresponding element 3.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 physical disability, and also answer 'No,' that the disability is not expected to be of
long, continued, and indefinite duration and substantially impair ability to live independently,
although a disability of such type may not qualify clients for programs meant for severely
disabled people and does 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 in order to comply with
Fair Housing laws and practices, unless this information is required to determine program
eligibility or is needed to determine whether applicants need units with special features or if
they have special needs related to communication. Projects should be especially sensitive to
the collection of disability information from clients under the age of 18. In households with
children accompanied by an adult, children's disabilities should be determined based on an
interview with the adult in the household.
System Logic and Other System Issues: 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. System may choose to only display dependent questions if user selects the
appropriate response.
FY2020 Revision Summary: Renumbered from 4.5 to 4.05.

9/3/2019

110

4.05 Data Element Fields and Responses:

1

Information Date

Response
Dependency Category/
Data Type
None
[Date]

2

Physical Disability

None

Field Number

A

Field Name

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

0 No
1 Yes

8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Field 2;
0 No
Response 1 1 Yes

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

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

8 Client
doesn't
know
9 Client
refused
99 Data not
collected

9/3/2019

111

4. PROGRAM SPECIFIC DATA ELEMENTS
4.05 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
HUD:CoC
All HMIS

ities Start,
Physical
Physical
HUD:HOPWA
Update, Disability
Disability
HUD:HUD-VASH
Project
record per record per
HUD:PFS
Exit
Enrollment Client
HUD:RHSAP
HHS:PATH
HHS:RHY
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

All
Clients

4.06

Developmental Disability

Rationale: To indicate whether clients have any disabling special needs which contribute to
their experience of homelessness or may be a factor in housing.
Data Collection Instruction: In separate fields, indicate if each client has the indicated disability.
Individual Disability records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. Disability update records should be
created at any time during a project stay if a client's 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 worker who did the data collection or recording.
If the disability is present, the corresponding element 3.08 Disabling Condition should also be
‘Yes’ whether by manual data entry, or in some systems, automatic population.
For residential homeless assistance programs, client intake as part of the program admission
process must be separated from the collection of disability information in order to comply with
Fair Housing laws and practices, unless this information is required to determine program
9/3/2019

112

eligibility or is needed to determine whether applicants need units with special features or if
they have special needs related to communication. Projects should be especially sensitive to
the collection of disability information from clients under the age of 18. In households with
children accompanied by an adult, children's disabilities should be determined based on an
interview with the adult in the household.
System Logic and Other System Issues: 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. System may choose to only display dependent questions if user selects the
appropriate response.
FY2020 Revision Summary: Renumbered from 4.6 to 4.06. Removed dependent field
"Substantially impedes the individual's ability to live independently" because the presence of
this condition in and of itself conforms to this designation.
4.06 Data Element Fields and Responses:
Response
Field Number Field Name Dependency Category/
Descriptions
Data Type
1
Information
None
[Date]
The date the information was
Date
collected.
2
Developmental None
0 No
Disability
1 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.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
4.06 Specifications:

9/3/2019

113

4. PROGRAM SPECIFIC DATA ELEMENTS
Relationship
Collection
Relationship to
to Enrollment
Point
Personal ID
ID
All
HUD:CoC
All HMIS
lities Start,
Developmental Developmental
HUD:HOPWA
Update, Disability
Disability
HUD:HUD-VASH
Project
record per
record per
HUD:PFS
Exit
Enrollment
Client
HUD:RHSAP
HHS:PATH
HHS:RHY
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven
Data
Funder/Program Project Type
Collected
XML
Component
Applicability
About

4.07

CSV

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: 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 (applicable to 4.05, 4.07, 4.09, and 4.10 only).
Individual Disability records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. Disability update records should be
created at any time during a project stay if a client's 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 worker who did the data collection or recording.
If the disability is present and is expected to be of long-continued and indefinite duration, the
corresponding element 3.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
9/3/2019

114

having a physical disability, and also answer 'No,' that the disability is not expected to be of
long, continued, and indefinite duration and substantially impair ability to live independently,
although a disability of such type may not qualify clients for programs meant for severely
disabled people and does 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 in order to comply with
Fair Housing laws and practices, unless this information is required to determine program
eligibility or is needed to determine whether applicants need units with special features or if
they have special needs related to communication. Projects should be especially sensitive to
the collection of disability information from clients under the age of 18. In households with
children accompanied by an adult, children's disabilities should be determined based on an
interview with the adult in the household.
System Logic and Other System Issues: 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. System may choose to only display dependent questions if user selects the
appropriate response.
FY2020 Revision Summary: Renumbered from 4.7 to 4.07.

9/3/2019

115

4. PROGRAM SPECIFIC DATA ELEMENTS
4.07 Data Element Fields and Responses:
Field Number

1
2

9/3/2019

Response
Dependency Category/
Descriptions
Data Type
Information Date None
[Date]
The date the information was
collected.
Chronic Health
None
0 No
Condition
1 Yes
For the purposes of these Data
Standards, a chronic health
condition means a diagnosed
condition that is more than three (3)
months in duration and is either not
curable or has residual effects that
limit daily living and required
adaptation in function or special
assistance. Examples of chronic
health conditions include, but are
not limited to: heart disease
(including coronary heart disease,
angina, heart attack and any other
kind of heart condition or disease);
severe asthma; diabetes; arthritisrelated conditions (including
arthritis, rheumatoid arthritis, gout,
lupus, or fibromyalgia); adult onset
cognitive impairments (including
traumatic brain injury, posttraumatic distress syndrome,
dementia, and other cognitive
related conditions); severe
headache/migraine; cancer; chronic
bronchitis; liver condition; stroke; or
emphysema.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Field Name

116

Field Number

A

Response
Dependency Category/
Descriptions
Data Type
Expected to be of Field 2;
0 No
long, continued
Response 1 1 Yes
1) Expected to be of long, continued
and indefinite
and indefinite duration,
duration and
(2) Substantially impedes an
substantially
individual's ability to live
impairs ability to
independently, and
live independently
(3) Of such a nature that such ability
could be improved by more suitable
housing conditions.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Field Name

4.07 Specifications:
Relationship
Collection
to
XML
CSV
Point
Enrollment
ID
HUD:CoC
All HMIS

ties
Start,
Chronic
HUD:HOPWA
Update, Health
HUD:HUD-VASH
Project
Condition
HUD:PFS
Exit
record per
HUD:RHSAP
Enrollment
HHS:PATH
HHS:RHY
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

Relationship
to Personal
ID

All
Clients

One or more
Chronic
Health
Condition
record per
Client

4.08

HIV/AIDS

Rationale: To indicate whether clients have any disabling special needs which contribute to
their experience of homelessness or may be a factor in housing.
9/3/2019

117

4. PROGRAM SPECIFIC DATA ELEMENTS
Data Collection Instruction: In separate fields, indicate if each client has the indicated disability.
HIV-related information is covered by confidentiality requirements. As in other areas
involving sensitive or protected client information, information should be recorded only when
a project has data confidentiality protections that conform to the standards specified in the
HMIS Final Rule, to be published. These protections include agency policies and procedures
and staff training to ensure that HIV-related information cannot be accessed by anyone
without the proper authorization.
Individual Disability records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. Disability update records should be
created at any time during a project stay if a client's 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 worker who did the data collection or recording.
If the disability is present, the corresponding element 3.08 Disabling Condition should also be
‘Yes’ whether by manual data entry, or in some systems, automatic population.
For residential homeless assistance programs, client intake as part of the program admission
process must be separated from the collection of disability information in order to comply with
Fair Housing laws and practices, unless this information is required to determine program
eligibility or is needed to determine whether applicants need units with special features or if
they have special needs related to communication. Projects should be especially sensitive to
the collection of disability information from clients under the age of 18. In households with
children accompanied by an adult, children's disabilities should be determined based on an
interview with the adult in the household.
System Logic and Other System Issues: 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. System may choose to only display dependent questions if user selects the
appropriate response.
FY2020 Revision Summary: Renumbered from 4.8 to 4.08. Removed dependent field
"Substantially impedes the individual's ability to live independently" because the presence of
this condition in and of itself conforms to this designation.

9/3/2019

118

4.08 Data Element Fields and Responses:
Field Number

1

Field Name

Information
Date
HIV/AIDS

2

Dependency
None
None

Response Category/
Descriptions
Data Type
[Date]
The date the information
was collected.
0 No
1 Yes
8 Client doesn't know
9 Client refused
99 Data not collected

4.08 Specifications:
Relationship
Collection
to
XML
CSV
Point
Enrollment
ID
HUD:CoC
All HMIS

ties
Start,
HIV/AIDS
HUD:HOPWA
Update, record per
HUD:HUD-VASH
Project
Enrollment
HUD:PFS
Exit
HUD:RHSAP
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

Relationship
to Personal
ID

All
Clients

One or more
HIV/AIDS
record per
Client

4.09

Mental Health Problem

Rationale: To indicate whether clients have any disabling special needs which contribute to
their experience of homelessness or may be a factor in housing.
Data Collection Instruction: In separate fields, indicate:
1. If each client has the indicated disability; and
2. If there is indication that the disability is expected to be of long-continued and
indefinite duration and substantially impair the client's ability to live
independently (applicable to 4.05, 4.07, 4.09, and 4.10 only).
Individual Disability records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. Disability update records should be
9/3/2019

119

4. PROGRAM SPECIFIC DATA ELEMENTS
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 worker who did the data collection or recording.
If the disability is present and is expected to be of long-continued and indefinite duration, the
corresponding element 3.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 physical disability, and also answer 'No,' that the disability is not expected to be of
long, continued, and indefinite duration and substantially impair ability to live independently,
although a disability of such type may not qualify clients for programs meant for severely
disabled people and does 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 in order to comply with
Fair Housing laws and practices, unless this information is required to determine program
eligibility or is needed to determine whether applicants need units with special features or if
they have special needs related to communication. Projects should be especially sensitive to
the collection of disability information from clients under the age of 18. In households with
children accompanied by an adult, children's disabilities should be determined based on an
interview with the adult in the household.
System Logic and Other System Issues: 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. System may choose to only display dependent questions if user selects the
appropriate response.
FY2020 Revision Summary: Renumbered from 4.9 to 4.09.

9/3/2019

120

4.09 Data Element Fields and Responses:
Field Number

1
2

A

9/3/2019

Response
Dependency Category/
Descriptions
Data Type
Information Date
None
[Date]
The date the information was
collected.
Mental Health
None
0 No
Problem
1 Yes
For the purposes of these Data
Standards, a mental health
problem may range from
situational depression to serious
mental illnesses. The dependent
field is designed to gauge the
severity of the mental health
problem.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Expected to be of
Field 2;
0 No
long, continued and Response 1 1 Yes
1) Expected to be of long,
indefinite duration
continued and indefinite
and substantially
duration,
impairs ability to live
(2) Substantially impedes an
independently
individual's ability to live
independently, and
(3) Of such a nature that such
ability could be improved by
more suitable housing
conditions.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Field Name

121

4. PROGRAM SPECIFIC DATA ELEMENTS
4.09 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
HUD:CoC
All HMIS

ities Start,
Mental
Mental
HUD:HOPWA
Update, Health
Health
HUD:HUD-VASH
Project
Problem
Problem
HUD:PFS
Exit
record per record per
HUD:RHSAP
Enrollment Client
HHS:PATH
HHS:RHY
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

All
Clients

4.10

Substance Abuse

Rationale: To indicate whether clients have any disabling special needs which contribute to
their experience of homelessness or may be a factor in housing.
Data Collection Instruction: In separate fields, indicate:
1. If each client has the indicated disability; and
2. If there is indication that the disability is expected to be of long-continued and
indefinite duration and substantially impair the client's ability to live
independently (applicable to 4.05, 4.07, 4.09, and 4.10 only).
Individual Disability records created at project start, update, and project exit are to reflect the
information as of the date of each phase of data collection. Disability update records should be
created at any time during a project stay if a client's 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 worker who did the data collection or recording.

9/3/2019

122

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 physical disability, and also answer 'No,' that the disability is not expected to be of
long, continued, and indefinite duration and substantially impair ability to live independently,
although a disability of such type may not qualify clients for programs meant for severely
disabled people and does 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 in order to comply with
Fair Housing laws and practices, unless this information is required to determine program
eligibility or is needed to determine whether applicants need units with special features or if
they have special needs related to communication. Projects should be especially sensitive to
the collection of disability information from clients under the age of 18. In households with
children accompanied by an adult, children's disabilities should be determined based on an
interview with the adult in the household.
System Logic and Other System Issues: 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. System may choose to only display dependent questions if user selects the
appropriate response.
FY2020 Revision Summary: None.
4.10 Data Element Fields and Responses:

1

Information Date

Response
Dependency Category/
Data Type
None
[Date]

2

Substance Abuse Problem

None

Field Number

9/3/2019

Field Name

Descriptions
The date the information
was collected.

0 No
1 Alcohol
Alcohol abuse, without
abuse
drug abuse
2 Drug abuse Drug abuse, without
alcohol abuse
3 Both
alcohol and
drug abuse
8 Client
doesn't
know
123

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

A

Field Name

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

Dependency

Field 2;
Response 1

Response
Category/
Data Type
9 Client
refused
99 Data not
collected
0 No
1 Yes

Descriptions

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.

8 Client
doesn't
know
9 Client
refused
99 Data not
collected

9/3/2019

124

4.10 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
HUD:CoC
All HMIS

ities Start,
Substance
Substance
HUD:HOPWA
Update, Abuse record Abuse record
HUD:HUD-VASH
Project
per
per Client
HUD:PFS
Exit
Enrollment
HUD:RHSAP
HHS:PATH
HHS:RHY
VA:GPD
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

All
Clients

4.11

Domestic Violence

Rationale: To indicate whether heads of household and other adults served are survivors of
domestic violence. Ascertaining whether a person is a survivor of or fleeing from domestic
violence is necessary to provide the person with the appropriate services to prevent further
abuse and to treat the physical and psychological injuries from prior abuse. Also, ascertaining
that a person may be experiencing domestic violence may be important for the safety of
project staff and other clients. At the aggregate level, knowing the size of the population of
persons experiencing homelessness who have also experienced domestic violence is critical for
determining the resources needed to address the problem.
Data Collection Instruction: In separate fields, indicate (1) if the client is a survivor of domestic
violence, (2) when the experience occurred, and (3) if the client is currently fleeing domestic
violence.
Domestic Violence records created at project start are to reflect the information as of the date
of project start. 'Information Date' for those records must reflect the date of project start.
A Domestic Violence record must be created at any time during a project stay if a client's
domestic violence status changes. 'Information Date' for those records must reflect the date of
the data collection.
If a client's domestic violence status was recorded incorrectly at project start, correct the
existing record.
9/3/2019

125

4. PROGRAM SPECIFIC DATA ELEMENTS
Verification is not necessary unless it is specifically required for project eligibility, in which case
documentation requirements established by the funder should be followed.
Projects should be especially sensitive to the collection of domestic violence information from
clients and should implement appropriate interview protocols to protect client privacy and
safety such as: asking this question in a private location and not in the presence of a romantic
partner; delaying all entry of data about clients identified with a recent history of domestic
violence; or choosing not to disclose data about clients with a history of domestic violence to
other homeless projects. Projects may wish to consult with specialized staff with training in
trauma-informed care, safety needs, or other population-specific considerations.
If clients are providing inconsistent information (e.g. indicating that they are currently fleeing
an abusive situation but their response to 'When experience occurred' is 'One year ago or
more'), clarification should be facilitated by appropriate staff. Staff can help clients understand
that the definition of a DV experience includes "dangerous... conditions that relate to violence
against the individual or a family member," which is broader than a specific violent episode.
There are situations where the act of fleeing takes place weeks or months after a particular
violent episode, but the conditions within the home remain dangerous. With this clarification,
the staff and client together can determine the best response for 'When experience occurred.'
System Logic and Other System Issues: The system must record the appropriate data collection
stage for each record of this 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. HMIS may choose to only display dependent questions if user selects the
appropriate response.
FY2020 Revision Summary: Funder: Program Components requiring data collection updated to
include PATH: All components and VA: SSVF.

9/3/2019

126

4.11 Data Element Fields and Responses:
Field Number

1
2

A

9/3/2019

Response
Dependency Category/ Data
Descriptions
Type
Information
None
[Date]
The date the information was
Date
collected.
Domestic
None
0 No
Violence
1 Yes
Domestic Violence Victim/Survivor
Victim/Survivor
should be indicated as ‘Yes’ if the
person has experienced any
domestic violence, dating violence,
sexual assault, stalking or other
dangerous or life-threatening
conditions that relate to violence
against the individual or a family
member, including a child, that has
either taken place within the
individual's or family's primary
nighttime residence.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
When
Field 2
1 Within the
experience
Response 1
past three
occurred
months
2 Three to six
months ago
(excluding
six months
exactly)
3 Six months
to one year
ago
(excluding
one year
exactly)
Field Name

127

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

B

9/3/2019

Response
Dependency Category/ Data
Descriptions
Type
4 One year
ago or more
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Currently fleeing Field 2
0 No
Response 1 1 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.
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
Field Name

128

4.11 Specifications:
Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID
HUD:CoC
All HMIS

Update, Violence
Violence
HUD:HUD-VASH
record per record per
HUD:PFS Enrollment Client
required for all
permanent
housing
projects
HUD:RHSAP
HHS:PATH
VA:GPD
VA:SSVF collection
required only
for RRH & HP
VA: CRS
VA: Community
Contract Safe
Haven

Data
Funder/Program Project Type
Collected
Component
Applicability
About

HOH
and
Other
Adults

4.12

Current Living Situation

Rationale: To record each contact with people experiencing homelessness by street outreach
and other service projects and to provide information on the number of contacts required to
engage the client, as well as to document a current living situation as needed in any applicable
project.
Data Collection Instruction: 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 record to be opened in the HMIS for the client. Refer to guidance in
HMIS Program Manuals (PATH, CoC, ESG, VA or RHY) for more details.
If client's Current Living Situation is in a temporary, permanent, or other situation from the
Living Situation Options List of headers, record additional housing status information to support
the determination of imminent and at-risk of homelessness housing statuses based on HUD's
definition of homelessness.
9/3/2019

129

4. PROGRAM SPECIFIC DATA ELEMENTS
All 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, Prior Living
Situation 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 worker and client about the client's well-being or
needs, an office visit to discuss their housing plan, or a referral to another community service.
Mobile HMIS data entry can be helpful for working in the field. If it is not possible, data will
need to be securely recorded and transported for entry at an office or data can be entered
remotely by a colleague by phone.
Night-by-Night shelters should only record a 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.
System Logic and Other System Issues: Collect once for each contact made. The system must
be able to store a theoretically unlimited number of Current Living Situations for any Enrollment
ID associated with the indicated project types.
Data collection requirements for PATH-funded components is 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) (16)
• Emergency shelter, including hotel or motel paid for with emergency shelter voucher, or
RHY-funded Host Home shelter (1)
• Safe Haven (18)
• Other (17)
• Worker unable to determine (37)
Field 3 should be populated by the list of CoC Project names in 2.02.2, if 2.02.5 indicates that
the project is a continuum project. Dependent A and its dependencies can be used to calculate
imminent and at risk of homelessness housing statuses based on HUD’s definition of
homelessness. One record of contact is required as an update for each contact made along with
the response to Field 2 which may change over the project stay.

9/3/2019

130

FY2020 Revision Summary: Restructured and renamed from Contact to Current Living
Situation. Mapping guidance is available for data formerly recorded in the Contact data element
structure.
4.12 Data Element Fields and Responses:
Field Number

Field Name

1

Information Date

2

Current Living
Situation

3

Living Situation
verified by:

A

Is client going to have
to leave their current
living situation within
14 days?

B

Has a subsequent
residence been
identified?

C

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

D

Has the client had a
lease or ownership

9/3/2019

Response Category/
Descriptions
Data Type
None
[Date]
The date the
information
was collected.
None
See Appendix A for complete list of
Living Situation Responses and
Destinations
Coordinated Entry List of Continuum Use the project
Projects Only
Projects
name from
2.02.2 for any
project with
2.02.5
'Continuum
Project' = "Yes"
Field 2 Responses 0 No
15, 6, 7, 25, 4, 5, 29, 1 Yes
14, 2, 32, 36, 35, 28, 8 Don't know
19, 3, 31, 33, 34, 10,
9 Client Refused
20, 21, 11
99 Data Not
Collected
Field A Response 1 0 No
1 Yes
8 Don't know
9 Client Refused
99 Data Not
Collected
Field A Response 1 0 No
1 Yes
8 Client doesn't
know
9 Client refused
99 Data Not
Collected
Field A Response 1 0 No
1 Yes
Dependency

131

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field Name

Dependency

interest in a
permanent housing
unit in the last 60
days?
E

Has the client moved Field A Response 1
2 or more times in the
last 60 days?

4

Location details

Response Category/
Descriptions
Data Type
8 Client doesn't
know
9 Client refused
99 Data Not
Collected
0 No
1 Yes
8 Client doesn't
know
9 Client refused
99 Data Not
Collected
[Text box]

4.12 Specifications:
Data
Funder/Program Project Type
Collected
XML
Component Applicability
About

1–
TBD
Head of HUD:CoC Household Street Outreach Emergency
Shelter
and Other and
4 - Street
Adults
Coordinated
Outreach
Entry only
HUD:ESG 6 - Services
Street
Only
Outreach, and 14 ES nbn
Coordinated
Entry
HHS:PATH
HHS:RHY Street Outreach
only
HUD: CoC YHDP
- any project
type serving
clients who
meet Category
2 or 3 of the
homeless
definition
9/3/2019

Relationship
Relationship
Collection
to
CSV
to Personal
Point
Enrollment
ID
ID
Current Occurrenc Zero or more Zero or more
LivingSi e
Current
Current
tuation
Living
Living
Situations
Situations
per
per Client
Enrollment

132

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: Record the date a client became engaged by a street outreach
project or night-by-night emergency shelter in the development of a plan to address their
situation. Only one date of engagement is allowed between project start and exit.
This date may be on or after the Project Start Date and if the client becomes engaged, must be
on or prior to the Project Exit Date. If the project has not developed this intensive relationship
with the client before exit, Date of Engagement should be left blank.
If the client returns after a project exit, a new Project Start Date and a new Date of Engagement
is to be established.
Reporting on data quality for street outreach projects is limited to clients with a Date of
Engagement. All Universal Data Elements and applicable Program Specific Data Elements
should be reviewed for completeness and accuracy on the Date of Engagement.
Refer to guidance in the Federal Partner HMIS Program Manuals (PATH, CoC, ESG, or RHY) for
more details.
System Logic and Other System Issues: Only one date of engagement is allowed between the
Project Start Date and Project Exit Date. If a client returns to the project at a later date the
previous date of engagement does not apply to the new project stay. The data must be
reentered based on the situation during the new project stay. It is possible that a case may be
closed without the client becoming engaged and thus date of engagement would be null in that
enrollment record.
FY2020 Revision Summary: None.
4.13 Data Element Fields and Responses:
Response
Field Number Field Name Dependency Category/
Data Type
1
Date of
None
[Date]
Engagement

9/3/2019

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

133

4. PROGRAM SPECIFIC DATA ELEMENTS
4.13 Specifications:
Data
Funder/Program Project Type
Collected
Component
Applicability
About

Head of HUD:CoC 1Household Street Outreach Emergency
and Other only
Shelter
Adults
HUD:ESG 4 - Street
Street Outreach Outreach
and Emergency 6 - Services
Shelter nbn only Only
HHS:PATH
HHS:RHY Street Outreach
only
4.14

Relationship
Collection
to
XML CSV
Point
Enrollment
ID
ment e
Date of
Engagement
per
Enrollment

Relationship
to Personal
ID
Zero or more
Dates of
Engagement
per Client

Bed-Night Date

Rationale: To determine each bed-night utilized by a client in a night-by-night shelter.
Data Collection Instruction: A Bed-Night Date record indicates that the client has utilized a bed
in a night-by-night shelter on that date.
Use the methodology built into the HMIS system to record the date of each night a client stays
in a bed. This may be a manual data entry, scan card system, check off, etc.
There must be a record of a bed night on the Project Start Date into a night-by-night shelter;
any additional bed night dates must be after the Project Start Date and before the Project Exit
Date.
System Logic and Other System Issues: Collect once for each bed night utilized. A bed night
date indicates that the client has utilized a bed in a night-by-night shelter on that date. The
system must be able to store a theoretically unlimited number of Bed-Night Dates for any
Enrollment ID associated with a night-by-night shelter. The Bed-Night Date must be exportable
in the [date field] format.
FY2020 Revision Summary: None.

9/3/2019

134

4.14 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/ Data
Name
Type
1
Bed-night None
[Date]
Date

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

4.14 Specifications:
Data
Funder/Program Project Type
Collected
Component
Applicability
About

All
All Funders, All 1 Clients ES components Emergency
using night by Shelter
night method
only
4.19

Relationship
Relationship
Collection
to
XML
CSV
to Personal
Point
Enrollment
ID
ID

Dates per
Dates per
Enrollment Client

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

9/3/2019

135

4. PROGRAM SPECIFIC DATA ELEMENTS
System Logic and Other System Issues: The system must be able to store a theoretically
unlimited number of Coordinated Entry Assessment records for any Enrollment ID associated
with a Coordinated Entry project.
For Field 2, it is recommended that a system administrator-managed list is used for this field. If
such functionality doesn't exist in the HMIS, a predetermined list of Coordinated Entry location
sites or a text box must be provided.
Fields 1-4 and Field 7 will be required for reporting purposes. Fields 5 & 6 are included as
placeholders for communities who currently do, or want to in the future, collect CE Assessment
questions, answers, and results in HMIS. These fields also serve as a common frame of
reference when transferring data via HMIS CSV or XML.
Fields 5 & 6 are representative of whatever assessment a community uses. There is no specified
structure or format for an assessment, and an HMIS might have more than one type of
assessment (Crisis Needs or Housing Needs or multiples of each). The system must be able to
treat a single assessment recorded for a client as one unit of data including the fields listed here
as well as the community-defined fields.
Field 5 and Dependent A 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”.
Similarly, Field 6 and Dependent B are a list of key-value (result type and result) pairs used to
contain any number of possible results, scores, or calculations on the assessment. For example,
one assessment might have three results: “Housing stability score” / “10”; “Total score” / “81”;
“Recommended placement” / “RRH”.
Data must be able to be added in multiple stages to complete a client record for a single
assessment.
FY2020 Revision Summary: New Element.
4.19 Data Element Fields and Responses:
Response Category/
Field Number Field Name Dependency
Descriptions
Data Type
1
Date of
None
[Date]
The date the assessment occurred.
Assessment
2
Assessment None
AdministratorCommunity defined values; Could
Location
managed list of
derive from HMIS Project List.
locations
Assessment was conducted by phone
3
Assessment None
1 Phone
Type
Assessment was conducted virtually,
2 Virtual
not face-to-face (i.e. website or app)

9/3/2019

136

Field Number Field Name Dependency

4

Assessment
Level

None

5

Assessment
Questions

None

A

Assessment
Answers

Field 5

6

Assessment
Result Type

None

B

Assessment
Result

Field 6

7

Prioritization None
Status

Response Category/
Descriptions
Data Type
Assessment was conducted in person
3 In Person
(face-to-face).
Assessment conducted for
1 Crisis Needs
immediate, crisis-based needs;
Assessment
initial, short, focused assessment to
help case workers identify
immediate resolutions to address
emergency needs, including shelter.
2 Housing Needs Assessment conducted for housing
needs; more in-depth, housing
Assessment
focused assessment to help case
workers direct clients to resources
for stabilization of their housing
situation.
Field 5 and Dependent A are a list of
1...n Locally
key-value (question and response)
determined
pairs for every question in the
fields
assessment, e.g. “Where did you
sleep last night” / “On the streets.”

1...n Locally
determined
fields
1...n Locally
determined
fields
1...n Locally
determined
fields
1 Placed on
prioritization
list
2

9/3/2019

Responses to Questions asked in
Field 5.
Results structured as defined by the
community.
Results for each result type in Field 6.

The result of the assessment is the
client was placed on the
community’s prioritization list for
housing resources.
Not placed on The result of the assessment is the
prioritization client was not placed on the
community’s prioritization list for
list
housing resources.

137

4. PROGRAM SPECIFIC DATA ELEMENTS
4.19 Specifications:
Data
Funder/Program Project Type
Collected
XML
Component
Applicability
About

Head of
HUD:CoC if
Household providing
Coordinated
Entry
HUD:ESG if
providing
Coordinated
Entry
VA:SSVF Rapid
Resolution Only
4.20

All HMIS
TBD
Project Types
depending
on design of
Coordinated
Entry
System.

CSV
Assessm
ent,
Assessm
entQues
tions,
Assessm
entResul
ts

Relationship
Relationshi
Collection
to
p to
Point
Enrollment
Personal ID
ID
Occurrence One or more One or
Coordinated more
Entry
Coordinated
Assessment Entry
per
Assessment
Enrollment per Client

Coordinated Entry Event

Rationale: The Coordinated Entry Event element is designed to capture key referral and
placement events, as well as the results of those events. It will help communities understand
the events that go into achieving desired (and undesired) results through the Coordinated Entry
system. This data element is intended to standardize data collection on core components of
Coordinated Entry like access, assessment, referral, and prioritization.
Data Collection Instruction: 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 indicates there is an opening for the
client to be housed by the project.
System Logic and Other System Issues: The system must be able to store a theoretically
unlimited number of Coordinated Entry Event records for any Enrollment ID associated with a
Coordinated Entry project.
For Dependent C, it is recommended that a system administrator-managed list is used for this
field. If such functionality doesn't exist in the HMIS, a pre-determined list of Coordinated Entry
location sites or a text box must be provided.

9/3/2019

138

Fields must be able to be updated over time as an event is resolved and information about the
result becomes available.
FY2020 Revision Summary: New Element.
4.20 Data Element Fields and Responses:
Dependen Response Category/
Field
Field Name
Number
cy
Data Type
1
Date of Event
None
[Date]
2
Event
None
Header: Access Events
1 Referral to a
Prevention
Assistance project
2

3

4

Problem
Solving/Diversion/
Rapid Resolution
intervention or
service
Referral to a
scheduled
Coordinated Entry
Crisis Assessment

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.
The client received a referral
Referral to a
to a Coordinated Entry
scheduled
Coordinated Entry Housing Needs Assessment; or
other local equivalent
Housing Needs
assessment. For a description
Assessment
of Housing Needs Assessment,
please see Data Element 4.19
CE Assessment.

Header: Referral
Events

9/3/2019

Descriptions

[Not a response option]

139

4. PROGRAM SPECIFIC DATA ELEMENTS
Field
Number

Field Name

Dependen Response Category/
Descriptions
cy
Data Type
5 Referral to post- The client received a referral
placement/ follow- to a post-placement service or
follow-up case management;
up case
or other local equivalent.
management

6

7

8

9/3/2019

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.
Referral to a Street The client received a referral
Outreach project to a Street Outreach project or
services, or other local
or services
equivalent referral. See 2.02
Project Information for the
definition of a Street Outreach
project.
The client received a referral
Referral to a
to an SSO or other service only
Housing
Navigation project project or service for the
purpose of receiving Housing
or services
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.
Referral to Non- The client received a referral
to non-continuum services
continuum
services: Ineligible because they were ineligible
for continuum services, or
for continuum
other local equivalent referral.
services
Non-continuum services may
include emergency assistance
projects for those not at-risk
of or experiencing
homelessness.

140

Field
Number

Field Name

Dependen Response Category/
cy
Data Type
9 Referral to Noncontinuum
services: No
availability in
continuum
services

Descriptions

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
10 Referral to
Emergency Shelter information regarding how to
access an emergency shelter
bed opening
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
11 Referral to
information regarding how to
Transitional
Housing bed/unit access a TH bed/unit opening.
A “referral” indicates there is
opening
an opening for the client to be
housed by this project (or
local equivalent).
12 Referral to Joint The client was provided with
information regarding how to
TH-RRH
project/unit/resou access a joint component
project bed/unit opening. A
rce opening
“referral” indicates there is an
opening for the client to be
housed by this project (or
local equivalent).
The client was provided with
13 Referral to RRH
project resource information regarding how to
access a RRH bed/unit
opening
opening. A “referral” indicates
there is an opening for the
client to be housed by this
project (or local equivalent).

9/3/2019

141

4. PROGRAM SPECIFIC DATA ELEMENTS
Field
Number

Field Name

A

Client housed/rehoused in a safe
alternative

B

Enrolled in Aftercare
project

9/3/2019

Dependen Response Category/
Descriptions
cy
Data Type
The client was provided with
14 Referral to PSH
project resource information regarding how to
access a PSH bed/unit
opening

opening. A “referral” indicates
there is an opening for the
client to be housed by this
project (or local equivalent).
15 Referral to Other The client was provided with
information regarding how to
PH
project/unit/resou access an “other PH” bed/unit
opening. A “referral” indicates
rce opening
there is an opening for the
client to be housed by this
project (or local equivalent).
The result of the diversion or
Field 2
0 No
rapid resolution problem –
Response
solving conversation and
2
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
1 Yes
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
Field 2
0 No
to a post-placement service or
Response
follow-up case management,
5
or other local equivalent
referral, subsequent follow up
with the client or project
indicates the client did not
enroll into the referred
project.

142

Field
Number

C

D

9/3/2019

Field Name

Dependen Response Category/
Descriptions
cy
Data Type
If the client received a referral
1 Yes

to a post-placement 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.
Location of Crisis
Field 2
List of HMIS Projects If a client was referred to an
opening in a continuum
Housing or Permanent Responses (from 2.02 with
project per response options
Housing Referral
10-15
project types
10-15 of Field 2 of this data
[Project Name]
1,2,3,13,9,10)
element, enter the Project
Name and HMIS Project ID of
the referred project.
Referral Result
Field 2
1 Successful referral: If a client was referred to an
opening in a continuum
Responses
client accepted
project per response options
10-15
10-15 of Field 2 of this data
element, subsequent follow
up with the client or provider
indicates the client was
accepted into the project
opening.
If a client was referred to an
2 Unsuccessful
opening in a continuum
referral: client
project per response options
rejected
10-15 of Field 2 of this data
element, subsequent follow
up with the client or provider
indicates the client decided to
reject the referral to the
project.

143

4. PROGRAM SPECIFIC DATA ELEMENTS
Field
Number

E

Field Name

Date of Result

Dependen Response Category/
Descriptions
cy
Data Type
If a client was referred to an
3 Unsuccessful
referral: provider opening in a continuum
project per response options
rejected

10-15 of Field 2 of this data
element, 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.

Field D All [Date]
Responses

4.20 Specifications:
Data
Funder/Program Project Type
Collected
XML
Component Applicability
About

Head of HUD:CoC if
Household providing
Coordinated
Entry
HUD:ESG if
providing
Coordinated
Entry
VA:SSVF Rapid
Resolution
Only
9/3/2019

All HMIS
TBD
Project
Types
depending
on design of
Coordinated
Entry
System.

CSV
Event

Relationship
Relationship
Collection
to
to Personal
Point
Enrollment
ID
ID
Occurrence One or more One or more
Coordinated Coordinated
Entry Event Entry Event
per
per Client
Enrollment

144

Federal Partner Program Data Elements
The following section represents placeholders for the forthcoming Federal Partner Program
Data Elements data collection instructions which will be released in the coming months. The
elements below have been updated where noted for FY2020 Data Standards requirements.
HOPWA
W1 Services Provided - HOPWA
FY2020 Revision Summary: None.
W1 Data Element Fields and Responses:
Response Category/ Data
Field
Field Number
Dependency
Descriptions
Name
Type
1
Date of None
[Date]
Service
2
Type of None
1 Adult day care and
Service
personal assistance
2 Case management
3 Child care
4 Criminal justice/legal
services
5 Education
6 Employment and
training services
7 Food/meals/nutritional A service record for each instance
services
of a residential meal provided is
not required or intended. This
response is only intended to
capture information about
food/meals being provided
outside of the "operating costs"
of the housing program. (Any
preparation of food off-site is
considered a supportive service.)
Do not use this response for a
daily meal program prepared onsite in a housing project. Provision
of food from non-housing
projects would be considered
"Supportive Services."

9/3/2019

145

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Response Category/ Data
Field
Dependency
Name
Type

Descriptions

8 Health/medical care
9 Life skills training
10 Mental health
care/counseling
11 Outreach and/or
engagement
12 Substance abuse
services/treatment
13 Transportation
14 Other HOPWA funded
service
W1 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All Clients
receiving
HOPWA
services

HUD:HOPWA

XML

CSV

1 Services
Emergency
Shelter
2Transitional
Housing
3 - PH Permanent
Supportive
Housing
6 - Services
Only
12 Homelessness
Prevention

Collection
Point
Occurrence

W2 Financial Assistance - HOPWA
FY2020 Revision Summary: None.

9/3/2019

146

W2 Data Element Fields and Responses
Field Number

1
2

Field Name

Dependency

Date of Financial None
Assistance
Financial
None
Assistance Type

Response Category/
Data Type
[Date]
1 Rental assistance
2 Security deposits
3 Utility deposits
4 Utility payments

3

Financial
Assistance
Amount

7 Mortgage assistance
[Currency/Decimal]

None

Descriptions

Collect for PHP and
STRMU and PH-TBRA
Collect for PHP
Collect for PHP
Collect for PHP and
STRMU
Collect for STRMU

W2 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

HOH Only

HUD:HOPWA

XML

CSV

6 - Services Services
Only
12 Homelessness
Prevention

Collection
Point
Occurrence

W3 Medical Assistance
FY2020 Revision Summary: None.
W3 Data Element Fields and Responses:
Field Number

1
2

9/3/2019

Field Name

Information Date
Receiving Public HIV/AIDS
Medical Assistance

Dependency
None
None

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

147

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field Name

Dependency

A

(if no) Reason

Field 2
Response 0

3

Receiving AIDS Drug
Assistance Program

None

B

(if no) Reason

Field 3
Response 0

9/3/2019

Response Category/
Descriptions
Data Type
1 Applied; decision
pending
2 Applied; client not
eligible
3 Client did not apply
4 Insurance type N/A
for this client
8 Client doesn't know
9 Client refused
99 Data not collected
0 No
1 Yes
8 Client doesn't know
9 Client refused
99 Data not collected
1 Applied; decision
pending
2 Applied; client not
eligible
3 Client did not apply
4 Insurance type N/A
for this client
8 Client doesn't know
9 Client refused

148

W3 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All Household HUD:HOPWA
members with
HIV/AIDS

1Emergency
Shelter
2Transitional
Housing
3 - PH Permanent
Supportive
Housing
6 - Services
Only
12 Homelessness
Prevention

Collection
Point
IncomeBenefits Project Start,
Update,
Project Exit
XML

CSV

W4 T-cell (CD4) and Viral Load
FY2020 Revision Summary: Renumbered dependencies.
W4 Data Element Fields and Responses:
Field Number

Field Name

Dependency

1

Information Date

None

2

T-Cell (CD4) Count
Available

None

A

(if yes) T-Cell Count Field 2
Response 1
How was the
Field 2
information obtained Response 1

B

9/3/2019

Response Category/
Descriptions
Data Type
[Date]
Date when
information was
collected
0 No
1 Yes
8 Client doesn't
know
9 Client refused
99 Data not collected
[Integer between 01500]
1 Medical Report
2 Client Report
3 Other

149

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field Name

3

Viral Load
Information
Available

C

Viral Load Count

D

Dependency
None

Field 3
Response 1
How was the
Field 3
information obtained Response 1

Response Category/
Data Type
0 Not Available
1 Available
2 Undetectable
8 Client doesn't
know
9 Client refused
99 Data not collected
[Integer between 0999999]
1 Medical report
2 Client report
3 Other

Descriptions

W4 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

Only Clients
HUD:HOPWA
funded in a
HOPWA project
presenting with
HIV/AIDS

9/3/2019

XML

1 - Emergency
Shelter
2 - Transitional
Housing
3 - PH Permanent
Supportive
Housing
6 - Services
Only
12 Homelessness
Prevention

CSV
Disabilities

Collection
Point
Project Start,
Update, Annual
Assessment,
Project Exit

150

W5 Housing Assessment at Exit
FY2020 Revision Summary: None.
W5 Data Element Fields and Responses:
Field Number Field Name

Dependency

1

Housing
Assessment
at Exit

None

A

Subsidy
Information

Field 1
Response 1

9/3/2019

Response Category/ Data
Descriptions
Type
1 Able to maintain the
housing they had at
project entry
2 Moved to new housing
unit
3 Moved in with
family/friends on a
temporary basis
4 Moved in with
family/friends on a
permanent basis
5 Moved to a transitional Includes transitional
or temporary housing housing for homeless and
facility or program
non-homeless persons,
treatment facilities, or
institutions.
6 Client became homeless
- moving to a shelter or
other place unfit for
human habitation
7 Client went to jail/prison
10 Client died
8 Client doesn't know
9 Client refused
99 Data not collected
1 Without a subsidy
2 With the subsidy they
had at project entry
3 With an ongoing subsidy
acquired since project
entry

151

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number Field Name

Dependency

B

Field 1
Response 2

Subsidy
Information

Response Category/ Data
Type
4 Only with financial
assistance other than a
subsidy
1 With ongoing subsidy
2 Without an ongoing
subsidy

Descriptions

W5 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All Clients

9/3/2019

HUD:HOPWA
HUD: ESG
Homeless
Prevention

XML

1 Exit
Emergency
Shelter
2Transitional
Housing
3 - PH Permanent
Supportive
Housing
6 - Services
Only
12 Homelessness
Prevention

CSV

Collection
Point
Project Exit

152

PATH
P1 Services Provided - PATH Funded
FY2020 Revision Summary: None.
P1 Data Element Fields and Responses:
Response Category/ Data
Field
Field Number
Dependency
Name
Type
1
Date of None
[Date]
Service
2
Type of None
1 Re-engagement
PATH
FUNDED
Service
Provided
2 Screening

Descriptions

The process of engaging with
PATH-enrolled individuals
who are disconnected from
PATH services.
An in-person process during
which a preliminary
evaluation is made to
determine a person’s needs
and how they can be
addressed through the PATH
Program.
14 Clinical assessment
A clinical determination of
psychosocial needs and
concerns.
3 Habilitation/rehabilitation Services that help a PATH
client learn or improve the
skills needed to function in a
variety of activities of daily
living.
4 Community mental health A range of mental health
and/or co-occurring services
and activities provided in
non-institutional settings to
facilitate an individual’s
recovery. Note: This category
does not include case
management, alcohol or
drug treatment, habilitation,
or rehabilitation, as they are
standalone services with
distinct definitions.

9/3/2019

153

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

9/3/2019

Field
Name

Dependency

Response Category/ Data
Descriptions
Type
5 Substance use treatment Preventive, diagnostic, and
other services and supports
provided for people who
have a psychological and/or
physical dependence on one
or more substances.
6 Case management
A collaboration between a
service recipient and
provider in which advocacy,
communication, and
resource management are
used to design and
implement a wellness plan
specific to a PATH-enrolled
individual’s recovery needs.
7 Residential supportive
Services that help PATHservices
enrolled individuals practice
the skills necessary to
maintain residence in the
least restrictive communitybased setting possible.
8 Housing minor renovation Services, resources, or small
repairs that ensure a housing
unit is physically accessible
and/or that health or safety
hazards have been mitigated
or eliminated.
9 Housing moving
Funds and other resources
assistance
provided on behalf of a
PATH- enrolled individual to
help establish that
individual’s household. Note:
This excludes security
deposits and one-time rental
payments, which have
specific definitions.
10 Housing eligibility
The process of determining
determination
whether an individual meets
financial and other
requirements to enter into
public or subsidized housing.
154

Field Number

Field
Name

Dependency

Response Category/ Data
Descriptions
Type
11 Security deposits
Funds provided on behalf of
a PATH-enrolled individual to
pay up to two months’ rent
or other security deposits in
order to secure housing.
12 One-time rent for eviction One-time payment on behalf
prevention
of PATH-enrolled individuals
who are at risk of eviction
without financial assistance.

P1 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

HOH and
Adults

HHS:PATH

4 - Street
Outreach
6 - Services
Only

XML

CSV

Services

Collection
Point
Occurrence

P2 Referrals Provided - PATH
FY2020 Revision Summary: None.
P2 Data Element Fields and Responses:
Field Number

1
2

9/3/2019

Field
Name

Response
Dependency Category/ Data
Type
None
[Date]

Date of
Referral
Type of None
Referral

1 Community
Mental
Health

Descriptions

Active and direct PATH staff support on
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that stabilizes, supports, or treats
people for mental health disorders or cooccurring mental health and substance
use disorders.

155

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

9/3/2019

Field
Name

Response
Dependency Category/ Data
Descriptions
Type
2 Substance
Active and direct PATH staff support on
Use
behalf of or in conjunction with a PATHTreatment
enrolled individual to connect to an
appropriate agency, organization, or
service that offers preventive, diagnostic,
and other services and supports for
individuals who have psychological
and/or physical problems with use of one
or more substances.
3 Primary
Active and direct PATH staff support on
Health/
behalf of or in conjunction with a PATHDental Care enrolled individual to connect to an
appropriate agency, organization, or
service that offers physical and/or dental
health care services.
4 Job Training Active and direct PATH staff support on
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that helps prepare an individual
to gain and maintain the skills necessary
for paid or volunteer work.
5 Educational Active and direct PATH staff support on
Services
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that offers academic instruction
and training.
6 Housing
Active and direct PATH staff support on
Services
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that offers assistance with
attaining and sustaining living
accommodations.

156

Field Number

A

9/3/2019

Response
Dependency Category/ Data
Descriptions
Type
11 Temporary Active and direct PATH staff support on
Housing
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that offers shelter in a timelimited setting.
7 Permanent Active and direct PATH staff support on
Housing
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that offers residence in a stable
setting where length of stay is
determined by the individual or family
without time limitations, as long as they
meet the basic requirements of tenancy.
8 Income
Active and direct PATH staff support on
Assistance
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that offers benefits that provide
financial support.
9 Employment Active and direct PATH staff support on
Assistance
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that offers assistance designed to
lead to compensated work.
10 Medical
Active and direct PATH staff support on
Insurance
behalf of or in conjunction with a PATHenrolled individual to connect to an
appropriate agency, organization, or
service that offers coverage that provides
payment for wellness or other services
needed as a result of sickness, injury, or
disability.
Outcome Field 2 &
1 Attained
‘Attained’ means the client was
Responses 1connected and received the service (if
11
the referral is for housing, it is not
attained until the housing placement
starts).
Field
Name

157

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field
Name

Response
Dependency Category/ Data
Descriptions
Type
2 Not Attained ‘Not Attained’ means the client was
referred to, but may not have ever been
connected with, the service or did not
actually receive the service.
3 Unknown
‘Unknown’ means the status of the
client’s connection or receipt of service is
unknown to the provider entering the
data.

P2 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

HOH and
Adults

HHS:PATH

4 - Street
Outreach
6 - Services
Only

XML

CSV

Services

Collection
Point
Occurrence

P3 PATH Status
FY2020 Revision Summary: Add response to Dependent A “Unable to locate client.”
P3 Data Element Fields and Responses:
Field Number

1

9/3/2019

Response
Dependency Category/
Data Type
Date of Status None
[Date]
Determination
Field Name

Descriptions

158

Field Number

2

A

9/3/2019

Response
Dependency Category/
Descriptions
Data Type
Client Became None
0 No
Enrolled in
1 Yes
An enrollment date is the date when a
PATH
PATH-eligible individual and a PATH
provider have mutually and formally
agreed to engage in services and the
provider has initiated an individual file
or record for that individual. The date
of PATH enrollment should be entered
into the HMIS at the point that the
client has become enrolled, using the
PATH Status element (P3). It may be
on or after the project start date or
engagement date and prior to project
exit. If the client exits without
becoming enrolled, the PATH Status
element (P3) needs to be completed,
indicating that the client was not
enrolled and the reason the client was
not enrolled. If the client was
contacted on the date that PATH
Status was determined, a contact
must also be entered for that date.
Reason Not
Field 2 &
1 Client was
Enrolled
Response 0
found
ineligible
for PATH
2 Client was
not
enrolled for
other
reason(s)
3 Unable to
locate
client
Field Name

159

4. PROGRAM SPECIFIC DATA ELEMENTS
P3 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

HHS:PATH

4 - Street
Outreach
6 - Services
Only

XML

CSV

Enrollment

Collection
Point
Occurrence

P4 Connection with SOAR
FY2020 Revision Summary: None.
P4 Data Element Fields and Responses:
Field Number
Field Name
Dependency Response Category/ Data Type Descriptions
1
Connection with SOAR None
0 No
1 Yes
8 Client doesn't know
9 Client refused
99 Data not collected
P4 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

HOH and
Adults

9/3/2019

HHS:PATH
VA:SSVF collection
required only
for RRH & HP

XML

4 - Street
Exit
Outreach
6 - Services
Only
12 Homelessness
Prevention
13 - PH Rapid ReHousing

CSV

Collection
Point
Project Start,
Update,
Annual
Assessment,
Project Exit

160

RHY
R1 Referral Source
FY2020 Revision Summary: None.
R1 Data Element Fields and Responses:
Field Number
Field Name
Dependency Response Category/ Data Type
1
Referral Source
None
1 Self-Referral
2 Individual:
Parent/Guardian/Relative/
Friend/Foster Parent/ Other
Individual
7 Outreach Project
11 Temporary Shelter
18 Residential Project
28 Hotline
30 Child Welfare/ CPS
34 Juvenile Justice
35 Law Enforcement / Police
37 Mental Hospital
38 School
39 Other Organization
8 Client doesn't know
9 Client refused
99 Data not collected
A
Number of times Field 1 &
[Integer]
approached by
Response 7
Outreach prior to
entering project

9/3/2019

Descriptions

161

4. PROGRAM SPECIFIC DATA ELEMENTS
R1 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing
12 Homelessness
Prevention

CSV
Enrollment

Collection
Point
Project Start

R2 RHY - BCP Status
FY2020 Revision Summary: None.
R2 Data Element Fields and Responses:
Field Number

1
2
A

9/3/2019

Field Name

Dependency

Date of Status
None
Determination
Youth Eligible for None
RHY Services

Response Category/
Data Type
[Date]

Descriptions

0 No
1 Yes
Reason by
Field 2
1 Out of age range Refers to youth who have
services are not Response 0
reached the age of 18 and are
funded by BCP
thereby ineligible for Basic
grant
Center Program shelter per
RHY program regulations
2 Ward of the State Pertains to youth who are
currently the responsibility of
child welfare or foster care
services

162

Field Number

B

Field Name

Runaway Youth

Response Category/
Descriptions
Data Type
3 Ward of the
Defines youth who are
Criminal Justice currently under a court order
System to attend a residential
Immediate
juvenile facility
Reunification
4 Other
Youth who are not eligible for
Basic Center Program shelter
services for reasons not
covered by other responses
Field 2
0 No
Response 1 1 Yes
An individual under 18 years
of age who absents himself or
herself from home or place of
legal residence without the
permission of a parent or
legal guardian. 42 U.S.C.
§5701 et seq.
8 Client doesn't
know
9 Client refused
99 Data Not
Collected
Dependency

R2 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

All Clients

9/3/2019

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)

XML

1 - Emergency
Shelter
12 Homelessness
Prevention

CSV
Enrollment

Collection
Point
Project Start

163

4. PROGRAM SPECIFIC DATA ELEMENTS
R3 Sexual Orientation
FY2020 Revision Summary: Added response option: “other” and text field. Added HUD: CoC –
Youth Homeless Demonstration Program (YHDP) – collection required for all components.
R3 Data Element Fields and Responses:
Field Number Field Name Dependency Response Category/ Data Type
1
Sexual
None
1
Heterosexual
Orientation
2
Gay
3
Lesbian
4
Bisexual
5
Questioning/Unsure
6
Other
8
Client doesn't know
9
Client refused
99
Data not collected
If other,
[text]
Field 1
A
please
Response 6
describe

9/3/2019

Descriptions

164

R3 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

Head of
22 - HHS:RHY –
Household and Basic Center
Adults
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
25 - HHS:RHY Street
Outreach
Project
26 - HHS:RHY –
Demonstration
Project
43 – HUD: CoC
– Youth
Homeless
Demonstration
Program

XML

1 - Emergency
Shelter
2 - Transitional
Housing
3 – PHPermanent
Supportive
Housing
4 - Street
Outreach
9 – PH-Housing
Only
10 – PHHousing with
Services
12 Homelessness
Prevention
13 – PH-Rapid
Re-housing

CSV
Enrollment

Collection
Point
Project Start

R4 Last Grade Completed
FY2020 Revision Summary: None.
R4 Data Element Fields and Responses:
Field Number
Field Name
Dependency
1
Last Grade
None
1
Completed
2
3
4
5

9/3/2019

Response Category/ Data Type
Less than Grade 5
Grades 5-6
Grades 7-8
Grades 9-11
Grade 12/High school diploma

Descriptions

165

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field Name

Dependency

Response Category/ Data Type
6 School program does not have
grade levels
7 GED
10 Some college
11 Associate's degree
12 Bachelor's degree
13 Graduate degree
14 Vocational Certification
8 Client doesn't know
9 Client refused
99 Data not collected

Descriptions

R4 Specifications:
Data Funder/Program Project Type
Collecte Component
Applicability
d About

HOH
and
Adults

XML

CSV

20 1
n
H
Shelter
22 - HHS:RHY – 2 Basic Center
Transitional
Program
Housing
(prevention and 3 - PH shelter)
Permanent
23 - HHS:RHY – Supportive
Maternity
Housing
Group Home 12 for Pregnant
Homelessnes
and Parenting s Prevention
Youth
13 - PHRapid
Rehousing

9/3/2019

Collectio
n Point
Project
Start,
Project
Exit

166

Data Funder/Program Project Type
Collecte Component
Applicability
d About

XML

CSV

Collectio
n Point

24 - HHS:RHY –
Transitional
Living Program
25 - HHS:RHY Street Outreach
Project
26 - HHS:RHY –
Demonstration
Project
33 - VA:SSVFcollection
required only
for RRH & HP
R5 School Status
FY2020 Revision Summary: None.
R5 Data Element Fields and Responses:
Response
Field
Field Number
Dependency Category/ Data
Descriptions
Name
Type
1
School None
1 Attending
The youth is enrolled in an educational
Status
school regularly program and attends classes regularly,
without extended absenteeism.
2 Attending
The youth is enrolled in an educational
school
program and attends classes 1-3 days per
irregularly
week on average.
3 Graduated from The youth has earned a high school
high school
diploma.
4 Obtained GED The youth has earned a GED.
5 Dropped out
The youth has formally withdrawn from
school prior to completing the course of
study.
6 Suspended
The youth has been temporarily removed
from school through official school
action.

9/3/2019

167

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Response

Field
Dependency Category/ Data
Name

Type
7 Expelled

8 Client doesn't
know
9 Client refused

Descriptions
The youth has been permanently
removed from school through official
school action.
The client did not know about their
school status.
The client refused to answer the
question.

99 Data not
collected
R5 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

HOH and
Adults

9/3/2019

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

1Emergency
Shelter
2Transitional
Housing
12 Homelessness
Prevention

Collection
Point
EmploymentEducation Project
Start,
Project Exit
XML

CSV

168

R6 Employment Status
FY2020 Revision Summary: Added GPD: All components.
R6 Data Element Fields and Responses:
Response
Field Number Field Name Dependency Category/
Data Type
1
Information None
[Date]
Date
2
Employed
None
0 No
1 Yes
A
Type of
Field 2
1 Full-time
Employment Response 1 2 Part-time
B
Why Not
Field 2
1 Looking for
Employed
Response 0
work
2 Unable to
work

Descriptions

Youth is employed full-time.
Youth is employed part-time.
Youth is not employed and is actively
looking for work.
Youth is not employed because he or
she is unable to work due to a physical
disability, a developmental disability, or
an illness.
3 Not looking Youth is not employed and is not
for work
looking for employment. This would
include persons who are not looking for
work because of full-time education,
under-age, etc.

R6 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

9/3/2019

20 1HUD:HUD/VASH Emergency
22 - HHS:RHY – Shelter
Basic Center
2Program
Transitional
(prevention and Housing
shelter)
23 - HHS:RHY –
Maternity
Group Home for
Pregnant and
Parenting Youth

XML

CSV

Collection
Point
EmploymentEducation Project
Start,
Project Exit

169

4. PROGRAM SPECIFIC DATA ELEMENTS
Data Collected Funder/Program Project Type
About
Component
Applicability

XML

CSV

Collection
Point

24 - HHS:RHY –
Transitional
12 Living Program Homelessness
25 - HHS:RHY - Prevention
Street Outreach 13 - PH Project
Rapid Re26 - HHS:RHY – Housing
Demonstration 9- -PH –
Project
Housing Only
33 - VA:SSVF- 8 - Safe
collection
Haven
required only
for RRH & HP
VA: GPD – all
components
R7 General Health Status
FY2020 Revision Summary: None.
R7 Data Element Fields and Responses:
Field Number
Field Name
Dependency Response Category/ Data Type Descriptions
1
General Health Status None
1 Excellent
2 Very Good
3 Good
4 Fair
5 Poor
8 Client doesn't know
9 Client refused
99 Data not collected

9/3/2019

170

R7 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

XML

CSV

Collection
Point
20 1 - Emergency HealthAndDV Project Start,
HUD:HUD/VASH Shelter
Project Exit
22 - HHS:RHY – 2 - Transitional
Basic Center
Housing
Program
12 (prevention and Homelessness
shelter)
Prevention
23 - HHS:RHY –
Maternity
Group Home for
Pregnant and
Parenting Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

R8 Dental Health Status
FY2020 Revision Summary: None.
R8 Data Element Fields and Responses:
Field Number
Field Name
Dependency Response Category/ Data Type Descriptions
1
Dental Health Status None
1 Excellent
2 Very Good
3 Good
4 Fair
5 Poor
8 Client doesn't know
9 Client refused
99 Data not collected

9/3/2019

171

4. PROGRAM SPECIFIC DATA ELEMENTS
R8 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

XML

CSV

Collection
Point
20 1 - Emergency HealthAndDV Project Start,
HUD:HUD/VASH Shelter
Project Exit
22 - HHS:RHY – 2 - Transitional
Basic Center
Housing
Program
12 (prevention and Homelessness
shelter)
Prevention
23 - HHS:RHY –
Maternity
Group Home for
Pregnant and
Parenting Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

R9 Mental Health Status
FY2020 Revision Summary: None.
R9 Data Element Fields and Responses:
Field Number
Field Name
Dependency Response Category/ Data Type Descriptions
1
Mental Health Status None
1 Excellent
2 Very Good
3 Good
4 Fair
5 Poor
8 Client doesn't know
9 Client refused
99 Data not collected

9/3/2019

172

R9 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

XML

CSV

Collection
Point
20 1 - Emergency HealthAndDV Project Start,
HUD:HUD/VASH Shelter
Project Exit
22 - HHS:RHY – 2 - Transitional
Basic Center
Housing
Program
12 (prevention and Homelessness
shelter)
Prevention
23 - HHS:RHY –
Maternity
Group Home for
Pregnant and
Parenting Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

R10 Pregnancy Status
FY2020 Revision Summary: Clarified system logic that female HOH, regardless of age, should
have pregnancy status recorded.
R10 Data Element Fields and Responses:
Field Number
Field Name
Dependency
1

Pregnancy
Status

A

Due Date

9/3/2019

Response Category/ Data
Type
None
0 No
1 Yes
8 Client doesn't know
9 Client refused
99 Data not collected
Field 2 & Response [Date]
1

Descriptions

173

4. PROGRAM SPECIFIC DATA ELEMENTS
R10 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

Female HOH
and Female
Adults

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
25 - HHS:RHY Street
Outreach
Project
26 - HHS:RHY –
Demonstration
Project

XML

CSV

1 - Emergency HealthAndDV
Shelter
2 - Transitional
Housing
4 - Street
Outreach
12 Homelessness
Prevention

Collection
Point
Project Start,
Update

R11 Formerly a Ward of Child Welfare/Foster Care Agency
FY2020 Revision Summary: None.
R11 Data Element Fields and Responses:
Field Number

1

9/3/2019

Field Name

Formerly a Ward of Child
Welfare/Foster Care Agency

Dependency

None

Response
Descriptions
Category/ Data
Type
0 No
1 Yes
8 Client doesn't
know
9 Client refused
99 Data not
collected

174

Field Number

Field Name

Dependency

A

Number of Years

Field 1 &
Response 1

B

Number of Months (1-11)

Dependent A &
Response 1

Response
Descriptions
Category/ Data
Type
1 Less than one
year
2 1 to 2 years
3 3 to 5 years
[Integer 1-11]

R11 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing
12 Homelessness
Prevention

CSV
Enrollment

Collection
Point
Project Start

R12 Formerly a Ward of Juvenile Justice System
FY2020 Revision Summary: None.
R12 Data Element Fields and Responses:
Field Number

1

9/3/2019

Field Name

Formerly a Ward of
Juvenile Justice System

Dependency
None

Response Category/ Descriptions
Data Type
0 No
1 Yes
8 Client doesn't
know

175

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

A

B

Field Name

Dependency

Response Category/ Descriptions
Data Type
9 Client refused
99 Data not collected
Number of Years
Field 1 & Response 1 Less than one year
1
2 1 to 2 years
3 3 to 5 years
Number of Months (1-11) Dependent A &
[Integer 1-11]
Response 1

R12 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

9/3/2019

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing
12 Homelessness
Prevention

CSV
Enrollment

Collection
Point
Project Start

176

R13 Family Critical Issues
FY2020 Revision Summary: None.
R13 Data Element Fields and Responses:
Field Number
Field Name
Dependency Response
Descriptions
Category/
Data Type
9
Unemployment None
0 No
Issues associated with the
Family member
inability to of an adult member in
the youth’s family to find and
secure steady employment.
1 Yes
11
Mental health Issues None
0 No
Issues related to a family
- Family member
member’s mental health status.
1 Yes
15
Physical Disability - None
0 No
Issues related to a family
Family member
member’s physical disability or
impairment.
1 Yes
21
Alcohol or Substance None
0 No
Any misuse of alcohol, or legal or
- Family member
illegal drugs within the
household.
1 Yes
22
Insufficient Income None
0 No
Issues related to insufficient
to support youth incomes of the parents/legal
Family member
guardians to support the basic
needs of the youth (e.g., food,
clothing, and shelter).
1 Yes
24
Incarcerated Parent None
0 No
Issues related to the
of Youth
incarceration of a parent or legal
guardian.
1 Yes

9/3/2019

177

4. PROGRAM SPECIFIC DATA ELEMENTS
R13 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing
12 Homelessness
Prevention

CSV
Enrollment

Collection
Point
Project Start

R14 RHY Service Connections
FY2020 Revision Summary: None.
R14 Data Element Fields and Responses:
Field Number Field Dependency
Response
BCP- BCP- TLP DEMO
Descriptions
Name
Category/ Data
p es &
Type
MGH
1
Date of None
[Date]
x
x
x
x
Service
2
Type None
2 Community
x
x
Activities that
of RHY
service/service
involve youth in
Service
learning (CSL)
helping others or
the community.
7 Criminal justice x
x
x
x
Legal services or
/legal services
guidance provided
through an
attorney or an
attorney-supervised
paralegal.

9/3/2019

178

Field Number Field Dependency
Response
BCP- BCP- TLP DEMO
Name
Category/ Data
p es &

Type
5 Education

x

x

6 Employment
and/or training
services

14 Health/medical x
care

26 Home-based
services

9/3/2019

x

x

MGH
x
x

x

x

x

x

Descriptions

Includes learning
disability
assessment,
tutoring, GED
preparation, local
school enrollment,
vocational
education, etc.
Includes services
related to helping
young people
obtain and retain
employment, such
as assessment,
coaching, filling out
applications,
interviewing,
practicing and
conducting job
searches, referrals,
and job
maintenance skills.
Provision of general
health care or
surgical services by
licensed medical
practitioners.
Includes any range
of services offered
at home, usually
aimed at keeping a
youth from running
away or the family
stabilized.

179

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number Field Dependency
Response
BCP- BCP- TLP DEMO
Name
Category/ Data
p es &

Type
8 Life skills
training

x

x

MGH
x
x

x

x

x

x

27 Post-natal
newborn care
(wellness
exams;
immunizations)

x

x

12 Post-natal care
for mother

x

x

13 Pre-natal care

x

x

10 Parenting
education for
youth with
children

9/3/2019

Descriptions

Includes formal and
informal coaching
and training in
communications
skills, health
promotion,
conflict/anger
management,
assertiveness, goal
setting, budgeting,
life planning,
nutrition, hygiene,
etc.
Services designed
to build improved
parenting skills for
RHY clients with
children.
Services and
healthcare
provided to the
baby after birth,
including wellness
exams and
immunizations.
Services and
healthcare
provided to the
mother after birth,
including wellness
exams and
immunizations.
Services and
healthcare
provided to
expectant clients to
ensure a healthy
pregnancy, labor,
and delivery.

180

Field Number Field Dependency
Response
BCP- BCP- TLP DEMO
Name
Category/ Data
p es &

Type
28 STD Testing

9/3/2019

Descriptions

MGH

x

x

29 Street-based
services

x

17 Substance
abuse
treatment

x

x

x

x

18 Substance
x
Abuse
Ed/Prevention
services

x

x

x

Procedures to test
for a range of
Sexually
Transmitted
Infections (STIs)
Services provided
to youth on the
street, including
gateway services,
assessment, harm
reduction, crisis
stabilization, and
continuum service
linkages.
Any research-based
youth treatment
service aimed at
stopping substance
use disorders and
related problems.
Comprehensive
assessment of an
individual’s current
or past involvement
with alcohol and/or
drugs and/or
provision of
treatment,
including screening,
aimed at stopping
their substance
abuse.

181

4. PROGRAM SPECIFIC DATA ELEMENTS
R14 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

HOH and
Adults

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

CSV

1 Services
Emergency
Shelter
2Transitional
Housing
Services Only
12 Homelessness
Prevention

Collection
Point
Occurrence

R15 Commercial Sexual Exploitation/Sex Trafficking
FY2020 Revision Summary: None.
R15 Data Element Fields and Responses:
Field Number

1

9/3/2019

Field Name

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

Dependency

None

Response
Descriptions
Category/
Data Type
0 No
Preferred language:
“Have you ever received
anything in exchange for
having sexual relations
with another person, such
as money, food, drugs, or
shelter?”
1 Yes
8 Client
doesn't
know
9 Client
refused
182

Field Number

Field Name

Dependency

A

In the last three months?

Field 1 &
Response 1

B

How many times?

Field 1 &
Response 1

9/3/2019

Response
Descriptions
Category/
Data Type
99 Data not
collected
0 No
Preferred language:
If they say “yes” to the
first question above, then
ask “Has it been in the
past three months?”
1 Yes
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
1 1-3
Preferred language:
Also if they say "yes" to
the first question above,
ask “How many times
have you received
something in exchange
for having sexual relations
with another person, such
as money, food, drugs, or
shelter?”
2 4-7
3 8-11
4 12 or
more
8 Client
doesn't
know
9 Client
refused
99 Data not
collected

183

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

C

D

9/3/2019

Field Name

Dependency

Response
Descriptions
Category/
Data Type
Ever
Field 1 &
0 No
Preferred language:
made/persuaded/forced to Response 1
Also if they say "yes" to
have sex in exchange for
the first question above,
something?
ask “Did someone ever
make you or persuade
you to have sex with
anyone else in exchange
for something, such as
money, food, drugs or
shelter?”
1 Yes
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
In the last three months? Dependent C 0 No
Preferred language:
& Response 1
If they say “yes” to the
question immediately
above, then ask “Has it
been in the past three
months?”
1 Yes
8 Client
doesn't
know
9 Client
refused
99 Data not
collected

184

R15 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
25 - HHS:RHY Street
Outreach
Project
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing
4 - Street
Outreach
12 Homelessness
Prevention

CSV
Exit

Collection
Point
Project Exit

R16 Labor Exploitation/Trafficking
FY2020 Revision Summary: None.
R16 Data Element Fields and Responses:
Field Number
Field Name
Dependency

1

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

Response
Category/
Data Type
0 No

Descriptions

Preferred language:
“Have you ever been afraid to
leave or quit a work situation
due to fears of violence or
other threats of harm to
yourself, family or friends?”

1 Yes

9/3/2019

185

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

2

A

B

9/3/2019

Field Name

Dependency

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

Felt forced, coerced,
pressured, or tricked
into continuing the
job?

Field 1 &
Response 1
Field 2 &
Response 2

In the last 3 months? Field 1 &
Response 1
Field 2 &
Response 2

Response
Category/
Data Type
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
0 No

1 Yes
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
0 No

1 Yes
8 Client
doesn't
know
9 Client
refused
99 Data not
collected
0 No

Descriptions

Preferred language:
“Have you ever been promised
work where the work or
payment ended up being
different from what you
expected?”

Preferred language:
“Did you feel forced, pressured
or tricked into continuing this
job?”

Preferred language:
“Have you had any jobs like
these in the last 3 months?”

1 Yes

186

Field Number

Field Name

Dependency

Response
Category/
Data Type
8 Client
doesn't
know
9 Client
refused
99 Data not
collected

Descriptions

R16 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

9/3/2019

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
25 - HHS:RHY Street
Outreach
Project
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing
4 - Street
Outreach
12 Homelessness
Prevention

CSV
Exit

Collection
Point
Project Exit

187

4. PROGRAM SPECIFIC DATA ELEMENTS
R17 Project Completion Status
FY2020 Revision Summary: None.
R17 Data Element Fields and Responses:
Field Number Field Name Dependency Response Category/ Data
Descriptions
Type
1
Project
None
1 Completed project
The youth completed the
Completion
project.
Status
2 Youth voluntarily left
The youth voluntarily
early
terminated from the
project to pursue other
opportunities. These
could include: a safe
appropriate independent
living situation an
educational or vocational
opportunity; military
service or any other
positive disposition.
3 Youth was expelled or The youth was
otherwise involuntarily involuntarily terminated
discharged from project from the project with no
plan or invitation to
return.
A
If Youth was
Field 1 &
1 Criminal
Youth left for displaying
expelled or
Response 3 activity/destruction of behavior that was a threat
otherwise
property/violence
to safety to themselves,
involuntarily
others, or property.
discharged
2 Non-compliance with
Youth refused to follow
from project,
project rules
program rules or
Select the
participate in activities as
major reason
outlined in their plan.
3 Non-payment of
Youth failed to make full
rent/occupancy charge or partial payments for
their accommodations per
rental or lease
agreement.

9/3/2019

188

Field Number

9/3/2019

Field Name

Dependency Response Category/ Data
Descriptions
Type
4 Reached maximum time Youth reached maximum
allowed by project
time allowed by the
project without
completing goals as out
lined in their goal plan.
5 Project terminated
Youth required to exit the
project prematurely as a
result of a closure of the
program or facility.
6 Unknown/disappeared Youth was exited from the
project after absenting
themselves without
developing an exit plan or
providing notification of
destination.
Note: A youth who is
exited from a program
because of their
disappearance without
advanced planning or
notice, should be
accurately reflected in
Data Element 3.12
Destination, as "No exit
interview.”

189

4. PROGRAM SPECIFIC DATA ELEMENTS
R17 Specifications:
Data
Funder/Program Project Type
Collected
Component Applicability
About

HOH and
Adults

23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

CSV Collection
Point

1 Exit Project Exit
Emergency
Shelter
2Transitional
Housing
12 Homelessness
Prevention

R18 Counseling
FY2020 Revision Summary: None.
R18 Data Element Fields and Responses:
Field Number

1
A

B
2

3

9/3/2019

Field Name

Dependency Response Category/ Descriptions
Data Type
Counseling received by client
None
0 No
1 Yes
Identify the type(s) of
Field 1 &
1 Individual
counseling received
Response 1
2 Family
3 Group - including
peer counseling
Identify the number of sessions Field 1 &
[Integer 1-48+]
received by exit
Response 1
Total number of sessions
None
[Integer 1-48+]
planned in youth's treatment or
service plan
A plan is in place to start or
None
0 No
continue counseling after exit
1 Yes

190

R18 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing
12 Homelessness
Prevention

CSV
Exit

Collection
Point
Project Exit

R19 Safe and Appropriate Exit
FY2020 Revision Summary: None.
R19 Data Element Fields and Responses:
Field Number

Field Name

Dependency

1

Exit destination safe - as determined None
by the client

2

Exit destination safe - as determined None
by the project/caseworker

9/3/2019

Response
Descriptions
Category/ Data
Type
0 No
1 Yes
8 Client doesn't
know
9 Client refused
99 Data not
collected
0 No
1 Yes
2 Worker does
not know

191

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field Name

Dependency

3

Client has permanent positive adult
connections outside of project

None

4

Client has permanent positive peer
connections outside of project

None

5

Client has permanent positive
community connections outside of
project

None

Response
Descriptions
Category/ Data
Type
0 No
1 Yes
2 Worker does
not know
0 No
1 Yes
2 Worker does
not know
0 No
1 Yes
2 Worker does
not know

R19 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

9/3/2019

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
Housing

CSV
Exit

Collection
Point
Project Exit

192

R20 Aftercare Plans
FY2020 Revision Summary: None.
R20 Data Element Fields and Responses:
Field Number

Field Name

Dependency

1
2

Information Date
Aftercare was provided

None
None

A

Identify the primary way it Field 2 &
was provided
Response 1

Response Category/ Descriptions
Data Type
[Date]
0
No
1
Yes
9
Client refused
1
Via email/social
media
2
Via telephone
3
In person: one-onone
4
In person: group

R20 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH and
Adults

9/3/2019

22 - HHS:RHY –
Basic Center
Program
(prevention
and shelter)
23 - HHS:RHY –
Maternity
Group Home
for Pregnant
and Parenting
Youth
24 - HHS:RHY –
Transitional
Living Program
26 - HHS:RHY –
Demonstration
Project

XML

1 - Emergency
Shelter
2 - Transitional
housing
12 Homelessness
Prevention

CSV
Exit

Collection
Point
Project Exit

193

4. PROGRAM SPECIFIC DATA ELEMENTS
RHSAP
U1 Worst Housing Situation
FY2020 Revision Summary: None.
U1 Data Element Fields and Responses:
Field Number
Field Name
Dependency Response Category/ Data Type Descriptions
1
Worst Housing Situation None
0 No
1 Yes
8 Client doesn't know
9 Client refused
99 Data not collected
U1 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

All Clients

HUD:RHSAP

XML

CSV
Enrollment

Collection
Point
Project Start

VA
V1 Veteran’s Information
FY2020 Revision Summary: None.
V1 Data Element Fields and Responses:
Field Number

1
2
3

4

9/3/2019

Field Name

Year Entered Military
Service
Year Separated from
Military Service
Theatre of Operations:
World War II

Theatre of Operations:
Korean War

Dependency Response Category/ Data Descriptions
Type
None
[Integer
YYYY]
None
[Integer
YYYY]
None
0
No
1
Yes
8
Client doesn't know
9
Client refused
99
Data not collected
None
0
No
1
Yes
8
Client doesn't know

194

Field Number

5

6

7

8

9

10

11

9/3/2019

Field Name

Dependency Response Category/ Data Descriptions
Type
9
Client refused
99
Data not collected
Theatre of Operations:
None
0
No
Vietnam War
1
Yes
8
Client doesn't know
9
Client refused
99
Data not collected
Theatre of Operations:
None
0
No
Persian Gulf War
1
Yes
(Operation Desert Storm)
8
Client doesn't know
9
Client refused
99
Data not collected
Theatre of Operations:
None
0
No
Afghanistan (Operation
1
Yes
Enduring Freedom)
8
Client doesn't know
9
Client refused
99
Data not collected
Theatre of Operations: Iraq None
0
No
(Operation Iraqi Freedom)
1
Yes
8
Client doesn't know
9
Client refused
99
Data not collected
Theatre of Operations: Iraq None
0
No
(Operation New Dawn)
1
Yes
8
Client doesn't know
9
Client refused
99
Data not collected
Theatre of Operations:
None
0
No
Other Peace-keeping
1
Yes
Operations or Military
8
Client doesn't know
Interventions (such as
9
Client refused
Lebanon, Panama, Somalia,
99
Data not collected
Bosnia, Kosovo)
Branch of the Military

None

1
2
3
4

Army
Air Force
Navy
Marines
195

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

12

9/3/2019

Field Name

Discharge Status

Dependency Response Category/ Data Descriptions
Type
6
Coast Guard
8
Client doesn't know
9
Client refused
99
Data not collected
None
1
Honorable
2
General under
honorable
conditions
6
Under other than
honorable
conditions (OTH)
4
Bad conduct
5
Dishonorable
7
Uncharacterized
8
Client doesn't know
9
Client refused
99
Data not collected

196

V1 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All Veterans

XML

CSV

20 - HUD:
1 Client
HUD/VASH
Emergency
27 - VA: CRS
Shelter
Contract
2Residential
Transitional
Services
Housing
33 - VA: SSVF- 3 - PHcollection
Permanent
required only Supportive
for RRH & HP Housing
VA: GPD – all 8 - Safe
components Haven
30 - VA:
10 - PH Community
Housing Only
Contract Safe 12 Haven Program Homelessness
Prevention
13 - PH Rapid ReHousing

Collection
Point
Record
Creation

V2 Services Provided - SSVF
FY2020 Revision Summary: Add Rapid Resolution, Extended Shallow Subsidy, and Returning
Home as response options for Type of Service.
V2 Data Element Fields and Responses:
Field Number
Field Name
Dependency
1
2

9/3/2019

Date of Service
Type of Service

None
None

Response Category/ Data Descriptions
Type
[Date]
1
Outreach services
2
Case management
services
3
Assistance obtaining VA
benefits
4
Assistance
obtaining/coordinating
other public benefits

197

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

A

B

9/3/2019

Field Name

Dependency

Response Category/ Data Descriptions
Type
5
Direct provision of other
public benefits
6
Other (non TFA)
supportive service
approved by VA
7
Extended Shallow
Subsidy
8
Returning Home
9
Rapid Resolution
If "Assistance obtaining Field 2 &
1
VA vocational and
VA Benefits"
Response 3
rehabilitation
counseling
2
Employment and
training services
3
Educational assistance
4
Health care services
If "Assistance
Field 2 &
1
Health care services
obtaining/coordinating Response 4 2
Daily living services
other public benefits"
3
Personal financial
planning services
4
Transportation services
5
Income support services
6
Fiduciary and
representative payee
services
7
Legal services - child
support
8
Legal services - eviction
prevention
9
Legal services outstanding fines and
penalties
10
Legal services restore/acquire driver's
license
11
Legal services - other
12
Child care
13
Housing counseling

198

Field Number

Field Name

Dependency

C

If "Direct provision of
other public benefits"

D

If "Other (non TFA)
Supportive Service
approved by VA"

Response Category/ Data Descriptions
Type
Field 2 &
1
Personal financial
Response 5
planning services
2
Transportation services
3
Income support services
4
Fiduciary and
representative payee
services
5
Legal services - child
support
6
Legal services - eviction
prevention
7
Legal services outstanding fines and
penalties
8
Legal services restore/acquire driver's
license
9
Legal services - other
10
Child care
11
Housing counseling
Field 2 &
[Text]
Response 6

V2 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All Clients
33 - VA: SSVFreceiving SSVF collection
Services
required only
for RRH & HP
Optional for all
other VA

XML

CSV

12 Services
Homelessness
Prevention
13- PH - Rapid
Re-housing

Collection
Point
Occurrence

V3 Financial Assistance - SSVF
FY2020 Revision Summary: Added “Extended Shallow Subsidy – rental assistance” as response
option for “Financial Assistance Type.”

9/3/2019

199

4. PROGRAM SPECIFIC DATA ELEMENTS
V3 Data Element Fields and Responses:
Field Number
Field Name
Dependency
Response Category/ Data Type
Descriptions
1
Date of Financial None
[Date]
Assistance
2
Financial
None
[Date]
Assistance
Amount
3
Financial
None
1
Rental assistance
Assistance Type
4
Utility fee payment assistance
2
Security deposit
3
Utility deposit
5
Moving costs
8
Transportation services:
token/vouchers
9
Transportation services: vehicle
repair/maintenance
10
Child care
11
General housing stability
assistance - emergency supplies
12
General housing stability
assistance - other
14
Emergency housing assistance
15
Extended Shallow Subsidy Rental Assistance
V3 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All Clients
33 - VA: SSVF receiving SSVF collection
Financial
required only
Assistance
for RRH & HP

XML

CSV

12 Services
Homelessness
Prevention
13- PH - Rapid
Re-housing

Collection
Point
Occurrence

V4 Percent of AMI (SSVF Eligibility)
FY2020 Revision Summary: None.

9/3/2019

200

V4 Data Element Fields and Responses:
Field Number

1

Field Name

Household Income as a
percentage of AMI

Dependency Response Category/ Descriptions
Data Type
None
1 Less than 30%
2 30% to 50%
3 Greater than 50%

V4 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH

33 - VA: SSVFcollection
required only
for RRH & HP

XML

12
Homelessness
Prevention
13- PH - Rapid
Re-housing

CSV
Enrollment

Collection
Point
Project Start

V5 Last Permanent Address
FY2020 Revision Summary: None.
V5 Data Element Fields and Responses:
Field Number Field Dependency Response Category/
Descriptions
Name
Data Type
1
Street
None
[Text]
This should never be the address of a
Address
shelter or a reference to a location
like the streets or a park – it should
be the address where the client was
last in housing that might be
categorized as permanent, such as:
• An apartment or house rented by
the client, with or without a subsidy;
• A home owned or rented by
someone else (e.g., the client’s
parents, a friend, etc.) where the
client lived.
2
City
None
[Text]
3
State
None
[Text]
4
Zip Code None
[Text]
5
Address None
1
Full address
Data
reported

9/3/2019

201

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

Field
Name

Quality

Dependency Response Category/
Data Type
2
Incomplete or
estimated
address
reported
8
Client doesn't
know
9
Client refused
99 Data not
collected

Descriptions

V5 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH

XML

20 3 - PH
HUD:HUD/VASH Permanent
33 - VA: SSVF- Supportive
collection
Housing
required only 12 for RRH & HP Homelessness
Prevention
13- PH - Rapid
Re-housing

CSV
Enrollment

Collection
Point
Project Start

V6 VAMC Station Number
FY2020 Revision Summary: Added VA: GPD, VA: CRS Contract Residential Services and VA:
Community Contract Safe Haven Programs
V6 Data Element Fields and Responses:
Field Number Field Name Dependency Response Category/
Descriptions
Data Type
1
VAMC
None
[Drop down list of all VAMC Station Codes and Names
Station
VAMC Station codes can be found in the CSV
Number
and names]
Specification Document

9/3/2019

202

V6 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH

XML

20 1 – Emergency
HUD:HUD/VASH Shelter
33 - VA: SSVF- 2 – Transitional
collection
Housing
required only 3 - PH for RRH & HP Permanent
VA: GPD
Supportive
27 - VA: CRS
Housing
Contract
6 – Services
Residential
Only
Services
8 – Safe Haven
30 - VA:
9 – PH-Housing
Community
Only
Contract Safe 12 Haven Program Homelessness
Prevention
13- PH - Rapid
Re-housing

CSV
Enrollment

Collection
Point
Project Start

V7 SSVF HP Targeting Criteria
FY2020 Revision Summary: None.
V7 Data Element Fields and Responses:
Field Number

1

2

9/3/2019

Field Name

Dependency Response Category/ Descriptions
Data Type
Referred by Coordinated Entry or None
0
No
a homeless assistance provider to
1
Yes
prevent the household from
entering an emergency shelter or
transitional housing or from
staying in a place not meant for
human habitation
Current housing loss expected
None
0
0-6 days
within
1
7-13 days
2
14-21 days
3
More than
21 days (0
points)
203

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

3

4

5

6

7

9/3/2019

Field Name

Dependency Response Category/ Descriptions
Data Type
Current household income is $0 None
0
No (0
points)
1
Yes
Annual household gross income None
0
0-14% of
amount
Area
Median
Income
(AMI) for
household
size
1
15-30% of
AMI for
household
size
2
More than
30% of AMI
for
household
size (0
points)
Sudden and significant decrease in None
0
No (0
cash income (employment and/or
points)
cash benefits) AND/OR
1
Yes
unavoidable increase in nondiscretionary expenses (e.g.: rent
or medical expenses) in the past 6
months
Major change in household
None
0
No
composition (e.g., death of a
1
Yes
family member,
separation/divorce from adult
partner, birth of new child) in the
past 12 months
Rental Evictions within the past 7 None
0
4 or more
years
prior rental
evictions
1
2-3 prior
rental
evictions

204

Field Number

8

9

10

11

12

13

9/3/2019

Field Name

Dependency Response Category/ Descriptions
Data Type
2
1 prior
rental
eviction
3
No prior
rental
eviction (0
points)
Currently at risk of losing a tenant- None
0
No (0
based housing subsidy or housing
points)
in a subsidized building or unit
1
Yes
History of Literal Homelessness
None
0
4 or more
(street/shelter/transitional
times or
housing)
total of at
least 12
months in
past three
years
1
2-3 times in
past three
years
2
1 time in
past three
years
3
None (0
points)
Head of Household with disabling None
0
No (0
condition (physical health, mental
points)
health, substance use) that
1
Yes
directly affects ability to
secure/maintain housing
Criminal record for arson, drug
None
0
No (0
dealing or manufacture, or felony
points)
offense against persons or
1
Yes
property
Registered sex offender
None
0
No (0
points)
1
Yes
At least one dependent child
None
0
No (0
under age 6
points)

205

4. PROGRAM SPECIFIC DATA ELEMENTS
Field Number

14

15

16

17

20
21

Field Name

Dependency Response Category/ Descriptions
Data Type
1
Yes
Single parent with minor
None
0
No (0
child(ren)
points)
1
Yes
Household size of 5 or more
None
0
No (0
requiring at least 3 bedrooms (due
points)
to age/gender mix)
1
Yes
Any Veteran in household served None
0
No (0
in Iraq or Afghanistan
points)
1
Yes
Female Veteran
None
0
No (0
points)
1
Yes
HP applicant total points
None
[Integer]
Grantee targeting threshold score None
[Integer]

V7 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

HOH

XML

33 - VA: SSVF- 12
collection
Homelessness
required only Prevention
for HP

CSV
Enrollment

Collection
Point
Project Start

V8 HUD-VASH Voucher Tracking
FY2020 Revision Summary: Updated collection point to be “Occurrence Point (as provided).”
V8 Data Element Fields and Responses:
Field Number Field Name
Dependency
Response Category/ Data Type
1
Information
None
[Date]
date
2
Voucher
None
1
Referral package forwarded
change
to PHA
2
Voucher denied by PHA
3
Voucher issued by PHA
4
Voucher revoked or expired
5
Voucher in use- veteran
moved into housing
9/3/2019

Descriptions

206

Field Number

A

Field Name

Dependency

If other, please Field 2 &
specify
Response 12

Response Category/ Data Type Descriptions
6
Voucher was ported locally
7
Voucher was administratively
absorbed by new PHA
8
Voucher was converted to
Housing Choice Voucher
9
Veteran exited - voucher was
returned
10
Veteran exited - family
maintained the voucher
11
Veteran exited - prior to ever
receiving a voucher
12
Other
[Text]

V8 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

Veteran HOH 20 3 - PH HUD:HUD/VASH Permanent
OTH
Supportive
Housing

XML

CSV

Services

Collection
Point
Occurrence
Point (as
provided)

V9 HUD-VASH Exit Information
FY2020 Revision Summary: None.
V9 Data Element Fields and Responses:
Field Number
Field Name
Dependency
Response Category/ Data Type Descriptions
1
Case
None
1
Accomplished goals and /or
Management Exit
obtained services and no
Reason
longer needs CM
2
Transferred to another HUDVASH program site
3
Found/chose other housing
4
Did not comply with HUDVASH CM
5
Eviction and/or other
housing related issues

9/3/2019

207

Metadata Elements
Field Number

A

Field Name

If other - please
specify

Dependency

Field 1 &
Response 13

Response Category/ Data Type Descriptions
6
Unhappy with HUD-VASH
housing
7
No longer financially eligible
for HUD-VASH voucher
8
No longer interested in
participating in this program
9
Veteran cannot be located
10 Veteran too ill to participate
at this time
11 Veteran is incarcerated
12 Veteran is deceased
13 Other
[Text]

V9 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

Veteran HOH

20 3 - PH HUD:HUD/VASH Permanent
OTH
Supportive
Housing

XML

CSV

Collection
Point

Exit

Metadata Elements
5.01 Date Created
System Logic and Other System Issues: HMIS generated.
The HMIS must store this metadata for all client-level data elements. It is not necessary that
this information be displayed in the user interface of the HMIS, but it must be accessible in the
programming of reports. Date Created must not change when a data element is edited. If two
client records representing the same person are merged, the earliest Date Created must be
retained for data elements for which the HMIS stores only one value per client (e.g., name, SSN,
date of birth).
HMIS must have the ability to identify the date on which a record was first created in HMIS for
any data element. Data elements that are collected together on a single form may share a
single Date created. HMIS users and system administrators must not have the ability to enter or
to modify the information in this Metadata Element.

9/3/2019

208

FY2020 Revision Summary: Renumbered from 5.1 to 5.01.
5.01 Data Element Fields and Responses:
Field Number
Field Name
Dependency
1

Date Created

None

Response Category/ Data
Type
[Date]

Descriptions

5.01 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

All records

XML

CSV

Collection
Point
All Funders, All All HMIS
XML Attribute: <*> Record
Program
Project Types DateCreated Field collected
creation
Components
across multiple
files

5.02 Date Updated
System Logic and Other System Issues: HMIS generated.
The HMIS must be able to determine, for all data elements, the date on which it was last edited
by a user. Each time a user saves data, the HMIS must store the current date as the Date
Updated with the data being saved. Data elements that are collected together on a single form
may share a single Date Updated. HMIS users or system administrators must not have the
ability to enter or to modify the information in this metadata element.
Created by the HMIS when a record for any data element is first created, and updated by the
HMIS every time the record is saved by an HMIS user.
FY2020 Revision Summary: Renumbered from 5.2 to 5.02.
5.02 Data Element Fields and Responses:
Field Number
Field Name
Dependency
1

Date Updated

None

Response Category/ Data
Type
[Date]

Descriptions

5.02 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All records

9/3/2019

XML

CSV

Collection
Point
All Funders, All All HMIS
XML Attribute: <*> Record
Program
Project Types DateUpdated Field collected
creation
Components
across multiple
files

209

Metadata Elements
5.03 Data Collection Stage
System Logic and Other System Issues: The point(s) at which the data must be able to be
collected in an HMIS. For data elements with multiple collection points (e.g. Project Start,
Occurrence Point, Project Exit), each record must be stored with the appropriate Data
Collection Stage (as listed in metadata element 5.3). Data elements with only a single collection
point need not be stored with any particular data collection stage, since their data collection
point is inherent in their requirements.
HMIS generated or HMIS user selected. An HMIS must be able to distinguish between data
collected at project start, project update (during a project stay), and at project exit. Data
elements that are collected together on a single form may share a single Data Collection Stage.
HMIS users should not have the ability to create more than one record per data element at
either project start or project exit (e.g., for a single project stay, a client should have one and
only one record of Income and Sources identified as project start). The system must allow a
user to save a dated record for a client’s annual assessment as an “annual assessment”.
The response categories correlate to response categories defined in the XML and CSV
specifications. An “annual assessment” is required as noted in the collection stage for some
Program Specific Elements. The Annual Assessment must include updating both the head of
household’s record and any other family members at the same time. Elements for which a
collection point of ‘annual assessment’ is required must be collected at least once annually for
each client. An Annual Assessment must occur between months 11 and 13 annually for all HUD
funded projects. The Information Date must be no more than 30 days before or after the
anniversary of the head of household’s Project Start Date; information must be accurate as of
the Information Date. The date range of the Annual Assessment is based entirely around the
head of household’s Project Start Date, not on the date of the client’s or head of household’s
previous assessment.
For all projects which require an annual assessment, data collected as part of an annual
assessment must have a Data Collection Stage of ‘annual assessment.’ There should be one and
only one record for each data element with a Data Collection Stage of ‘annual assessment’
within the 60-day period surrounding the anniversary of the head of household’s Project Start
Date. Regardless of whether or not the responses have changed since project start or the
previous annual assessment, a new record must be created for each annual assessment such
that it is possible to view a history, by date, of the values for each data element.
FY2020 Revision Summary: Renumbered from 5.3 to 5.03.

9/3/2019

210

5.03 Data Element Fields and Responses:
Field Number Field Name Dependency Response
Descriptions
Category/
Data Type
1
Data
None
1 Project Start Indicates the element is required to be
Collection
collected at every project start. Elements
Stage
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.

9/3/2019

211

Metadata Elements
Field Number Field Name Dependency

9/3/2019

Response
Category/
Data Type
2 Project
Update

Descriptions

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. While
data may be edited by users associated
with the project to correct errors or
omissions, correct records should never be
overwritten or discarded when update
records are created. Corrections to
existing records will change neither the
data collection stage nor the information
date unless it is explicitly altered by the
user.

212

Field Number Field Name Dependency

9/3/2019

Response
Descriptions
Category/
Data Type
5 Project
Data elements required for collection at
Annual
annual assessment must be entered with
Assessment 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 collection stage nor the
information date unless they are explicitly
altered by the user.

213

Metadata Elements
Field Number Field Name Dependency

Response
Category/
Data Type
3 Project Exit

6 Post Exit

Descriptions

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.
Indicates the element may be collected
after project exit for a period of no longer
than six months.

5.03 Specifications:
Data
Funder/Progra
Project
Collected m Component
Type
About
Applicabilit

y
All data All Funders, All All HMIS
elements Program
Project
with
Components Types
multiple
data
collectio
n stages

XML

CSV

Collectio
n Point

XML Attribute:
<*> Field collected across creation
e
multiple files

5.04 Information Date
System Logic and Other System Issues: This Metadata Element is a hybrid in that it pertains to
the client data and not directly to the client, but it will be entered in HMIS by users.

9/3/2019

214

This Metadata Element has been added to the data elements where it applies (e.g. Income and
Sources, with Response 1 Information Date). The metadata element is included here to provide
further information for HMIS vendors and system administrators.
Data that is collected only at initial HMIS project start (e.g., Name, Social Security Number) does
not require an Information Date. Data that is collected only at project start or only at project
exit, may be assumed to have an Information Date that matches the Project Start Date or
Project Exit Date, respectively or an HMIS may require that a user specify the date.
Data elements that are collected together on a single form may share a single Information Date.
This Metadata Element is applicable to all elements which can change over time.
FY2020 Revision Summary: Renumbered from 5.4 to 5.04.
5.04 Data Element Fields and Responses:
Field Number
Field Name
Dependency
1

Information Date

None

Response Category/ Data
Type
[Date]

Descriptions

5.04 Specifications:
Data Collected Funder/Program
About
Component

Project
XML
CSV
Collection
Type
Point
Applicability
As specified All Funders, All All HMIS
XML Attribute: <*> Record
in Data
Program
Project
InformationDate Field collected across creation
Element
Components Types
multiple files
Definitions
5.05 Project Identifier
System Logic and Other System Issues: HMIS auto-generated or HMIS user selected.
Data elements that are collected together on a single form may share a single Project Identifier.
In order to report on data quality on a project's report, it is first necessary to establish that the
project in question was responsible for the data.
This is a basic requirement that assumes a simple relationship between clients and projects. In
circumstances where one project may be responsible for entering data that would
appropriately appear on another project's required report (e.g., a central intake point), it may
be necessary to create a more sophisticated method to establish responsibility for the data
entered.
FY2020 Revision Summary: Renumbered from 5.5 to 5.05.
9/3/2019

215

Metadata Elements
5.05 Data Element Fields and Responses:
Field Number Field Name Dependency Response Category/ Data
Descriptions
Type
1
Project
None
[Integer]
Project Identifier (2.02) of
Identifier
the project that entered or
edited the data
5.05 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

Specified Data All Funders, All All HMIS
Elements
Program
Project Types
Components

XML
Unique
Identifier:
ProjectID

CSV

Collection
Point
<*> Record
Field collected creation
across multiple
files

5.06 Enrollment Identifier
Data Collection Instruction: HMIS generated.
The data element should be created by the HMIS at the time that the record of a project start is
first entered into HMIS and should be stored with any data that pertains to that particular
period of service.
Data elements that are collected together on a single form may share a single Enrollment
Identifier. An HMIS should be able to correlate data to a specific project stay.
This metadata element must be stored with all elements identified in this document as having a
collection point “Project Start”
FY2020 Revision Summary: Renumbered from 5.6 to 5.06. Change in name: ID to Identifier for
consistency. May be shortened to ID.
5.06 Data Element Fields and Responses:
Field Number Field Name Dependency Response Category/ Data
Descriptions
Type
1
Enrollment None
[Integer]
A unique project start
Identifier
identifier used to
associate data with a
particular period of
service.

9/3/2019

216

5.06 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

XML

CSV

Collection
Point
All Enrollment All Funders, All All HMIS
Unique
<*> Record
Level Data
Program
Project Types Identifier:
Field collected
creation
Components
EnrollmentID across multiple
files
5.07 User Identifier
System Logic and Other System Issues: HMIS generated.
Each authorized user of an HMIS must have a unique identifier stored in the HMIS. Every time
data is entered or edited in HMIS, the HMIS must keep a record of which user entered or edited
the data based on the credentials supplied at the time of login.
The data element should be stored with any Universal or Program-Specific Data Element
entered or edited in an HMIS.
It must be possible to determine, for all client-level data, which user entered it in HMIS. Each
time a user saves data, the HMIS must store the User Identifier of that particular user with the
data being saved.
Data elements that are collected together on a single form may share a single User Identifier.
HMIS users must not have the ability to enter or to modify the information in this Metadata
Element.
If a data element is edited, the system must retain the original value, along with the User
Identifier of the user who entered it, in addition to storing the new value and the User Identifier
of the editing user.
FY2020 Revision Summary: Renumbered from 5.7 to 5.07. New file User.csv.
5.07 Data Element Fields and Responses:
Field Number Field Dependency Response Category/ Data
Descriptions
Name
Type
1
User
None
[Integer]
A unique ID used to
Identifier
associate data with the user
who entered and/or edited
it

9/3/2019

217

Metadata Elements
5.07 Specifications:
Data Collected Funder/Program Project Type
About
Component
Applicability

All Records

All Funders, All All HMIS
Program
Project Types
Components

XML

CSV

Collection
Point
XML Attribute: <*> Record
UserID
Field collected creation
across multiple
files

5.08 Personal Identifier
Data Collection Instruction: HMIS generated.
A Personal ID must be created, but there is no required format if there is a single unique
Personal ID for every client and it contains no personally identifying information.
The Personal ID must be able to be attached to the same individual when served by multiple
projects.
There is a one-to-one relationship between Personal ID and 3.01 Name, 3.02 Social Security
Number, 3.03 Date of Birth, 3.04 Race, 3.05 Ethnicity, 3.06 Gender, and 3.7 Veteran Status.
Search functionality must exist to facilitate linkage of the same person with their Personal ID as
they are served by different projects within the continuum. There are multiple ways to
accomplish this. The recommended method of search by users for clients in open record
systems is for users to enter a combination of personal identifying information (Name, SSN,
Date of Birth, and/or Gender) into the HMIS application and have the application search for
matching records. If a match is found and a Personal ID is retrieved, the same Personal ID will
be assigned to the client, i.e. the same record is used. If no matches are found, a new
automatically generated Personal ID is assigned to the client. Variations or other methods may
also be utilized by vendors if the system is designed to mitigate duplicate record entry.
HMIS must have functionality to allow the HMIS Lead to de-duplicate multiple records with
distinct Personal ID's that are identified as representing the same individual based on
identifying information.

9/3/2019

218

5.08 Data Element Fields and Responses:
Field Number Field Dependency Response Category/ Data
Descriptions
Name
Type
1
Personal None
[Integer]
A Personal ID is an
Identifier
automatically generated
identifier created by the
HMIS application. A Personal
ID must be permanent and
unique to a single individual
within an HMIS
implementation.
5.08 Specifications:
Data Collected Funder/Program Project Type
About
Component Applicability

All Clients

XML

CSV

All Funders, All All HMIS
Client
Program
Project Types
Components

Collection
Point
Record
creation

5.09 Household Identifier
Data Collection Instruction: HMIS generated.
A Household ID will be assigned to each household at each project start and applies for the
duration of that project stay to all members of the household served. The Household ID must
be automatically generated by the HMIS application to ensure that it is unique. The Household
ID has no meaning beyond a single enrollment; it is used in conjunction with the Project ID,
Project Start Date, and Project Exit Date to link records for household members together and
indicate that they were served together. The Household ID is to be unique to the household
stay in a project; reuse of the identification for the same or similar household upon readmission
into the project is unacceptable.
Persons may join a household with members who have already begun a project start or may
leave a project although other members of the household remain in the project. A common
Household ID must be assigned to each member of the same household. Persons in a
household (either adults or children) who are not present when the household initially applies
for assistance and later join the household should be assigned the same Household ID that links
them to the rest of the persons in the household. The early departure of a household member
would have no impact on the Household ID. An HMIS may, but is not required to, utilize a
Global Household ID at record creation upon initial entry into an HMIS based on the person(s)
presenting together as a household at the time of initial entry.

9/3/2019

219

Metadata Elements
A Global Household ID is a value which spans an entire HMIS implementation representing a
collection of persons who have been in a household together. Assignment of a client in or out
of a global household at a specific project need not immediately affect the client’s data at other
projects. If, for example, one household member exits from a household in project A and that
household is also being served in project B, there is no requirement to alter the household
configuration at project B.
5.09 Data Element Fields and Responses:
Field Number Field Name Dependency Response Category/ Data
Descriptions
Type
1
Household None
[Integer]
A Household ID is an
Identifier
automatically generated
identifier created by the
HMIS application. A
Household ID must be
permanent and unique to a
single household at each
project start within an
HMIS implementation.
5.09 Specifications:
Data
Collected
About

All Clients

9/3/2019

Funder/Program
Component

Project
XML
CSV
Collection
Type
Point
Applicability
All Funders, All All HMIS
Enrollment Record
Program
Project
creation
Components Types

220

Appendix A. Living Situation Response Categories and
Descriptions
Header

Field
Response
Number

Homeless
Situations

16

1

Description

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,
or RHY-funded
Host Home
shelter

•
•

•

•

•

18

Safe Haven

•
•

•

Prior
Living
Sit.
(3.917)

Current Destination
Living (3.12)
Sit
(4.12)

X

X

X

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

X

X

X

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

X

X

X

221

Appendix A. Living Situation Response Categories and Descriptions
Header

Field
Response
Number

Institutional 15
Situations

Current Destination
Living (3.12)
Sit
(4.12)

X

X

X

Hospital or other
residential nonpsychiatric
medical facility

X

X

X

7

Jail, prison, or
juvenile
detention facility

X

X

X

25

Long-term care
facility or nursing
home

X

X

X

4

Psychiatric
hospital or other
psychiatric
facility

X

X

X

5

Substance abuse
treatment facility
or detox center

X

X

X

29

Residential or
halfway house
with no homeless
criteria

X

X

X

X

X

X

14

9/3/2019

Prior
Living
Sit.
(3.917)

Foster care home
or foster care
group home

6

Temporary
and
Permanent
Housing
Situations

Description

Hotel or motel
paid for without
emergency
shelter voucher

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

222

Header

Field
Response
Number
2

Transitional
housing for
homeless
persons
(including
homeless youth)

Description

•
•

•

•

•

9/3/2019

32

Host home (noncrisis)

13

Staying or living
with friends,
temporary
tenure (e.g.
room, apartment
or house)

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

Prior
Living
Sit.
(3.917)

Current Destination
Living (3.12)
Sit
(4.12)

X

X

X

X

X

X

X

223

Appendix A. Living Situation Response Categories and Descriptions
Header

Field
Response
Number
36

12

22

35

23

26

27

9/3/2019

Description

Staying or living
in a friend's
room, apartment
or house

Prior
Living
Sit.
(3.917)

X

Current Destination
Living (3.12)
Sit
(4.12)

X

Staying or living
with family,
temporary
tenure (e.g.
room, apartment
or house)

X

Staying or living
with family,
permanent
tenure

X

Staying or living
in a family
member's room,
apartment or
house

X

X

Staying or living
with friends,
permanent
tenure

X

Moved from one Limited to use by
HOPWA funded HOPWA-funded projects
project to
HOPWA PH

X

Moved from one Limited to use by
HOPWA funded HOPWA-funded projects
project to
HOPWA TH

X

28

Rental by client,
with GPD TIP
housing subsidy

X

X

X

19

Rental by client,
with VASH
housing subsidy

X

X

X

224

Header

Field
Response
Number
3

31

33

34

9/3/2019

Permanent
housing (other
than RRH) for
formerly
homeless
persons

Description

•

•

CoC Permanent
Supportive
Housing
HOPWA
facility/TBRA
permanent
housing (for
Destination:
when moving
from nonHOPWA projects)

Prior
Living
Sit.
(3.917)

Current Destination
Living (3.12)
Sit
(4.12)

X

X

X

X

X

X

Rental by client, Includes HCV with no
with Housing
paired services.
Choice Voucher
(HCV) (tenant or
project based)

X

X

X

Rental by client
in a public
housing unit

X

X

X

Rental by client,
with RRH or
equivalent
subsidy

Use this response
category as a
Destination only if the
client is moving directly
into a unit.
• CoC Rapid ReHousing
• ESG Rapid ReHousing
• VA SSVF Rapid
Re-Housing
• Locally-funded
Rapid ReHousing

225

Appendix A. Living Situation Response Categories and Descriptions
Header

10

When a client leaves an
RRH project maintaining
(or moving to) a rental
that they will pay for on
their own (without a
subsidy of any kind) you
should select Rental by
Client, no ongoing
housing subsidy.

X

X

X

Any subsidized rental
housing other than CoC
PSH, HOPWA PH, RRH,
GPD TIP, or VASH.
Includes legacy SRO and
Pay For Success.

X

X

X

Rental by client,
no ongoing
housing subsidy

Rental by client,
with other
ongoing housing
subsidy

21

Owned by client,
with ongoing
housing subsidy

X

X

X

11

Owned by client,
no ongoing
housing subsidy

X

X

X

30

No exit interview This will be considered
completed
"missing data" for data
quality and reporting
purposes.

17

9/3/2019

Current Destination
Living (3.12)
Sit
(4.12)

Description

20

Other

Prior
Living
Sit.
(3.917)

Field
Response
Number

Other

24

Deceased

37

Worker unable to
confirm

Any response of "Other"
in Destination will not
count in any HMISbased reporting as a
positive outcome.
Review the above list
carefully to determine if
any option above is a
reasonable match.

X

X

X

X
X

226

Header

9/3/2019

Field
Response
Number

Description

Prior
Living
Sit.
(3.917)

Current Destination
Living (3.12)
Sit
(4.12)

8

Client doesn't
know

X

X

X

9

Client refused

X

X

X

99

Data not
collected

X

X

X

227