U.S. Department of Housing and Urban Development
Community Planning and Development
Special Attention of:
Notice CPD-13-017
All Regional Directors
Issued: xxxx
All Field Office Directors
Expires: xxxx
All CPD Division Directors
All HUD Homeless Assistance Program Grantees
SUBJECT: Draft Homeless Management Information Systems (HMIS) Data Standards
Table of Contents
1.
Introduction to the 2013 Draft HMIS Data Standards Notice......................................................................4
1.1
Contents of the Notice .....................................................................................................................................6
1.2
Significant Differences between the 2010 Notice and the 2013 Draft Notice .................................................6
1.3
Statutory Authority ..........................................................................................................................................8
1.4
Key Terms .......................................................................................................................................................9
1.5
Victim Service Provider Data in HMIS ......................................................................................................... 11
1.6
Summary of Data Standard Applicability and Collection Requirements ...................................................... 11
Exhibit 1-1: Summary of Project Descriptor Data Elements ....................................................................................... 13
Exhibit 1-2: Summary of Universal Data Elements..................................................................................................... 14
Exhibit 1-3: Summary of Project -Specific Data Elements ......................................................................................... 15
2.
Project Descriptor Data Elements ..............................................................................................................21
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
Organization Identifier .................................................................................................................................. 21
Organization Name ....................................................................................................................................... 22
Project Identifier ............................................................................................................................................ 23
Project Name ................................................................................................................................................. 23
Direct Service Code ...................................................................................................................................... 24
Site Information............................................................................................................................................. 24
Continuum of Care Code ............................................................................................................................... 27
Project Type .................................................................................................................................................. 27
Bed and Unit Inventory Information ............................................................................................................. 29
Target Population A (Optional) ..................................................................................................................... 33
Target Population B ...................................................................................................................................... 34
Method for Tracking Residential Occupancy ................................................................................................ 35
Federal Funding Source(s) ............................................................................................................................ 36
3.
Universal Data Elements .............................................................................................................................37
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
Name ............................................................................................................................................................. 39
Social Security Number................................................................................................................................. 39
Date of Birth .................................................................................................................................................. 40
Race ............................................................................................................................................................... 41
Ethnicity ........................................................................................................................................................ 42
Gender ........................................................................................................................................................... 42
Veteran Status ............................................................................................................................................... 43
Disabling Condition ...................................................................................................................................... 44
Residence Prior to Project Entry ................................................................................................................... 45
Project Entry Date ......................................................................................................................................... 47
Project Exit Date ........................................................................................................................................... 48
Destination .................................................................................................................................................... 49
3.13
3.14
3.15
3.16
Personal Identification Number ..................................................................................................................... 51
Household Identification Number ................................................................................................................. 51
Head of Household ........................................................................................................................................ 52
Length of Time On Street, in an Emergency Shelter or Safe Haven ............................................................. 53
4.
Program-Specific Data Elements ...............................................................................................................54
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
4.31
4.32
4.33
4.34
4.35
4.36
4.37
4.38
4.39
4.40
4.41
4.42
4.43
4.44
Zip Code of Last Permanent Address ............................................................................................................ 56
Housing Status............................................................................................................................................... 57
Income and Sources ...................................................................................................................................... 60
Non-Cash Benefits ........................................................................................................................................ 64
Health Insurance / Medical Assistance .......................................................................................................... 67
Employment Status ....................................................................................................................................... 70
Physical Disability......................................................................................................................................... 71
Developmental Disability .............................................................................................................................. 72
Chronic Health Condition ............................................................................................................................. 73
HIV/AIDS ..................................................................................................................................................... 74
Mental Health Problem ................................................................................................................................. 75
Substance Abuse ........................................................................................................................................... 76
Domestic Violence ........................................................................................................................................ 77
Contact .......................................................................................................................................................... 78
Dates of Engagement and Enrollment ........................................................................................................... 79
Veterans Information ..................................................................................................................................... 80
Services Provided .......................................................................................................................................... 82
Financial Assistance Provided ....................................................................................................................... 84
Area Median Income (AMI) Percentage Used for Eligibility ....................................................................... 86
Sexual Orientation ......................................................................................................................................... 86
Last Grade Completed ................................................................................................................................... 87
School Status ................................................................................................................................................. 87
General Health Status .................................................................................................................................... 88
Pregnancy Status ........................................................................................................................................... 89
Funding Source for Residence Prior to Project Entry ................................................................................... 89
Funding Source for Destination .................................................................................................................... 90
Referrals Provided ......................................................................................................................................... 90
Reason for Leaving ....................................................................................................................................... 94
Project Transition .......................................................................................................................................... 95
Formerly a Ward of Child Welfare/Foster Care Agency ............................................................................... 95
Formerly a Ward of Juvenile Justice System ................................................................................................ 96
Young Person’s Critical Issues ...................................................................................................................... 97
Referral Source .............................................................................................................................................. 98
Transitional, Exitcare, or Aftercare Plans and Actions ............................................................................... 100
Project Completion Status ........................................................................................................................... 101
Family Reunification Achieved ................................................................................................................... 101
Physical Health Status ................................................................................................................................. 101
Dental Health Status .................................................................................................................................... 102
Mental Health Status ................................................................................................................................... 102
Housing Category ........................................................................................................................................ 103
Percent of AMI ............................................................................................................................................ 103
Formerly Chronically Homeless.................................................................................................................. 104
Federal Program Funding Source for Project Clients .................................................................................. 104
Worst Housing Situation ............................................................................................................................. 106
5.
Metadata Elements .................................................................................................................................... 106
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Date Created ................................................................................................................................................ 106
Date Updated ............................................................................................................................................... 107
Data Collection Stage .................................................................................................................................. 108
Information Date ......................................................................................................................................... 109
Project Identifier .......................................................................................................................................... 110
Project Entry Identifier ................................................................................................................................ 110
User Identifier ............................................................................................................................................. 111
1.
Introduction to the 2013 Draft HMIS Data Standards Notice
This Notice revises the Homeless Management Information Systems (HMIS) Data Standards
Revised Notice of March 2010. The Notice includes changes in data elements necessary to
support data collection and reporting for projects funded under Title IV of the McKinney-Vento
Homeless Assistance Act (42 U.S.C. 11360 et seq.) (McKinney-Vento Act), as amended by the
Homeless Emergency Assistance and Rapid Transition to Housing (HEARTH) Act of 2009.
The HEARTH Act consolidated and amended three separate homeless assistance programs
carried out under Title IV of the McKinney-Vento Act into a single grant program that is
designed to improve administrative efficiency and enhance response coordination and
effectiveness in addressing the needs of homeless persons. The single Continuum of Care (CoC)
Program established by the HEARTH Act consolidated the following programs: the Supportive
Housing Program (SHP), the Shelter Plus Care program (S+C), and the Moderate
Rehabilitation/Single Room Occupancy (SRO) program. The former Emergency Shelter Grants
Program was renamed the Emergency Solutions Grants (ESG) Program and revised to expand
essential services related to emergency shelter and street outreach and add short- and mediumterm rental assistance and housing relocation and stabilization services for people who are
homeless or at risk of homelessness. The new ESG Program requires that recipients and
subrecipients participate in a applicable community-wide HMIS. The HEARTH Act also
codifies into law and enhances the CoC planning process, the coordinated response to addressing
the needs of homelessness established administratively by the U.S. Department of Housing and
Urban Development in 1995.
The 2013 Draft HMIS Data Standards no longer include data elements specific to the
Homelessness Prevention and Rapid Re-Housing Program (HPRP), funded under the American
Recovery and Reinvestment Act of 2009.
This Notice also includes changes to support data collection and reporting for other federal
targeted homeless assistance programs, new metadata elements to facilitate data exchange and
reporting, and additional minor corrections and changes to support efficient data collection and
reporting. Updating HMIS Data Standards to accommodate use by other federal agencies is
being undertaken in part to support goals identified in Opening Doors: the Federal Strategic
Plan to Prevent and End Homelessness.
Background on HMIS and HMIS Data and Technical Standards
An HMIS is the information system designated by Continuums of Care to comply with the
requirements of CoC regulation at 24 CFR 578 and in anticipation of a final rule for Homeless
Management Information Systems, which has been proposed but not yet finalized. It is a locallyadministered data system used to record, analyze, and transmit client and activity data in regard
to the provision of shelter, housing, and services to individuals and families who are homeless or
at risk of homelessness. HMIS is a valuable resource because of its capacity to integrate and
unduplicate data from all homeless assistance and homelessness prevention Projects in a CoC.
Aggregate HMIS data can be used to understand the size, characteristics, and needs of the
homeless population at the local, state, and national levels. Today’s advanced HMIS solutions
offer many other benefits as well. They enable organizations that operate homeless assistance
and homelessness prevention projects to improve case management by collecting information
about client needs, goals, and service outcomes. They also help to improve access to timely
resource and referral information and to better manage operations.
4
Following Congressional directive, HUD has supported the implementation of local Homeless
Management Information Systems by: (1) providing technical support and funding to operate
and administer local HMIS; and (2) undertaking a research effort to collect and analyze HMIS
data from a representative sample of communities in order to understand the nature and extent of
homelessness nationally. As part of this effort, HUD published HMIS Data and Technical
Standards in 2004 that allowed for the collection of standardized client and project-level data on
homeless service usage among projects within a community and across all communities. The
2004 HMIS Data and Technical Standards provided a resource to enable every HMIS to capture
the information necessary to fulfill HUD reporting requirements while protecting the privacy of
homeless individuals.
HUD published updated HMIS Data Standards in March 2010. Among other changes, the 2010
HMIS Data Standards added Program Descriptor Data Elements and data elements required for
HPRP.
Process for Revising the Data Standards
HUD receives continuous feedback from CoC representatives, HMIS system administrators,
HMIS vendors, researchers, and technical assistance providers pertaining to the data standards.
HUD has undertaken a revision of the data standards in response to this feedback, as well as in
response to evolving reporting needs at the local and national level, expanded use of HMIS by
projects funded by a wider variety of federal agencies, and the McKinney-Vento Act as amended
by the HEARTH Act.
In order to support the integration of data collection and reporting for other federal targeted
homeless assistance projects into HMIS, HUD solicited recommendations on changes and
updates to the data standards from the Substance Abuse and Mental Health Services
Administration (SAMHSA), the Administration for Children, and the Family and Youth Services
Bureau (FYSB) in the Department of Health and Human Services, the Department of Veterans
Affairs (VA), and HUD’s Office of HIV/AIDS Housing. In March 2011, HUD convened a
meeting of HMIS vendors and technical assistance providers to solicit input and feedback on
proposed changes to the data standards, and further sought data, opinions, and expert advice
from the Board of Directors of the National Human Services Data Consortium (NHSDC). HUD
considered input from all of these sources in drafting this Notice for public comment.
HUD appreciates that every change to the data standards represents a cost in time and resources
for HMIS vendors, system administrators, and users. There are a number of considerations that
influence the decision to make a particular change, including:
1. Is the modification necessary in order for projects to generate reports required by HUD or
other federal agencies?
2. Does the modification represent an improvement in the information value or data quality
over the status quo?
3. Is it feasible and practical to expect that HMIS users will be able to collect and enter the
data without excessive additional burden?
This draft Notice for public comment represents an additional step in gathering feedback to
actively solicit feedback from clients, projects, CoCs, funders, HMIS vendors, and other
interested parties. Although comments on any aspect of this draft notice are welcome, HUD is
specifically encouraging comments regarding proposed changes to:
5
1. Project Descriptor data elements, including changes to the Project Type element and
addition of the Federal Program Funding Source(s) element;
2. the method data pertaining to income and sources are collected (for heads of household
and adult household members rather than for all members of households); and
3. addition of Services Provided and Financial Assistance Provided data elements and their
utility in tracking service transactions.
At the end of the public comment period, HUD will review all of the comments received and
make revisions prior to the publication of the final notice. The final notice will also provide
HUD’s response to comments submitted.
1.1
Contents of the Notice
This Notice presents revised HMIS Data Standards. Proposed revisions for HMIS Technical
Standards related to privacy, security and other topics will be issued separately. The remainder
of this section reviews major differences between the data standards presented in the March 2010
Final Notice and this 2013 Draft Notice, describes the statutory authority that allows HUD to
prescribe the HMIS Standards, and presents key terms referenced throughout the Notice.
Section 2 of the Notice presents the Project Descriptor Data Standards that HUD has determined
must be collected by all CoC Projects (see definition, Section 1.4).
Section 3 of the Notice presents the Universal Data Elements, which represent the data elements
that HUD has determined must be collected by all Contributing CoC Projects (see definition,
Section 1.4).
Section 4 presents the Program Specific Data Elements; this section includes a wide array of
data elements. The applicability of these data elements for projects funded by HUD is defined in
this Notice. Other federal agencies will issue guidance on data collection and reporting
requirements for the data elements in Section 4 as required for their respective programs. HMIS
vendors must have the ability to tailor the data collection for a project based on the data elements
in this Notice identified by HUD as required, as well as additional data collection as required by
other federal agencies.
Section 5 presents the Metadata Elements that HUD has determined are required to facilitate
reporting and data exchange; these are new standards.
1.2
Significant Differences between the 2010 Notice and the 2013 Draft Notice
The key differences between the March 2010 Notice and the 2013 Draft Notice with regard to
HMIS Data Standards are described below:
Data Standards Structure and Applicability
The 2010 Notice included three different categories of data elements related to client
characteristics, services provided, and outcomes–Universal, Provider-Specific, and Optional.
Under this notice, there are four categories of data elements–project-Specific (see definition,
Section 1.4), Universal, or Program-Specific (see definition, Section 1.4). All Contributing CoC
Projects (see definition, Section 1.4) must collect all of the Universal Data Elements. The
Program-Specific section includes a wide array of data elements and response categories
required for collection in HMIS by HUD and other federal agencies and collection is dependent
on the specific type of program design and funding. Other federal agencies will issue guidance
outlining which of the Program-Specific Data Elements their projects are required to collect and
6
report. HMIS vendors should consult that guidance, in conjunction with local CoC and HMIS
staff, to determine how to configure data collection for each project.
Use of “project” and “program”
To avoid confusion, this Notice is now restricting the use of the term “program” to mean federal,
state, and local funding sources (e.g., ESG, CoC, HHS PATH, HHS RHY, VA GPD, etc.) This
is a change from the 2010 Data Standards were the term “program” was used to refer to what is
now defined as a “project” in the McKinney-Vento Act and the CoC Program rule. Accordingly,
this Notice will use “project” as defined in the CoC rule. This change is noted here but is not
included in the Changes from Previous Notice section for each individual data element.
Don’t Know and Refused
Throughout the Notice, the response categories “Don’t Know” and “Refused” have been
changed to “Client doesn’t know” and “Client refused,” respectively. The intent is to emphasize
that these response categories should only be selected when the client indicates that they do not
know or are not willing to provide the information requested. This change is noted here but is
not included in the Changes from Previous Notice section for each individual data element.
Numbered Response Categories
Previous versions of the Notice have included numbered response categories with an integer
assigned to each response category, e.g., “9 = Refused.” The purpose of the numbering was to
facilitate a standardized data exchange; there is no requirement that HMIS solutions store those
numbers. This revision of the HMIS Data Standards discontinues this practice. The appropriate
numeric translation for each response category will be included in the specifications documents
for HUD’s standardized CSV and XML data exchange formats. This change is noted here but is
not included in the Changes from Previous Notice section for each individual data element.
Project Descriptor Data Elements
The Program Descriptor Data Elements have been renamed to Project Descriptor Data Elements
and have been revised to better reflect project models and to differentiate between those that
provide lodging, formerly called “residential homeless assistance programs” in the March 2010
standards, from those that do not. This will assist in the accuracy of Housing Inventory Count
(HIC) reporting, reduce confusion over which Project Descriptor Data Elements are applicable to
which type of project (per the revised Project Type data element), and will facilitate CoC and
project performance measurement. Additionally, a Federal Program Funding Source Data
Element was added to allow for project association to a federal funding source in order to
facilitate reporting to federal agencies.
Universal Data Elements
The Destination data element has been reclassified as a universal data element, consistent with
HUD’s emphasis on housing outcomes, and a Head of Household data element has been added to
identify the head of household for each project enrollment. Length of Time On the Street, in ES
or a Safe Haven has been added to enable an HMIS to identify individuals or families that meet
the definition of chronically homeless. Housing Status and Zip Code of Last Permanent Address
have been moved from the Universal Data Elements to the Project-Specific Data Elements. The
remaining Universal Data Elements are substantially unchanged from the 2010 Notice. Minor
changes include the addition of response categories to a number of data elements to provide
7
detailed information and to meet the data collection and reporting needs of other federal
agencies, and refining of some existing response categories with the goal of minimizing the need
to utilize the “Other” response category in some fields.
Program-Specific Data Elements
This draft notice includes the addition of a number of data elements within the Program-Specific
section that are required to meet the data collection and reporting needs of other federal targeted
homeless assistance programs including, but not limited to:
1. U.S. Department of Health and Human Services (HHS):


Projects for Assistance in Transition from Homelessness (PATH) funded by
the Substance Abuse and Mental Health Services Administration (SAMHSA)
Runaway and Homeless Youth (RHY) projects funded by the Administration
for Children and Families’ Family and Youth Services Bureau (FYSB)
2. U.S. Department of Housing and Urban Development (HUD):

Housing Opportunities for Persons with AIDS (HOPWA) projects
3. U.S. Department of Veterans Affairs (VA):




Domiciliary Care for Homeless Veterans (DCHV) projects
Grant and Per Diem (GPD) projects
Supportive Services for Veteran Families (SSVF) projects
Veterans Homelessness Prevention Demonstration (VHPD) projects
4. HUD-VA:

