U.S. Department Of Housing And Urban Development Community Planning And Development

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 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 medium- term 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 locally- administered 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. Following Congressional directive, HUD has supported the implementation of local Homeless Management Information Systems by: (1) providing technical support and funding to operate 2 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: 1. Project Descriptor data elements, including changes to the Project Type element and addition of the Federal Program Funding Source(s) element;

3 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 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” 4 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 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

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

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

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

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

9 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. Domiciliary Care for Homeless Veterans (DCHV) projects b. Grant and Per Diem (GPD) projects c. Supportive Services for Veteran Families (SSVF) projects d. Veterans Homelessness Prevention Demonstration (VHPD) programs 4. HUD-VA: a. HUD-Veterans Affairs Supportive Housing (VASH) programs.

10 Exhibit 1-1: Summary of Project Descriptor Data Elements

When collected

Data Elements Project Applicability Assign At least annually ed or more frequently once if changes occur

1. Organization Identifier All CoC Projects X 2. Organization Name All CoC Projects 3. Project Identifier All CoC Projects X 4. Project Name All CoC Projects 5. Direct Service Code (optional) X 6. Site Information All CoC Projects 7. Continuum of Care Code All CoC Projects 8. Project Type All CoC Projects and Non-CoC Projects 9. Bed and Unit Inventory Information All CoC Lodging Projects1 X 10. Target Population A (Optional for all All CoC Projects projects) 11. Target Population B All CoC Lodging Projects 12. Method for Tracking Residential All CoC Lodging Projects Project Occupancy 13. Federal Funding Source(s) All CoC Projects

1 CoC Lodging Projects include the following Project Types: Emergency Shelter, Transitional Housing, Safe Havens, Permanent Supportive Housing, and Permanent Housing Only

11 Exhibit 1-2: Summary of Universal Data Elements

Subjects When Collected Heads of I Household ni Every Every Data Project All All and Adult ti Project Project Elements Applicability Clients Adults Household al Entry Exit Members P 1. Name1 All CoC Projects X Xr 2. Social Security All CoC Projects X X Number1 3. Date of All CoC Projects X X Birth1 4. Race1 All CoC Projects X X 5. Ethnicity 1 All CoC Projects X X

6. Gender1 All CoC Projects X X 7. Veteran All CoC Projects X X Status 8. Disablin g All CoC Projects X X Conditio n 9. Residenc e Prior to All CoC Projects X X Project Entry 10. Housin All CoC Projects X X g Status 11. Projec t Entry All CoC Projects X X Date 12. Projec t Exit All CoC Projects X X Date

12 13. Destin All CoC Projects X X ation 14. Person al Identific All CoC Projects X X ation Number 15. House hold Identific All CoC Projects X X ation Number 16. Head of All CoC Projects X X Househol d 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.

13 Exhibit 1-3: Summary of Project -Specific Data Elements

HUD Program Applicability When Collected

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt 1. Zip Code of Heads of Last Househol Permanent d and Address X X X X X X Adult X Househol d Members 2. Income and Heads of Sources Househol d and X X X Adult X X X Househol d Members 3. Non-Cash Heads of Benefits Househol d and X X X Adult X X X Househol d Members 4. Health Heads of Insurance Househol d and X X X Adult X X X Househol d Members 5. Employment Heads of Status X X X Househol X X X d and 14 HUD Program Applicability When Collected

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt Adult Househol d Members 6. Physical All X X X X X X Disability Clients

7. Development All X X X X X X al Disability Clients 8. Chronic All Health X X X X X X Condition Clients

9. HIV/AIDS All X X X X X X Clients 10.Mental Health All X X X X X X Clients 11.Substance All X X X X X X Abuse Clients 12.Domestic Heads of Violence Househol d and X X X X X X Adult X Househol d Members 13.Contact All X4 X Clients 14.Date of All X4 X Engagement Clients

15 HUD Program Applicability When Collected

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt 15.Veteran’s All X X X X Information Veterans

16.Services All X X X X X X X Provided Clients 17.Financial All Assistance X X X X X Provided Clients

