36C25019Q0616-006.pdf

HMIS Data Standards

MANUAL

July, 2017

U.S. Department of Housing and Urban Development

Aligns with Version 1.2 of the HMIS Data Dictionary i

1. INTRODUCTION

HMIS Data Standards Overview Related Documents

HMIS Data Standard Documents HMIS Federal Partner Program Manuals

HMIS Data Standards Terms and Concepts Data Element Structure

Sample HMIS Data Element

Reference Tables Metadata and Data Element Relationships

2. PROJECT DESCRIPTOR DATA ELEMENTS

HMIS Project Setup Guidance

Multiple Funding Sources Multiple Project Setup

Elements

2.1 Organization Identifiers

2.2 Project Identifiers

2.3 Continuum of Care Code

2.4 Project Type

2.5 Method for Tracking Emergency Shelter Utilization

2.6 Federal Partner Funding Sources

2.7 Bed and Unit Inventory Information

2.8 Additional Project Information

3. UNIVERSAL DATA ELEMENTS

General Data Collection Guidance Data Collection Guidance by Project Type Universal Identifier Elements (One and Only One per Client Record)

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

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

3.8 Disabling Condition

3.10 Project Start Date

3.11 Project Exit Date

3.12 Destination

3.15 Relationship to Head of Household

3.16 Client Location

3.20 Housing Move-in Date

3.917 Living Situation

ii

4. PROGRAM SPECIFIC DATA ELEMENTS

Common Program Specific Data Elements

4.2 Income and Sources

4.3 Non-Cash Benefits

4.4 Health Insurance

4.5 – 4.10 Disability Elements

4.5 Physical Disability

4.6 Developmental Disability

4.7 Chronic Health Condition

4.8 HIV/AIDS

4.9 Mental Health Problem

4.10 Substance Abuse

4.11 Domestic Violence

4.12 Contact

4.13 Date of Engagement

4.14 Bed-Night Date

4.18 Housing Assessment Disposition

APPENDIX A. FEDERAL PARTNER PROGRAM COMPONENTS: ASSOCIATED HMIS PROJECT TYPES AND

FUNDING SOURCES

U.S. Department of Housing and Urban Development (HUD) U.S. Department of Housing and Urban Development (HUD) and U.S. Department of Justice (DOJ) ... 85 Substance Abuse and Mental Health Services Administration (SAMHSA) U.S. Department of Health and Human Services (HHS) Administration for Children and Families (ACYF) Family and Youth Services Bureau (FYSB) U.S. Department of Veteran Affairs (VA)

APPENDIX B. DATA ELEMENT COLLECTION SUMMARY

1. INTRODUCTION

HMIS Data Standards Overview A Homeless Management Information System (HMIS) is the information system designated by a local Continuum of Care (CoC) to comply with the requirements of CoC Program interim rule 24 CFR 578. It is a locally-administered data system used to record and analyze client, service, and housing data for individuals and families who are homeless or at risk of homelessness.

HMIS is administered by the U.S. Department of Housing and Urban Development (HUD) through the Office of Special Needs Assistance Programs (SNAPS) as its comprehensive data response to the congressional mandate to report annually on national homelessness. It is used by all projects that target services to persons experiencing homelessness within SNAPS and the office of HIV-AIDS Housing. It is also used by other federal partners from the U.S. Department of Health and Human Services (HHS) and the U.S. Department of Veterans Affairs and their respective programs to measure project performance and participate in benchmarking of the national effort to end homelessness.

The HMIS Data Standards were first published by HUD in 2004 as the HMIS Data and Technical Standards. The original standards served as the foundation for software developers in constructing HMIS applications. In March 2010, HUD updated the Data Standards (March 2010 HMIS Data Standards), primarily to reflect data collection requirements for the Homelessness Prevention and Rapid Rehousing Program (HPRP). HUD, in collaboration with its federal partners, updated the HMIS Data Standards again in 2014 with the release of the 2014 HMIS Data Standards Manual and Data Dictionary. Both documents superseded the previously released HMIS Data Standards. Together, the 2017 HMIS Data Standards Dictionary and Manual are the documentation of requirements for the programming and use of all HMIS systems and comparable database systems,1 effective October 1, 2017.

This manual is designed for CoCs, HMIS Lead Agencies, HMIS System Administrators, and HMIS Users to help them understand the data elements that are required in an HMIS to meet participation and reporting requirements established by HUD and the federal partners. An HMIS software must be able to collect all the data elements defined within these HMIS Data Standards, support the system logic identified in the HMIS Data Dictionary, and ensure that the visibility of data elements is appropriate to the Project Type and Federal Partner Funding Sources for any given project.