HUD-Veterans Affairs Supportive Housing (VASH) projects.
Metadata Elements
Several Metadata Elements have been added in order to facilitate reporting and import/export
functionality. These Metadata Elements are not project or client-related, but instead provide
information about HMIS data, such as when it was collected, which projects entered the data,
and when it was last edited. Some of these Metadata Elements are already implicitly required by
various reports; for example, it is not possible to report on a client’s income at project entry in
the APR if an HMIS solution is not able to distinguish income data collected at project entry
from data collected at another time. The majority of ‘data entry’ for these Metadata Elements
should be performed by the HMIS solution itself; there should be minimal additional data entry
burden for HMIS users.
1.3
Statutory Authority
The HMIS Standards were developed in response to a series of Congressional directives
beginning with the Fiscal Year (FY) 1999 HUD Appropriations Act. In that year, Congress
directed HUD to collect HMIS data from a representative sample of communities in order to
develop an unduplicated count of homeless people nationwide and analyze the use and
effectiveness of homeless assistance services. In subsequent years, Senate and House
Appropriations Committee reports have reiterated Congress’ directive to HUD to:
8
1. assist communities in implementing local Homeless Management Information
Systems (HMIS), and
2. develop an Annual Homeless Assessment Report (AHAR) based on HMIS data from
a representative sample of communities.
Congress renewed its support for the HMIS initiative and the AHAR in conjunction with the
passage of the Transportation, Treasury, Housing and Urban Development, the Judiciary, the
District of Columbia, and Independent Agencies Appropriations Act of 2006 (PL 109-115).
In addition to Congressional direction on HMIS, HUD, other federal agencies and the
U.S. Interagency Council on Homelessness (USICH) are required under various statutory
authorities and Congressional directive to collect information about the nature and extent of
homelessness. Individual programs authorized under the McKinney-Vento Act, as amended by
the HEARTH Act, require the assessment of homeless needs, the provision of services to address
those needs, and reporting on the outcomes of federal assistance in helping homeless people to
become more independent. The major congressional imperatives in HUD’s McKinney-Vento
Act programs are:
1. Assessing the service needs of persons experiencing homelessness;
2. Ensuring that services are directed to meeting those needs;
3. Assessing the outcomes of these services in enabling homeless persons to become
more self-sufficient; and
4. Reporting to Congress on the characteristics of homeless persons and effectiveness of
federal efforts to address homelessness.
Both individually and as a whole, these provisions provide statutory requirements for collecting
comprehensive data on homeless individuals and persons at risk of homelessness and their needs.
1.4
Key Terms
This section defines terms commonly used throughout the Notice.
Annual Homeless Assessment Report (AHAR): HUD’s annual report to Congress on the
nature and extent of homelessness nationwide.
Annual Performance Report (APR): A reporting tool used to track progress and
accomplishments of HUD Shelter Plus Care (S+C), Supportive Housing Programs (SHP),
Section 8 Moderate Rehabilitation for SRO, HOPWA, Continuum of Care (CoC), and Rural
Housing Stability Program-funded projects on an annual basis.
Consolidated Annual Performance and Evaluation Report (CAPER): Annual performance
report for the Consolidated Plan.
Client: An individual about whom a Contributing HMIS Organization (CHO) collects or
maintains personally identifiable information:
1. because the individual is receiving, has received, may receive, or has inquired about
assistance from a CHO; or
2. in order to identify needs, or to plan or develop appropriate assistance within the
CoC.
Continuum of Care (CoC): The composed of representatives of organizations including
nonprofit homeless providers , victim service providers , faith-based organizations, governments,
9
businesses, advocates, public housing agencies, school districts, social service providers, mental
health agencies, hospitals, universities, affordable housing developers, law enforcement,
organizations that serve homeless and formerly homeless veterans, and homeless and formerly
homeless persons organized to carry out the responsibilities of the Continuum of Care
established under 24 CFR part 578.
CoC Project (formerly referred to CoC Program): A project, which may or may not be
funded by HUD, that provides services and/or lodging and is identified by the CoC as part of its
service system, and whose primary purpose is to meet the specific needs of people who are
homeless or at risk of homelessness. CoC projects can be classified as either one that provides
lodging (lodging project) or one that does not provide lodging (services project).
Lodging Project: Provides overnight accommodations and whose primary purpose is to meet
the specific needs of people who are homeless. This includes projects classified as the following
under data element 2.8: Project Type: Emergency Shelter, Safe Haven, Transitional Housing,
Rapid Re-Housing, Permanent Supportive Housing, and Permanent Housing.
Services Project: Does not provide lodging and whose primary purpose is to provide services
that meet the specific needs of people who are homeless or at risk of homelessness. This
includes projects classified as the following under 2.8 Project Type: Homelessness Prevention,
Street Outreach, Day Shelter, Services Only, and Other.
Contributing CoC Project: A CoC project that contributes Protected Identifying Information
(PII) or other client-level data to an HMIS.
Contributing HMIS Organization (CHO): An organization that operates a project that
contributes data to an HMIS.
e-snaps: Online registration, application & grants management system for HUD’s CoC
Programs.
Head of Household: An adult client or minor (if no adult is present in the household) who is
identified as the head of the household. Unless otherwise defined by a federal agency, it is up to
each CoC to identify the criteria for identifying a head of household for purposes of HMIS data
collection.
Homeless Management Information System (HMIS): The information system designated by
the CoC to comply with the requirements of the CoC regulation at 24 CFR 578 and in
anticipation of a final rule for HMIS, which has been proposed but not yet finalized. The HMIS
is used to record, analyze, and transmit client and activity data in regard to the provision of
shelter, housing, and services to individuals and families who are experiencing homeless or at
risk of experiencing homelessness.
Homelessness Data Exchange (HDX): An online tool designed to allow CoCs to submit data to
HUD including the HIC, PIT, and AHAR.
Household: For general HMIS purposes, a household is a single individual or a group of
persons who apply together to a CoC 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. This broad definition may be superseded by more prescriptive definitions of a
household required by a particular agency.
Housing Inventory Count (HIC): An inventory of beds for homeless persons, including
seasonal and overflow beds.
10
HMIS Lead: An organization designated by a CoC to operate the CoC’s HMIS on its behalf.
HMIS Vendor: A contractor who provides materials or services for the operation of an HMIS.
An HMIS vendor includes an HMIS software provider, web server host, data warehouse
provider, as well as a provider of other information technology or support.
Lodging: A bed, room, or other indoor space offered by a project to clients as lodging.
Protected Identifying Information (PII): Information about a project participant that can be
used to distinguish or trace the participant’s identity, either alone or when combined with other
personal or identifying information using methods reasonably likely to be used, which is linkable
to the project participant.
Unaccompanied youth: An individual under the age of 18 with a household size of one.
Unduplicated Count of Homeless Persons: An enumeration of homeless persons where each
person is counted only once during a defined period of time.
User: An employee, volunteer, affiliate, associate, and any other individual who uses or enters
data in the HMIS or another administrative database from which data are periodically provided
to the HMIS.
Victim Service Provider: A private nonprofit organization whose primary mission is to provide
services to victims of domestic violence, dating violence, sexual assault, or stalking. This term
includes rape crisis centers, battered women’s shelters, domestic violence transitional housing
projects, and other projects.
1.5
Victim Service Provider Data in HMIS
Victim service providers that are funded under HUD’s Supportive Housing Program, Shelter
Plus Care Program, Section 8 Moderate Rehabilitation SRO Program, Emergency Solutions
Grant Program, and Continuum of Care Program are prohibited from disclosing any personally
identifying information for purposes of HMIS, per the requirements of the Violence Against
Women and Department of Justice Reauthorization Act of 2005 (Pub. L. 109-162) (VAWA).
Since Victim Service Providers are prohibited from providing any client-related data to HMIS,
HMIS bed and service coverage will be calculated excluding victim service providers from the
universe of CoC projects.
Regardless of funding sources, Project Descriptor data for each CoC project within the CoC
operated by a victim service provider must be recorded in the HMIS, either by project staff
member or by the HMIS system administrator, with the exception of a street address for a facility
that provides victim services to clients.
1.6
Summary of Data Standard Applicability and Collection Requirements
The data standards establish uniform definitions for the types of information to be collected and
protocols for when data are collected and from whom. CHOs may have additional data
collection requirements based on other funding sources, the client population served, and the
types of data necessary to effectively monitor projects. The following exhibits group the HMIS
data elements by type (Project Descriptor, Universal, and Program-Specific) and summarize the
requirements regarding: (1) applicability of each data element by project type for HUD-funded
programs; (2) from whom the data are collected (for client-specific data elements); and (3) when
the data are collected.
11
Other federal agencies will issue applicability guidance, published separately. These agencies
and their programs include, but are not limited to:
1. U.S. Department of Health and Human Services (HHS):
a. Projects for Assistance in Transition from Homelessness (PATH) projects
funded by the Substance Abuse and Mental Health Services Administration
(SAMHSA)
b. Runaway and Homeless Youth (RHY) projects funded by the Administration
for Children and Families’ Family and Youth Services Bureau (FYSB)
2. U.S. Department of Housing and Urban Development (HUD):
a. Housing Opportunities for Persons with AIDS (HOPWA) projects
3. U.S. Department of Veterans Affairs (VA):
a.
b.
c.
d.
Domiciliary Care for Homeless Veterans (DCHV) projects
Grant and Per Diem (GPD) projects
Supportive Services for Veteran Families (SSVF) projects
Veterans Homelessness Prevention Demonstration (VHPD) programs
4. HUD-VA:
a. HUD-Veterans Affairs Supportive Housing (VASH) programs.
12
Exhibit 1-1: Summary of Project Descriptor Data Elements
When collected
Data Elements
1.
2.
3.
4.
5.
6.
7.
8.
Organization Identifier
Organization Name
Project Identifier
Project Name
Direct Service Code
Site Information
Continuum of Care Code
Project Type
Project Applicability
Assigned
once
All CoC Projects
All CoC Projects
All CoC Projects
All CoC Projects
(optional)
All CoC Projects
All CoC Projects
All CoC Projects and Non-CoC Projects
X
Assigned
once;
reviewed
annually
X
X
X
X
X
X
X
9. Bed and Unit Inventory Information
All CoC Lodging Projects1
10. Target Population A (Optional for all projects)
X
11. Target Population B
All CoC Projects
All CoC Lodging Projects
12. Method for Tracking Residential Project Occupancy
All CoC Lodging Projects
X
All CoC Projects
X
13. Federal Funding Source(s)
At least
annually
or more
frequently
if changes
occur
X
X
CoC Lodging Projects include the following Project Types: Emergency Shelter, Transitional Housing, Safe Havens, Permanent Supportive Housing, and Permanent
Housing Only
1
13
Exhibit 1-2: Summary of Universal Data Elements
Subjects
When Collected
Heads of
Household and
Adult
Household
Members
Initial
Project
Entry
Only
Every
Project
Entry
Project
Applicability
All
Clients
1. Name1
All CoC Projects
X
X
2. Social Security Number1
All CoC Projects
X
X
3. Date of Birth1
All CoC Projects
X
X
4. Race1
All CoC Projects
X
X
5. Ethnicity1
All CoC Projects
X
X
6. Gender1
All CoC Projects
X
X
7. Veteran Status
All CoC Projects
8. Disabling Condition
All CoC Projects
9. Residence Prior to Project Entry
All CoC Projects
10. Housing Status
11. Project Entry Date
All CoC Projects
All CoC Projects
X
X
12. Project Exit Date
All CoC Projects
X
X
13. Destination
All CoC Projects
X
X
14. Personal Identification Number
All CoC Projects
X
15. Household Identification Number
All CoC Projects
X
X
16. Head of Household
All CoC Projects
X
X
Data Elements
All Adults
X
Every
Project Exit
X
X
X
X
X
X
X
X
1One
or more of these personal identifiers may need to be asked on subsequent visits to find and retrieve the client’s record. However, this information only
needs to be recorded in HMIS during an initial entry.
14
Exhibit 1-3: Summary of Project -Specific Data Elements
1. Zip Code of Last
Permanent
Address
X
X
X
X
When Collected
HOPWA
ESG
Homelessness
Prevention
ESG
Rapid
Re-Housing
ESG
Emergency Shelter
ESG
Street Outreach
Data Elements
CoC1
HUD Program Applicability
Every
Exit
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
All Clients
X
X
X
X
X
X
All Clients
X
X
X
3. Non-Cash
Benefits
4. Health Insurance
5. Employment
Status
7. Developmental
Disability
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
At Least
Once
Annually
During
Project
Enrollment3
During
Client
Assessment
Near Entry
X
2. Income and
Sources
6. Physical Disability
Subjects
At Least
Once
Every Three
Months
During
Project
Enrollment2
At Every
Contact/
Service/
Referral
X
15
9. HIV/AIDS
10.
Mental Health
11. Substance
Abuse
ESG
Homelessness
Prevention
ESG
Rapid
Re-Housing
ESG
Emergency Shelter
Every
Exit
X
All Clients
X
X
X
X
X
X
All Clients
X
X
X
X
X
X
All Clients
X
X
X
X
X
X
All Clients
X
X
X
X
Heads of
Household
and Adult
Household
Members
X
X
X
X
X
X4
All Clients
14. Date of
Engagement
X4
All Clients
X
15. Veteran’s
Information
X
X
16. Services
Provided
X
17. Financial
Assistance
Provided
At Least
Once
Annually
During
Project
Enrollment3
X
X
Contact
At Least
Once
Every Three
Months
During
Project
Enrollment2
X
12. Domestic
Violence
13.
During
Client
Assessment
Near Entry
HOPWA
8. Chronic Health
Condition
When Collected
Subjects
CoC1
Data Elements
ESG
Street Outreach
HUD Program Applicability
X
X
X
At Every
Contact/
Service/
Referral
X
X
X
All
Veterans
X
X
X
All Clients
X
X
X
X
All Clients
X
16
18. Area Median
Income (AMI)
Percentage Used
for Eligibility
When Collected
HOPWA
ESG
Homelessness
Prevention
ESG
Rapid
Re-Housing
ESG
Emergency Shelter
ESG
Street Outreach
Data Elements
CoC1
HUD Program Applicability
X
19. Sexual
Orientation
20. Last Grade
Completed
21.
School Status
22. General Health
Status
23. Pregnancy
Status
24. Funding
Source for
Residence Prior
to Project Entry
X
Subjects
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
During
Client
Assessment
Near Entry
X
At Least
Once
Annually
During
Project
Enrollment3
Every
Exit
At Every
Contact/
Service/
Referral
X
X
All Clients
X
All Clients
X
All Clients
or Heads of
Household
and Adult
Household
Members
All Females
of Childbearing
Age
Heads of
Household
and Adult
Household
Members
At Least
Once
Every Three
Months
During
Project
Enrollment2
X
X
X
X
17
When Collected
Subjects
25. Funding
Source for
Destination
X
Heads of
Household
and Adult
Household
Members
26. Referrals
Provided
X
All Clients
Data Elements
CoC1
HOPWA
ESG
Homelessness
Prevention
ESG
Rapid
Re-Housing
ESG
Emergency Shelter
ESG
Street Outreach
HUD Program Applicability
27. Reason for
Leaving
28. Project
Transition
X
29. Project
Completion
Status
30. Family
Reunification
Achieved
31. Physical
Health Status
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
During
Client
Assessment
Near Entry
At Least
Once
Every Three
Months
During
Project
Enrollment2
At Least
Once
Annually
During
Project
Enrollment3
Every
Exit
At Every
Contact/
Service/
Referral
X
X
X
X
X
18
32. Referral
Source
33. Transitional,
Exitcare, or
Aftercare Plans
and Actions
34. Project
Completion
Status
35. Family
Reunification
Achieved
36. Physical
Health Status
37. Dental Health
Status
When Collected
HOPWA
ESG
Homelessness
Prevention
ESG
Rapid
Re-Housing
ESG
Emergency Shelter
ESG
Street Outreach
Data Elements
CoC1
HUD Program Applicability
Subjects
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
During
Client
Assessment
Near Entry
At Least
Once
Every Three
Months
During
Project
Enrollment2
At Least
Once
Annually
During
Project
Enrollment3
Every
Exit
At Every
Contact/
Service/
Referral
X
X
X
X
X
19
38. Mental Health
Status
Percent of AMI
41. Formerly
Chronically
Homeless
42. Federal
Funding Source
for Project
Enrollment
Subjects
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
Heads of
Household
and Adult
Household
Members
39. Housing
Category
40.
When Collected
HOPWA
ESG
Homelessness
Prevention
ESG
Rapid
Re-Housing
ESG
Emergency Shelter
ESG
Street Outreach
Data Elements
CoC1
HUD Program Applicability
X
X
X
X
X
Heads of
Household
During
Client
Assessment
Near Entry
At Least
Once
Every Three
Months
During
Project
Enrollment2
At Least
Once
Annually
During
Project
Enrollment3
Every
Exit
At Every
Contact/
Service/
Referral
X
X
X
X
X
CoC programs include the Supportive Housing Program (SHP), Shelter Plus Care, and the Section 8 Moderate Rehabilitation for Single Room Occupancy Dwellings
(SRO) Program, and the new CoC Program authorized under the McKinney-Vento Act as amended by the HEARTH Act of 2009.
2 Only collected at least once every three months if the period between entry and exit exceeds three months.
3 Only collected at least once annually if the period between entry and exit exceeds 1 year.
4 Only street outreach projects funded by a CoC program.
1
20
2.
Project Descriptor Data Elements
This section describes the data to be recorded about each CoC project in the CoC jurisdiction and
updated in the HMIS at least annually. With few exceptions, which are specified in this section,
the CoC must record project information in the HMIS on all CoC projects within its jurisdiction,
regardless of whether the project is a Contributing HMIS Organization or a non-contributing
HMIS Organization. The CoC must also identify in the HMIS, per data element 2.8 (Project
Type), whether a project is a Contributing HMIS Organization (CHO) or a non-Contributing
HMIS Organization. CoC projects that operate in multiple CoCs must be established as distinct
projects within each CoC’s HMIS.
The general purpose of these requirements is to ensure that the HMIS is the central repository of
information about homelessness in the CoC, including information about projects and clients.
Including Project Descriptor data in the HMIS ensures that uniform information about each CoC
project is available to:
1. complete required reports including the APR, the AHAR, and the HIC that is part of a
CoC’s competitive funding application;
2. track bed utilization;
3. calculate rates of HMIS participation; and
4. monitor data quality. Complete Project Descriptor information also enhances the
HMIS as a tool for supporting information and referral services.
In creating project records in HMIS, system administrators should be cognizant of the need for
program-reporting. For example, projects that are required to produce an APR, must include
only clients who were served under a particular HUD program. If a project record is set up in
HMIS to include projects that receive funding from more than one Federal program, then it must
be possible to identify, for each client served, the specific Federal program under which the
client was being served.
The Project Descriptor Data Elements are:
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.1
Organization Identifier
Organization Name
Project Identifier
Project Name
Direct Service Code
Site Information
Continuum of Care Code
Project Type
Bed and Unit Inventory Information
Target Population A
Target Population B
Method for Tracking Project Occupancy
Federal Funding Source(s)
Organization Identifier
Rationale: To uniquely identify each organization that operates a CoC project within the CoC.
Data Source: Automatically generated by the HMIS solution.
21
When Data are Collected: The Organization Identifier is assigned once for each organization.
An Organization Identifier must be associated with each CoC project operated by the
organization.
Subjects: All organizations operating a CoC project within the CoC.
Definitions and Instructions: A unique Organization Identifier must be assigned to each
distinct organization that operates a CoC project. There is no specified format for this data
element. The Organization Identifier can be a randomly generated number or some other code
so long as each organization receives a distinct identifier that is consistently associated with that
organization. HUD is aware that in many cases the Organization Identifier and the Project
Identifier may be the same.
Required Response Categories:
Project Descriptor Data Element
2.1 Organization Identifier
Response Categories
A unique Organization Identifier needs to be assigned to each
distinct organization that operates a CoC project. There is no
specified format for this data element.
Special Issues: None.
Changes from Previous Notice: None.
2.2
Organization Name
Rationale: To identify the name of each organization that operates a CoC project within the
CoC.
Data Source: HMIS Lead.
When Data are Collected: Data are collected once for each organization but must be reviewed
annually to ensure accuracy.
Subjects: All organizations operating a CoC project.
Definitions and Instructions: Record the organization name. HUD is aware that in many cases
the Organization Name and the Project Name may be the same.
Required Response Categories:
Project Descriptor Data Element
2.2 Organization Name
Response Categories
An Organization Name needs to be identified for each
distinct organization that operates a CoC project.
Special Issues: It is recommended that Organization Name and Project Name (Project
Descriptor Data Element 2.4) for each CoC organization and project be standardized across all
HUD-related information gathering and reporting activities (APR, AHAR, PIT, and HIC).
Generally, use of an organization’s legal name will achieve this consistency. CoCs may institute
naming conventions to ensure that the HMIS captures consistent and standardized names for
organizations and projects referenced in e-snaps, in the HDX, and in individual project reports.
It is recommended that HMIS solution also track aliases for Organization Name in order to
22
ensure that the organization can be located in the system based on names that users readily
recognize.
Changes from Previous Notice: None.
2.3
Project Identifier
Rationale: To uniquely identify each CoC project within the CoC.
Data Source: Automatically generated by the HMIS solution at the time the project is created in
the HMIS.
When Data are Collected: The Project Identifier is assigned once for each CoC project. The
Project Identifier must be associated automatically with each client for each service record.
Subjects: All CoC projects.
Definitions and Instructions: A unique Project Identifier must be assigned to each distinct
CoC project. There is no specified format for this data element. The Project Identifier can be a
randomly generated number or some other code so long as each project receives a distinct
identifier that is consistently associated with that project. All other Project Descriptor data
elements must be associated with the Project Identifier.
Required Response Categories:
Project Descriptor Data Element
2.3 Project Identifier
Response Categories
A unique Project Identifier needs to be assigned to
each distinct CoC project. There is no specified
format for this data element.
Special Issues: None.
Changes from Previous Notice: None.
2.4
Project Name
Rationale: To identify the name of each CoC project within the CoC. This can be used within
the solution to associate a client with a project. As applicable, this name must be consistent with
the project name listed on a CoC’s HIC, the APR, and other federal reports.
Data Source: HMIS Lead or project staff.
When Data are Collected: Data are collected once for each CoC project but must be reviewed
annually to ensure accuracy.
Subjects: All CoC projects.
Definitions and Instructions: Record the project name.
Required Response Categories:
Project Descriptor Data Element
2.4 Project Name
Response Categories
A unique Project Name must be recorded for each
distinct CoC project.
23
Special Issues: It is recommended that Project Name and Organization Name for each CoC
organization and project be standardized across all HUD-related information gathering and
reporting activities. CoCs may institute naming conventions to ensure that the HMIS captures
consistent and standardized names for organizations and project referenced in e-snaps, in the
HDX, and in individual project reports. It is recommended that HMIS solution also track aliases
for Project Name in order to ensure that the organization can be located in the system based on
names that users readily recognize.
Changes from Previous Notice: None
2.5
Direct Service Code
Rationale: To differentiate CoC projects in the HMIS that provide direct services from
organizations that do not provide direct services (such as HMIS Lead Agencies, organizations
that oversee or support CoC projects, or HMIS vendors). The Direct Service Code helps to
ensure that all client-level HMIS records are linked to a specific direct service projects.
Data Source: HMIS Lead.
When Data are Collected: The Direct Service Code is assigned for new CoC projects before
data are associated with them.
Subjects: All CoC projects.
Definitions and Instructions: If clients can directly enroll in the project then the Direct Service
Code is ‘Yes.’ If the project does not enroll clients directly, then the Direct Service Code is
‘No.’ CoC projects that provide direct services to clients but do not have a formal enrollment
process or period (e.g., 2-1-1 Information & Referral programs, street outreach, drop-in or day
resource centers, food pantries, or other supportive services) should code ‘Yes.’
Required Response Categories:
Project Descriptor Data Element
2.5 Direct Service Code
Response Categories
No
Yes
Special Issues: It is critical that information about client enrollments and/or service encounters
is associated with a project that serves clients, and HMIS solutions must enforce this
requirement. It is not necessary that the mechanism for this enforcement is linked to this data
element, nor is it necessary that the data element be used at all as long as it is not possible for a
user to inadvertently enter client project enrollment or service data into a project that does not
actually serve clients.
Changes from Previous Notice: Clarification about the intent of the data element under Special
Issues.
2.6
Site Information
Rationale: To describe the overall project configuration and the location(s) where the project
provides lodging and/or services (i.e., the project service site(s)) within the CoC.
Data Source: HMIS Lead.
24
When Data are Collected: Data are collected once for each CoC project but must be reviewed
annually to ensure accuracy.
Subjects: All CoC projects.
Definition and Instructions: Site information is collected at the project - and site-level. For each
CoC project, record the project site configuration type in accordance with the guidance below.
For the principal project service site within the CoC, or the site where the greatest level of
lodging or services are provided, record: (1) the site address; (2) geocode; (3) site type; and
(4) lodging or housing type.
2.6A Site Configuration Type. For the overall project, record the site configuration type as
follows:

Single site, single building. Housing units, lodging, or service encounters are at
one site, in a single structure.

Single site, multiple buildings. Housing units, lodging, or service encounters are
at one site, in multiple structures (e.g., single apartment complex with multiple
buildings and project units in two or more buildings).

Multiple sites. Housing units, lodging, or service encounters are at multiple sites
(e.g., scattered-site units, outreach).
2.6B Site Address. For the project service site, record the street address, city, state, and zip code.
Victim service providers are exempt from recording address information.
2 6C Geocode. For the project service site, record the geocode associated with the geographic
location of the site. HUD provides a list of geocodes as part of the annual CoC application
process. Geocodes must be updated annually. Mobile projects (e.g., street outreach) should
record the Geocode based on the location of their administrative office. Scattered-site housing
project should record the Geocode where the greatest number of beds are located or where most
beds are located as of the last inventory update.
2.6D Lodging or Housing Type. For lodging projects (Emergency Shelter, Safe Haven,
Transitional Housing, Permanent Supportive Housing, and Permanent Housing), to record the
appropriate housing type for the project service site. Projects that do not offer lodging should
select “Not applicable: non-residential project.”




Mass shelter/barracks. Multiple individuals and/or family households sleep
in a large room with multiple beds.
Dormitory/hotel/motel. Most individuals and/or families share small to
medium sized sleeping rooms or have private sleeping rooms. Persons may
share a common kitchen, common bathrooms, or both.
Shared housing. Most individuals and/or families reside in one or more
shared housing units that house up to 8 individuals or 4 families. Each unit
includes a kitchen and bath. Each family generally has a private sleeping
room, though more than one individual may share sleeping space.
Single Room Occupancy (SRO) units. Most individuals reside in a private unit
with a sleeping/living room intended for one occupant that contains no
sanitary facilities or food preparation facilities, or contains either, but not
both, types of facilities.
25

Single apartment (non-SRO) units. Most individuals and/or families reside in
a self-contained apartment intended for one individual or family household
that includes a private kitchen and bath.
 Single homes/townhouses/duplexes. Most individuals and/or families reside in
a self-contained home/townhouse/duplex intended for one individual or family
household.
 Not applicable: non-residential project. The project does not offer lodging to