18.Area Median Heads of Income (AMI) Househol Percentage d and Used for X Adult X X Eligibility Househol d Members 19.Sexual Heads of Orientation Househol d and Adult X Househol d Members 20.Last Grade All X Completed Clients 21.School Status All X Clients

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt 22.General All Health Status Clients or Heads of Househol d and X X Adult Househol d Members 23.Pregnancy All Status Females of Child- X bearing Age 24.Funding Heads of Source for Househol Residence d and Prior to X Adult X Project Entry Househol d Members 25.Funding Heads of Source for Househol Destination d and X Adult X Househol d Members 26.Referrals All X X Provided Clients

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt 27.Reason for Heads of Leaving Househol d and Adult X Househol d Members 28.Project Heads of Transition Househol d and X Adult X Househol d Members 29.Project Heads of Completion Househol Status d and Adult Househol d Members 30.Family Heads of Reunification Househol Achieved d and Adult Househol d Members

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt 31.Physical Heads of Health Status Househol d and Adult X Househol d Members 32.Referral Heads of Source Househol d and Adult Househol d Members 33.Transitional, Heads of Exitcare, or Househol Aftercare d and Plans and Adult X Actions Househol d Members 34.Project Heads of Completion Househol Status d and Adult X Househol d Members

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt 35.Family Heads of Reunification Househol Achieved d and Adult X Househol d Members 36.Physical Heads of Health Status Househol d and Adult X Househol d Members 37.Dental Health Heads of Status Househol d and Adult X Househol d Members 38.Mental Health Heads of Status Househol d and Adult X Househol d Members

ESG At Least At ESG ESG Hom ESG Once At Least During Every Every Once Stre Eme eles Rapi Client Contac Three Annually Ever CoC et rge sne d HOP Assessm t/ Months During y Data Elements 1 Subjects ent Service Outr ncy ss Re- WA During Project Exit Near / eac Shel Prev Hou Project Enrollme Entry Referra h ter enti sing Enrollme nt3 2 l on nt 39.Housing Heads of Category Househol d and Adult X Househol d Members 40.Percent of Heads of AMI Househol d and Adult X Househol d Members 41.Formerly Heads of Chronically Househol Homeless d and Adult X Househol d Members 42.Federal Funding Heads of Source for X X X X X Househol X Project d Enrollment

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

21 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 Organization Identifier 2.2 Organization Name 2.3 Project Identifier 2.4 Project Name 2.5 Direct Service Code 2.6 Site Information 2.7 Continuum of Care Code 2.8 Project Type 2.9 Bed and Unit Inventory Information 2.10 Target Population A 2.11 Target Population B 2.12 Method for Tracking Project Occupancy 2.13 Federal Funding Source(s)

2.1 Organization Identifier Rationale: To uniquely identify each organization that operates a CoC project within the CoC.

22 Data Source: Automatically generated by the HMIS solution. 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 Response Categories Identifier 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. 23 It is recommended that HMIS solution also track aliases for Organization 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.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.

24 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. When Data are Collected: Data are collected once for each CoC project but must be reviewed annually to ensure accuracy. 25 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.

26  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 Response Categories Information Site Single site, single building Configuration Single site, multiple buildings Type Multiple sites Site Address Address City State (two-letter state abbreviation) Zip code (5-digit numeric code) Geocode Numeric geocode format Lodging or Mass shelter/barracks Housing Type Dormitory/hotel/motel Shared housing Single Room Occupancy (SRO) units Single apartment (non-SRO) units Single homes/townhouses/duplexes Not applicable: non-residential project Principal Site 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, 27 Rapid Re-Housing, Permanent Supportive Housing, and Permanent Housing) from projects that 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 Response Categories Code 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

28 homeless people who are unwilling or unable to access emergency shelter, housing, or an appropriate health facility.  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.

29 Required Response Categories:

Project Descriptor Data Element 2.8 Project Response Categories CoCType Project Yes No CoC Project Homelessness Prevention Type 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 Serviceswithout Only services) 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 30 history should reflect changes in standard project operations, but need not reflect day-to-day 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 facility- based 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.

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