There are many software products on the market that communities across the county have chosen to use as their HMIS. Each product has unique features and was built to meet the different data collection needs of each community. Each software vendor should provide the guidance, support, and documentation necessary for the CoC to understand the system they are using.

Communities may elect to add data elements or maintain historical data element collection beyond what is specified in the Data Standards as long as it does not impact the ability of the CoC to accurately collect and report on the required data elements. In these cases, HMIS Leads should work directly with their HMIS vendors to meet their individual needs.

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

1 Comparable databases are required for use by providers of services for victims of domestic violence, as described in the VAWA.

https://www.hudexchange.info/resource/2033/hearth-coc-program-interim-rule/ https://www.hudexchange.info/resource/1318/2004-hmis-data-and-technical-standards-final-notice/ https://www.hudexchange.info/resource/1318/2004-hmis-data-and-technical-standards-final-notice/ https://www.hudexchange.info/resource/1220/final-hmis-data-standards/ https://www.hudexchange.info/resource/3824/hmis-data-dictionary/

HMIS Data Standard Documents The 2017 HMIS Data Standards Dictionary and Manual together contain the foundation for the data contained within an HMIS, project set up instructions, and data collection instructions.

Document Name Intended Audience Contents HMIS Data Standards Dictionary

HMIS Vendors & HMIS Lead Agencies

The Dictionary provides the detailed information required for system programming of each HMIS element and the responses required for an HMIS software. It delineates data collection requirements, system logic, and contains the XML and CSV tables and numbers.

It also includes critical information about data collection stages, federal partner data collection required elements, and metadata data elements.

HMIS Data Standards Manual

HMIS Lead Agencies & HMIS Users

The manual provides data collection instructions for the Project Descriptor Data Elements, Universal Data Elements, and the common Program Specific Data Elements. It contains information on project setup, client-level data collection requirements, and detailed descriptions of each data element.

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

Links to each Manual will be made available on the 2017 HMIS Data Standards resource page as they are updated.

Manual Name Intended Audience

Federal Partner Contents

CoC Program HMIS Manual

• HMIS Lead Agencies

• HMIS Users

• Grantees

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

CoC Program information link

The manual assists in project set up of all Continuum of Care (CoC) Program component projects:

Transitional Housing, Permanent Supportive Housing, Rapid Re- Housing, and Services Only.

Information aligns with the CoC Program Interim Rule

ESG Program HMIS Manual

• HMIS Lead Agencies

• HMIS Users

• Recipients

• Subrecipients

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

ESG Program information link

The manual assists in project set up of all Emergency Solution Grant (ESG) Program component projects: Emergency Shelter (night by night and entry/exit), Street Outreach, Rapid Re- Housing and Homelessness Prevention.

Information aligns with the ESG Program Interim Rule

HOPWA

Program HMIS Manual

• HMIS Lead Agencies

• HMIS Users

• Grantees

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

HOPWA Program information link

The manual assists in project set up of all of the Housing Opportunities for Persons with AIDS (HOPWA) program components.

PATH Program HMIS Manual

• HMIS Lead Agencies

• HMIS Users

• Grantees

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

PATH Program information link

The manual assists in project set up for all Projects for Assistance in Transition from Homelessness (PATH) program component projects: Street Outreach and Services Only.

RHY Program HMIS Manual

• HMIS Lead Agencies

• HMIS Users

• Grantees

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

RHY Program information link

The manual assists in project set up for all Runaway and Homeless Youth program component projects: Basic Center Program, Street Outreach Program, Transitional Living Program, and Maternity Group Homes.

VA Program HMIS Manual

• HMIS Lead Agencies

• HMIS Users

• Grantees

Department of Veterans Affairs

VA Program information link

This manual assists in projects set up for the Veteran’s homeless programs. Programs on HMIS include: SSVF and GPD programs of the VA.

https://www.hudexchange.info/programs/coc/ https://www.hudexchange.info/resource/2033/hearth-coc-program-interim-rule/ https://www.hudexchange.info/resource/2033/hearth-coc-program-interim-rule/ https://www.hudexchange.info/programs/esg/ https://www.hudexchange.info/resource/1927/hearth-esg-program-and-consolidated-plan-conforming-amendments/ https://www.hudexchange.info/resource/1927/hearth-esg-program-and-consolidated-plan-conforming-amendments/ https://www.hudexchange.info/programs/hopwa/ https://www.hudexchange.info/programs/hopwa/ http://www.samhsa.gov/homelessness-programs-resources http://www.acf.hhs.gov/programs/fysb/programs/runaway-homeless-youth https://www.va.gov/homeless/ http://www.va.gov/homeless/ssvf/index.asp http://www.va.gov/HOMELESS/GPD_ProviderWebsite.asp