clients.
2.6E Principal Site. For projects that record site data for multiple sites, identify whether the site
is the principal site. The principal site is the site where the project provides the greatest number
of lodging and/or services. Projects without a principal project service site (e.g., mobile projects
such as street outreach and scattered-site housing) should record the address of their
administrative office as the principal site.
Required Response Categories:
Project Descriptor Data Element
2.6 Site Information
Site Configuration
Type
Response Categories
Single site, single building
Single site, multiple buildings
Multiple sites
Site Address
Address
City
State (two-letter state abbreviation)
Zip code (5-digit numeric code)
Geocode
Lodging or Housing
Type
Numeric geocode format
Mass shelter/barracks
Dormitory/hotel/motel
Shared housing
Single Room Occupancy (SRO) units
Single apartment (non-SRO) units
Single homes/townhouses/duplexes
Principal Site
Not applicable: non-residential project
Yes
No
Special Issues: Projects may choose to record the Site Information data element for each site or
facility operated by the project. For example, if a single emergency shelter project operates two
mass shelter facilities, the project may choose to record site information for two sites. The
HMIS must have the capability of allowing projects to enter site information for multiple sites.
Projects that are physically located in multiple CoCs must be recorded as distinct projects within
each CoC’s HMIS.
Changes from Previous Notice: Site type has been removed as an aspect of this data element
since the Project Type data element now includes additional classifications that distinguish
between projects that offer lodging (i.e., Emergency Shelter, Safe Haven, Transitional Housing,
Rapid Re-Housing, Permanent Supportive Housing, and Permanent Housing) from projects that
26
do not offer lodging, including those projects that may provide rental assistance to persons in
community-based housing (i.e., Homelessness Prevention, Street Outreach, Day Shelter,
Services Only, and Other). Principal Site is a new component of this data element; it enables
identification of the principal site for projects that record data for multiple sites.
2.7
Continuum of Care Code
Rationale: To associate each CoC project with a CoC for reporting purposes.
Data Source: HMIS Lead.
When Data are Collected: The CoC code is collected once for each CoC project but must be
reviewed annually and updated if there are changes to the CoC.
Subjects: All projects that directly serve clients.
Definitions and Instructions: Each CoC project is assigned a designated HUD CoC code.
Required Response Categories:
Project Descriptor Data Element
2.7 Continuum of Care Code
Response Categories
HUD-assigned CoC code
Special Issues: Projects that are located in more than one CoC must either establish separate
project records in each CoCs HMIS where there are different HMISs for each CoC.
Changes from Previous Notice: None.
2.8
Project Type
Rationale: To associate each CoC project with the specific type of assistance offered.
Data Source: HMIS Lead.
When Data are Collected: This data element is collected once for each CoC project but it must
be reviewed annually and updated when project types change.
Subjects: All CoC projects regardless of funding (CoC-funded or not CoC funded Definitions
and Instructions: Identify whether the program is a CoC project or a non-CoC project.
For each CoC project, select the one response category that best describes the project. If
multiple distinct types of assistance (e.g., emergency shelter and rapid re-housing) are offered,
each component should be treated as a separate project in the HMIS.
Select the appropriate CoC project type that best corresponds to the following types of projects:

Homelessness Prevention: a project that offers services necessary to prevent a
person from moving into an emergency shelter or place not meant for human
habitation.

Street Outreach: a project that offers services necessary to reach out to
unsheltered homeless people, connect them with emergency shelter, housing, or
critical services, and provide urgent, non-facility-based care to unsheltered
homeless people who are unwilling or unable to access emergency shelter,
housing, or an appropriate health facility.
27

Emergency Shelter: a project that offers temporary shelter (lodging) for the
homeless in general or for specific populations of the homeless, and which does
not require occupants to sign leases or occupancy agreements.

Day Shelter: a project that offers daytime facilities and services (no lodging) for
persons who are homeless.

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.

Transitional Housing: means housing, where all program participants have signed
a lease or occupancy agreement, the purpose of which is to facilitate the movement
of homeless individuals and families into permanent housing within 24 months or
such longer period as HUD determines necessary. The program participant must
have a lease or occupancy agreement for a term of at least 1 month that ends in 24
months and cannot be extended.

Rapid Re-Housing: a permanent housing project that provides housing relocation
and stabilization services and short- and/or medium-term rental assistance as
necessary to help a homeless individual or family move as quickly as possible into
permanent housing and achieve stability in that housing.

Permanent Supportive Housing: a project that offers permanent housing and
supportive services to assist homeless persons with a disability to live
independently.

Permanent Housing: a project that offers community-based housing without a
designated length of stay. To be permanent housing, the program participant must
be the tenant on a lease for a term of at least 1 year, which is renewable for terms
that are a minimum of 1 month long, and is terminable only for cause.

Services Only: a project that offers supportive services to address the special
needs of participants, such as child care, employment assistance, and transportation
services.

Other: a project that offers services, but does not provide lodging, and cannot
otherwise be categorized as another project type, per above.
28
Required Response Categories:
Project Descriptor Data Element
2.8 Project Type
CoC Project
CoC Project Type
Response Categories
Yes
No
Homelessness Prevention
Street Outreach
Emergency Shelter
Day Shelter
Safe Haven
Transitional Housing
Rapid Re-Housing
Permanent Supportive Housing
Permanent Housing (e.g., Mod Rehab SRO, subsidized housing without services)
Services Only
Other
Special Issues: CoC, HMIS and project staff should consult guidance on classifying CoC
project for purposes of the HIC and other CoC reporting. Additional information may be found
at www.HUDHRE.info.
Changes from Previous Notice: “Homeless Outreach” has been changed to “Street Outreach.”
“Homelessness Prevention” and “Rapid Re-Housing” response categories have been added to
replace the former “Homelessness Prevention and Rapid Re-Housing” category. A description
of each project type has been added to improve consistency in project classification and to
distinguish between projects that offer lodging from those that do not. Additionally, CoCs must
now record whether a project is a CoC project or a non-CoC project.
2.9
Bed and Unit Inventory Information
Rationale: To record inventory information for each CoC project that offers lodging
(Emergency Shelter, Safe Haven, Transitional Housing, Permanent Supportive Housing) in order
to produce HIC data.
Data Source: HMIS Lead, CoC Lead or project staff.
When Data are Collected: At least annually, or whenever inventory information changes.
Subjects: All Emergency Shelter, Safe Haven, Transitional Housing, Rapid Re-Housing and
Permanent Supportive Housing projects.
Definitions and Instructions: One or more Bed and Unit Inventory Information records must
be established for each project that offers lodging (Emergency Shelter, Safe Haven, Transitional
Housing, Rapid Re-Housing, and Permanent Supportive Housing). Historical values are required
for the inventory in order to generate reports that relate to various reporting periods. These fields
must be transactional, meaning they must be able to record multiple values over time along with
the date that the information changed.
An HMIS may track the data in a variety of ways as long as historical data are maintained, the
HIC can be produced, and inventory data can be mapped to the linked inventory data elements
described in this section. Data can be collected annually, as long as the data reflects the changes
in inventory over the course of the year, rather than at only a single point in time. The inventory
history should reflect changes in standard project operations, but need not reflect day-to-day
29
fluctuations. Examples of housing inventory changes that should be tracked historically include:
the addition or removal of a group of new beds or units; the addition or removal of seasonal beds
that are available for any period in the year; a project decision to target beds to a different
household type; or changes in HMIS bed participation.
The inventory data elements are: Household Type, Bed Type, Availability, Bed Inventory, Unit
Inventory, Inventory Start Date, Inventory End Date, HMIS Participating Beds, HMIS
Participation Start Date, and HMIS Participation End Date. Permanent supportive housing
projects must also record the Chronic Homeless Bed inventory.
Records must be established for each project depending on the combination of Household Types
served, Bed Types, and Availability as described in 2.9A, 2.9B, and 2.9C. A project that serves
both households without children and households with at least one adult and one child will have
at least two Bed and Unit Inventory information records in order to track inventory information
by household type. If a project operates different types of beds (e.g., year-round and seasonal)
then a separate record is established for each bed type. For example, a project that serves single
adults and 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.
(See the explanation of the Fair Housing Act’s prohibition on discrimination because of familiar
status under “Special Issues.”)
The bed inventory includes the total number of beds for each household type, bed type, and the
availability of those beds throughout the year. For example, if a project has 50 year-round
facility-based beds as of October 1, 2012, the inventory record should reflect 50 year-round beds.
If 50 new year-round facility-based beds are added on January 1, 2013, an end date of December
31, 2012, should be recorded and a new record should be created with a total inventory of 100
year-round facility-based beds and a start date of January 1, 2013. If a year-round project closes,
the Bed and Unit Inventory information record must be updated to indicate an end date equal to
the last date of project operation.
If a seasonal project has a change in bed/unit inventory capacity, a new record must be
established with the bed/unit inventory revised to reflect the new capacity. The start date must
be the date when the new beds are available. For example, a project has 100 seasonal facilitybased beds that are available January 1 through March 31, with an additional 50 seasonal
facility-based beds available starting February 1 and ending
March 31. The project must enter a Bed and Unit Inventory Information record showing 100
seasonal facility-based beds with the start date of January 1 and an end date of January 31. A
new Bed and Unit Inventory information record would then be entered for the project with an
inventory of 150 seasonal facility-based beds, a start date of
February 1, and an end date of March 31.
For HMIS participation, projects must report the total number of beds participating (or covered)
in HMIS (see Section 1.4 for definition). A bed is considered a “participating HMIS bed” if the
project makes a reasonable effort to record all universal data elements on all clients served in that
bed and discloses that information through agreed upon means to the HMIS Lead at least once
annually. If a project is only reporting data for clients staying in a portion of its beds, then only
that portion of the beds must be counted as participating in HMIS. Non-contributing CoC
projects must enter “0” in the HMIS participating beds field.
2.9A Household Type. This data element describes the household type served by beds and units
counted in the Bed and Unit Inventory Information Data Elements. If some or all beds and units
30
are not designated exclusively for a particular type of household, then record the household type
most frequently served by the associated beds and units. For purposes of this data element,
persons 18 and over are considered adults and persons under 18 are children. Record the
household type for the associated beds and units as follows:

Households without children. Beds and units serving households with adults
only. This includes households composed of single adults and multiple adults.
(Housing covered under the Fair Housing Act cannot deny admission to families
with children: See “Special Issues.”)

Households with at least one adult and one child. Beds and units are intended for
households with at least one adult and one minor child.

Households with only children. Beds and units are intended for households with
only minor children, including unaccompanied children and households with
multiple children only (e.g., juvenile parent and child).
2.9B Bed Type (Emergency Shelter Only). The Bed Type describes the type of emergency
shelter beds based on whether beds are: located in an emergency shelter facility (including cots
or mats); provided through a voucher with a hotel or motel; or other types of beds. Record the
bed type as follows:



Facility-based. Beds (including cots or mats) are located in an emergency shelter
or other facility dedicated for use by persons who are homeless.
Voucher. Beds are located in a hotel or motel and made available by the
homeless assistance project through vouchers or other forms of payment.
Other. Beds are located in a church or other facility not dedicated for use by
persons who are homeless.
2.9C Availability (Emergency Shelter Only). Describes the availability of emergency shelter
beds based on whether beds are available on a planned basis year-round or seasonally (during a
defined period of high demand), or on an ad hoc or temporary basis as demand indicates. Record
the availability as follows:

Year-round. Beds are available on a year-round basis.

Seasonal. Beds/units are available on a planned basis, with set start and end
dates, during an anticipated period of higher demand.

Overflow. Beds/units 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.
2.9D Bed Inventory. The bed inventory data element is an integer that tracks the total number of
beds available for occupancy as of the inventory start date (see 2.9G). Projects that serve a
mixed population without a fixed number of beds per household type should divide the beds
based on average utilization. For example, a project has 100 beds that could be used by either
households without children or households with at least one adult and one child. If one-half of
the households are without children on an average night, then the project enters two separate Bed
and Inventory Records for the 50 beds for households without children and for the 50 beds for
households with at least one adult and one child. Projects that only have units (no fixed number
of beds) can use a multiplier factor to estimate the number of beds (e.g., a project with 30 family
units and an average family size of 3 would enter 90 beds).
31
2. 9E Chronic Homeless Bed Inventory (Permanent Supportive Housing Only). The chronic
homeless bed inventory data element is an integer that tracks the total number of beds available
for occupancy for persons who are chronically homeless (as defined by HUD) as of the inventory
start date recorded in 2.9G. A chronically homeless bed is a bed that is readily available and
targeted to chronically homeless persons. The number of beds for chronically homeless persons
is a subset of the total permanent supportive housing bed inventory for a given project and must
be equal to or less than the total bed inventory. All the beds that have been funded by the HUD
Samaritan Bonus Project must be captured in this category.
2.9F Unit Inventory. The unit inventory data element is an integer that tracks the total number of
units available for occupancy as of the inventory start date recorded in
2.9G. 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 used for lodging as the unit integer.
2.9G Inventory Start Date. The inventory start date is the date when the Bed and Unit Inventory
information first applies. This may represent the date when a change in household type, bed
type, availability, bed inventory or unit inventory occurs for a given project.
2.9H Inventory End Date. The inventory end date is the date when the Bed and Unit inventory
information as recorded is no longer applicable (i.e., the day after the last night when the record
is applicable). This may be due to a change in household type, bed type, availability, bed
inventory or unit inventory. For seasonal beds, this should reflect the projected end date for the
seasonal bed inventory.
2.9I HMIS Participating Beds. This data element is an integer that tracks the total number of
beds participating in HMIS as of the HMIS participation start date recorded in 2.9J. For projects
that serve a mixed population without a fixed number of beds per household type, record
participating beds according to instructions provided in 2.9D.
2.9J HMIS Participation Start Date. This is the date when the HMIS participating bed
information first applies (i.e., the date when a change in the number of HMIS participating beds
occurs for a project’s Bed and Unit inventory record). The HMIS Participation Start Date is the
earliest project entry date that could be associated with a client using the bed or unit.
2.9K HMIS Participation End Date. The HMIS participation end date is the date when the
HMIS Participation information record is no longer applicable (i.e., the day after the last night
when the number of HMIS participating beds is applicable for a project’s Bed and Unit
Inventory record).
32
Required Response Categories:
Project Descriptor Data Element
2.9 Bed and Unit Inventory Information
Household Type
Bed Type (ES Only)
Availability (ES Only)
Bed Inventory
CH Bed Inventory (PSH Only)
Unit Inventory
Inventory Start Date
Inventory End Date
HMIS Participating Beds
HMIS Participation Start Date
HMIS Participation End Date
Response Categories
Households without children
Households with at least one adult and one child
Households with only children
Facility-based
Voucher
Other
Year-round
Seasonal
Overflow
(integer)
(integer)
(integer)
(date)
(date)
(integer)
(date)
(date)
Special Issues: These data may also be collected separately for distinct sites within a project, as
long as they can be aggregated to the project level.
Projects may choose to create a separate Bed and Unit Inventory Information record to track
inventory under development. In such instances, a projected start date for a new or expanded
project may be tracked by recording the total beds and units expected along with a future start
date.
The number of beds participating in HMIS must not exceed the total number of corresponding
beds recorded in the Bed and Unit Inventory Information record at any point in time. Beds must
only be recorded as participating if they meet the definition of HMIS participation as described
in Section 1.3.
Projects that target certain populations are advised that nothing in these standards allow for
circumventing fair housing laws. The Fair Housing Act prohibits discrimination because of inter
alia, 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.
Changes from Previous Notice: Households with only children was added as a household type
in order to improve consistency between project data as recorded in the HIC and other HUD
reports (e.g., AHAR and APR). Clarification was added to Bed Type and Availability to indicate
that these data are only required for emergency shelter projects.
2.10
Target Population A (Optional)
Rationale: This information may be used to track bed utilization and service gaps.
Data Source: HMIS Lead.
When Data are Collected: At least annually, or whenever inventory information changes.
Subjects: All CoC projects.
33
Definitions and Instructions: Identify the appropriate target population served by the project.
Select only one response. A population is considered a "target population" if the project is
designed to serve that population and at least three-fourths (75 percent) of the clients served by
the project fit the target group descriptor.
Response Categories:
2.10 Target Population A
Target Population Type
Project Descriptor Data Element
Response Categories
Definition
SM
Single Males (18 years and older)
SF
Single Females (18 years and older)
SMF
Single Males and Females (18 years and older)
CO
Couples Only, No Children
SM+HC
Single Males and Households with Children
SF+HC
Single Females and Households with Children
HC
Households with Children
CM
Unaccompanied Children-Males (under 18)
CF
Unaccompanied Children-Females (under 18)
Unaccompanied Children-Males and Females
CMF
(under 18)
Single Male and Female and Households with
SMF+HC
Children
Special Issues: Nothing in these standards permits violating fair housing laws. The Fair
Housing Act prohibits discrimination because of race, color, religion, sex, familial status,
disability, or national origin. Except where otherwise permitted by the federal program statute,
housing covered under the Fair Housing Act may not deny admission on the basis of any
protected class.
Changes from Previous Notice: “Unaccompanied Young Males (under 18)” was changed to
“Unaccompanied Children-Males (under 18).” “Unaccompanied Young Females (under 18)”
was changed to “Unaccompanied Children-Females (under 18).” “Unaccompanied Young
Males and Females (under 18)” was changed to “Unaccompanied Children-Males and Females
(under 18).” “YM,” “YF,” and “YMF” were changed to “CM,” “CF,” and “CMF,” respectively.
2.11
Target Population B
Rationale: To allow HMIS to produce the HIC.
Data Source: HMIS Lead.
When Data are Collected: At least annually, or whenever inventory information changes.
Subjects: All CoC projects.
Definitions and Instructions: Record the appropriate Target Population B served by the
project. Select only one response. If a project does not target one of these populations, select
“NA: Not Applicable.” A population is considered a "target population" if the project is
designed to serve that population and at least 75 percent of the clients served by the project fit
the target group descriptor.



DV: Domestic Violence victims. The project targets persons who have experienced
domestic violence.
VET: Veterans. The project targets veterans and their household members.
HIV: Persons with HIV/AIDS. The project targets persons with HIV/AIDS.
34


RHY: Runaway and Homeless Youth. The project targets runaway and homeless
individuals under the age of 18.
NA: Not Applicable. The project does not target domestic violence victims, veterans,
persons with HIV/AIDS, or runaway and homeless youth.
Required Response Categories:
Project Descriptor Data Element
2.11 Target Population B
Target Population Type
Response Categories
DV: Domestic Violence victims
VET: Veterans
HIV: Persons with HIV/AIDS
RHY: Runaway and Homeless Youth
NA: Not Applicable
Special Issues: None.
Changes from Previous Notice: The “RHY: Runaway and Homeless Youth” target population
has been added to the response categories for Target Population B.
2.12
Method for Tracking Residential Occupancy
Rationale: This data element is required to identify the method for accurately calculating
project utilization and length of stay.
Data Source: HMIS Lead.
When Data are Collected: Annually.
Subjects: All residential homeless assistance projects.
Definitions and Instructions: Record the method used to track the actual nights that a client
stays at a project. The standard method for projects that offer lodging and complete an APR or
provide data for a CAPER must be based on a comparison of entry and exit dates. A project that
offers lodging and is not required to produce an APR or provide data for a CAPER may
alternatively use a bed management tool or service transaction approach to report the number of
persons receiving shelter/housing on a particular night.
Required Response Categories:
Project-Descriptor Data Element
2.12 Method for Tracking Residential Occupancy
Response Categories
Project Entry and Exit Date Comparison
Bed Management Model
Service Transaction Model
Special Issues: Taken together, the Project Entry Date and Project Exit Date may be used for
tracking length of stay in projects that offer lodging. However, tracking length of stay using
these two data elements can be problematic for some projects, especially large shelter projects
that experience a high degree of client turnover on a nightly basis. Two alternative methods for
tracking length of stay are described below. Projects that utilize either of these methods should
continue to enter (or be able to infer) a Project Entry Date and a Project Exit Date. Note that the
Project Entry and Project Exit Date Comparison method must be used by residential projects
receiving HUD homeless assistance funding to determine length of stay.
35
Bed Management Model. If the HMIS solution bed management functionality can store
historical information on the actual night(s) of occupancy separately for each client, bed
management modules can be used as an alternative to project entry and exit dates for projects
that are not required to produce an APR or to produce data for a CAPER to track the actual
nights a client stays in a residential project. For instance, a seasonal emergency shelter might
enroll a client in a project using the Project Entry Date the first time the person stays in the
shelter. The project might then prefer to track the actual nights the person stayed throughout the
season using a bed management module, rather than entering and exiting the individual every
time the person left the project. At the end of the season, or after a specified period of nonattendance, the person would be exited from the project designating a Project Exit Date.
Bed management systems used to track actual lengths of stay for projects must: (1) assign a bed
to a specific person; (2) restrict each bed to one person, such that a bed cannot be assigned to
more than one person at any given time; (3) maintain historical bed utilization data for reporting
purposes; and (4) provide a mechanism to aggregate distinct nights stayed to calculate each
client’s total length of stay in the project. If using a bed management system to track shelter
stays, the project must record every night of shelter stayed for every client served, mirroring the
requirements for project entry and exit date.
Service Transaction Model. Projects may use a similar approach to tracking nights of shelter
provided using a service transaction approach, where each night of shelter is listed as a shelter
service provided to the client wherever “services received” are recorded. The service transaction
model is acceptable if: (1) the project records every discrete night (or series of nights) that
residential services are recorded; (2) the system maintains historical data on the residential
service provided; and (3) the duration of each residential stay can be accurately determined and
aggregated to calculate each client’s total length of stay in the project. If using a service
transaction approach to track shelter stays, the project must record residential services mirroring
the requirements for project entry and exit date.
Changes from Previous Notice: None.
2.13
Federal Funding Source(s)
Rationale: To identify federal funding sources that support each project in the CoC for purposes
of understanding which funding source(s) are used to support projects in the CoC and assuring
accurate and complete reporting, according to each funder’s reporting requirements.
Data Source: Project staff.
When Data Are Collected: Data are collected once for each project but must be reviewed
annually to ensure that the information is up to date.
Subjects: All CoC projects.
Definition and Instructions: Select one or more federal funding source(s) that support the CoC
project, if applicable. If the CoC project receives no federal funding, select “NA: Not
Applicable.” A Grant Identifier should be assigned to each federal funding source. All
subgrantees of a principal grant should use the same Grant Identifier as the principal grantee to
allow for aggregated reporting by the principal grantee. The Grant Identifier may be the number
assigned by the funding source, but it need not be as long as it uniquely identifies the grant and
allows for grant-level reporting.
36
Required Response Categories:
Project Descriptor Data Element
2.13 Federal Funding Source(s)
Federal Funding source
Response Categories
HUD-Supportive Housing Program
HUD-Shelter Plus Care
HUD-Section 8 Moderate Rehabilitation Program
HUD-Continuum of Care Program
HUD-Emergency Solutions Grant Program (includes
Emergency Shelter Grant Program)
HUD-Rural Housing Stability Program
HUD-Housing Opportunities for Persons with AIDS
(HOPWA)
HUD-Veterans Affairs Supportive Housing (VASH) Program
HHS-Runaway and Homeless Youth Programs
HHS-Projects for Assistance in Transition from
Homelessness (PATH)
HHS-Healthcare for the Homeless
VA-Grant and Per Diem Program
VA-Supportive Services for Veteran Families (SSVF)
VA-Homelessness Prevention Demonstration Program
VA-Residential Rehabilitation Treatment Programs (RRTP)Domiciliary (DOM)
VA-Compensated Work Therapy (CWT)-Transitional
Residence (TR)
VA-Health Care for Homeless Veterans (HCHV) Residential
Treatment Program
VA-Health Care for Re-entry Veterans (HCRV)
VA-VA Community Contract Emergency Housing
[Other-identify]
NA: Not Applicable
Grant identifier
Changes from Previous Notice: This is a new data element.
3.
Universal Data Elements
The Universal Data Elements establish the baseline data collection requirements for all
contributing CoC projects. As with the 2010 HMIS Data Standards, HUD carefully weighed the
reporting burden of the Universal Data Elements against the importance of the information for
producing meaningful local and federal reports. Of special concern to HUD was the reporting
burden for projects that register large numbers of clients on a daily basis, with little time to
collect information from each client. As a result, the number of Universal Data Elements was
kept to a minimum.
37
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 episodes over time. The Universal Data
Elements are:
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
Name
Social Security Number
Date of Birth
Race
Ethnicity
Gender
Veteran Status
Disabling Condition
Residence Prior to Project Entry
Project Entry Date
Project Exit Date
Destination
Personal Identification Number
Household Identification Number
Head of Household
Length of Time Homeless
Data elements 3.1 through 3.9 require that staff from a CoC project enter information provided
by a client into the HMIS. Data elements 3.1 to 3.6 must only be collected the first time an
individual uses a particular CoC project or, where HMIS data are shared among projects in a
CoC, at the time the shared client record is created in HMIS. If this information is not collected
the first time a client accesses services or is later found to be inaccurate, it should be added or
corrected whenever possible. Data elements 3.7 to 3.9 may need to be updated in the course of
subsequent client contacts as this information can change over time. The new information
should be captured without overwriting the information collected previously, providing a history
of the appropriate values for those data elements over time.
Data elements 3.10 (Project Entry Date) and 3.11 (Project Exit Date), are entered by staff (or
computer-generated) every time a client enters or leaves a project. Data element 3.12
(Destination) should be entered every time a client leaves a project. Elements 3.13 (Personal
Identification Number) and 3.14 (Household Identification Number) are automatically generated
by the HMIS solution, although staff inquiries are essential for the proper generation of these
elements. Data element 3.15 (Head of Household) is entered by project staff at the time of
project entry and at any time the head of household leaves a project while other household
members remain. Data element 3.16 (Length of Time Homeless) are entered by staff every time a
client enters a project.
For each Universal Data Element, response categories are provided. For any data element,
projects may choose to capture more detailed information as long as this information can be
exactly mapped to the required response categories described in this section. Most data elements
include a “Client doesn’t know” or “Client refused” response category. These are considered
valid responses if the client does not know or the client refuses to respond to the question. It is
38
not HUD’s intention that clients be denied service if they refuse or are unable to supply the
information; however, some information may be required by projects or private funders to
determine eligibility for housing or services, to assess needed services, or to fulfill reporting
requirements. The “Client doesn’t know” or “Client refused” responses must not be used to
indicate that the case manager or data entry person does not know the client’s response.
All Universal Data Elements must be asked of each adult and unaccompanied youth who applies
for a service, with the exception of 3.7 Veteran Status. Most universal data elements are also
required for children under 18 years of age. Where a group of persons apply for services
together (as a household or family), information about any children under the age of 18 can be
provided by the head of household who is applying for services. The children are not required to
be present at the time the head of household applies for services. However, information should
not be recorded for children under age 18 if it is indicated that these children will not be entering
the project on the same day as the head of household. Information for these children should be
recorded when the children join the project. Information on any other adults (18 years of age or
older) who are applying for services as part of the household will be obtained directly from that
adult. As a general rule, one adult should not provide information for another adult.
3.1
Name
Rationale: The first, middle, last names, and suffix should be collected to support the unique
identification of each person served.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or within accordance with CoC HMIS
timeliness policies and procedures.
Subjects: All clients.
Definitions and Instructions: Four fields should be created in the HMIS database to capture
the client’s full first, middle, and last names and any suffixes (e.g., John David Doe, Jr.).
Projects should seek to obtain legal names only and avoid aliases or nicknames.
Required Response Categories:
Universal Data Element
3.1 Name
Response Categories
First
Middle
Last
Suffix
(text)
(text)
(text)
(text)
Examples
John
David
Doe
Jr.
Special Issues: None.
Changes from Previous Notice: None.
3.2
Social Security Number
Rationale: The collection of a client’s Social Security Number (SSN) and other personal
identifying information is required for two important reasons. First, unique identifiers are critical
to producing an accurate, unduplicated local count of homeless persons accessing services
covered by HMIS. This is particularly true in jurisdictions where CoC projects do not share data
at the local level and are, therefore, unable to use a Personal Identification Number to deduplicate (at intake) across all the projects participating in the CoC’s HMIS. Where data are not
39
shared, CoCs must rely on a set of 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 these identifiers alone do not facilitate as accurate an unduplicated count of
homeless persons as the SSN since names change and people share the same date of birth.
Where data are shared across projects, the SSN greatly facilitates the process of identifying
clients who have been served and allows projects to de-duplicate upon project entry. Second, an
important objective for ending homelessness is to increase access and utilization of mainstream
programs by homeless persons. Since SSN is a required data element for many mainstream
programs, such as Temporary Assistance for Needy Families (TANF), Medicaid, Supplemental
Security Income (SSI), etc., projects need the SSN along with the other personal identifiers in
order to access mainstream services for their clients.
Data Source: Interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: All clients.
Definitions and Instructions: In one field, record the nine-digit Social Security Number. In
another field, record the appropriate SSN type (data quality code).
Required Response Categories:
Universal Data Element
3.2 Social Security Number
Response Categories
Examples
Social Security Number
__ __ __ - __ __ - __ __ __
123-45-6789
Social Security Number Type
Full SSN reported
Partial or unreliable SSN reported
Client doesn’t know or doesn’t have SSN
Client refused
123-45-6789
123-4
Special Issues: HMIS solutions 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 and HMIS system
administrators may designate special characters (e.g., the letter x) to indicate missing digits and
otherwise devise methodologies to allow entry and effective matching of partial SSNs.
The federal statute at 5 U.S.C. Section 552a prohibits government agencies from denying shelter
or services to clients who refuse to provide their SSN, unless the requirement was in effect
before 1975 or SSN is a statutory requirement for receiving services from the project. No HUDadministered McKinney-Vento Act program qualifies under this exception.
Changes from Previous Notice: Additional explanation has been added to the special issues
section regarding SSN format and data export capabilities for HMIS solutions.
3.3
Date of Birth
Rationale: The date of birth can be used to calculate the age of persons served at time of project
entry or at any point in receiving services. It will also support the unique identification of each
person served.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: All clients.
40
Definitions and Instructions: Collect the month, day, and year of birth for every person served.
If a client cannot remember their birth year, ask the person’s age and calculate 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 their existing policy. Approximate dates for month and day will
allow calculation of a person’s age within one year of their actual age. In another field, record
the appropriate date of birth type (data quality code).
Required Response Categories:
Universal Data Element
3.3 Date of Birth
Response Categories
Examples
Date of Birth
Date of Birth Type
(date)
Full DOB Reported
Approximate or partial DOB reported
Client doesn’t know
Client refused
(9/2/1972)
Special Issues: One date-format field for birth dates should be created in the HMIS database.
Date of birth must be exportable in the mm/dd/yyyy format.
Changes from Previous Notice: Additional explanation has been added to the special issues
section regarding date of birth format and data export capabilities for HMIS solutions.
3.4
Race
Rationale: Race is used to count the number of persons experiencing homelessness who
identify themselves within five different racial categories. 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. The data standards in this Notice follow the OMB guidelines
and can be used to complete form HUD-27061.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: All clients.
Definitions and Instructions: In separate data fields, collect the self-identified race of each
client served. Allow clients to identify as many racial categories as apply (up to five). Staff
observations should not be used to collect information on race. Definitions of each of the race
categories are as follows:



American Indian or Alaska Native is a person having origins in any of the original
peoples of North and South America, including Central America, and who maintains
tribal affiliation or community attachment.
Asian is a person having origins in any of the original peoples of the Far East, Southeast
Asia or the Indian subcontinent including, for example, Cambodia, China, India, Japan,
Korea, Malaysia, Pakistan, the Philippine Islands, Thailand and Vietnam.
Black or African American is a person having origins in any of the black racial groups of
Africa. Terms such as “Haitian” can be used in addition to “Black or African American.”
41


Native Hawaiian or Other Pacific Islander is a person having origins in any of the
original peoples of Hawaii, Guam, Samoa, or other Pacific Islands.
White is a person having origins in any of the original peoples of Europe, the Middle East
or North Africa.
Required Response Categories:
Universal Data Element
3.4 Race
Race
Response Categories
American Indian or Alaska Native
Asian
Black or African American
Native Hawaiian or Other Pacific Islander
White
Client doesn’t know
Client refused
Special Issues: HMIS solutions should accommodate the recording of up to five race response
categories per client.
Changes from Previous Notice: Additional explanation has been added to the special issues
section regarding data collection capabilities for HMIS applications.
3.5
Ethnicity
Rationale: Ethnicity is used to count the number of homeless persons who identify themselves
as Hispanic or Latino.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: All clients.
Definitions and Instructions: Collect the self-identified Hispanic or Latino ethnicity of each
client served. Staff observations should not be used to determine ethnicity. The definition of
Hispanic or Latino ethnicity is a person of Cuban, Mexican, Puerto Rican, South or Central
American or other Spanish culture of origin, regardless of race.
Required Response Categories:
Universal Data Element
3.5 Ethnicity
Ethnicity
Response Categories
Non-Hispanic/Non-Latino
Hispanic/Latino
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: None.
3.6
Gender
Rationale: To create separate counts of men, women, and transgendered clients experiencing
homelessness.
Data Source: Client interview or self-administered form.
42
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: All clients.
Definitions and Instructions: Record the self-reported gender of each client served. Gender
should be assigned based on the client’s self-identified gender identity. Transgender is defined
as persons with a gender identity that is different from the sex assigned to them at birth.
Required Response Categories:
Universal Data Element
3.6 Gender
Gender
Response Categories
Female
Male
Transgendered male to female
Transgendered female to male
Other
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: None.
3.7
Veteran Status
Rationale: To determine the number of veterans experiencing homelessness.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: All adults served.
Definitions and Instructions: A veteran is someone who has served on active duty in the
Armed Forces of the United States. This does not include inactive military reserves or the
National Guard unless the person was called up to active duty.
Required Response Categories:
Universal Data Element
3.7 Veteran Status
Veteran Status
Response Categories
No
Yes
Client doesn’t know
Client refused
Special Issues: Some veterans may not be aware that they meet the criteria for Veteran Status.
Project staff may elicit more accurate veteran status data by asking alternative or additional
questions. For example, “Have you ever been on active duty in the military?” or “Have you ever
received health care or benefits from a VA center?”
A project may wish to edit the record of a client who turns 18 after entry, but before exit, to add
a response for this data element in order to improve the reported overall data quality for the
project.
Changes from Previous Notice: Additional explanation has been added to the special issues
section regarding alternative or additional questions that may be asked to ascertain veteran status.
43
3.8
Disabling Condition
Rationale: Disabling condition is required to help identify clients that meet HUD’s definition of
chronically homeless and, depending on the source of project funds, may be required to establish
client eligibility to be served by the project.
Data Source: Client interview, self-administered form, or assessment. Where disability is
required to determine project eligibility, the data source is the evidence required by the funding
source.
When Data are Collected: At any time after the client has been admitted into the project
(unless a disabling condition is required for determining the client’s eligibility for the project).
Subjects: All clients served.
Definitions and Instructions: For this data element, a disabling condition means:
1. a disability as defined in Section 223 of the Social Security Act;
2. a physical, mental, or emotional impairment which is:
a. expected to be of long-continued and indefinite duration,
b. substantially impedes an individual’s ability to live independently, and
c. of such a nature that such ability could be improved by more suitable housing
conditions;
3. a developmental disability as defined in Section 102 of the Developmental Disabilities
Assistance and Bill of Rights Act;
4. the disease of acquired immunodeficiency syndrome or any conditions arising from the
etiological agency for acquired immunodeficiency syndrome; or
5. a diagnosable substance abuse disorder.
This field should be answered “Yes” for any 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 as defined in Section 223 of the Social Security Act.
Required Response Categories:
Universal Data Element
3.7 Disabling Condition
Disabling Condition
Response Categories
No
Yes
Client doesn’t know
Client refused
Special Issues: The Fair Housing Act prohibits discrimination because of inter alia, disability.
The housing may not be limited to persons with specific disabilities except as otherwise provided
by federal program statute. Unless this information is required to determine project eligibility or
is required to determine whether applicants need units with special features or if they have
special needs related to communication, data pertaining to disabilities should not be collected as
part of the application process for a project, but at project entry (i.e., after a determination has
been made to admit the individual to the project).
It is possible to derive client responses to the Disabling Condition question from certain
Program-Specific Data Elements if the HMIS software can automatically map those responses to
44
the Disabling Condition data element. For example, if a client responds affirmatively to having
a physical disability (Data Element 4.6), a developmental disability (Data Element 4.7), or
HIV/AIDS (Data Element 4.9), then the response to Disabling Condition is “Yes.” If a client
affirms that they have a mental health problem (Data Element 4.10) or a substance abuse
problem (Data Element 4.11) and they also affirm that the problem is expected to be of long
duration and substantially impairs their ability to live independently, then the response to
Disabling Condition is “Yes.” An affirmative response to Chronic Health Condition (Data
Element 4.8) does not provide enough information to assess whether the response to Disabling
Condition is “Yes.” Additional assessment is required to determine whether the condition
substantially impedes a client’s ability to live independently and could be improved by more
suitable housing conditions. It is important to note that a “no” to any of the questions in 4.6, 4.7,
4.8, 4.9, 4.10, or 4.11 does not automatically preclude a client from being disabled under the
SSA definition. However, a “No” response may require additional assessment to determine
whether a physical, emotional or mental impairment is present, whether the condition is expected
to last for a long duration, and whether it significantly impedes the client’s ability to live
independently.
CoC projects should be especially sensitive to collecting information on disabling condition from
clients under the age of 18. In households composed of adults and children, the disabling
condition of children should be reported by an adult in the household.
Changes from Previous Notice: Clarification has been added regarding determining the
disability status for veterans.
3.9
Residence Prior to Project Entry
Rationale: To identify the type of residence and length of stay at that residence just prior to
(i.e., the night before) project admission.
Data Source: Interview or self-administered form.
When Data are Collected: At any time after the client has been admitted into the project
(unless the type of residence just prior to admission must be assessed to determine the client’s
eligibility).
Subjects: Heads of household and adult household members.
Definitions and Instructions: Record the type of living arrangement of the client the night
before their entry into the project. For rental by client and owned by client, select the response
that includes the type of housing subsidy, if any, the client received. A housing subsidy may be
tenant-, project-, or sponsor-based and provides ongoing assistance to reduce rent burden. This
includes either a housing subsidy provided through the Veterans Affairs Supportive Housing
(VASH) program or other housing subsidy. Other housing subsidies may include a HUD-funded
subsidy (e.g., public housing, Housing Choice Voucher, or “Section 8”) or other housing subsidy
(e.g., state rental assistance voucher).
45
Required Response Categories:
Universal Data Element
3.9 Residence
Prior to
Project
Entry
Type of
Residence
Length of Stay
in Previous
Place
Response Categories
Emergency shelter, including hotel or motel paid for with emergency shelter voucher
Foster care home or foster care group home
Hospital or other residential non-psychiatric medical facility
Hotel or motel paid for without emergency shelter voucher
Jail, prison or juvenile detention facility
Long-term care facility or nursing home
Owned by client, no ongoing housing subsidy
Owned by client, with ongoing housing subsidy
Permanent housing for formerly homeless persons (such as SHP, S+C, or SRO Mod
Rehab)
Place not meant for habitation (e.g., a vehicle, an abandoned building,
bus/train/subway station/airport or anywhere outside); inclusive of non-housing
service site (outreach projects only)
Psychiatric hospital or other psychiatric facility
Rental by client, no ongoing housing subsidy
Rental by client, with ongoing housing subsidy
Residential project or halfway house with no homeless criteria
Safe Haven
Staying or living in a family member’s room, apartment or house
Staying or living in a friend’s room, apartment or house
Substance abuse treatment facility or detox center
Transitional housing for homeless persons (including homeless youth)
Other
Client doesn’t know
Client refused
One week or less
More than one week, but less than one month
One to three months
More than three months, but less than one year
One year or longer
Client doesn’t know
Client refused
Special Issues: This standard does not preclude the collection of residential history information
beyond the residence experienced the night prior to project admission. This data element must
be recorded in a transactional field each time a client enters a project. Communities may decide
whether to include additional response values as long as they can be mapped to the categories
included here, including the “Other” category.
A project may wish to edit the record of a client who turns 18 after entry, but before exit, to add
a response for this data element in order to improve the reported overall data quality for the
project, as this element is for heads of household and adult household members only.
46
Changes from Previous Notice: Under the previous notice, this data element was required for
all adults and unaccompanied youth. This has been changed so that data collection is required
for all heads of household and adult household members, which will require collection for at
least one member of a household comprised of only children.
The previous notice included the response category “Rental by client, with VASH housing
subsidy.” This response category has been removed. The “Hospital, non-psychiatric” response
category has been expanded to include other residential non-psychiatric medical facilities. Two
response categories have been added: “Long-term care facility or nursing home” and
“Residential project or halfway house with no homeless criteria.”
3.10
Project Entry Date
Rationale: To determine the start of a client’s period of involvement with any CoC project.
This data element is required for reporting purposes for all projects and to measure lengths of
stay for lodging projects.
Data Source: Project staff.
When Data are Collected: Upon any project entry (whether or not it is an initial project entry).
Subjects: All clients.
Definitions and Instructions: Record the month, day, and year of first day of service or project
entry. For projects that offer lodging, this date would represent the first day of residence in the
project following residence at any other place. There should be a new project entry date (and
corresponding exit date) for each continuous period of residence. If there is a gap in residence
(except for gaps allowed in Permanent Supportive Housing projects), a return to the project
should be recorded as a new project entry date. Lodging projects not required to collect projectspecific data that are using alternative models to track length of stay, as described in Section
2.12, may determine a specified period of non-attendance after which a project exit date is
generated and a subsequent return to the lodging project requires a new project entry date along
with the collection of other data required upon each new project admission.
For services, this date may represent the day of project enrollment, the day a service was
provided, or the first date of a period of continuous participation in a service (e.g., daily, weekly,
or monthly). There should be a new project entry date (and corresponding project exit date) for
each period of service. Therefore, any return to a project after a break in treatment, completion
of the project, or termination of the project by the user or project must be recorded as a new
project entry date. A definition of what constitutes a break in the treatment depends on the
project and needs to be defined by project staff. For example, projects that expect to see the
same client on a daily (or almost daily) basis may define a break in treatment as one missed day
that was not arranged in advance or three consecutive missed days for any reason. Treatment
projects that are scheduled less frequently than a daily basis may define a break in treatment as
one or more missed weekly sessions. The project entry date must be exportable in the
mm/dd/yyyy format.
Required Response Categories:
Universal Data Element
3.10 Project Entry Date
Project Entry Date
Response Categories
Examples
(date)
(08/01/2007)
47
Special Issues: Two methods are suggested below for noting and tracking supportive services
provided/received by a client prior to project entry. It may be useful to record these service
events for case management purposes although they would not be included in the APR or other
reports that define clients served based on project entry and exit dates associated with the project.
Service Transaction Model. To track services provided before official project entry and/or after
project exit, project staff can use the Services Provided data element described under the
Program-Specific Data Element section of this Notice, if the HMIS solution supports this
approach. CoC projects may select a service type from the response categories in the Services
Provided data element to track client services contacts, engagements, enrollment processes
and/or screenings that occur prior to project entry and/or aftercare services provided after project
exit.
Separate Project Model. Alternatively, CoC projects may establish a separate project profile
within the locally-defined profile of project types in HMIS as another option for tracking
provision of services prior to project entry date. Services received by clients in a pre-project
entry setting may include enrollment screening, eligibility determination, housing search
assistance prior to moving, and/or services that are not eligible activities under the primary
project’s funding criteria. A separate, pre-entry project will need its own unique Project
Identification Number in HMIS. Projects may choose to use this option for tracking provision of
services prior to project entry or after project exit. Again, these services are not included in a
project’s APR.
Changes from Previous Notice: Project Entry Date, in conjunction with Project Exit Date,
continues to be the primary tool for tracking length of stay in lodging projects. The standards
outline additional methods for noting and tracking periods of service provision that occur outside
the traditional residential stay period or outside the official reporting period. For a more detailed
description of the suggested methods for noting and tracking length of stay, see the Project
Descriptor Data Standards in Section 2.
3.11
Project Exit Date
Rationale: To determine the end of a period of project involvement for all clients of CoC
projects. This data element is required for reporting purposes for all projects and to calculate the
lengths of stay in projects that offer lodging or the amount of time spent participating in
services-only CoC projects.
Data Source: Project staff.
When Data are Collected: Upon any exit.
Subjects: All clients.
Definitions and Instructions: Record the month, day and year of last day of service. For a
project providing lodging to a client, this date would represent the last day of continuous stay in
the project before the client transfers to another project that offers lodging or otherwise stops
residing in the project. For example, if a person checked into an overnight shelter on
January 30, 2012, stayed overnight and left in the morning, the last date of service for that shelter
stay would be January 31, 2012. If the client returned on February 2, 2012, a new project entry
date is recorded. 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 enter the entry and exit date at the same
time or can specify HMIS solution that automatically enters the exit date as the day after the
entry date for clients of the overnight project.
48
For projects that are not required to collect Project-Specific Data, alternate methods can be used
for recording actual dates stayed in the project. HUD-funded Transitional Housing projects
should use Project Exit Date to record the day that the client leaves the residential portion of the
project; follow-up services can be recorded using the methods discussed under Special Issues
below, but should not be reported as part of the APR.
For projects that do not provide lodging, the exit date may represent the day a service was
provided or the last date of a period of ongoing service. The exit date should coincide with the
date the client is no longer considered a project participant. Projects should have a clear and
consistently applied procedure for determining when a client who is receiving supportive
services is no longer considered a client. For example, if a person has been receiving weekly
counseling as part of an ongoing treatment project and either formally terminates their
involvement or fails to return for counseling, the last date of service is the date of the last
counseling session. If a client uses a service for just one day (i.e., starts and stops before
midnight of same day, such as an outreach encounter), the Project Exit Date may be the same as
the Project Entry Date.
The Project Exit Date must be exportable in the mm/dd/yyyy format.
Required Response Categories:
Universal Data Element
3.11 Project Exit Date
Project exit date
Response Categories
Examples
(date)
(08/01/2007)
Special Issues: Projects may choose to track client contacts or provision of service after a
project exit. For example, some transitional housing projects offer a period of “aftercare” or
“follow up” that corresponds to a period of client contact after the client has exited the residential
project component. Depending on the HMIS solution, service transactions that occur after exit
may be tracked using the optional Services Provided data element. Note that for HUD-funded
projects, services provided after the exit date are not included in the required reports. HUDfunded service-only projects should use the Project Exit Date to indicate the date of service exit
for reporting purposes.
Projects that do not offer lodging may identify a period of no client contact that can be used as a
flag for project exit determination by the HMIS solution. For example, a period of
30 consecutive days with no client contact could trigger a project exit. The actual exit date
should be based on the last date of service provision. The length of time without client contact
or activity that triggers a project exit should be locally determined based on project design and
client profile. Ideally, an HMIS solution that supports this function should provide a data field in
each project’s set-up/profile to record the period of no client contact after which a client would
be flagged for a default exit.
Changes from Previous Notice: None.
3.12
Destination
Rationale: Destination is an important outcome measure required to fulfill multiple reporting
requirements.
Data Source: Client interview or self-administered form.
When Data Are Collected: At project exit.
49
Subjects: All clients served.
Definition and Instructions: Determine the response value that best describes where the client
will be staying after they leave the project. For clients who will be staying with family or
friends, select the response that includes the expected tenure of the destination (permanent or
temporary). For rental by client and owned by client, select the response that includes the type
of housing subsidy, if any, the client will be receiving. 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).
Required Response Categories:
Universal Data Element
3.12 Destination
Destination Type
Response Categories
Deceased
Emergency shelter, including hotel or motel paid for with emergency shelter voucher*
Foster care home or foster care group home
Hospital or other residential non-psychiatric medical facility
Hotel or motel paid for without emergency shelter voucher
Jail, prison or juvenile detention facility
Long-term care facility or nursing home
Owned by client, no ongoing housing subsidy
Owned by client, with ongoing housing subsidy:
Permanent supportive housing for formerly homeless persons (such as SHP, S+C, or
SRO Mod Rehab)
Place not meant for habitation (e.g., a vehicle, an abandoned building,
bus/train/subway station/airport or anywhere outside)
Psychiatric hospital or other psychiatric facility
Rental by client, no ongoing housing subsidy
Rental by client, with ongoing housing subsidy
Rental by client, with VASH housing subsidy
Residential project or halfway house with no homeless criteria
Safe Haven
Staying or living with family, permanent tenure
Staying or living with family, temporary tenure (e.g., room, apartment or house)
Staying or living with friends, permanent tenure
Staying or living with friends, temporary tenure (.e.g., room apartment or house)
Substance abuse treatment facility or detox center
Transitional housing for homeless persons (including homeless youth)*
Other
Client doesn’t know
Client refused
Special Issues: For response categories marked with an asterisk (*), these destinations are
currently not permissible destinations for HOPWA-funded projects that provide short-term
payments to prevent homelessness.
Changes from Previous Notice: Destination has been re-classified as a Universal Data
Element. Under the previous notice, this data element was required for all adults and
50
unaccompanied youth. This has been changed so that data collection is required for all heads of
household and adult household members, which will require collection for at least one member
of a household comprised of two or more minors. The “Hospital” response category has been
expanded to include other residential non-psychiatric medical facilities, and there are two new
categories: “Long-term care facility or nursing home” and “Residential project or halfway house
with no homeless criteria.”
3.13
Personal Identification Number
Rationale: Every client receiving services from a contributing CoC project within a CoC is
assigned a Personal Identification Number (PIN), which is a permanent and unique number
generated by the HMIS application. The PIN is used to obtain an unduplicated count of persons
served within a CoC.
Data Source: The PIN is generated automatically by the HMIS application. Where data are
shared across projects in a CoC, staff will determine at intake whether a client has been assigned
a PIN previously by any of the participating projects. To make this determination, the staff
enters personal identifying information (Name, SSN, Date of Birth, and Gender) into the HMIS
application. The application then searches the HMIS for matching records. If a match is found
and a PIN is retrieved, the same PIN will be assigned to the client. If no matches are found, a
new randomly generated PIN is assigned to the client.
Where data are not shared across projects, staff will similarly determine at intake whether
a client has been assigned a PIN previously by their agency or project. If the client is found
within their project records, the same PIN will be assigned to the client. If the client has not
been served by their project previously, a PIN is randomly generated and assigned to the client.
When Data Are Collected: Upon project entry.
Subjects: All clients.
Definition and Instructions: Assign a unique ID number to each client served; the PIN should
be unique to a single client within the CoC, even across projects that do not share data. The PIN
is a number automatically generated by the HMIS application. The PIN will not be based on any
client-specific information, but instead should be a randomly assigned, computer-generated
number.
The HMIS must have functionality to allow the HMIS Lead to de-duplicate clients with distinct
PINs using identifying information.
Required Response Categories:
Universal Data Element
3.13 Personal Identification
Number
Response Categories
A PIN must be created, but there is no required format as long
as there is a single unique PIN for every client served in the CoC
using a consistent format and it contains no personally
identifying information.
Special Issues: None.
Changes from Previous Notice: None.
3.14
Household Identification Number
Rationale: To count the number of households served in a project.
51
Data Source: Interview or staff observation that a client is participating in a project as a single
person household or as a household with two or more members. This may be generated
automatically by the HMIS application.
When Data Are Collected: Upon any project entry.
Subjects: All clients.
Definition and Instructions: A household is a single individual or a group of persons who
apply together to a CoC 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).
Assign a unique ID number to each household served. There is no specified format for this data
element. The Household Identification Number can be a randomly generated number or some
other code as long as each household receives a distinct identifier that is associated with each
member of that household.
Required Response Categories:
Universal Data Element
3.14 Household Identification Number
Response Categories
A Household ID number must be created, but there is no
required format as long as the number allows identification of
clients that receive services as a member of a specific
household.
Special Issues: If it is not evident to project staff whether others are applying for assistance with
the person who is being interviewed, then project staff should ask if anyone else is applying for
assistance with that person.
Persons may join a household with members who have already begun a project stay or leave a
project although other members of the household remain in the project. A common Household
Identification Number should 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 Identification
Number that links them to the rest of the persons in the household.
Changes from Previous Notice: None.
3.15
Head of Household
Rationale: Identification of the heads of household for each household in HMIS will facilitate
the identification, tracking, and enumeration of households served by projects.
Data Source: Client interview, self-administered form, or staff observation.
When Data Are Collected: At project entry, and any time the head of household leaves the
project while other household members remain.
Subjects: All clients.
Definition and Instructions: Identify the head of household for each household at project entry
and any time the head of household leaves the project while other household members remain.
HMIS solution should ensure that there is only one head of household identified at any given
time for persons identified as belonging to the same household.
A household is a single individual or a group of persons who apply together to a CoC project for
assistance and who live together in one dwelling unit (or, for persons who are not housed, who
52
would live together in one dwelling unit if they were housed). 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 CoC 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. For HUD-funded projects that target or limit lodging or
services for persons who are chronically homeless, the household member who meets
chronically homeless criteria should be identified as the head of household.
Required Response Categories:
Universal Data Element
3.15 Head of Household
Head of household
Response Categories
No
Yes
Special Issues: None.
Changes from Previous Notice: This is a new data element.
3.16
Length of Time On Street, in an Emergency Shelter or Safe Haven
Rationale: Chronic homelessness is, in part, determined by the length of time an individual or
family has spent on the street, in shelter or a Safe Haven. The addition this data element enables
an HMIS to be queried for chronic homelessness.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon project entry or as soon as possible thereafter.
Subjects: All clients.
Definitions and Instructions: In separate data fields, collect the self-identified length of time
an individual or family has been on the street, in an ES or a Safe Haven. Definitions of each of
the categories are as follows:





Less than 1 year is a person/family who has experienced homelessness as defined in
Category 1 of the Final Rule Defining Homelessness 24 CFR Parts 582, 583, 576, and
578 for less than 365 days.
Consecutively for 1 year–12 months is a person/family that has experienced homelessness
as defined in Category 1 of the Final Rule Defining Homelessness 24 CFR Parts 582,
583, 576 and 578 for 365 or more consecutive days.
At least 12 months over the past three years is a person/family that over the course of the
past three years has been homeless as defined in Category 1 of the Final Rule Defining
Homelessness 24 CFR Parts 582, 583, 576, and 578 for at least 12 months.
Client Doesn’t Know
Client Refused
53
Required Response Categories:
Universal Data Element
3.17
Length of Time on
the Street, in an ES
or a Safe Haven
Response Categories
Less than 1 year
Consecutively for 1 year – 12 months
At least 12 months over the past 3 years
Client Doesn’t Know
Client Refused
4.
Program-Specific Data Elements
Program-Specific Data Elements provide information about the characteristics of clients, the
services that are provided, and client outcomes. These data elements must be collected from all
clients served by Contributing CoC Projects as specified by HUD and other federal agencies.
Projects that receive funding through HUD’s Supportive Housing Program, Shelter Plus Care,
Section 8 Moderate Rehabilitation for Single Room Occupancy (SRO) program, the new CoC
Program, or the ESG program, and the homeless projects funded through the HOPWA program
are required to collect many of these data elements in order to fulfill HUD reporting
requirements. HUD will specify data collection requirements for projects funded by HUD
relative to Program-Specific Data Elements in the separate guidance for each program-specific
report. For Contributing CoC Projects funded by other federal agencies, the applicable federal
agency will issue separate rules, regulation or guidance indicating which Program-Specific data
Elements must be collected. A federal agency may require all of the fields in a data element or
may specify which of the fields are required. A federal agency may require all of the response
categories defined in this Notice or may specify a subset of response categories which are valid
for their projects. HMIS vendors must be prepared to tailor data collection for projects based on
the data elements in this Notice identified as required by federal agencies.
HUD recommends that local CoCs require that all Contributing CoC Projects collect a standard
subset of the data elements contained in this section to obtain consistent information across a
range of projects that can be used to plan service delivery, monitor the provision of services, and
identify client outcomes. However, these data elements do not constitute a client assessment
tool, and projects must develop their own data collection protocols in order to properly assess
applicants’ needs for services.
The Program-Specific Data Elements that are required for federal reporting include:
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
Zip Code of Last Permanent Address
Housing Status
Income and Sources
Non-Cash Benefits
Health Insurance / Medical Assistance
Employment Status
Physical Disability
Developmental Disability
Chronic Health Condition
HIV/AIDS
Mental Health Problem
Substance Abuse
54
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
4.31
4.32
4.33
4.34
4.35
4.36
4.37
4.38
4.39
4.40
4.41
4.42
4.43
4.44
Domestic Violence
Contact
Dates of Engagement and Enrollment
Veterans Information
Services Provided
Financial Assistance Provided
Area Median Income (AMI) Percentage Used for Eligibility
Sexual Orientation
Last Grade Completed
School Status
General Health Status
Pregnancy Status
Funding Source for Residence Prior to Project Entry
Funding Source for Destination
Referrals Provided
Reason for Leaving
Project Transition
Formerly a Ward of Child Welfare / Foster Care Agency
Formerly a Ward of Juvenile Justice System
Young Person’s Critical Issues
Referral Source
Transitional, Exitcare, or Aftercare Plans and Actions
Project Completion Status
Family Reunification Achieved
Physical Health Status
Dental Health Status
Mental Health Status
Housing Category
Percent of AMI
Formerly Chronically Homeless
Federal Funding Source for Project Enrollment
Worst Housing Situation
The Program-Specific Data Elements require that staff from a Contributing CoC Project collect
information from clients and enter it into an HMIS. In most cases, this information may be:

Provided by the client; and/or

Taken from case manager interviews or records, assuming that this information has
been collected consistent with 24 CFR Parts 91, 576,578, 582, 583, and the Homeless
Management Information Systems (HMIS) Requirements, when implemented, and
the baseline privacy standards of the 2004 Data and Technical Standards or updated
Technical Standards, as issued by HUD.
In the 2004 Notice, HUD established requirements for maintaining client privacy and data
confidentiality to ensure that clients are notified of possible uses and disclosures of their
55
information and that all information collected remains secure. These requirements remain in
effect until such time as HUD updates these requirements.
For each Program-Specific Data Element, multiple response categories are provided. Projects
may choose to capture more detailed information (or finer response categories) as long as this
information can be exactly mapped to the required response categories described in this section.
For HUD reporting purposes, an HMIS solution must be able to produce required report using
the response categories exactly as they are presented in this section.
Most data elements include a “Client doesn’t know” or “Client refused” response category.
These are considered valid responses if the client does not know or the client refuses to respond
to the question. It is not HUD’s intention that clients be denied service 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.
For purposes of collecting data regarding disability status for reporting purposes only–in which
data collection regarding disability is unrelated to program eligibility requirements–any
questions regarding a client’s disability status must be voluntary and clients must be informed
prior to responding of the voluntary nature of the question and that their refusal to respond will
not result in a denial of service. No questions should be posed regarding the nature or severity of
the person’s disability.
Finally, many of these data elements represent transactions or information that may change over
time. Most Program-Specific Data Elements should be captured at project entry and exit, and a
few must be captured at project entry, exit, and on an annual basis. Projects may decide when to
collect the information on an annual basis, but HUD encourages projects that are required to
complete an APR to update these data elements near the end of their APR operating year.
4.1
Zip Code of Last Permanent Address
Rationale: To identify the most recent geographic location where persons experiencing
homelessness or persons who are at risk of homelessness lived on a permanent basis.
Data Source: Interview or self-administered form.
When Data are Collected: Upon any project entry or as soon as possible thereafter.
Subjects: Heads of household and adult household members.
Definitions and Instructions: In one field, record the five-digit zip code of the apartment,
room, or house where the client last lived in community-based housing without a designated
length of stay. In another field, record the appropriate zip code type (data quality code).
Required Response Categories:
Program-Specific Data Element
4.1 Zip Code of Last Permanent Address
Response Categories
Examples
Zip Code
Zip Code Type
__ __ __ __ __
12345
Full or partial zip code reported
12345
Client doesn’t know
Client refused
56
Special Issues: A project may edit the record of a client who turns 18 after entry, but before
exit, to add a response for this data element in order to improve the reported overall data quality
for the project.
Changes from Previous Notice: This is no longer a Universal Data Element; it may be
collected at the discretion of the CoC, an individual project, or at the direction of a particular
funder, but it is no longer mandatory for all projects participating in HMIS. Under the previous
notice, this data element was required for all adults and unaccompanied youth. This has been
changed so that data collection is required for all heads of household and adult household
members; this will require collection for at least one member of a household comprised of only
children.
4.2
Housing Status
Rationale: To identify the housing status and risk for homelessness for persons at project entry,
including whether persons, homeless and housed and at risk of homelessness, or in a stable
housing situation. This data element allows projects that serve homeless and non-homeless
persons to separate these two populations for reporting purposes, as well as identify persons
according to homeless and at risk criteria established by HUD in the homeless definition.
Data Source: Documentation of homeless or at risk as required of the specific category of
homelessness as posted in the Final Rule Defining Homelessness at
24 CFR Parts 91, 582 and 583.
When Data are Collected: Upon initial project entry or as soon as possible thereafter for all
projects.
Subjects: All clients.
Definitions and Instructions: For each client, determine the appropriate Housing Status
according to the definitions below based on the client’s housing and related conditions as
determined in accordance with the verification and documentation procedures established under
the applicable program rules. A client must be coded to a single Homeless and At Risk of
Homelessness Status response category. In addition, in cases where an individual or family
meets the definition of homeless under Categories 1 or 2 or meets the at risk definition AND is
fleeing domestic violence, they should only be coded to Category 1, 2 or At Risk. Category 4
should only be used when the household does NOT meet any other category but is homeless
because of domestic violence.
1. Category 1: Homeless
An individual or family who lacks a fixed, regular, and adequate nighttime residence,
meaning:
(i) An individual or family with a primary nighttime residence that is 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; OR
(ii) An individual or family living in a supervised publicly or privately operated
shelter designated to provide temporary living arrangements (including
congregate shelters, transitional housing, and hotels and motels paid for by
charitable organizations or by federal, state, or local government programs
for low income individuals); OR
57
(iii) An individual who is exiting an institution where he or she resided for 90
days or less and who resided in an emergency shelter or place not meant for
human habitation immediately before entering that institution.
2. Category 2: At-imminent risk of losing housing
(1) Housing Loss in 14 Days: An individual or family who will imminently lose their
primary nighttime residence1, provided that:
(i) The primary nighttime residence will be lost within 14 days of the date of
application for homeless assistance; AND
(ii) No subsequent residence has been identified; AND
(iii) The individual or family lacks the resources or support networks, e.g., family,
friends, faith-based or other social networks required to obtain other
permanent housing.
3. Category 3: Homeless only under other federal statutes
Unaccompanied youth under 25 years of age, or families with children and youth,
who do not otherwise qualify as homeless under this definition, but who:
(i) Are defined as homeless under section 387 of the Runaway and Homeless
Youth Act (42 U.S.C. 5732a), section 637 of the Head Start Act (42 U.S.C.
9832), section 41403 of the Violence Against Women Act of 1994 (42
U.S.C. 14043e–2), section 330(h) of the Public Health Service Act (42
U.S.C. 254b(h)), section 3 of the Food and Nutrition Act of 2008 (7 U.S.C.
2012), section 17(b) of the Child Nutrition Act of 1966 (42 U.S.C. 1786(b)),
or section 725 of the McKinney-Vento Homeless Assistance Act (42 U.S.C.
11434a); AND
(ii) Have not had a lease, ownership interest, or occupancy agreement in
permanent housing at any time during the 60 days immediately preceding the
date of application for homeless assistance; AND
(iii) Have experienced persistent instability as measured by two moves or more
during the 60-day period immediately preceding the date of applying for
homeless assistance; AND
(iv) Can be expected to continue in such status for an extended period of time
because of chronic disabilities, chronic physical health or mental health
conditions, substance addiction, histories of domestic violence or childhood
abuse (including neglect), the presence of a child or youth with a disability,
or two or more barriers to employment, which include the lack of a high
school degree of General Education Development (GED), illiteracy, low
English proficiency, a history of incarceration or detention for criminal
activity, and a history of unstable employment.
4. Category 4: Fleeing domestic violence
Domestic Violence: Any individual or family who:
1
A primary nighttime residence may include housing an individual or family owns, rents, or lives in without
paying rent, are sharing with others, and rooms in hotels or motels not paid for by federal, state, or local
government programs for low-income individuals or by charitable organizations.
58
(i) Is fleeing, or is attempting to flee, 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 or has made the individual or family afraid to return to their
primary nighttime residence; AND
(ii) Has no other residence; AND
(iii) Lacks the resources or support networks, e.g., family, friends, faith based or
other social networks, to obtain other permanent housing.
5. At-Risk of Homelessness –Prevention Programs Only
(1) An individual or family who:
(i) Has an annual income below 30 percent of median family income for the
area, as determined by HUD; AND
(ii) Does not have sufficient resources or support networks, e.g., family, friends,
faith-based or other social networks, immediately available to prevent them
from moving to an emergency shelter or another place described in Homeless
Category 1 above; AND
(iii) Meets one of the following conditions:
(A) Has moved because of economic reasons two or more times during the
60 days immediately preceding the application for homelessness
prevention assistance;
(B) Is living in the home of another because of economic hardship;
(C) Has been notified in writing that their right to occupy their current
housing or living situation will be terminated within 21 days after the
date of application for assistance;
(D) Lives in a hotel or motel and the cost of the hotel or motel stay is not
paid by charitable organizations or by Federal, State, or local
government programs for low-income individuals;
(E) Lives in a single-room occupancy or efficiency apartment unit in which
there reside more than two persons or lives in a larger housing unit in
which there reside more than 1.5 persons reside per room, as defined by
the U.S. Census Bureau;
(F) Is exiting a publicly funded institution, or system of care (such as a
health-care facility, a mental health facility, foster care or other youth
facility, or correction program or institution); or
(G) Otherwise lives in housing that has characteristics associated with
instability and an increased risk of homelessness, as identified in the
recipient’s approved consolidated plan (for ESG projects) or the
jurisdiction’s approved consolidated plan (for non-ESG projects); OR
(2) A child or youth who does not qualify as ‘‘homeless’’ under the categories
described above, but qualifies as ‘‘homeless’’ under section 387(3) of the
Runaway and Homeless Youth Act (42 U.S.C. 5732a(3)), Section 637(11) of the
59
Head Start Act (42 U.S.C. 9832(11)), Section 41403(6) of the Violence Against
Women Act of 1994 (42 U.S.C. 14043e–2(6)),
Section 330(h)(5)(A) of the Public Health Service Act
(42 U.S.C. 254b(h)(5)(A)), Section 3(m) of the Food and Nutrition Act of 2008 (7
U.S.C. 2012(m)), or Section 17(b)(15) of the Child Nutrition Act of 1966 (42
U.S.C. 1786(b)(15)); OR
(3) A child or youth who does not qualify as ‘‘homeless’’ under the categories
described’ above, but qualifies as ‘‘homeless’’ under section 725(2) of the
McKinney-Vento Homeless Assistance Act (42 U.S.C. 11434a(2)), and the
parent(s) or guardian(s) of that child or youth if living with her or him.
6. Stably Housed
(a) An individual or family who is not otherwise experiencing homelessness or at risk of
homelessness according to the categories above.
Program Specific Data Element
4.2 Housing Status
Homeless and At-Risk
of Homelessness Status
Response Categories
Category 1– Homelessness
Category 2- At imminent risk of losing housing
Category 3- Homeless only under other Federal statutes
Category 4-Fleeing domestic violence
At-risk of homelessness - Prevention programs only
Stably Housed
Client doesn’t know
Client refused
Special Issues:
Changes from Previous Notice: Housing Status has been moved from a Universal Data
Elements to Program Specific Data Element and has been updated to reflect HUD’s new
definitions for “homeless” and “at risk of homelessness” and to facilitate reporting. The
requirement to collect Housing Status at program exit has been removed for all projects.
4.3
Income and Sources
Rationale: Income and sources of income are important for determining service needs of people
at the time of project entry, determining whether they are accessing all income sources for which
they are eligible, and describing the characteristics of the population experiencing homelessness.
Capturing the receipt of cash income from various sources will help to: ensure all income
sources are counted in the calculation of total income; enable project staff to take into account
the composition of income in determining needs; determine if people are receiving the
mainstream project benefits to which they may be entitled; help clients apply for benefits
assistance; and allow analysis of changes in the composition of income between entry and exit
from the project and annual changes prior to project exit. Income data are also required to fulfill
multiple reporting requirements.
Data Source: Client interview, self-administered form, and/or case manager records.
When Data Are Collected: In the course of client assessment nearest to project entry, at project
exit and at least once annually during project enrollment, if the period between project entry and
exit exceeds 1 year. Projects may decide when to collect the information on an annual basis, but
60
HUD encourages projects that are required to show a client’s change in income to update these
data elements near the end of their reporting or operating year.
Subjects: All heads of household and adult household members.
Definition and Instructions: Enter the date on which the information was collected. In the
event that multiple data elements are collected on the same form (or are stored in the same table),
a single Information Date field will suffice for all data elements on the form. In separate fields,
determine (1) whether the client receives any income from any source listed below, (2) if the
client receives income from any of the listed sources, the amount of income received from each
of the sources on a monthly basis and (3) the client’s total monthly income (rounded to the
nearest U.S. dollar) based on income currently being received by the client. The total monthly
income should be equal to the sum of the amounts entered for each individual income source; the
HMIS application may calculate this automatically. HOPWA-funded projects must enter the
approximate start date for each income source.
Income received by or on behalf of a minor child should be assigned to the head of household.
In the event that a minor child enters or leaves the household and the household monthly income
changes as a result, an update to the head of household’s record must be entered to reflect that
change.
61
Required Response Categories: Program-Specific Data Element
4.3 Income
and Source
Information
Date
Financial
Resources
Source and
Amount of
Income
Response Categories
(date)
Income from any source?
Source of Income
Earned Income (i.e.,
employment income)
Unemployment Insurance
Supplemental Security Income
(SSI)
Social Security Disability
Income (SSDI)
VA service-connected
disability compensation
VA non-service-connected
disability pension
Private disability insurance
Worker’s compensation
Temporary Assistance for
Needy Families (TANF)
(or use local name)
General Assistance (GA) (or
use local name)
Retirement income from
Social Security
Veteran’s pension
Pension from a former job
Child support
Alimony or other spousal
support
Other source
Total
Monthly
Income
Monthly income from all
sources
No
Yes
Client doesn’t know
Client refused
Receiving income
source?
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
$_ _ _ _.00
(HOPWA
only)
Approximat
e Start Date
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
Amount
from
Source
$_ _ _ _.00
(date)
(date)
No
Yes
No
Yes
No
Yes
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
No
Yes
$_ _ _ _.00
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
(date)
$_ _ _ _.00
Special Issues: Income should be recorded at the client-level for heads of household and adult
household members. Projects may choose to disaggregate the sources of income into more
detailed categories as long as these categories can be aggregated into the above stated sources of
62
income. Projects may choose to collect this information for all household members including
minor children, as long as the data are reported appropriately. Projects collecting data through
client interviews should ask clients whether they receive income from each of the sources listed
rather than asking them to state the sources of income they receive. The “Client doesn’t know”
and “Client refused” responses should only be used when clients do not know or refuse to answer
whether they have any income. When a client has income, but does not know the amount, a
“Yes” response should be recorded for both the overall income question and the specific source,
and the income amount should be left blank.
To reduce data collection and reporting burden, if a client reports receiving no income from any
source, no additional data collection is required. If a client reports receiving income, an HMIS
may be designed such that projects only need to directly enter “Yes” for the income the client
receives. The HMIS solution may automatically generate a “No” response for the other income
sources. The HMIS may also be designed to automatically generate a “Yes” response where
income amounts are recorded. However, since clients often know the source of income, but not
the precise amount, users should have the ability to enter “Yes” without recording an exact
amount.
Data in the fields of this data element should be logically consistent. If there is a “Yes” response
to Receiving income from source? for any of the specific income sources, Income from any
source? should also be answered “Yes.” Unless Receiving income from source? is “Yes” for a
particular income source, the corresponding Amount from source should be either 0.00 or null. If
Total monthly income is an amount greater than 0.00, Receiving income from source? should not
be “No.” HMIS solution may be programmed to enforce these rules or to notify users when
inconsistent data has been entered. For HUD reporting purposes, at a minimum, Income from
any source? must be answered “Yes” and Total monthly income must have an amount greater
than 0.00 in order to report the client/household as having a non-zero income.
Changes from Previous Notice: Information Date is a new field and should reflect the date on
which the information was collected. Under the previous notice, collection of this information
was required for all clients; recording income for minor children on the minor child’s record is
no longer required. Previously, projects were required to identify all sources of income received
during the past 30 days, regardless of whether the client was still receiving income from a
particular source on the date the information was collected; this has been changed. Projects are
now required to record only sources of income that are expected to be ongoing on the date that
the information is collected. As an example, under the previous notice, projects were required to
record employment income for clients who had received any income from employment in the
past 30 days, even if the employment had been terminated and the client had not yet secured
additional employment. Under this draft Notice, the response for ‘Employment income’ for a
client in those circumstances would appropriately be ‘No.’ As a further example, if 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 per hour, record
the income from the job the client has at the time data are collected.
Under the previous notice, there was no requirement to collect specific amounts for income
sources other than earned income; an amount is now required for each income source and the
total monthly income should be equal to the sum of the amounts entered for each source.
Previously, there was a “Veteran’s pension” response category for Source of Income; this has
been removed, and two more specific response categories (“VA service-connected disability
pension,” which refers to a benefit paid to veterans with a service-connected disability, and “VA
non-service-connected disability pension,” which refers to a benefit paid to wartime veterans
63
who have limited or no income and who are age 65 or older; or, if under 65, who are
permanently and totally disabled) have been added.
4.4
Non-Cash Benefits
Rationale: Non-cash benefits are important to determine whether clients are accessing all
mainstream program benefits for which they may be eligible and to ascertain a more complete
picture of their economic circumstances. This information is required to fulfill multiple
reporting requirements.
Data Source: Client interview, self-administered form, and/or case manager records.
When Data Are Collected: In the course of client assessment nearest to project entry, at project
exit and at least once annually during project enrollment, if the period between project entry and
exit exceeds 1 year. Projects may decide when to collect the information on an annual basis, but
HUD encourages projects that are required to show a client’s change in income to update these
data elements near the end of their reporting or operating year.
Subjects: Heads of household and adult household members.
Definition and Instructions: Enter the date on which the information was collected. In the
event that multiple data elements are collected on the same form (or are stored in the same table),
a single Information Date field will suffice for all data elements on the form. For each source
listed below, determine if the client currently receives any non-cash benefits. As an example, if
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 ‘Yes’ for Supplemental Nutritional Assistance Program
(SNAP). If 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, she would not be considered to be currently receiving
food stamps; record ‘No’ for Supplemental Nutritional Assistance Program (SNAP). Clients
may identify multiple sources of non-cash benefits. Benefits received by a minor child should be
assigned to the head of household. In the event that a minor child enters or leaves the household
and the non-cash benefits received by the household change as a result, an update to the head of
household’s record should be entered to reflect that change. For HOPWA-funded projects, enter
the start date for each benefit and, if not receiving a benefit, the reason why such benefit is not
being received.
64
Required Response Categories:
Program-Specific Data Element
4.4 Non-Cash Benefits
Response Categories
Date
(date)
Non-Cash Benefit
Non-cash benefit received
from any source?
No
Yes
Client doesn’t know
Client refused
Source of Non-cash Benefit
Receive
Benefit
(HOPWA
only)
If yes, start
date
(date)
Supplemental Nutrition
Assistance Program
(SNAP) (Previously
known as Food Stamps)
0 = No
1 = Yes
Special Supplemental
Nutrition Program for
Women, Infants, and
Children (WIC)
0 = No
1 = Yes
(date)
TANF child care services (or
use local name)
0 = No
1 = Yes
(date)
TANF transportation services
(or use local name)
0 = No
1 = Yes
(date)
(HOPWA only)
If no, reason
All services full
Client not
eligible
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
All services full
Client not
eligible
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
All services full
Client not
eligible
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
All services full
Client not
eligible
65
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
Other TAN F-funded services
(or use local name)
0 = No
1 = Yes
(date)
Section 8, public housing, or
other ongoing rental
assistance
0 = No
1 = Yes
(date)
Other source
0 = No
1 = Yes
(date)
0 = No
1 = Yes
(date)
Temporary rental assistance
All services full
Client not
eligible
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
All services full
Client not
eligible
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
All services full
Client not
eligible
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
All services full
Client not
eligible
Applied;
decision
pending
Client refused
service
Service does
not exist
Unknown
66
Special Issues: Projects may choose to disaggregate the non-cash sources of income into more
detailed categories as long as these categories can be aggregated into the above-stated non-cash
benefits. Projects may also choose to record additional information about non-cash benefits,
including: information related to benefit eligibility (e.g., if a person is not receiving a service, is
it because they are not eligible or eligibility has not yet been determined); date of application;
amount of benefits; and start and stop dates for receipt of benefits.
In order to determine whether the client received any non-cash benefits, projects collecting data
through client interviews are advised to ask clients whether they receive non-cash benefits from
each of the sources listed under “Required Response Categories” rather than asking whether they
received any benefit and to state the sources of benefits they receive. To reduce data collection
and reporting burden, if a client reports receiving no non-cash benefit from any source, no
additional data collection is required. If a client reports receiving non-cash benefits, an HMIS
may be designed such that projects only need to directly enter “Yes” for the benefits the clients
received. The HMIS solution may automatically generate a “No” response for the other noncash benefit sources.
Changes from Previous Notice: Under the previous notice, this data element was required for
all adults and unaccompanied youth. This has been changed so that data collection is required
for all heads of household and adult household members, which will require collection for at
least one member of a household comprised of two or more minors.
Information Date is a new field, and should reflect the date on which the information is
collected.
Previously, projects were required to document any non-cash benefits the client had received in
the past 30 days, regardless of whether the client was still receiving the benefit on the date that
the information was being collected; this has been changed so that projects are only required to
collect information on benefits that are expected to be ongoing. Health insurance coverage
sources have been isolated into a separate data element.
4.5
Health Insurance / Medical Assistance
Rationale: Health insurance information is important to determine whether clients currently
have health insurance coverage and are accessing all mainstream project medical assistance
benefits for which they may be eligible, and to ascertain a more complete picture of their
economic circumstances. This information is required to fulfill multiple reporting requirements.
Data Source: Client interview, self-administered form, and/or case manager records.
When Data Are Collected: In the course of client assessment nearest to project entry, at project
exit and at least once annually during project enrollment, if the period between project entry and
exit exceeds 1 year.
Subjects: Heads of household and adult household members.
Definition and Instructions: Enter the date on which the information was collected. In the
event that multiple data elements are collected on the same form (or are stored in the same table),
a single Information Date field will suffice for all data elements on the form. For each source of
health insurance/medical assistance listed below, determine if the client is presently covered by
that health insurance source or is otherwise receiving the medical assistance specified. Clients
may identify multiple sources of health insurance and medical assistance. Insurance received by
a minor child should be assigned to the head of household. In the event that a minor child enters
or leaves the household and the health insurance coverage of the household changes as a result,
67
an update to the head of household’s record should be entered to reflect that change. For
HOPWA-funded projects, enter the start date for each source and, if not receiving health
insurance or medical assistance, the reason why such insurance is not being received.
Required Response Categories:
Program-Specific Data Element
4.5 Health Insurance
/ Medical
Assistance
Information Date
Covered by health
insurance?
Response Categories
(date)
No
Yes
Client doesn’t know
Client refused
Type of Health Insurance /
Medical Assistance
Coverage
in effect?
MEDICAID health insurance
program (or use local name)
No
Yes
(HOPWA
only)
If yes, start
date
(date)
(HOPWA only)
If no, reason
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
MEDICARE health insurance
program (or use local name)
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
State Children’s Health Insurance
Program (or use local name)
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
Veteran’s Administration (VA)
Medical Services
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
68
Client refused
service
Service does not
exist
Unknown
Employer-provided health
insurance
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
Health insurance obtained through
COBRA
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
Private pay health insurance
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
Ryan White medical assistance
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
AIDS Drug Assistance Program
(ADAP)
No
Yes
(date)
All services full
Client not eligible
Applied; decision
pending
Client refused
service
Service does not
exist
Unknown
69
Special Issues: Projects may choose to disaggregate the sources of health insurance into more
detailed categories as long as these categories can be aggregated into the above-stated non-cash
sources of income. Projects may choose to record health insurance coverage for each member of
the household including minor children, as long as the coverage is reported appropriately.
Projects may also choose to record additional information about non-cash sources of income,
including: information related to health coverage (e.g., if the person has been denied coverage;
cost of coverage; and start and stop dates for receipt of benefits).
To reduce data collection and reporting burden, if a client reports having no health insurance
coverage, no additional data collection is required. If a client reports having health insurance, an
HMIS may be designed such that projects only need to directly enter “Yes” for the coverage in
effect at the time the information is collected. The HMIS solution may automatically generate a
“No” response for the other health insurance types.
Changes from Previous Notice: This is a new data element.
4.6
Employment Status
Rationale: To assess client’s employment status and need for employment services.
Data Source: Client interview or self-administered form.
When Data Are Collected: In the course of client assessment nearest to project entry, at Project
exit and at least once annually during Project enrollment, if the period between Project entry and
exit exceeds 1 year.
Subjects: Heads of household and adult household members.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS), a single Information Date may be shared by all data elements on the
form. Select the response category that most accurately reflects the client’s employment status.
Required Response Categories:
Project-Specific Data Element
4.6 Employment Status
Information Date
Employment status
Response Categories
(date)
Full-time
Part-time
Part-time, looking for full-time
Seasonal / sporadic (including day labor)
Not employed, looking for work
Not employed, in school
Not employed, unable to work
Not employed, not looking for work
Client doesn’t know
Client refused
Special Issues: Projects may ask additional information about a person’s employment status,
including more detailed information on the type of employment.
Changes from Previous Notice: This data element (under the previous notice, 4.15A
Employment) has been significantly streamlined to match the data collection and reporting needs
70
of other federal agencies. Under the previous notice, this data element was optional; it has been
re-classified as Project-Specific Data Element.
Information Date is a new field, and should reflect the date on which the information was
collected.
4.7
Physical Disability
Rationale: To count the number of physically disabled persons served, determine eligibility for
disability benefits, and assess the need for services. This is required to fulfill multiple reporting
requirements.
Data Source: Client interview, self-administered form, or case manager records.
When Data Are Collected: In the course of client assessment once the individual is admitted–
unless this information is required prior to admission to determine project eligibility–at project
exit, and at least once annually during project enrollment if the period between project entry and
exit exceeds 1 year.
Subjects: All clients served.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS database), a single Information Date may be shared by all data elements
on the form. In separate fields, determine (1) if the client has a physical disability, and (2) if the
client is currently receiving services or treatment for this disability or received services or
treatment prior to exiting the project. For the purposes of this Notice, a physical disability means
a physical impairment which is: (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.
Required Response Categories:
Program-Specific Data Element
4.7 Physical Disability
Information Date
Physical disability
(If yes)
[At entry]
Currently receiving services or treatment for this condition?
[At annual assessment and at exit]:
Received services/treatment while in the project?
Response Categories
(date)
No
Yes
Client doesn’t know
Client refused
No
Yes
Client doesn’t know
Client refused
Special Issues: 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 disability should be determined based on an interview with the adult in the household.
If the response to physical disability is yes, the case manager records must document the physical
disability. Documentation includes written verification from a state-licensed professional, such
as a medical service project or a health-care project, the Social Security Administration, or the
receipt of a disability check (i.e., SSDI check or VA disability benefit check).
71
Changes from Previous Notice: Information Date is a new field, and should reflect the date on
which the information was collected.
4.8
Developmental Disability
Rationale: To count the number of developmentally disabled persons served, determine
eligibility for disability benefits, and assess their need for services. This is required to fulfill
multiple reporting requirements.
Data Source: Client interview, self-administered form and/or case manager records.
When Data Are Collected: In the course of client assessment once the individual is admitted–
unless this information is required prior to admission to determine project eligibility–at project
exit, and at least once annually during project enrollment if the period between project entry and
exit exceeds 1 year.
Subjects: All clients served.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS database), a single Information Date may be shared by all data elements
on the form. In separate fields, determine (1) if the client has a developmental disability, and (2)
if the client is currently receiving services or treatment for this disability or received services or
treatment prior to exiting the project. For the purposes of this Notice, 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.
Required Response Categories:
Program-Specific Data Element
4.8 Developmental Disability
Information Date
Developmental disability
(If yes)
[At entry]
Currently receiving services or treatment for this condition?
[At annual assessment and at exit]:
Received services/treatment while in the project?
Response Categories
(date)
No
Yes
Client doesn’t know
Client refused
No
Yes
Client doesn’t know
Client refused
Special Issues: 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 disability should be determined based on an interview with the adult in the household.
If the response to developmental disability is yes, the case manager records must document the
developmental disability. Documentation includes written verification from a state-licensed
professional, such as a medical service project or a health-care project, the Social Security
Administration, or the receipt of a disability check (i.e., SSDI check or VA disability benefit
check).
Changes from Previous Notice: Information Date is a new field, and should reflect the date on
which the information was collected.
72
4.9
Chronic Health Condition
Rationale: To count the number of persons served with severe health conditions and assess their
need for healthcare and other medical services. Required to fulfill multiple reporting
requirements.
Data Source: Client interview, self-administered form or case manager records.
When Data Are Collected: In the course of client assessment once the individual is admitted–
unless this information is required prior to admission to determine project eligibility–at project
exit, and at least once annually during project enrollment if the period between project entry and
exit exceeds 1 year.
Subjects: All clients served.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS database), a single Information Date may be shared by all data elements
on the form. In separate fields, determine: (1) if the client has a chronic health condition, and
(2) if the client is currently receiving services or treatment for this condition or received services
or treatment prior to exiting the project. For the purposes of this Notice, a chronic health
condition means a diagnosed condition that is more than 3 months in duration and is either not
curable or has residual affects that limit daily living and require adaptation in function or special
assistance. Examples of chronic health conditions include, but are not limited to, heart disease
(including coronary heart disease, angina, heart attack and any other kind of heart condition or
disease); severe asthma; diabetes; arthritis-related conditions (including arthritis, rheumatoid
arthritis, gout, lupus, or fibromyalgia); adult onset cognitive impairments (including traumatic
brain injury, post-traumatic distress syndrome, dementia, and other cognitive related conditions);
severe headache/migraine; cancer; chronic bronchitis; liver condition; stroke; or emphysema.
Required Response Categories:
Program-Specific Data Element
4.9 Chronic Health Condition
Information Date
Chronic Health Condition
(If yes)
[At entry]
Currently receiving services or treatment for this condition?
[At annual assessment and at exit]:
Received services/treatment while in the project?
Response Categories
(date)
No
Yes
Client doesn’t know
Client refused
No
Yes
Client doesn’t know
Client refused
Special Issues: 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 disability should be determined based on an interview with the adult in the household.
If the response to chronic health condition is yes, the case manager records must document the
chronic health condition. Documentation includes written verification from a state-licensed
professional, such as a medical service project or a health-care project, the Social Security
Administration, or the receipt of a disability check (i.e., SSDI check or VA disability benefit
check).
73
Changes from Previous Notice: Information Date is a new field, and should reflect the date on
which the information was collected.
4.10
HIV/AIDS
Rationale: To count the number persons served who have been diagnosed with AIDS or have
tested positive for HIV and assess their need for services. Required to fulfill multiple reporting
requirements.
Data Source: Client interview, self-administered form and/or case manager records.
When Data are Collected: In the course of client assessment once the individual is admitted–
unless this information is required prior to admission to determine project eligibility–at project
exit, and at least once annually during project enrollment if the period between project entry and
exit exceeds 1 year.
Subjects: All clients served.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS database), a single Information Date may be shared by all data elements
on the form. In separate fields, determine if the client (1) has been diagnosed with AIDS or has
tested positive for HIV, and (2) if the client is currently receiving services or treatment for this
diagnosis or received services or treatment prior to exiting the project.
Required Response Categories:
Program-Specific Data Element
4.10 HIV/AIDS
Information Date
HIV/ AIDS
(If yes)
[At entry]
Currently receiving services or treatment for this condition?
[At annual assessment and at exit]:
Received services/treatment while in the project?
Response Categories
(date)
No
Yes
Client doesn’t know
Client refused
No
Yes
Client doesn’t know
Client refused
Special Issues: This information is required for determining eligibility for the HOPWA project.
Such information is covered by confidentiality requirements. As in other areas involving
sensitive or protected client information, information should be recorded only when a project or
project has adequate data confidentiality protections. 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.
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 disability
should be determined based on an interview with the adult in the household.
Changes from Previous Notice: Information Date is a new field, and should reflect the date on
which the information was collected.
74
4.11
Mental Health Problem
Rationale: To count the number of persons with mental health problems served and to assess
the need for treatment. Required to fulfill multiple reporting requirements including to record
eligibility for HHS PATH services.
Data Source: Client interview, self-administered form or case manager records.
When Data are Collected: In the course of client assessment once the individual is admitted–
unless this information is needed prior to admission to determine project eligibility–at project
exit, and at least once annually during project enrollment if the period between project entry and
exit exceeds 1 year.
Subjects: All clients served.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS database), a single Information Date may be shared by all data elements
on the form. In separate data fields, determine: (1) if the client has a mental health problem, (2)
if the problem is expected to be of long-continued and indefinite duration and substantially
impedes a client’s ability to live independently, and (3) if the client is currently receiving
services or treatment for the condition or received services or treatment prior to exiting the
project. A mental health problem may include serious depression, serious anxiety,
hallucinations, violent behavior, or thoughts of suicide. For PATH-funded projects, identify how
the mental health problem was confirmed, whether the mental health problem qualifies as a
serious mental illness (SMI) and, if so, how SMI was confirmed.
Required Response Categories:
Program-Specific Data Element
4.11 Mental Health Problem
Information Date
Mental health problem
(PATH only)
(If Mental health problem is Yes)
How confirmed
(PATH only)
(If Mental health problem is Yes)
Serious mental illness (SMI) and, if SMI, how
confirmed
(If client has a mental health problem)
Expected to be of long-continued and
indefinite duration and substantially impairs
ability to live independently
(If client has a mental health problem)
[At entry]
Response Categories
(date)
No
Yes
Client doesn’t know
Client refused
Unconfirmed; presumptive or self-report
Confirmed through assessment and clinical evaluation
Confirmed by prior evaluation or clinical records
No
Unconfirmed; presumptive or self-report
Confirmed through assessment and clinical evaluation
Confirmed by prior evaluation or clinical records
Client doesn’t know
Client refused
No
Yes
Client doesn’t know
Client refused
No
Yes
75
Program-Specific Data Element
4.11 Mental Health Problem
Currently receiving services or treatment for
this condition?
[At annual assessment and at exit]:
Received services/treatment while in the
provider?
Response Categories
Client doesn’t know
Client refused
Special Issues: 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 disability should be determined based on an interview with the adult in the household.
If the response to mental health condition is yes, the case manager records must document the
mental health condition. Documentation includes written verification from a state-licensed
professional, such as a psychiatrist, medical service project, or a health-care project, the Social
Security Administration, or the receipt of a disability check (i.e., SSDI check or VA disability
benefit check).
Changes from Previous Notice: Information Date is a new field, and should reflect the date on
which the information was collected. PATH-required fields pertaining to how staff determined
the client’s mental health status and serious mental illness are also new.
4.12
Substance Abuse
Rationale: To count the number of persons served with substance abuse problems and to assess
the need for treatment. Required to fulfill multiple reporting requirements, including to record
eligibility for HHS PATH services.
Data Source: Client interview, self-administered form and/or case manager records.
When Data are Collected: In the course of client assessment once the individual is admitted–
unless this information is needed prior to admission to determine project eligibility–at project
exit, and at least once annually during project enrollment if the period between project entry and
exit exceeds 1 year. Subjects: All clients served.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS database), a single Information Date may be shared by all data elements
on the form. In separate data fields, determine: (1) if the client has an alcohol or drug abuse
problem or both, (2) if the problem is expected to be of long-continued and indefinite duration
and substantially impedes a client’s ability to live independently, and (3) if the client is currently
receiving services or treatment for the condition or received services or treatment prior to exiting
the project. For PATH-funded projects, identify how the substance abuse problem was
confirmed.
Required Response Categories:
Program-Specific Data Element
4.12 Substance Abuse
Response Categories
Information Date
Substance abuse problem
(date)
No
Alcohol abuse
Drug abuse
Both alcohol and drug abuse
76
Program-Specific Data Element
4.12 Substance Abuse
Response Categories
Client doesn’t know
Client refused
(PATH only)
(If Substance abuse problem is Alcohol abuse,
Drug abuse, or Both alcohol and drug abuse)
How confirmed
(If client has a substance abuse problem)
Expected to be of long-continued and indefinite
duration and substantially impairs ability to live
independently
Unconfirmed; presumptive or self-report
Confirmed through assessment and clinical evaluation
Confirmed by prior evaluation or clinical records
No
Yes
Client doesn’t know
Client refused
No
Yes
Client doesn’t know
Client refused
(If client has a substance abuse problem)
[At entry]
Currently receiving services or treatment for
this condition?
[At annual assessment and at exit]:
Received services/treatment while in the
Special
Issues: Projects should be especially sensitive
provider?
to the collection of disability information
from clients under the age of 18. In households with children accompanied by an adult,
children’s disability should be determined based on an interview with the adult in the household.
Changes from Previous Notice: Information Date is a new field, and should reflect the date on
which the information was collected. A PATH-required field pertaining to how the staff
confirmed the client’s substance use/abuse status has also been added.
4.13
Domestic Violence
Rationale: Ascertaining whether a person is a victim of 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 experiencing homelessness that has
experienced domestic violence is critical for determining the resources required to address the
problem in this population. Required to fulfill multiple reporting requirements.
Data Source: Client interview, self-administered form and/or case manager records. When
Data are Collected: In the course of client assessment.
Subjects: All heads of household and adult household members.
Definition and Instructions: Enter the date that the information was collected from the client.
In the event that multiple data elements are collected on a single form (and/or are stored in a
single table in the HMIS database), a single Information Date may be shared by all data elements
on the form. In separate fields, determine (1) if the client has ever been a victim of domestic
violence, and (2), if so, when the client’s most recent experience of domestic violence occurred.
77
Required Response Categories:
Program-Specific Data Element
4.13 Domestic Violence
Information Date
Domestic violence
victim/survivor
(If yes) When experience
occurred
Response Categories
(date)
No
Yes
Client doesn’t know
Client refused
Within the past three months
Three to six months ago
From six to one year
More than a year ago
Client doesn’t know
Client refused
Special Issues: 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.
Changes from Previous Notice: Information Date is a new field, and should reflect the date on
which the information was collected.
4.14
Contact
Rationale: To record and count the number of contacts with homeless persons by street
outreach projects and other PATH service projects. Required to fulfill multiple reporting
requirements, including HHS PATH projects.
Data Source: Project staff.
When Data Are Collected: Each time a client is contacted.
Subjects: All clients served.
Definition and Instructions: A contact is an interaction between a street outreach worker and a
client. A contact is, a verbal conversation between the street outreach worker and the client
about the client’s well-being or service needs, or a referral to service. PATH-funded projects
should enter Length of contact in minutes, as well as Type of contact, whether a one-on-one
contact (“Individual”) or a contact in a group setting (“Group”).
78
Required Response Categories:
Program-Specific Data Element
4.14 Date of Contact
Date of contact
Time of contact
(PATH only)
Length of contact
(PATH only)
Type of contact
Location of Contact
Response Categories
(date)
(Use 24-hour “military” time)
(integer)
Examples
(8/31/2013)
15:45
20
Individual
Group
Place not meant for habitation
Service setting, non-residential
Service setting, residential
Vehicle, abandoned building,
bus/train/subway station/airport or
anywhere outside that is not a
Homeless Connect-type event
Homeless Connect-type event, drop in
center, day services center, soup
kitchen, etc.
Emergency, transitional or permanent
housing; treatment facility, including
health, mental health, or substance
abuse clinic or hospital; jail, prison,
or juvenile detention facility; family
or friend’s room, apartment, condo,
or house; foster care or group home
Special Issues: To record a contact in HMIS requires that a client record be established with at
least minimal client descriptors included in the Universal Data elements (e.g., name, gender,
race).
Changes from Previous Notice: Under the previous notice, the time of contact was required; it
is now optional. Length of contact and Type of contact are new fields required for PATH
projects and optional for others.
4.15
Dates of Engagement and Enrollment
Rationale: To count the number of homeless persons engaged by street outreach projects during
the operating year and/or enrolled in the PATH program. Required to fulfill multiple reporting
requirements, including HHS PATH projects.
Data Source: Project staff.
When Data Are Collected: In the course of client assessment.
Subjects: All clients served.
Definition and Instructions: 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 may occur on the same date as the date of enrollment, or a distinct date that may
occur before, concurrent with, or after the project entry date. This date must be in the
mm/dd/yyyy format.
An enrollment date is the date on which the client is enrolled into a PATH funded program. This
date reflects the date on which the client has formally consented to participate in services
through the PATH project. For the PATH reporting, projects must report the number of clients
that were enrolled. This date must be in the mm/dd/yyyy format.
Required Response Categories:
79
Program-Specific Data Element
4.15 Dates of Engagement and
Enrollment
Response Category
Date of engagement
(date)
Date of enrollment
(date)
Special Issues: There should be one and only one Date of engagement and Date of enrollment
per project intake. It is also possible that a case may be closed without the client becoming
engaged or enrolling and thus no dates would be recorded in that client record.
Changes from Previous Notice: None.
4.16
Veterans Information
Rationale: To collect a detailed profile of veteran’s experiencing homelessness and to
determine eligibility for VA projects and benefits. These questions were developed in
consultation with VA and reflect HUD’s continuing effort to standardize data definitions and
standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: In the course of client assessment nearest to project entry.
Subjects: All persons who answered “Yes” to Veteran Status data element.
Definition and Instructions: This data element is required for VA-funded SSVF projects; it is
optional for all others.
80
Required Response Categories:
Program-Specific Data Element
4.16 Veteran’s
information
Year entered
military service
Year separated
from military
service
Served in a
theater of
operations?
(If Yes) Name of
theater of
operations
Branch of the
military
Response Categories
(year)
(year)
No
Yes
Client doesn’t know
Client refused
World War II
Korean War
Vietnam War
Persian Gulf War (Operation Desert Storm)
Afghanistan (Operation Enduring Freedom)
Iraq (Operation Iraqi Freedom)
Iraq (Operation New Dawn)
Other peace-keeping operations or military interventions (such as
Lebanon, Panama, Somalia, Bosnia, Kosovo)
Client doesn’t know
Client refused
Army
Air Force
Navy
Marines
Coast Guard
Other
Client doesn’t know
Discharge
status
Client refused
Honorable
General under honorable conditions
Under other than honorable conditions (OTH)
Bad conduct
Dishonorable
Uncharacterized
Client doesn’t know
Client refused
Special Issues: Users must be able to select as many response categories as apply under Name
of theater of operations.
Changes from Previous Notice: Under the previous notice, Optional Data Element 4.15E
outlined collection of data pertaining to military service beyond the universal Veteran Status data
element. The Optional Data Element has been retired in favor of the one defined here to meet
the requirements of the VA.
81
4.17
Services Provided
Rationale: To determine the services provided to clients during project participation, and to
meet the data collection and reporting needs of federal agencies.
Data Source: Case manager or project records.
When Data are Collected: When services are provided during the course of project
participation.
Subjects: All clients served.
Definition and Instructions: Services provided are those that the project offers directly for the
benefit of clients. Services should be recorded for the individual client to whom they were
provided; a service that benefits the whole household (e.g., housing search and placement) may
be recorded solely for the head of household. For each service provided, projects should record
the service start date, service end date, funding source, and service type.
This data element provides the universe of fields and response categories required by HUD and
other federal agencies identified in Section 1.6. Each federal agency may issue an applicability
notice or other guidance that identifies which, if any, of the fields and response categories
defined here must be collected by their projects. HMIS solution projects should be prepared to
configure data collection of this data element based on that guidance.
Required Response Categories:
4.17 Services
Provided
Date of
service
Service start
date
Service end
date
Funding
source
Response Categories
(date)
(date)
(date)
HUD-Supportive Housing Program
HUD-Shelter Plus Care
HUD-Section 8 Moderate Rehabilitation Program
HUD-Continuum of Care Program
HUD-Emergency Solutions Grant Program (includes Emergency Shelter
Grant Program)
HUD-Rural Housing Stability Program
HUD-Housing Opportunities for Persons with AIDS (HOPWA)
HUD-Veterans Affairs Supportive Housing (VASH) Program
HHS-Runaway and Homeless Youth Programs
HHS-Projects for Assistance in Transition from Homelessness (PATH)
HHS-Healthcare for the Homeless
VA-Grant and Per Diem Program
VA-Supportive Services for Veteran Families (SSVF)
VA-Homelessness Prevention Demonstration Program
VA-Residential Rehabilitation Treatment Programs (RRTP)-Domiciliary
(DOM)
VA-Compensated Work Therapy (CWT)-Transitional Residence (TR)
VA-Health Care for Homeless Veterans (HCHV) Residential Treatment
Program
VA-Health Care for Re-entry Veterans (HCRV)
VA-VA Community Contract Emergency Housing
82
4.17 Services
Provided
Service type
Response Categories
[Other-identify]
Adult day care and personal assistance
Assistance obtaining other public benefits
Assistance obtaining VA benefits
Basic support services
Birthing care
Case management
Child care
Community service / service learning
Consumer assistance / credit repair
Criminal justice / legal services
Dental care
Education
Employment and training services
Food / meals / nutritional services
Formal placement in alternative setting other than BCP or original home
Habilitation / rehabilitation
Health / medical care
HIV/AIDS-related services
Housing minor renovation
Housing search and placement
Housing technical assistance
Life skills training
Material goods
Mental health care / counseling
Outreach and/or engagement
Parenting education for parent of youth
Parenting education for youth with children
Peer (youth) counseling
Post-natal care
Pre-natal care
Pre-resident assessment
Preventative - in-home prevention services
Preventative - out-of-home prevention services
Preventive - temporary stay or respite outside of home, not in BCP
Psychological or psychiatric care
Recreational activity
Referral to other service(s)
Residential supportive services
Screening / assessment
Substance abuse services / treatment
Support group
Temporary housing and other financial aid
Transitional life planning
83
4.17 Services
Provided
Response Categories
Transportation
Youth mentoring
Special Issues: This data element outlines the universe of fields and response categories for this
data element. There is no intent that projects collecting services data in HMIS must do so using
all of the fields and response categories shown. Projects may streamline or expand on the fields
and response categories presented here to meet their particular data collection and reporting
requirements. There is also no intent to require that all services data for all projects be stored in
the same set of fields within an HMIS.
In some instances, it may be necessary to differentiate between services funded by multiple
funding sources. The addition of the Funding Source field is intended to acknowledge and
address this need in a standardized way; there will be a corresponding addition to the XML and
CSV specifications. Response categories must correspond to the funding sources identified in
project descriptor data element 2.13 Federal Funding Source(s). Projects with a single funding
source (or with no need to differentiate) are not required to enter data in this field. HUD
recognizes that the use of this field is not the only acceptable approach for addressing this need,
and as long as projects that might need to differentiate are able to do so, an HMIS will be
considered compliant.
Changes from Previous Notice: The previous notice included data element 4.15H Services
Provided as an optional data element; this data element includes significant additions to the
fields contained in the data element and the response categories to identify services.
4.18
Financial Assistance Provided
Rationale: To track financial assistance provided to clients during project participation and to
meet the data collection and reporting requirements of other federal agencies.
Data Source: Case manager or project records.
When Data are Collected: When financial assistance is provided during the course of project
participation.
Subjects: Clients who receive financial assistance.
Definition and Instructions: Financial Assistance records payments made by the project on
behalf of or for the benefit of the client. For each instance of financial assistance provided, there
should be one and only one record created. Unless the financial assistance provided was for the
particular benefit of a single household member, records of financial assistance should be
attached to the head of household.
This data element provides the universe of fields and response categories required by HUD and
the federal agencies identified in Section 1.6. Each federal agency may issue an applicability
notice that identifies which, if any, of the fields and response categories defined here must be
collected by their projects. HMIS vendors should be prepared to configure data collection of this
data element based on that guidance.
84
Required Response Categories:
4.18 Financial
assistance
Date of financial
assistance
Start date of
financial
assistance
End date of
financial
assistance
Funding source
Response Categories
(date)
(date)
(date)
HUD-Supportive Housing Program
HUD-Shelter Plus Care
HUD-Section 8 Moderate Rehabilitation Program
HUD-Continuum of Care Program
HUD-Emergency Solutions Grant Program (includes Emergency Shelter
Grant Program)
HUD-Rural Housing Stability Program
HUD-Housing Opportunities for Persons with AIDS (HOPWA)
HUD-Veterans Affairs Supportive Housing (VASH) Program
HHS-Runaway and Homeless Youth Programs
HHS-Projects for Assistance in Transition from Homelessness (PATH)
HHS-Healthcare for the Homeless
VA-Grant and Per Diem Program
VA-Supportive Services for Veteran Families (SSVF)
VA-Homelessness Prevention Demonstration Program
VA-Residential Rehabilitation Treatment Programs (RRTP)-Domiciliary
(DOM)
VA-Compensated Work Therapy (CWT)-Transitional Residence (TR)
VA-Health Care for Homeless Veterans (HCHV) Residential Treatment
Program
VA-Health Care for Re-entry Veterans (HCRV)
VA-VA Community Contract Emergency Housing
[Other-identify]
Service type
Financial
assistance
amount
Rental assistance
Security deposits
Utility deposits
Utility payments
Moving cost assistance
Purchase of emergency supplies
Transportation
Child care
HOPWA long term rental
HOPWA short term rental
Mortgage assistance
(amount)
85
Special Issues: There is no intent that projects collecting financial assistance data in HMIS must
do so using all of the fields and response categories shown. Projects may streamline or expand
on the fields and response categories presented here to meet their particular data collection and
reporting requirements. There is also no intent to require that all financial assistance data for all
projects be stored in the same set of fields within an HMIS solution.
In some situations, it may be necessary to differentiate between financial assistance funded by
multiple funding sources. The addition of the Funding source field is intended to acknowledge
and address this need in a standardized way; there will be a corresponding addition to the XML
and CSV specifications. Response categories must correspond to the funding sources identified
in project descriptor data element 2.13 Federal Funding Source(s). Projects with a single funding
source (or with no need to differentiate) are not required to use this field. HUD recognizes that
the use of this field is not the only acceptable approach for addressing this need, and as long as
projects that might need to differentiate are able to do so, an HMIS solution will be considered
compliant.
Changes from Previous Notice: This is a new data element.
4.19
Area Median Income (AMI) Percentage Used for Eligibility
Rationale: To record the percentage of Area Median Income (AMI) for the household as
calculated by the case worker. This question was developed in consultation with HOPWA and
reflects HUD’s continuing effort to standardize data definitions and standards across federal
agencies.
Data Source: Project or case management records.
When Data are Collected: When referrals are provided during the course of project
participation.
Subjects: All heads of household.
Definition and Instructions: Calculate the AMI percentage as required to determine eligibility
and record.
Required Response Categories:
Program-Specific Data Element
4.19 AMI Percentage Used for
Eligibility
Response Category
(percentage)
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.20
Sexual Orientation
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: Youth heads of household.
86
Definitions and Instructions: Choose one response category indicating how the youth
describes his/her sexual orientation.
Required Response Categories:
Program-Specific Data Element
4.20 Sexual Orientation
Sexual Orientation
Response Categories
Heterosexual
Gay
Lesbian
Bisexual
Questioning / Unsure
Client doesn’t know or refused
Special Issues: Any questions regarding a client’s sexual orientation must be voluntary and
clients must be informed prior to responding of the voluntary nature of the question and that their
refusal to respond will not result in a denial of services.
Changes from Previous Notice: This is a new data element.
4.21
Last Grade Completed
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: Youth heads of household.
Definitions and Instructions: Choose one response category describing the last grade level
completed by the youth.
Required Response Categories:
Program-Specific Data Element
4.21 Last grade
completed
Last grade
completed
Response Categories
Less than Grade 5
Grades 5-6
Grades 7-8
Grades 9-12
GED
Some college
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.22
School Status
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
87
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: Youth heads of household.
Definitions and Instructions: Choose one response category describing the youth’s school
status. If school is not in session at the time of the youth’s project entry, this question pertains to
the school year just completed.
Required Response Categories:
Program-Specific Data Element
4.22 School status
School status
Response Categories
Attending school regularly
Attending school irregularly
Graduated from high school
Obtained GED
Dropped out
Suspended
Expelled
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.23
General Health Status
Rationale: Information on general health status is a first step to identifying what types of health
services a client may need. This data element permits the self-reported health status of clients to
be compared with the self-reported health status of the U.S. population in general.
Data Source: Client interview or self-administered form.
When Data are Collected: In the course of client assessment nearest to project entry, at project
exit and at least once annually during project enrollment, if the period between project entry and
exit exceeds 1 year.
Subjects: All clients served or all heads of household and adult household members.
Definition and Instructions: Determine how the client assesses their health (and the health of
minors with the household, if applicable) in comparison to other people their age.
Required Response Categories:
Optional Program-Specific Data Element
4.23 General Health
Response Categories
Excellent
Very good
Good
Fair
Poor
Client doesn’t know
Client refused
88
Special Issues: None.
Changes from Previous Notice: None.
4.24
Pregnancy Status
Rationale: To determine eligibility for benefits and need for services and to determine the
number of women entering CoC projects while pregnant.
Data Source: Client interview or self-administered form.
When Data are Collected: In the course of client assessment nearest to project entry.
Subjects: All females of child-bearing age served.
Definition and Instructions: In separate fields, determine (a) if a client is pregnant and (b), if
so, what is the due date. The due date must be in the mm/dd/yyyy format. If the day is
unknown, projects are encouraged to record “01” as a default value. Communities that already
have a policy of entering another approximate day may continue this policy. If the month is
unknown, projects should leave the data field blank.
Required Response Categories:
Optional Program-Specific Data Element
4.24 Pregnancy Status
Pregnancy status
Response Categories
No
Yes
Client doesn’t know
Client refused
If yes, due date
(date)
Special Issues: Records for pregnant clients should be updated automatically to account for
changes in clients’ pregnancy status (e.g., following the birth of a child). Using the “If yes, due
date” field, the HMIS should automatically update, but not overwrite, the client’s record by
changing the “Pregnancy status” field from “Yes” to “No” once the due date passes. This is a
transactional data element and changes in pregnancy status should be recorded in data fields
without overwriting previously entered data.
Changes from Previous Notice: This is a new data element.
4.25
Funding Source for Residence Prior to Project Entry
Rationale: To identify, for specific funders, whether the residence prior to project entry was a
project funded by the same program. This question was developed in consultation with VA and
HOPWA and reflects HUD’s continuing effort to standardize data definitions and standards
across federal agencies.
Data Source: Case manager records, interview, or self-administered form.
When Data are Collected: At any time after the client has been admitted into the project
(unless a residence just prior to project admission is required for determining the client’s
eligibility for the project).
Subjects: Heads of household and adult household members.
Definition and Instructions: Select the response category that appropriately identifies the
funding source for the residence prior to project entry.
89
Required Response Categories:
Program-Specific Data Element
4.25 Funding
source for
Residence Prior
Funding source for
residence prior to
project entry
Response categories
HOPWA
VA
Other
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.26
Funding Source for Destination
Rationale: To identify, for specific funders, whether the destination is a project funded by the
same source. This question was developed in consultation with VA and HOPWA and reflects
HUD’s continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Case manager records, interview, or self-administered form.
When Data are Collected: At project exit.
Subjects: Heads of household and adult household members.
Definition and Instructions: Select the response category that appropriates identifies the
funding source for the destination.
Required Response Categories:
Program-Specific Data Element
4.26 Funding
Source for
Destination
Funding source for
destination
Response categories
HOPWA
VA
Other
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.27
Referrals Provided
Rationale: To record the referrals provided to clients during program participation. This
question was developed in consultation with HHS and HOPWA and reflects HUD’s continuing
effort to standardize data definitions and standards across federal agencies.
Data Source: Case manager records.
When Data are Collected: When referrals are provided during the course of project
participation.
90
Subjects: All clients served.
Definition and Instructions: The referrals to be recorded in HMIS are those which the project
made for the benefit of the client being referred. An assisted referral must include
documentation that the project performed at least one of the following functions on behalf of or
in conjunction with the client:
1.
2.
3.
4.
Assisting the client in obtaining the application;
Assisting the client in obtaining the appropriate supporting documentation;
Assisting the client with completion of the application; and
Assisting the client in filing the application with the appropriate agency or
organization (business if employment); OR
5. Referring the client to a program that specializes in assisting clients with an
application process and that can certify that the application has been successfully filed
by the client.
In separate fields, record the date of referral; the type of referral; the referral status; if not met,
reason; outcome; and target service.
This data element provides the universe of fields and response categories required by HUD and
the federal agencies identified in Section 1.6. Each of the federal agencies will issue
applicability notices for their programs that identifies which, if any, of the fields and response
categories defined here must be collected by their projects. HMIS vendors should be prepared to
configure data collection of this data element based on that guidance and the requirements of
CoCs and individual projects.
Required Response Categories:
Program-Specific Data Element
4.27 Referrals
Provided
Date of
referral
Type of referral
(PATH)
Referral status
(PATH)
Referral
Outcome
(HOPWA and
RHY)
Referral
Outcome
Response Categories
Examples
(date)
Referral
Assisted referral
Closed
Identified
In progress
Service pending
Fully met
Partially met
Not met
Service pending
Client is receiving services and is
compliant with plan
Client is receiving services and is
partially compliant with plan
Client is receiving services but is not
compliant with plan
Client is not receiving services
91
Program-Specific Data Element
4.27 Referrals
Provided
(If Referral
outcome is Not
met or Client is
not receiving
services)
Reason
Referral Target
Response Categories
All services full
Client not eligible
Client refused service
No show
Service does not exist
Unknown
Adult day care and personal
assistance
Case management
Child care and other child services
Childcare (non TANF)
Community mental health
Education
Educational services
Employment and training services
Employment assistance
Supplemental Nutrition Assistance
Program (SNAP) formerly
called Food Stamps or other
non-WIC nutrition
Health/medical/intensive care
services
Housing placement assistance
Housing placement assistance
HUD Section 8 or other permanent
housing assistance
Income assistance
Job training
Legal services
Examples
Adult day care projects, in home
assistance, personal care
Case/care management, medical
social work
Child day care, in home
assistance, personal care
Community-based supports
Adult Education, GED instruction,
General Health and Nutrition
Education, English as a
second language, child
education advocacy,
Educational services to assist in
obtaining employment
Employment preparation, job
training, job
search/placement, day labor,
part-time employment
Assisted referral for obtaining
employment
General medical care, screening,
testing (including HIV),
dental, counseling,
prevention services,
community mental health
services
Assisted referral for obtaining
transitional, permanent, or
other housing
Housing search assistance,
forms/application assistance
Assisted referral for obtaining
income including mainstream
benefits
Job training
Legal counseling, benefits
assistance, ex-offender
services, advocacy,
landlord/tenant, eviction
assistance, tax preparation
92
Program-Specific Data Element
4.27 Referrals
Provided
Response Categories
Examples
Life skills education
Home management instruction,
parenting, personal financial
management, life skills
development
Furniture, house wares, cooking
utensils, appliances
Emergency food, food banks,
meals, soup kitchens,
nutritional counseling
Material goods
Meals/nutritional services
Medicaid
Medical assistance
Mental health services
Mentoring program other than RHY
agency
National service (e.g., AmeriCorps.
VISTA, Learn and Serve)
Non-residential substance abuse
treatment or mental health
program
Other
Other public federal, state, or local
program
Outreach
Primary health services
Private non-profit charity or
foundation support
Relevant housing services
SCHIP
SSI, SSDI or other disability
assistance
SOAR program
Substance use services
Substance use treatment
Assisted referral for obtaining
medical care
Screening/assessment/evaluation,
counseling, treatment,
intervention, psychiatric
rehabilitation,
Outreach, street outreach
Primary health care services
Miscellaneous services for
obtaining and maintaining
housing
SAMHSA's SSI/SSDI Outreach,
Access, and Recovery
(SOAR) program
Alcohol and drug testing,
screening, Detox projects,
prevention, treatment,
counseling, dependency
support groups
Treatment for substance use
disorders
TANF or other welfare/ nondisability income maintenance
(All TANF services)
93
Program-Specific Data Element
4.27 Referrals
Provided
Response Categories
Examples
Temporary financial assistance
Short term rental, mortgage, and
utility financial assistance,
including security deposits,
application fees, and
connection fees.
Local transportation, taxi services,
bus passes, mass transit
passes
Transportation
Unemployment Insurance
WIC
Workforce Development (e.g., WIA)
Special Issues: There is no intent that projects collecting referral data in HMIS must do so using
all of the fields and response categories shown. Projects may streamline or expand on the fields
and response categories presented here to meet their particular data collection and reporting
requirements. There is also no intent to require that all services data for all projects be stored in
the same set of fields within an HMIS solution.
Changes from Previous Notice: This is a new data element.
4.28
Reason for Leaving
Rationale: Reason for leaving is used, in part, to identify the barriers and issues clients face in
completing a project or staying in a residential facility, which may affect their ability to achieve
economic self-sufficiency.
Data Source: Client interview, self-administered form or case manager records.
When Data Are Collected: At project exit.
Subjects: All clients served.
Definition and Instructions: Identify the reason why the client left the project. If a client left
for multiple reasons, record only the primary reason.
Required Response Categories:
Program-Specific Data Element
4.28 Reason for Leaving
Reason for leaving
Response Categories
Left for a housing opportunity before completing project
Completed project
Non-payment of rent/occupancy charge
Non-compliance with project
Criminal activity/destruction of property/violence
Reached maximum time allowed by project
Needs could not be met by project
Disagreement with rules/persons
Death
Unknown/disappeared
Other
94
Special Issues: None.
Changes from Previous Notice: None.
4.29
Project Transition
Rationale: To identify the type of project a client may have transitioned to after exit. This
question was developed in consultation with HHS and HOPWA and reflects HUD’s continuing
effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview, self-administered form, or case manager records.
When Data are Collected: At project exit.
Subjects: All clients served.
Definition and Instructions: Identify the project transition that the client made at exit, if
known.
Required Response Categories:
Program-Specific Data Element
4.29 Project Transition
Response Category
Project transition
Transitioned to case management project (outreach only)
Transitioned to treatment project (outreach only)
Transitioned to a residential plus treatment project (outreach only)
No transition
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.30
Formerly a Ward of Child Welfare/Foster Care Agency
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: Youth heads of household.
Definitions and Instructions: Choose one response category to indicate whether the youth was
formerly the responsibility of the child welfare or foster care agency.
95
Required Response Categories:
Program-Specific Data Element
4.30 Formerly ward of child
welfare / foster care agency
Formerly a ward of child welfare
or foster care agency
(If Yes)
Number of years
Response Categories
No
Yes
Client doesn’t know
Client refused
Less than one year
1 to 3 years
3 to 5 years
more than 5 years
(If number of years is Less than
one year)
Number of months
(a number between 1 and 11)
Special Issues: FYSB funds are not intended to support youth who are currently the
responsibility of the foster care/child welfare system. Some states designate such youth as
“wards of the state” (for whom the state is legal guardian). However, some youth previously in
foster care have been discharged from that system or have reached an age of legal independence
in a state–Specific rules about age vary by state. Such youth are no longer a public responsibility
and can be assisted with FYSB funds.
Changes from Previous Notice: This is a new data element.
4.31
Formerly a Ward of Juvenile Justice System
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: Youth head of household.
Definitions and Instructions: Choose one response category to indicate whether the youth was
formerly the responsibility of the juvenile justice system.
Required Response Categories:
Program-Specific Data Element
4.31 Formerly a ward of juvenile
justice system
Formerly a ward of juvenile
justice system
(If Yes)
Number of years
(If number of years is Less than
one year)
Number of months
Response Categories
No
Yes
Client doesn’t know
Client refused
Less than one year
1 to 3 years
3 to 5 years
more than 5 years
(a number between 1 and 11)
96
Special Issues: FYSB funds are not intended to support youth who are presently the
responsibility of the juvenile justice system. However, some youth previously under the
supervision or care of juvenile justice agencies have been discharged from that system or have
reached an age of legal independence in a state–specific rules about age vary by state. Such
youth are no longer a public responsibility and can be assisted with FYSB funds.
Changes from Previous Notice: This is a new data element.
4.32
Young Person’s Critical Issues
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form and case manager records.
When Data are Collected: Data are collected during the youth’s project stay. Data should be
entered into HMIS at exit.
Subjects: Youth heads of household.
Definitions and Instructions: Choose appropriate response categories to identify the young
person’s critical issues, as identified by staff and the young person during period of services.
These categories are for reporting purposes and are therefore general and broad. Agency case
management practice should reflect more precision.
Required Response Categories:
Program-Specific Data Element
4.32 Youth / Family Critical Issues
Household Dynamics – Youth
Household Dynamics - Family member
Sexual Orientation/Gender Identity – Youth
Sexual Orientation/Gender Identity - Family
member
Housing Issues – Youth
Housing Issues - Family member
School or Educational Issues – Youth
School or Educational Issues - Family member
Unemployment – Youth
Unemployment - Family member
Mental Health Issues – Youth
Mental Health Issues - Family member
Health Issues – Youth
Response Categories
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
97
Program-Specific Data Element
4.32 Youth / Family Critical Issues
Health Issues - Family member
Physical Disability – Youth
Physical Disability - Family member
Mental Disability – Youth
Mental Disability - Family member
Abuse and Neglect – Youth
Abuse and Neglect - Family member
Alcohol or other drug abuse – Youth
Alcohol or other drug abuse - Family member
Insufficient Income to support youth – Youth
Insufficient Income to support youth - Family
member
Incarcerated parent of youth
(If Incarcerated parent of youth is Yes)
Please specify
Response Categories
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
One parent / legal guardian is
incarcerated
Both parents / legal guardians are
incarcerated
The only parent / legal guardian is
incarcerated
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.33
Referral Source
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: Upon initial project entry or as soon as possible thereafter.
Subjects: Youth heads of household.
Definitions and Instructions: Choose one response category to indicate the individual or
organization through which the youth was advised about, sent, or directed to your project.
98
Required Response Categories:
Program-Specific Data Element
4.33 Referral Source
Referral Source
Response Categories
Self-Referral
Individual: Parent/Guardian
Individual: Relative or Friend
Individual: Other adult or youth
Individual: partner/spouse
Individual: Foster Parent
Outreach Project: FYSB
Outreach Project: Other
Temporary Shelter: FYSB Basic Center Project
Temporary Shelter: Other Youth Only Emergency Shelter
Temporary Shelter: Emergency Shelter for Families
Temporary Shelter: Emergency Shelter for Individuals
Temporary Shelter: Safe Place
Temporary Shelter: Other
Residential Project: FYSB Transitional Living Project
Residential Project: other Transitional Living Project
Residential Project: Group Home
Residential Project: Independent Living Project
Residential Project: Job Corps
Residential Project: Drug Treatment Center
Residential Project: Treatment Center
Residential Project: Educational Institute
Residential Project: Other Agency project
Residential Project: Other project
Hotline: National Runaway Switchboard
Hotline: Other
Other Agency: Child Welfare/CPS
Other Agency: Non-Residential Independent Living Project
Other Project operated by your agency
Other Youth Services Agency
Juvenile Justice
Law Enforcement/ Police
Religious Organization
Mental Hospital
School
Other organization
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
99
4.34
Transitional, Exitcare, or Aftercare Plans and Actions
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Case manager records.
When Data are Collected: Data are collected during the youth’s project stay. Data should be
entered into HMIS at exit.
Subjects: Youth heads of household.
Definitions and Instructions: Choose all response categories that identify discharge services
provided to the young person through the project.
Required Response Categories:
Program-Specific Data Element
4.34 Transitional, Exitcare, or Aftercare Plans and Actions
A written transitional, aftercare or follow-up plan or agreement
Advice about and/or referral to appropriate mainstream
assistance programs
Placement in appropriate, permanent, stable housing (not a
shelter)
Due to unavoidable circumstances or scarcities of appropriate
housing, the youth must be transported or accompanied to a
temporary shelter
Exit counseling
A course of further follow-up treatment or services
A follow-up meeting or series of staff/youth meetings or contacts
has been scheduled
A "package" of such things as maps, information about local
shelters and resources
Other
Response Categories
No
Yes
Client refused
No
Yes
Client refused
No
Yes
Client refused
No
Yes
Client refused
No
Yes
Client refused
No
Yes
Client refused
No
Yes
Client refused
No
Yes
Client refused
No
Yes
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
100
4.35
Project Completion Status
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: A t project exit.
Subjects: Youth heads of household in FYSB-funded Transitional Living Projects.
Definitions and Instructions: Choose one response category that describes the youth’s project
completion status.
Required Response Categories:
Program-Specific Data Element
4.35 Project Completion
Status
Project Completion Status
Response Categories
Completed project
Voluntarily did not complete project because of other
opportunities
Voluntarily did not complete project, no plans
Youth was expelled or otherwise involuntarily discharged
from project
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.36
Family Reunification Achieved
Rationale: This question was developed in consultation with HHS/PATH and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: At project exit.
Subjects: Youth heads of household.
Definitions and Instructions: Choose one response category to indicate whether family
reunification was achieved at program exit.
Required Response Categories:
Program-Specific Data Element
4.36 Family reunification
achieved
Family reunification achieved
Response Categories
No
Yes
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.37
Physical Health Status
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
101
Data Source: An examining health professional; the examining health professional should be a
certified practitioner but is not required to be a licensed medical doctor.
When Data are Collected: At project exit.
Subjects: Youth heads of household in FYSB-funded Transitional Living Projects.
Definitions and Instructions: Choose one response category that describes the youth’s physical
health status at exit.
Required Response Categories:
Program-Specific Data Element
4.37 Physical Health Status
Physical Health Status
Response Categories
Good
Not Good
Not Known
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.38
Dental Health Status
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: An examining dental health professional; the examining dental health
professional should be a certified practitioner but need not be a licensed dentist.
When Data are Collected: At project exit.
Subjects: Youth heads of household in FYSB-funded Transitional Living Projects.
Definitions and Instructions: Choose one response category that describes the youth’s dental
health status at exit.
Required Response Categories:
Program-Specific Data Element
4.38 Dental Health Status
Dental Health Status
Response Categories
Good
Not Good
Not Known
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.39
Mental Health Status
Rationale: This question was developed in consultation with HHS/FYSB and reflects HUD’s
continuing effort to standardize data definitions and standards across federal agencies.
Data Source: A n examining mental health professional; the examining mental health
professional should be a certified practitioner but need not be a licensed doctor.
When Data are Collected: At project exit.
Subjects: Youth head of household in FYSB-funded Transitional Living Projects.
102
Definitions and Instructions: Choose one response category that describes the youth’s mental
health status at exit.
Required Response Categories:
Program-Specific Data Element
4.39 Mental Health Status
Response Categories
Mental Health Status
Good
Not Good
Not Known
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.40
Housing Category
Rationale: This question was developed in consultation with VA and reflects HUD’s continuing
effort to standardize data definitions and standards across federal agencies.
Rationale: To document program eligibility and facilitate SSVF reporting.
Data Source: Client interview or self-administered form.
When Data are Collected: In the course of client assessment nearest to project entry.
Subjects: Heads of household and adult household members.
Definition and Instructions: This data element is required for VA-funded SSVF projects; it is
optional for all others.
Required Response Categories:
Program-Specific Data Element
4.40 Housing
Category
Housing
category at
program entry
Response Categories
Residing in permanent housing
Homeless and scheduled to become residents of permanent housing in
90 days
Exited permanent housing within the previous 90 days and seeking
other housing that is responsive to their needs
Other (ineligible)
Special Issues: Households that fall into the ‘Other (ineligible)’ category are not eligible for
service under the SSVF program.
Changes from Previous Notice: This is a new data element.
4.41
Percent of AMI
Rationale: To document program eligibility and facilitate reporting for the VA’s SSVF
program. This question was developed in consultation with VA and reflects HUD’s continuing
effort to standardize data definitions and standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: In the course of client assessment nearest to project entry.
Subjects: Heads of household and adult household members.
103
Definition and Instructions: This data element is required for VA-funded SSVF projects; it is
optional for all others. Users should indicate household income as a percentage of area median
income, as published annually by HUD (http://www.huduser.org).
Required Response Categories:
Program-Specific Data Element
4.41 Percent of AMI
Household income
as a percentage of
AMI
Response categories
Less than 30%
30% to 50%
Greater than 50% (ineligible)
Special Issues: Households with income greater than 50 percent of AMI are not eligible for
service under the SSVF program.
Changes from Previous Notice: This is a new data element.
4.42
Formerly Chronically Homeless
Rationale: To facilitate reporting for the VA’s SSVF program. This question was developed in
consultation with VA and reflects HUD’s continuing effort to standardize data definitions and
standards across federal agencies.
Data Source: Client interview or self-administered form.
When Data are Collected: In the course of client assessment nearest to project entry.
Subjects: Heads of household or spouse of head of household.
Definition and Instructions: This data element is required for VA-funded SSVF projects; it is
optional for all others. This data element documents whether the household (or head of
household) has been chronically homeless in the past.
Required Response Categories:
Program-Specific Data Element
4.42 Formerly
Chronically Homeless
(for households not
currently designated as
chronically homeless)
History of chronic
homelessness
Response categories
No
Yes
Client doesn’t know
Client refused
Special Issues: None.
Changes from Previous Notice: This is a new data element.
4.43
Federal Program Funding Source for Project Clients
Rationale: To identify the funding source for clients.
Data Source: Case manager records.
When Data are Collected: At project entry, or at the point a funding source is determined
applicable (i.e. effective) for the client
104
Subjects: Heads of household OR specific clients that are served by or must be accounted for in
a funding source
Definition and Instructions: From a list of funding sources and grant identifiers that
correspond to the funding sources identified in project descriptor data element 2.13 Federal
Funding Source(s), select, for each program entry, a single source of funding.
Required Response Categories:
4.43 Federal
Program Funding
Source for Project
Enrollment
Effective Date
Federal Funding
Program source
Response Categories
(date)
HUD-Supportive Housing Program
HUD-Shelter Plus Care
HUD-Section 8 Moderate Rehabilitation Program
HUD-Continuum of Care Program
HUD-Emergency Solutions Grant Program (includes Emergency Shelter Grant
Program)
HUD-Rural Housing Stability Program
HUD-Housing Opportunities for Persons with AIDS (HOPWA)
HUD-Veterans Affairs Supportive Housing (VASH) Program
HHS-Runaway and Homeless Youth Programs
HHS-Projects for Assistance in Transition from Homelessness (PATH)
HHS-Healthcare for the Homeless
VA-Grant and Per Diem Program
VA-Supportive Services for Veteran Families (SSVF)
VA-Homelessness Prevention Demonstration Program
VA-Residential Rehabilitation Treatment Programs (RRTP)-Domiciliary (DOM)
VA-Compensated Work Therapy (CWT)-Transitional Residence (TR)
VA-Health Care for Homeless Veterans (HCHV) Residential Treatment Program
Grant ID
VA-Health Care for Re-entry Veterans (HCRV)
VA-VA Community Contract Emergency Housing
[Other-identify]
(response categories set at local level)
Special Issues: If a project is funded by more than one grant, and those multiple grants fund the
same type of activity, e.g., the provision of lodging, it must be possible to identify which clients
were served under each of the grants for reporting purposes. This data element is an example of
a method that an HMIS solution might allow HMIS users to identify the grant used. Although
the ability to provide grant-level reporting is required for an HMIS solution, HUD recognizes
that the use of this data element is not the only acceptable approach for addressing this
requirement. As an example of an alternate approach, HMIS administrators could set up separate
projects in HMIS for each separate grant. As long as projects are able to provide grant-level
reporting, an HMIS solution will be considered compliant.
Changes from Previous Notice: This is a new data element.
105
4.44
Worst Housing Situation
Rationale: To identify persons who are in the worst housing situations in a geographic area and
are being served through the Rural Housing Stability Program (RHSP), when implemented.
Data Source: Documentation of worst housing situation as defined by HUD in the
24 CFR 579.3.
When Data are Collected: Upon project entry or as soon as possible thereafter.
Subjects: All clients.
Definitions and Instructions: Choose one response category to indicate whether the household
is currently residing in a worst housing situation.
Required Response Categories:
Program-Specific Data Element
4.44
Worst Housing Situation
5.
Response Categories
Yes
No
Client doesn’t know
Client refused
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. The intent behind each of these
Metadata Elements is explained in the Rationale section for each. These elements do not
represent an attempt to standardize the way that HMIS solutions store data. As long as HMIS
solution is able to accomplish the purposes identified in the rationale for the Metadata Elements,
the solution is not required to use the exact metadata elements listed here. Future programming
specifications for reports will reference these Metadata Elements. The Metadata Elements are:
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.1
Date Created
Date Updated
Data Collection Stage
Information Date
Project Identifier
Project Entry Identifier
User
Date Created
Rationale: To identify the date on which client-level information was first entered into HMIS.
This is necessary, in conjunction with the 5.4 Information Date Metadata Element and the 3.11
Project Entry Date and 3.12 Project Exit Date data elements, to create reports on the timeliness
of data entry and for audit purposes.
Data Source: Automatically generated by the HMIS solution.
106
When Data are Collected: Created by the HMIS solution when client-level information is first
entered.
Definition and Instructions: The HMIS must have the ability to identify the date on which a
record was first created in HMIS for any client-level data. 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.
Required Response Categories:
Metadata Element
5.1 Date Created
Response Category
Date created
(date)
Special Issues: HMIS solutions 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 solution, but it
must be accessible in the programming of reports. Date Created must not change when a data
element is edited. For example, if a client was first entered into an HMIS on 9/30/2009 and a
user edits the client’s name and date of birth on 2/1/2013, the Date Created for the client’s name,
date of birth, and any other data elements included on the same form must remain 9/30/2009. 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).
Changes from Previous Notice: This is a new data element.
5.2
Date Updated
Rationale: To identify the date on which client-level information was last edited. This is
necessary in order to produce an export of HMIS data that includes only the data that has
changed since the last export and for audit purposes.
Data Source: Automatically generated by the HMIS solution.
When Data are Collected: Created by the HMIS solution when client-level information is first
entered, and updated by the HMIS solution every time client-level information is saved by an
HMIS user.
Definition and Instructions: HMIS solutions must be able to determine, for all client-level
information, the date on which it was last edited by a user. Each time a user saves data, the
HMIS solution must store the current date (Date Updated) with the data being saved. Data
elements that are collected together on a single form may share a single Date Updated. It should
not be possible for HMIS users or system administrators must not have the ability to enter or to
modify the information in this metadata element.
Required Response Categories:
Metadata Element
5.2 Date Updated
Date updated
Response Category
(date)
Special Issues: None.
Changes from Previous Notice: This is a new data element.
107
5.3
Data Collection Stage
Rationale: To identify the stage in the client’s project participation at which client-level
information was collected. This is necessary to fulfill multiple reporting requirements, including
the APR. For example, the APR includes a section on data quality that reports on the number of
clients who either did not know or who refused to provide information and the number of clients
missing data for Income and Sources at project entry and exit, for Non-Cash Benefits at project
entry and exit, for Physical Disability at project entry only. A client may have multiple records
of these data elements created over the course of project participation; Data Collection Stage
identifies the relevant record.
Data Source: May be automatically generated by the HMIS solution or entered by HMIS users,
as appropriate.
When Data are Collected: At the time client-level information is entered into HMIS.
Definition and Instructions: An HMIS must be able to distinguish between data collected at
project entry, project update (during enrollment), project exit, and project follow-up (post-exit)
for the following data elements:
 Housing Status
 Income and Sources
 Non-Cash Benefits
 Health Insurance / Medical Assistance
 Physical Disability
 Developmental Disability
 Chronic Health Condition
 HIV/AIDS
 Mental Health Problem
 Substance Abuse
 Domestic Violence