Project Descriptor Data Element 2.9 Bed and Unit Inventory Response Categories Information Households without children Household Type Households with at least one adult and one Householdschild with only children Facility-based Bed Type (ES Only) Voucher Other Year-round Availability (ES Only) Seasonal Overflow Bed Inventory (integer) CH Bed Inventory (PSH Only) (integer) Unit Inventory (integer) Inventory Start Date (date) Inventory End Date (date) HMIS Participating Beds (integer) HMIS Participation Start Date (date) HMIS Participation End 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. 34 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:

Project Descriptor Data Element 2.10 Target Response Definition TargetPopulation Population A SMCategories Single Males (18 years and older) Type SF Single Females (18 years and older) SMF Single Males and Females (18 years CO Couplesand older)Only, No Children SM+HC Single Males and Households with SF+HC SingleChildren Females and Households with HC HouseholdsChildren with Children CM Unaccompanied Children-Males CF Unaccompanied(under 18) Children-Females Unaccompanied(under 18) Children-Males and CMF Females (under 18) Single Male and Female and SMF+HC Households with 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.

35  HIV: Persons with HIV/AIDS. The project targets persons with HIV/AIDS.  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 Response Categories Target Population Type 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 Response Categories Occupancy 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 36 Project Entry and Project Exit Date Comparison method must be used by residential projects receiving HUD homeless assistance funding to determine length of stay. 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 non- attendance, 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. 37 38 Required Response Categories: Project Descriptor Data Element 2.13 Federal Funding Response Categories Source(s) HUD-Supportive Housing Program Federal Funding source 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.

39 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 Name 3.2 Social Security Number 3.3 Date of Birth 3.4 Race 3.5 Ethnicity 3.6 Gender 3.7 Veteran Status 3.8 Disabling Condition 3.9 Residence Prior to Project Entry 3.10 Project Entry Date 3.11 Project Exit Date 3.12 Destination 3.13 Personal Identification Number 3.14 Household Identification Number 3.15 Head of Household 3.16 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 40 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 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 Examples First (text) John Middle (text) David Last (text) Doe Suffix (text) 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 41 at the local level and are, therefore, unable to use a Personal Identification Number to de- duplicate (at intake) across all the projects participating in the CoC’s HMIS. Where data are not 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 Full SSN reported 123-45-6789 Type Partial or unreliable SSN reported 123-4 Client doesn’t know or doesn’t Clienthave refused SSN 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 HUD- administered 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. 42 When Data are Collected: Upon initial project entry or as soon as possible thereafter. Subjects: All clients. 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) (9/2/1972) Date of Birth Type Full DOB Reported Approximate or partial DOB Clientreported doesn’t know Client refused 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. 43  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.”  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 Response Categories Race 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 Response Categories Ethnicity Ethnicity Non-Hispanic/Non-Latino Hispanic/Latino Client doesn’t know Client refused Special Issues: None. Changes from Previous Notice: None.

44 3.6 Gender Rationale: To create separate counts of men, women, and transgendered clients 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 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 Response Categories Gender 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 Response Categories Status Veteran Status 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?” 45 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. 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.1.1. a disability as defined in Section 223 of the Social Security Act; 1.1.2. a physical, mental, or emotional impairment which is: i.i.1.a.a. expected to be of long-continued and indefinite duration, i.i.1.a.b. substantially impedes an individual’s ability to live independently, and i.i.1.a.c. of such a nature that such ability could be improved by more suitable housing conditions; 1.1.3. a developmental disability as defined in Section 102 of the Developmental Disabilities Assistance and Bill of Rights Act; 1.1.4. the disease of acquired immunodeficiency syndrome or any conditions arising from the etiological agency for acquired immunodeficiency syndrome; or 1.1.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 Response Categories Condition Disabling No Condition 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 46 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 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).