HMIS Data Standards Terms and Concepts Continuum of Care (CoC) is used in multiple ways:

1. Continuum of Care and Continuum means the group organized to carry out the responsibilities required under the CoC Program Interim Rule (24 CFR Part 578) and comprises representatives of organizations, including nonprofit homeless providers, victim service providers, faith-based organizations, governments, businesses, advocates, public housing agencies, school districts, social service providers, mental health agencies, hospitals, universities, affordable housing developers, and law enforcement, and organizations that serve homeless and formerly homeless persons to the extent that these groups are represented within the geographic area and are available to participate.

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

3. Continuum project refers to a distinct unit of an organization, which may or may not be funded by HUD or the federal partners, whose primary purpose is to provide services and/or lodging for the homeless and is identified by the Continuum as part of its service system. [Note: a project funded by the HUD’s CoC Program may be referred to then as a “CoC Program-funded continuum project”.]

HMIS User means the individual who uses or enters data in an HMIS or a comparable database approved by the CoC.

HMIS Lead means the entity designated by the Continuum of Care in accordance with the HMIS Proposed Rule2 (24 CFR Part 580) to operate the Continuum’s HMIS on the Continuum’s behalf.

HMIS System Administrator means the individual(s) whose job it is to manage the HMIS implementation at the local level: enrolling programs and managing appropriate use, supporting users through connection to, or direct provision of, user training, and overseeing system setup.

Project versus Program Across the federal agencies the terms project and program are used differently.

In this document, and for the purposes of data collection in HMIS, a program refers to the federal funding source (e.g., HUD CoC, HHS PATH, VA SSVF, etc.) whereas project refers to a distinct unit of an organization as set up in the HMIS.

Data Element Structure The key data elements required by HUD and most federal partner programs are included in this Manual.

This Manual is intended to be read in conjunction with the HMIS Data Dictionary, providing the data collection guidance necessary for System Administrators and HMIS Users to use in local trainings. The following format is used to describe each data element:

Sample HMIS Data Element Rationale and Reporting Utility provides a basic rationale for data collection for the element and describes how the data are used in national or local reporting.

Data Collection Instruction (client-level data elements only) or Project Setup Instruction (project descriptor data elements only) provides overall instructions for data collection and entry. Project setup and data collection instructions specific to an HMIS federal partner program can be found in the HMIS Federal Partner Program Manuals.

2 As of June, 2017 the HMIS Rule is not in effect. When HUD publishing the final HMIS Rule communities will be given time to come into compliance with the rule.

https://www.hudexchange.info/resource/2033/hearth-coc-program-interim-rule/ https://www.hudexchange.info/resource/1967/hearth-proposed-rule-for-hmis-requirements/ https://www.hudexchange.info/resource/1967/hearth-proposed-rule-for-hmis-requirements/

Most data elements include a ‘Client doesn’t know’ or ‘Client refused’ response category. It is not the intention of the federal partners that clients be denied assistance if they refuse or are unable to supply the information. However, some information may be required by projects or public or private funders to determine eligibility for housing or services, or to assess needed services.

The ‘Client doesn’t know’ or ‘Client refused’ responses should not be used to indicate that the case manager or data entry person does not know the client’s response. Nor are these responses to be assumed without first asking the client to provide the information. Some clients may decline to provide responses to some fields but case managers or data entry staff may not make that decision for them. At a national level, in every project type, a majority of clients are willing to provide identifying information.

If a project is experiencing a high rate of client refusals as compared to similar projects, CoCs may wish to consider implementing trainings around interviewing or trust-building techniques to support client engagement. A deeper engagement with clients may lead to more rapid movement off the street and placement in housing, consistent with meeting federal goals to end homelessness and improvement on HUD’s System Performance Measures.

The HMIS Data Standards assume that fields for which data are not collected will be left blank (i.e., ‘missing’). In situations where a system requires a response to all data fields before saving a record, the system must use a specific response category to indicate that data were not collected. In such cases, that response category must be treated as missing data for reporting purposes.

Data Element Fields and Responses

Field Dependency Response Category/ Data Type

Descriptions

# Field Name

Dependent Fields and the Field/ Response option to which they are dependent.