Data elements that are collected together on a single form may share a single Data Collection
Stage. The user or systems administrator should not have the ability to create more than one
record per data element at either project entry 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 entry”).
The system must allow a user to save a dated record for a client’s annual assessment at least as a
project update. If the client’s data did not change (e.g. a client enters with SSI income and at
update still has SSI income of the same dollar amount) the system must be able to note the record
was reviewed on the date and no change was made. The saved record does not necessarily need
to contain the entire contents of the client’s assessment if no data has changed.
Required Response Categories:
5.3 Data Collection Stage
Metadata Element
Response Categories
Project entry
Project update
Project annual assessment
Project exit
Project follow up
108
Special Issues: The response categories correlate to response categories defined in the XML
and CSV specifications.
Changes from Previous Notice: This is a new data element.
5.4
Information Date
Rationale: To identify the date on which information was collected by project staff. This is
necessary to fulfill multiple reporting requirements, including the APR. For example, the APR
reports on monthly cash income at project entry as compared to monthly cash income at the most
recent update for clients who remain in the project at the end of the reporting period.
Data Source: HMIS users.
When Data are Collected: At the time client-level information is entered into HMIS.
Definition and Instructions: This Metadata Element correlates to the Assessment Date field in
the XML and CSV data exchange formats. It 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. Throughout the notice, this
Metadata Element has been added to the data elements where it applies, e.g., Income and
Sources, with the field label 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 project entry (e.g., Name, Social Security Number) does not
require an Information Date.
Data that is collected only at project entry or only at project exit, e.g., Residence Prior to Project
Entry or Destination, may be assumed to have an Information Date that matches the Project
Entry Date or Project Exit Date, respectively, although this is not a requirement; an HMIS
solution may require that a user specify the date on which the information was collected.
Data elements that are collected together on a single form may share a single Information Date.
As an example, if an HMIS solution has a form that includes all of the data elements pertaining
to particular disabilities (physical, developmental, etc.), a single Information Date field at the top
of the form in which the user enters the date the information was collected will suffice for all of
the data elements on the page.
Required Response Categories:
Metadata Element
5.4 Information Date
Information Date
Response Categories
(date)
Special Issues: This Metadata Element is applicable to the following Program-Specific Data
Elements:








Income and Sources
Non-Cash Benefits
Health Insurance / Medical Assistance
Physical Disability
Developmental Disability
Chronic Health Condition
HIV/AIDS
Mental Health
109


Substance Abuse
Domestic Violence
Changes from Previous Notice: This is a new data element.
5.5
Project Identifier
Rationale: To identify the project to which the data belongs, so that reporting on data quality
(among other aspects) accurately reflects what was entered by the project in question. This is
necessary to fulfill multiple reporting requirements, including the APR, and to create an export
that is limited to a particular project’s data.
Data Source: Generated by HMIS solutions or specified by HMIS users, as appropriate.
When Data are Collected: At the time client-level information is entered into HMIS.
Definition and Instructions: 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. The Project
Identifier stored with the client level data should correlate to the Project Identifier (Data Element
2.3) that uniquely identifies the project for which the data are being entered.
Required Response Categories:
Metadata Element
5.5 Project Identifier
Response Categories
The Project Identifier of the project that entered or edited the data.
Special Issues: This is a basic requirement that assumes a simple relationship between users 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.
Changes from Previous Notice: This is a new data element.
5.6
Project Entry Identifier
Rationale: To uniquely identify a particular period of service (bracketed by a Project Entry
Date and a Project Exit Date) during which an individual was a client of a project and enable
associating data entered into HMIS with that particular period of service. This is necessary to
fulfill multiple reporting requirements, including the APR, and to create an export that includes
data only for project entries within a specified date range.
Data Source: Generated by HMIS solutions.
When Data are Collected: The data element should be created by the HMIS solution at the
time that the record of a project entry is first entered into HMIS, and should be stored with any
data that pertains to that particular period of service.
Definition and Instructions: Data elements that are collected together on a single form may
share a single Project Identifier. An HMIS solution should be able to correlate data to a specific
project stay.
110
Required Response Categories:
Metadata Element
5.6 Project Entry Identifier
Response Categories
A unique project entry identifier used to associate data
with a particular period of service.
Special Issues: This metadata element must be stored with the following data elements:


















Veteran Status
Disabling Condition
Residence Prior to Program Entry
Housing Status
Project Entry Date
Project Exit Date
Destination
Zip Code of Last Permanent Address
Income and Sources
Non-Cash Benefits
Health Insurance / Medical Assistance
Physical Disability
Developmental Disability
Chronic Health Condition
HIV/AIDS
Mental Health
Substance Abuse
Domestic Violence
Changes from Previous Notice: This is a new data element.
5.7
User Identifier
Rationale: To identify the HMIS user who originally entered and/or edited a particular data
element. This is necessary for audit purposes.
Data Source: Each authorized user of an HMIS solution must have a unique identifier stored in
the HMIS. Every time data are 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
User Identifier must not be editable by the user.
When Data are Collected: The data element should be stored with any Universal or ProgramSpecific Data Element entered or edited in an HMIS solution.
Definition and Instructions: 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 solution 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 user must not have the
ability to enter or to modify the information in this Metadata Element. If a data element is
edited, the solution 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.
111
Required Response Categories:
Metadata Element
5.7 User Identifier
Response Categories
A unique identifier used to associate data with the user
who entered and./or edited it
Special Issues: None.
Changes from Previous Notice: This is a new data element.
112