Universal Data Element 3.9 Response Categories Residenc e Prior to Project Entry Type of Emergency shelter, including hotel or motel paid for with Residence 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 Length of One week or less Stay in More than one week, but less than one month Previous One to three months Place 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.

48 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. 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 project- specific 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:

49 Universal Data Element 3.10 Project Entry Date Response Categories Examples Project Entry Date (date) (08/01/2007)

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 50 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. 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 Response Categories Examples Project exit date (08/01/200 (date) 7)

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

51 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. 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 Response Categories Destination Destination Deceased Type 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)* 52 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 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 Response Categories Identification Number 53 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. 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 Response Categories Identification Number 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. 54 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 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 Response Categories Head of household 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.

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

Universal Data Element 3.17 Response Categories Length of Time Less than 1 year on the Street, Consecutively for 1 year – 12 months in an ES or a Safe Haven 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 Zip Code of Last Permanent Address 4.2 Housing Status 4.3 Income and Sources 4.4 Non-Cash Benefits 57 4.5 Health Insurance / Medical Assistance 4.6 Employment Status 4.7 Physical Disability 4.8 Developmental Disability 4.9 Chronic Health Condition 4.10 HIV/AIDS 4.11 Mental Health Problem 4.12 Substance Abuse 4.13 Domestic Violence 4.14 Contact 4.15 Dates of Engagement and Enrollment 4.16 Veterans Information 4.17 Services Provided 4.18 Financial Assistance Provided 4.19 Area Median Income (AMI) Percentage Used for Eligibility 4.20 Sexual Orientation 4.21 Last Grade Completed 4.22 School Status 4.23 General Health Status 4.24 Pregnancy Status 4.25 Funding Source for Residence Prior to Project Entry 4.26 Funding Source for Destination 4.27 Referrals Provided 4.28 Reason for Leaving 4.29 Project Transition 4.30 Formerly a Ward of Child Welfare / Foster Care Agency 4.31 Formerly a Ward of Juvenile Justice System 4.32 Young Person’s Critical Issues 4.33 Referral Source 4.34 Transitional, Exitcare, or Aftercare Plans and Actions 4.35 Project Completion Status 4.36 Family Reunification Achieved 4.37 Physical Health Status 4.38 Dental Health Status 4.39 Mental Health Status 4.40 Housing Category 4.41 Percent of AMI 4.42 Formerly Chronically Homeless 4.43 Federal Funding Source for Project Enrollment 4.44 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: 58  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 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).

Program-Specific Data Element 4.1 Zip Code of Last Permanent Response Categories Exampl Address es Zip Code ______12345 Zip Code Type Full or partial zip code 12345 reported Client doesn’t know Client refused 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:

60 (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 (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 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. 61 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: (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;

62 (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 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 Response Categories Status Homeless and At- Risk of Category 1– Homelessness Homelessness Status 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.

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

64 Required Response Categories: Program-Specific Data Element 4.3 Response Categories Income and Source Informat (date) ion Date Financia Income from any No l source? Yes Resourc Client doesn’t know es Client refused Source (HOPWA and Amount only) Receiving Amount Source of Income from Approxim income source? of Source ate Start Income Date Earned Income (i.e., No $_ _ _ _.00 (date) employment Yes Unemploymentincome) No $_ _ _ _.00 (date) Insurance Yes Supplemental Security No $_ _ _ _.00 (date) Income (SSI) Yes Social Security Disability No $_ _ _ _.00 (date) Income (SSDI) Yes VA service-connected (date) No disability $_ _ _ _.00 Yes compensation VA non-service- (date) No connected disability $_ _ _ _.00 Yes pension Private disability No $_ _ _ _.00 (date) insurance Yes No $_ _ _ _.00 (date) Worker’s compensation Yes Temporary Assistance No (date) $_ _ _ _.00 for Needy Families Yes (TANF) (or use local General Assistance (GA) No $_ _ _ _.00 (date) (or use local name) Yes Retirement income from No $_ _ _ _.00 (date) Social Security Yes No $_ _ _ _.00 (date) Veteran’s pension Yes Pension from a former No $_ _ _ _.00 (date) job Yes No $_ _ _ _.00 (date) Child support Yes Alimony or other No $_ _ _ _.00 (date) spousal support Yes No $_ _ _ _.00 (date) Other source Yes Total Monthly income from all Monthly $_ _ _ _.00 sources Income 65 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 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.

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

Program-Specific Data Element 4.4 Non-Cash Response Categories Benefits Date (date) Non-Cash Benefit Non-cash benefit No received from any Yes source? Client doesn’t know Client refused (HOPWA (HOPWA Source of Non-cash Receive only) only) Benefit Benefit If yes, If no, start reason Supplemental Nutrition 0 = No (date) All services Assistance Program 1 = Yes full (SNAP) (Previously Client not known as Food eligible Stamps) Applied; decision pending Client refused service Service does not exist Unknown Special Supplemental 0 = No (date) All services Nutrition Program 1 = Yes full for Women, Infants, Client not and Children (WIC) eligible Applied; decision pending Client refused service Service does not exist Unknown TANF child care 0 = No (date) All services services (or use 1 = Yes full local name) Client not eligible Applied; decision pending Client refused service Service does not exist Unknown

68 TANF transportation 0 = No (date) All services services (or use 1 = Yes full local name) Client not eligible Applied; decision pending Client refused service Service does not exist Unknown Other TAN F-funded 0 = No (date) All services services (or use 1 = Yes full local name) Client not eligible Applied; decision pending Client refused service Service does not exist Unknown Section 8, public 0 = No (date) All services housing, or other 1 = Yes full ongoing rental Client not assistance eligible Applied; decision pending Client refused service Service does not exist Unknown Other source 0 = No (date) All services 1 = Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown

69 Temporary rental 0 = No (date) All services assistance 1 = Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown 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 non- cash 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.

70 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, 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 / Response Categories Medical InformationAssistance (date) Date Covered by No health Yes insurance? Client doesn’t know Client refused (HOPWA (HOPWA only) Covera Type of Health Insurance only) If no, reason ge in / Medical Assistance If yes, effect? start MEDICAID health insurance No (date) All services program (or use local Yes full name) Client not eligible Applied; decision pending Client refused service Service does not exist Unknown MEDICARE health insurance No (date) All services program (or use local Yes full name) Client not eligible Applied; decision pending 71 Client refused service Service does not exist Unknown State Children’s Health No (date) All services Insurance Program (or Yes full use local name) Client not eligible Applied; decision pending Client refused service Service does not exist Unknown Veteran’s Administration No (date) All services (VA) Medical Services Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown Employer-provided health No (date) All services insurance Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown Health insurance obtained No (date) All services through COBRA Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown 72 Private pay health insurance No (date) All services Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown Ryan White medical No (date) All services assistance Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown AIDS Drug Assistance No (date) All services Program (ADAP) Yes full Client not eligible Applied; decision pending Client refused service Service does not exist Unknown 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.

73 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 Response Categories Information Date (date) Employment status 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 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 74 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 Response Categories Information Date (date) Physical disability No Yes Client doesn’t know Client refused (If yes) No [At entry] Yes Currently receiving services or treatment for this condition? Client doesn’t know [At annual assessment and at exit]: Received services/treatment while in the Client refused project? 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). 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

75 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 Response Categories Information Date (date) Developmental disability No Yes Client doesn’t know Client refused (If yes) No [At entry] Yes Currently receiving services or treatment for this condition? Client doesn’t know [At annual assessment and at exit]: Received services/treatment while in the Client refused project? 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. 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 76 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 Response Categories Information Date (date) Chronic Health Condition No Yes Client doesn’t know Client refused (If yes) No [At entry] Yes Currently receiving services or treatment for this condition? Client doesn’t know [At annual assessment and at exit]: Received services/treatment while in the Client refused project? 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). Changes from Previous Notice: Information Date is a new field, and should reflect the date on which the information was collected.

77 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 Response Categories Information Date (date) HIV/ AIDS No Yes Client doesn’t know Client refused (If yes) No [At entry] Yes Currently receiving services or treatment for this condition? Client doesn’t know [At annual assessment and at exit]: Received services/treatment while in the Client refused project? 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.

78 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 Response Categories Information Date (date) Mental health problem No Yes Client doesn’t know Client refused (PATH only) Unconfirmed; presumptive or self-report (If Mental health problem is Yes) Confirmed through assessment and clinical How confirmed Confirmedevaluation by prior evaluation or clinical (PATH only) No records (If Mental health problem is Yes) Unconfirmed; presumptive or self-report Serious mental illness (SMI) and, if Confirmed through assessment and clinical SMI, how confirmed Confirmedevaluation by prior evaluation or clinical Clientrecords doesn’t know Client refused (If client has a mental health problem) No Expected to be of long-continued Yes and indefinite duration and substantially impairs ability to live Client doesn’t know independently Client refused (If client has a mental health problem) No [At entry] Yes 79 Program-Specific Data Element 4.11 Mental Health Problem Response Categories Client doesn’t know

Currently receiving services or Client refused treatment for this condition? [At annual assessment and at exit]: 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 (date) Substance abuse problem No Alcohol abuse Drug abuse

80 Program-Specific Data Element 4.12 Substance Abuse Response Categories Both alcohol and drug abuse Client doesn’t know Client refused (PATH only) Unconfirmed; presumptive or self-report (If Substance abuse problem is Alcohol Confirmed through assessment and clinical abuse, Drug abuse, or Both alcohol and Confirmedevaluation by prior evaluation or clinical drug abuse) records (IfHow client confirmed has a substance abuse problem) No Expected to be of long-continued Yes and indefinite duration and Client doesn’t know substantially impairs ability to live independently Client refused (If client has a substance abuse No problem) Yes [At entry] Client doesn’t know Currently receiving services or treatment for this condition? 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. 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.

81 Required Response Categories: Program-Specific Data Element 4.13 Domestic Response Categories InformationViolence Date (date) Domestic violence No victim/survivor Yes Client doesn’t know Client refused (If yes) When Within the past three months experience Three to six months ago occurred 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”).

Program-Specific Data Element 4.14 Date of Response Categories Examples Contact Date of contact (date) (8/31/2013) Time of contact (Use 24-hour “military” 15:45 time) (PATH only) (integer) 20 Length of contact (PATH only) Individual Type of contact Group Location of Place not meant for Vehicle, abandoned building, Contact habitation bus/train/subway station/airport or anywhere outside that is not a Homeless Connect-type event Service setting, non- Homeless Connect-type event, residential drop in center, day services center, soup kitchen, etc. Service setting, Emergency, transitional or residential 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. 83 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:

Program-Specific Data Element 4.15 Dates of Engagement and Response Category Enrollment 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.

Program-Specific Data Element 4.16 Veteran’s Response Categories information Year entered military service (year) Year separated from military service (year) Served in a No theater of Yes operations? Client doesn’t know Client refused (If Yes) World War II Name of Korean War theater of Vietnam War operations 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 Branch of Army the military Air Force Navy Marines Coast Guard Other Client doesn’t know Client refused Discharge Honorable status 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.

85 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. 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 Response Categories Provided Date of (date) service Service (date) start date Service (date) end date Funding HUD-Supportive Housing Program source 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 86 4.17 Services Response Categories Provided 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 Adult day care and personal assistance type 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 87 4.17 Services Response Categories Provided 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 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.

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

89 Required Response Categories: 4.18 Financial Response Categories assistance Date of (date) financial assistance Start date of (date) financial assistance End date of (date) financial assistance Funding HUD-Supportive Housing Program source 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 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 Financial (amount) 90 4.18 Financial Response Categories assistance assistance amount 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 Response Category Used for Eligibility (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.

91 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 indicating how the youth describes his/her sexual orientation. Required Response Categories:

Program-Specific Data Element 4.20 Sexual Response Categories Orientation Sexual Orientation 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 Response Categories completed Last grade Less than Grade 5 completed 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. 92 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. 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 Response Categories status School status 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

93 Good Fair Poor Client doesn’t know Client refused 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 Response Categories Pregnancy status 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.

94 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. Required Response Categories:

Program-Specific Data Element 4.25 Funding source for Response categories Residence Prior Funding source HOPWA for residence VA prior to project Other entry 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 Response categories Destination Funding source HOPWA for destination VA Other Client doesn’t know Client refused Special Issues: None. Changes from Previous Notice: This is a new data element. 95 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. 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. Assisting the client in obtaining the application; 2. Assisting the client in obtaining the appropriate supporting documentation; 3. Assisting the client with completion of the application; and 4. 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 Response Categories Examples Referrals Provided Date of (date) referral Type of Referral referral Assisted referral (PATH) Closed Referral Identified status In progress (PATH) Service pending Referral Fully met Outcome Partially met Not met

96 Program-Specific Data Element 4.27 Response Categories Examples Referrals Provided (HOPWA and Service pending RHY) Client is receiving services Referral and is compliant with Outcome 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 (If Referral All services full outcome is Client not eligible Not met or Client refused service Client is not No show receiving Service does not exist services) Unknown Reason Referral Adult day care and personal Adult day care projects, in Target assistance home assistance, personal care Case management Case/care management, medical social work Child care and other child Child day care, in home services assistance, personal care Childcare (non TANF) Community mental health Community-based supports Education Adult Education, GED instruction, General Health and Nutrition Education, English as a second language, child education advocacy, Educational services Educational services to assist in obtaining employment Employment and training Employment preparation, services job training, job search/placement, day labor, part-time employment Employment assistance Assisted referral for obtaining employment Supplemental Nutrition Assistance Program (SNAP) formerly called Food Stamps or other non-WIC nutrition

97 Program-Specific Data Element 4.27 Response Categories Examples Referrals Provided Health/medical/intensive General medical care, care services screening, testing (including HIV), dental, counseling, prevention services, community mental health services Housing placement Assisted referral for assistance obtaining transitional, permanent, or other housing Housing placement Housing search assistance, assistance forms/application assistance HUD Section 8 or other permanent housing assistance Income assistance Assisted referral for obtaining income including mainstream benefits Job training Job training Legal services Legal counseling, benefits assistance, ex-offender services, advocacy, landlord/tenant, eviction assistance, tax preparation Life skills education Home management instruction, parenting, personal financial management, life skills development Material goods Furniture, house wares, cooking utensils, appliances Meals/nutritional services Emergency food, food banks, meals, soup kitchens, nutritional counseling Medicaid Medical assistance Assisted referral for obtaining medical care Mental health services Screening/assessment/eval uation, counseling, treatment, intervention, psychiatric rehabilitation, Mentoring program other than RHY agency

98 Program-Specific Data Element 4.27 Response Categories Examples Referrals Provided 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 Outreach, street outreach Primary health services Primary health care services Private non-profit charity or foundation support Relevant housing services Miscellaneous services for obtaining and maintaining housing SCHIP SSI, SSDI or other disability assistance SOAR program SAMHSA's SSI/SSDI Outreach, Access, and Recovery (SOAR) program Substance use services Alcohol and drug testing, screening, Detox projects, prevention, treatment, counseling, dependency support groups Substance use treatment Treatment for substance use disorders TANF or other welfare/ non- disability income maintenance (All TANF services) Temporary financial Short term rental, assistance mortgage, and utility financial assistance, including security deposits, application fees, and connection fees. Local transportation, taxi Transportation services, bus passes, mass transit passes Unemployment Insurance WIC Workforce Development (e.g., WIA)

99 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 Response Categories Reason for leaving 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 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.

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

Program-Specific Data Element 4.30 Formerly ward of child welfare / foster Response Categories care agency Formerly a ward of child No welfare or foster care Yes agency Client doesn’t know Client refused (If Yes) Less than one year Number of years 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 Response Categories juvenile justice system Formerly a ward of No juvenile justice system Yes Client doesn’t know Client refused (If Yes) Less than one year Number of years 1 to 3 years 3 to 5 years more than 5 years (If number of years is (a number between 1 and 11) Less than one year) 102 Number of months 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 Response Categories Household Dynamics – Youth No Yes Household Dynamics - Family No member Yes Sexual Orientation/Gender Identity – No Youth Yes Sexual Orientation/Gender Identity - No Family member Yes Housing Issues – Youth No Yes Housing Issues - Family member No Yes School or Educational Issues – Youth No Yes School or Educational Issues - Family No member Yes Unemployment – Youth No Yes Unemployment - Family member No Yes Mental Health Issues – Youth No Yes Mental Health Issues - Family No member Yes 103 Program-Specific Data Element 4.32 Youth / Family Critical Issues Response Categories Health Issues – Youth No Yes Health Issues - Family member No Yes Physical Disability – Youth No Yes Physical Disability - Family member No Yes Mental Disability – Youth No Yes Mental Disability - Family member No Yes Abuse and Neglect – Youth No Yes Abuse and Neglect - Family member No Yes Alcohol or other drug abuse – Youth No Yes Alcohol or other drug abuse - Family No member Yes Insufficient Income to support youth No – Youth Yes Insufficient Income to support youth No - Family member Yes Incarcerated parent of youth No Yes (If Incarcerated parent of youth is One parent / legal guardian is Yes) incarcerated Please specify 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.

Program-Specific Data Element 4.33 Referral Response Categories Source Referral Source 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

105 Special Issues: None. Changes from Previous Notice: This is a new data element. 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 Response and Actions Categories A written transitional, aftercare or follow-up plan No or agreement Yes Client refused Advice about and/or referral to appropriate No mainstream assistance programs Yes Client refused Placement in appropriate, permanent, stable No housing (not a shelter) Yes Client refused Due to unavoidable circumstances or scarcities No of appropriate housing, the youth must be Yes transported or accompanied to a temporary shelter Client refused Exit counseling No Yes Client refused A course of further follow-up treatment or No services Yes Client refused A follow-up meeting or series of staff/youth No meetings or contacts has been scheduled Yes Client refused A "package" of such things as maps, information No about local shelters and resources Yes Client refused Other No Yes Client refused Special Issues: None.

106 Changes from Previous Notice: This is a new data element. 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 Response Categories Completion Status Project Completion Completed project Status 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 Response Categories reunification achieved Family reunification No achieved Yes Client doesn’t know Client refused Special Issues: None. Changes from Previous Notice: This is a new data element.

107 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. 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 Response Categories Status Physical Health Status 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 Response Categories Status Dental Health Status 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.

108 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. 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 Response Categories Status Good Mental Health Status 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 Response Categories Category Housing Residing in permanent housing category at Homeless and scheduled to become residents of program permanent housing in 90 days entry 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.

109 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. 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 Response categories AMI Household Less than 30% income as a 30% to 50% percentage of Greater than 50% (ineligible) AMI 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 Response categories Homeless (for households not No currently designated as chronically Yes homeless) Client doesn’t know History of chronic homelessness Client refused 110 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 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 Response Categories Source for Project Enrollment Effective Date (date) Federal HUD-Supportive Housing Program Funding HUD-Shelter Plus Care Program HUD-Section 8 Moderate Rehabilitation Program source 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] Grant ID (response categories set at local level)

111 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. 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 Response Categories Worst Housing Situation Yes No Client doesn’t know Client refused

5. 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 Date Created 5.2 Date Updated 5.3 Data Collection Stage 5.4 Information Date 112 5.5 Project Identifier 5.6 Project Entry Identifier 5.7 User

5.1 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. 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 113 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 Response Category Date updated (date) Special Issues: None. Changes from Previous Notice: This is a new data element. 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”).

114 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: Metadata Element 5.3 Data Collection Response Categories Stage Project entry Project update Project annual assessment Project exit Project follow up 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 Response Categories 115 Information Date (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  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 116 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.

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 Program- Specific 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 118 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. 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.