The dependencies outlined in the Data Dictionary are expected to be visible to users on-screen. The methods vendors use to make dependencies visible will vary by software provider.

# All response options associated with the field, and their data type, if specified.

General definitions and descriptions of fields and responses.

More detailed, program-specific descriptions can be found in the HMIS Federal Partner Program Manuals, as applicable.

Reference Tables Additional information about each client-level data element can be found in the Appendices.

• Appendix A identifies all HMIS Federal Partner programs and components that may use the HMIS, the Program and Component/Activity abbreviations used throughout the Manual, and associates each Component/Activity with an HMIS Project Type and Federal Partner Funding Source.

• Appendix B summarizes the client universe for each data element contained in this manual and when it is collected.

Metadata and Data Element Relationships 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.

A complete list of metadata elements and logic for those elements can be found in the HMIS Data Dictionary. These elements do not represent an attempt to standardize the way that HMIS solutions store data. As long as an 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. Programming specifications for reports reference the Metadata Elements.

2. PROJECT DESCRIPTOR DATA ELEMENTS

Project descriptor data elements (PDDE) are intended to identify the organization, specific project, and project details to which an individual client record in an HMIS is associated.

They enable the HMIS to:

1. Associate client-level records with the various projects that the client will enroll in across continuum projects;

2. Clearly define the type of project the client is associated with the entire time they received housing or services;

3. Identify which federal partner programs are providing funding to the project; and

4. Track bed and unit inventory and other information, by project, which is relevant for the Annual

Homeless Assessment Report (AHAR), System Performance Measures, Housing Inventory Counts (HIC), Point In Time (PIT) counts, and utilization analysis

This section describes the data to be recorded in HMIS for each project descriptor data element and its relation to each project entering data. Correct use of the 2.4 Project Type and 2.6 Funding Sources data elements will help assure that projects are identified for correct visibility and are able to generate reports required for each of the federal partners as reporting parameters will be based off of one or both of these elements.

Project descriptor data are generally entered and managed in an HMIS by the HMIS Lead, not a project end user. They are created at initial project setup within the HMIS and should be reviewed at least once annually and as often as needed to ensure that reporting is accurate. The HMIS Lead, in consultation with the CoC, should develop a plan and timeline for routine review and updates to PDDEs. If any project descriptor data is entered or updated by project end users, the HMIS Lead Agency must have oversight and data entry/edit ability along with strong review procedures to assure timely, accurate and complete data.

At a minimum, the HMIS Lead Agency must ensure that the HMIS includes project descriptor information for all continuum projects participating in HMIS and all residential continuum projects, regardless of their participation in HMIS. If the HMIS database includes client and service data entered by non-continuum projects, the continuum must identify them as such using the PDDEs to ensure that data are excluded from required reporting on continuum projects.

HUD requires that the CoC must collect program information in the HMIS on all continuum projects within its jurisdiction participating in HMIS and all residential continuum projects, regardless of their participation in HMIS (last required in the 2010 data standards). This is to facilitate AHAR participation.

The following Project Descriptor Data Elements are required for project setup in HMIS:

2.1 Organization Identifiers

2.2 Project Identifiers

2.3 Continuum of Care Code

2.4 Project Type

2.5 Method for Tracking Emergency Shelter Utilization

2.6 Federal Partner Funding Sources

2.7 Bed and Unit Inventory Information

2.8 Additional Project Information

HMIS Project Setup Guidance One of the most critical steps in accurate data collection and reporting is ensuring that a project is set up properly in an HMIS. If project setup is done incorrectly, this will jeopardize the ability to produce accurate, reliable reports.

Prior to creating a new project in the HMIS, the HMIS Lead should consult with both the organization administering the project and the CoC Lead Agency regarding appropriate responses for the PDDEs.

Project Type and Federal Partner Funding Sources are particularly critical as they are the basis for setting up client-level data collection and for reporting. Project Types must be consistent with grant agreements and with HIC and PIT guidance issued by HUD each year. Appendix A lists federal funding sources and programs along with the project type required for each. Some HMIS applications automatically configure data collection based on Project Type and Federal Partner Funding Sources to ensure that minimum requirements are met. Where this is not the case, data collection for each project must be set up so that all data elements required based on Project Type and Federal Partner Funding Sources are available for data entry. The HMIS Project Setup Tool provides identifies the required data elements for each funding source, project type, and funding source combinations.

For additional information on federal partner programs and related project setup guidance, refer to the applicable federal partner HMIS Program Manual.

Multiple Funding Sources CoCs may have projects operating in their communities that receive funding from multiple federal partners for the same project to serve the same clients. There are a few issues the HMIS Lead will need to consider in these cases.

First, it is important that projects are set up in the system so all data elements needed for all required reports are “visible” to the end users. For example, a youth shelter may be funded through HUD’s Emergency Solutions Grants Program (ESG) to support essential services and through HHS’s Runaway and Homeless Youth (RHY) Program as a Basic Center Program. In this example, the project should be set up with a Project Type (data element 2.4) of ‘Emergency Shelter’ using the ‘Entry/Exit Date’ Method for Tracking Shelter Utilization (data element 2.5); it will show both ‘HUD:ESG – Emergency Shelter’ (operating and/or essential services) and ‘HHS:RHY – Basic Center Program’ as the Federal Partner Funding Source (data element 2.6). With the appropriate project type and correct identification of both funding sources, all elements required for both federal partner funding sources must be visible, and all data required for reporting to both funders can be collected. If the HMIS does not automatically configure data collection based on Project Type and Federal Partner Funding Sources, the HMIS Lead should reference the HMIS Data Dictionary to appropriately set the element visibility for the project.

Second, it is important to understand how projects are funded and what reports are required of each funding source because some projects receive funding from multiple funding sources for different eligible activities. For example, a project may receive a grant for residential operations/leasing costs and another grant for services. These two grants may be from the same federal program or two different federal programs. In these cases, HMIS Leads and project providers have two options:

1. Create one project in the HMIS that both the housing provider and the service provider will jointly share and record data in, or

2. Create two separate projects in the HMIS, one for the housing provider and another for the service provider.

Correct setup under either option is critically important to accurately record HIC/PIT information and to support correct system wide performance measures.

https://www.hudexchange.info/resource/4898/hmis-project-set-up-tool/

If a single project is created, the Project Type (data element 2.4) will be the appropriate residential project type (e.g. Transitional Housing, Permanent Supportive Housing, etc.), and the Federal Partner Funding Sources (data element 2.6) will identify both funding sources / component types for the project.

If two separate projects are created, each project will be associated only with the specific federal funding source and component type appropriate to the grant.

• The housing project will have a residential Project Type appropriate to the grant and must comport with all data collection requirements associated with that project type.

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

Multiple Project Setup There may be other circumstances within the HMIS implementation where a project that appears to be one project must be set up as two separate projects in an HMIS. Some common examples of this are:

a) If one residential building has both emergency shelter beds and transitional housing beds, this must be set up as two separate projects, with the Project Types ‘Emergency Shelter’ and ‘Transitional Housing,’ respectively. Clients moving from the shelter bed to the transitional housing bed, even if in the same building or funded by the same source, will require an exit from the shelter project and an entry into the transitional housing project. Similarly, a permanent housing facility may have both a permanent housing for persons with disabilities required for entry and other units without a disability requirement. Those must be set up as separate projects in HMIS.

b) Projects that provide Homelessness Prevention and Rapid Re-Housing, whether funded by HUD or by the VA (i.e., under the Supportive Services for Veteran Families (SSVF) program), must be set up as two separate projects in the HMIS with the two distinct project types, even if they are funded under a single grant. In this case, the grant identifier will be the same in both project setups.

c) Permanent Housing projects are often created with a variety of rental subsidies. Unless the HMIS has the ability to identify the source and specific grant for a rental subsidy on a client-level basis, separate projects will have to be created in the HMIS in order to segregate the client records for reporting purposes. A common example of this is the “pre-HEARTH” McKinney Vento Shelter Plus Care (S+C) program. Although operated as a unified project, different clients are served using rental subsidies from multiple S+C grants, each with a different operating year and grant number. In many systems, in order to accurately report which and how many clients are served under each separate grant, the grants are set up and maintained as separate projects in the HMIS unless or until the S+C grants are consolidated under the CoC Program.

d) PATH projects may provide funding to one organization for both traditional street outreach services and supportive services such case management to persons at-risk of homelessness. In such cases, PATH requires that two projects be set up in the HMIS, one with the Project Type ‘Street Outreach’ and one with the Project Type ‘Services Only’ to distinguish the projects’ operations and reporting for PATH and to support system level performance measurement.

Elements

2.1 Organization Identifiers

Rationale To uniquely identify organizations operating one or more projects that enter data into HMIS, as well as any residential continuum projects not participating in HMIS.

Project Setup Instruction Organization Identifiers are assigned once for each organization. Record the organization’s legal name. The ‘Organization Name’ must be reviewed annually to ensure accuracy.

There must be only one organizational identifier/name for each organization that has projects which operate in the HMIS implementation.

Many organizations operate multiple projects that participate in HMIS. Projects that are operated by the same organization must all be associated with the same ‘Organization ID.’ Each project in the HMIS must be associated with one and only one organization. If the project moves from one organization to another (e.g. grant transfers to a new organization), an update of the information to associate the project to the new organization must be made by the system administrator in the HMIS.

An organization’s legal name is not always the name by which it is commonly known in the community.

Some HMIS implementations include an additional field to track more familiar “common names” for organizations, but this is not required.

Data Element Fields and Responses

Field Dependency Response Category/ Data Type

Descriptions

1 Organization

ID

None System generated number or code. There is no specified format for this data element.

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

2 Organization Name

None [Text] The organization’s legal name.

2.2 Project Identifiers

Rationale To uniquely identify each project entering data into the HMIS, as well as any residential continuum projects not participating in HMIS. The Project ID is used to link project descriptor information in other data elements to the specific project, and also to link clients and their enrollment data to the project.

Project Setup Instruction The ‘Project ID’ must be automatically generated by the HMIS at the time the project is created in the HMIS. Each project must receive a distinct identifier that is consistently associated with that project.

In separate fields, record the project's name and operating start/end date, if applicable. This information must be reviewed annually to ensure accuracy. ‘Project Name’ must be consistent with HUD and other federal reporting requirements and should match grant agreements or other documentation. Often the project will have a common name that is used by the community for the specific project, but may also have different names on formal grant agreements and perhaps even a different name in the HMIS. HMIS software solutions may elect to create another field for the entry of additional names of the project for ease of access purposes, but it is not required.

Residential projects that operate in multiple CoCs that cross HMIS systems must be documented in each CoC’s HMIS, even in cases where all client data are entered into a single CoC’s HMIS.

Project identification can be difficult for HMIS Lead Agencies. A project in HMIS is often referred to as a “program” by agency providers. When an organization designs a project to assist persons in their community, they are generally not considering the data collection and reporting requirements associated with it. Until funding is received for that project, they may not even know the reporting requirements. Therefore, HMIS project set-up begins with the determination by the System Administrator or HMIS Lead Agency, in cooperation with the project’s leadership, of whether a new project will be set up as a single or multiple projects in the HMIS. For more guidance on project setup, please refer to the Introduction to Section 2.

Data Element Fields and Responses

Field Dependency Response Category/ Data Type

Descriptions

1 Project ID None System generated number or code. There is no specified format for this data element.

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

2 Project Name

None [Text] The project's name. Where applicable, project names must be consistent with HUD and other federal reporting requirements and should match grant agreements or other documentation.

3 Operating Start Date

None [Date] The first day on which a project provided (or will provide) services and/or housing. For projects that began operating prior to October 1, 2012, the start date may be estimated if it is not known.

Projects that are fully funded but have not yet begun operating may be entered with future project start date that reflects the date the project will begin providing services.

4 Operating End Date

None [Date] The last day on which the project provided or is expected to provide services and/or housing. It may be a date in the future; it may also be blank if the project is expected to continue operating indefinitely.

2.3 Continuum of Care Code

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

Project Setup Instruction ‘Continuum Codes’ are published annually by HUD in the CoC Program NOFA and are associated with specific geographic areas. Each project must be associated with the HUD-assigned code for each CoC in which the project operates (i.e., in which the project is funded to provide lodging and/or services) and for which the project will be entering data into the HMIS (if applicable).

Some projects are funded to provide lodging and/or services to clients in only one continuum (e.g., CoC:

Transitional Housing); others are funded to provide lodging and/or services across a geographic area that includes more than one continuum (e.g., some VA-funded SSVF projects). For federally-funded projects operating in multiple CoCs but entering data into a single HMIS implementation, the ‘Continuum Code’ selected for the project must be consistent with the area served by the project according to their grant agreement with the federal funder. For example, a VA SSVF project providing services to clients in both a balance of state and an urban CoC must be associated with the ‘Continuum Code’ for both the balance of state AND the urban continuum.

Projects participating in an HMIS implementation are subject to the policies and procedures of that HMIS implementation, regardless of whether participation is by entering data directly into the HMIS or by providing data exported from another source. Projects providing data from one HMIS implementation to another HMIS implementation are subject to the policies and procedures of both.

Data Element Fields and Responses

Field Dependency Response Category/ Data Type

Descriptions

1 Continuum Code

None HUD-assigned CoC codes for the project location [Text – 6 characters]

CoC Codes as published by HUD annually. The format of these CoC codes is 2 letters (state abbreviation), a dash, and 3 numbers, e.g., XX-

999. The HMIS software may provide a drop-down list of valid CoC Codes or require manual entry.

2.4 Project Type

Rationale To associate each project entering data into the HMIS, as well as any residential continuum projects not participating in HMIS, with the specific type of lodging or services provided. Data related to project type is necessary to identify corresponding data collection requirements and for reporting purposes. The element also identifies whether the project is a continuum project or a non-continuum project. The element also identifies the relationship of a 'Services Only' project to a housing project as necessary.

Project Setup Instruction A project is to be assigned a type based on the lodging or service it is providing. All HMIS federal partner programs have identified the requirements and correct project type for each program and program component in separate HMIS Program Manuals (created for each of the federal partner programs). Select one and only project type per ‘Project ID.’

If a potential new project has more than one project type, each type must be set up in HMIS as a separate project. For more guidance on project setup, including determining whether a single or multiple projects should be set up in your HMIS, please refer to the Introduction to Section 2.

The project type selected directly impacts data collection and reporting requirements. In the event that the nature of a project changes such that the recorded project type is no longer appropriate, very careful consideration must be given to whether it is more appropriate to edit the project type for the existing project or to create an entirely new project with a different type.

Data Element Fields and Responses

Field Dependency Response Category/ Data Type

Descriptions

1 Continuum Project

None 0 No

1 Yes A project within the geographic boundaries of the Continuum(s) of Care served by the HMIS whose primary purpose is to meet the specific needs of people who are homeless by providing lodging and/or services. A continuum project is not limited to those projects funded by HUD and should include all of the federal partner projects and all other federally or non-federally funded projects functioning within the continuum.

2 Project Type None 12 Homelessness Prevention

A project that offers services and/or financial assistance necessary to prevent a person from moving into an emergency shelter or place not meant for human habitation.

4 Street Outreach

A project that offers services necessary to reach out to unsheltered homeless people, connect them with emergency shelter, housing, or critical services, and provide urgent, non-facility-based care to unsheltered homeless people who are unwilling or unable to access emergency shelter, housing, or an appropriate health facility. Only persons who are “street homeless” should be entered into a street outreach project. Projects that also serve persons other than “street homeless” must have two separate projects to be set up in an HMIS – one ‘Street Outreach’ and the other ‘Services Only.’

1 Emergency Shelter

A project that offers temporary shelter (lodging) for the homeless in general or for specific populations of the homeless. Requirements and limitations may vary by program, and will be specified by the funder.

Field Dependency Response Category/ Data Type

Descriptions

2 Project Type (continued)

None 11 Day Shelter A project that offers daytime facilities and services (no lodging) for persons who are homeless.

2 Transitional Housing

A project that provides temporary lodging and is designed to facilitate the movement of homeless individuals and families into permanent housing within a specified period of time, but no longer than 24 months.

Requirements and limitations may vary by program, and will be specified by the funder.

8 Safe Haven A project that offers supportive housing that (1) serves hard to reach homeless persons with severe mental illness who came from the streets and have been unwilling or unable to participate in supportive services;

(2) provides 24-hour residence for eligible persons for an unspecified period; (3) has an overnight capacity limited to 25 or fewer persons; and (4) provides low demand services and referrals for the residents.

13 PH - Rapid Re- 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.

3 PH -

Permanent Supportive Housing (disability required for entry)

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

10 PH – Housing with Services (no disability required for entry)

A project that offers permanent housing and supportive services to assist homeless persons to live independently, but does not limit eligibility to individuals with disabilities or families in which one adult or child has a disability.

9 PH - Housing Only

A project that offers permanent housing for persons who are homeless, but does not make supportive services available as part of the project.

14 Coordinated Assessment

A project that administers the continuum’s centralized or coordinated process to coordinate assessment and referral of individuals and families seeking housing or services, including use of a comprehensive and standardized assessment tool.

Descriptions

2 Project Type (continued)

None 6 Services Only A project that offers only stand-alone supportive services (other than outreach) to address the special needs of participants (such as child care, employment assistance, and transportation services) and has associated housing outcomes.

• If the Services Only project is affiliated with any one of the following:

o One residential project and Does not offer to provide services for all the residential project clients; Or Only serves clients for a portion of their project stay (e.g. provides classes); Or Information sharing is not allowed between residential project and service provider.

o Multiple residential projects of the same project type (e.g. multiple PH:PSH) and Does not serve all the all residential project clients; Or Information sharing is not allowed between residential projects and service provider.

o Multiple residential projects of different project types (e.g. PH: RRH and PH:PSH) o Emergency Shelter(s)

Then the project type will be ’Services Only’ and ‘Affiliated with a Residential Project’ will be ‘Yes.’ Each of the residential projects with which the Services Only project is associated must be identified.

• If the Services Only project provides only services (other than outreach), has associated housing outcomes, and is not limited to serving clients of one or more specific residential projects, then the project type will be 'Services Only' and ‘Affiliated with a Residential Project’ will be 'No.'

• A residential project that is funded under one or more separate grants to provide supportive services to 100% of the clients of the residential project will be set up as a single project with the appropriate residential project type. All federal funding sources must be identified in 2.6 Federal Partner Funding Sources.

7 Other A project that offers services, but does not provide lodging, and cannot otherwise be categorized as another project type, per above. Any project that provides only stand-alone supportive services (other than outreach) and has no associated housing outcomes should be typed as ‘Other.’ For example, a project funded to provide child care for persons in permanent housing or a dental care project funded to serve homeless clients should be typed ‘Other.’ A project funded to provide ongoing case management with associated housing outcomes should be typed ‘Services Only.’

Descriptions

A Affiliated with a Residential Project

Field 2:

Response 6

0 No For all projects typed ‘Services Only’ identify if the services that are being provided are in conjunction with a residential project which is a separate project in the HMIS (e.g. a service only project for case management that services one or more PSH projects.)

1 Yes

B Project ID(s) of Residential Project(s) Affiliated with SSO

Field A:

Response 1

[‘Project ID’] If the service is being provided to another project within the HMIS, identify the project ID(s) of those residential project(s). For the sake of consistency, HMIS vendors are recommended to create a drop down list from element

2.2 Project Identifiers that includes the ‘Project Names’

and IDs for all non-emergency shelter projects.

2.5 Method for Tracking Emergency Shelter Utilization

Rationale To identify the method used for tracking shelter occupancy for each emergency shelter project entering data into the HMIS. This allows HMIS reporting to accurately calculate project bed utilization and length of stay and to distinguish shelters for other data collection and reporting purposes.

Project Setup Instruction Record the method used to track the nights that a client stays at a project.

One method must be identified in an HMIS for each emergency shelter project. Reporting and outcome requirements will differ depending on the method utilized by the shelter.

• The entry/exit (e/e) method requires the client have a full record created for each project stay.

All data required for the project at project entry and exit are recorded.

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

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

The method used is important for the indication of length of stay in projects. Only projects utilizing a project start/exit date comparison will be able to report on a continuous length of stay.

Utilization of the night-by-night method does not mean that an HMIS must identify a client in a specific bed. If the HMIS supports a custom module that identifies clients in a bed that module may continue to be used. However, use of that module does not necessarily equate with the night-by-night model.

If a shelter/continuum determines the method of tracking needs to be changed, the following approach must be taken in order to minimize impact on the System Performance Measures and other reports:

1) A new shelter project must be established in the HMIS using the new method of tracking

2) All clients in the exiting HMIS shelter project must be exited

3) All clients that spend the first night in the new HMIS shelter must have data collected for a new shelter project entry

4) The old shelter project should be disabled from entry in the system (i.e. closed)

Data Element Fields and Responses

Data Type

Descriptions

1 Emergency Shelter Tracking Method

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

3 Night-by-Night (nbn) The night-by-night method may be used by some high-volume shelters and shelters where a significant proportion of clients spend a night at the shelter as needed on an irregular basis.

The night-by-night method relies on creating a separate record of each individual date on which a client is present in the shelter as a means for calculating length of stay and implies that the emergency shelter is generally unable to collect as much client data at project exit as an emergency shelter that uses an entry/exit method for tracking utilization.

In this method: (1) entry information is collected the first time that a client stays at the shelter (2) the project records every discrete date (or series of dates) that the client utilizes a bed; (3) the HMIS maintains historical data on the nights a client is sheltered; (4) the client may be exited when shelter staff has information that indicates that the client is unlikely to return to the shelter or the system may be designed to automatically generate an exit after an extended absence; and (5) for reporting purposes, a client’s length of stay in the project will be based on the actual number of bed nights and not on the period of time from entry to exit.

2.6 Federal Partner Funding Sources

Rationale To identify federal funding sources for each project entering data into the HMIS, as well as any residential continuum projects not participating in HMIS, and associate projects with corresponding data collection requirements and…