HMIS Data Standards DATA DICTIONARY

Transcription

1 HMIS Data Standards DATA DICTIONARY June, 2017 U.S. Department of Housing and Urban Development Version 1.2

2 Contents SUMMARY OF CHANGES... 1 HMIS DATA DICTIONARY OVERVIEW... 1 Introduction... 1 HMIS RELATED DOCUMENTS... 2 HMIS Data Standard Documents... 2 HMIS Federal Partner Program Manuals... 3 ABOUT THIS DICTIONARY... 4 HMIS Concepts and Terms... 4 Data Element Structure... 5 PROJECT DESCRIPTOR DATA ELEMENTS Organization Identifiers Project Identifiers Continuum of Care Code Project Type Method for Tracking Emergency Shelter Utilization Federal Partner Funding Sources Bed and Unit Inventory Additional Project Information UNIVERSAL DATA ELEMENTS Name Social Security Number Date of Birth Race Ethnicity Gender Veteran Status Disabling Condition Project Start Date Project Exit Date Destination Relationship to Head of Household Client Location Housing Move-In Date Living Situation A Living Situation B Living Situation PROGRAM SPECIFIC DATA ELEMENTS COMMON DATA ELEMENTS Income and Sources Non-Cash Benefits Health Insurance Physical Disability Developmental Disability Chronic Health Condition HIV/AIDS... 52

3 4.9 Mental Health Problem Substance Abuse Domestic Violence Contact Date of Engagement Bed-night Date Housing Assessment Disposition INDIVIDUAL FEDERAL PARTNER PROGRAM ELEMENTS CoC Program Element Visibility Collection Requirements Program Specific Components and Project Types Program Specific Visibility Collection Requirements ESG Program Element Visibility Collection Requirements Program Specific Components and Project Types Program Specific Visibility Collection Requirements HOPWA Program Element Visibility Collection Requirements Program Specific Components and Project Types Program Specific Visibility Collection Requirements W1 Services Provided HOPWA W2 Financial Assistance HOPWA W3 Medical Assistance W4 T-cell (CD4) and Viral Load W5 Housing Assessment at Exit PATH Program Element Visibility Collection Requirements Program Specific Components and Project Types Program Specific Visibility Collection Requirements P1 Services Provided PATH Funded P2 Referrals Provided PATH P3 PATH Status P4 Connection with SOAR Pay for Success (PFS) Program Element Visibility Collection Requirements Program Specific Components and Project Types Program Specific Visibility Collection Requirements RHY Program Element Visibility Collection Requirements Program Specific Components and Project Types Program Specific Visibility Collection Requirements R1 Referral Source R2 RHY BCP Status R3 Sexual Orientation R4 Last Grade Completed R5 School Status R6 Employment Status R7 General Health Status R8 Dental Health Status R9 Mental Health Status... 84

4 R10 Pregnancy Status R11 Formerly a Ward of Child Welfare/Foster Care Agency R12 Formerly a Ward of Juvenile Justice System R13 Family Critical Issues R14 RHY Service Connections R15 Commercial Sexual Exploitation/Sex Trafficking R16 Labor Exploitation/Trafficking R17 Project Completion Status R18 Counseling R19 Safe and Appropriate Exit R20 Aftercare Plans RHSAP Program Element Visibility Collection Requirements U1 Worst Housing Situation VA Program Element Visibility Collection Requirements Program Specific Components and Project Types VA Program Specific Element Visibility Collection Requirements HUD/VASH and HUD/VASH Other Program Specific Element Visibility Collection Requirement V1 Veteran s Information V2 Services Provided SSVF V3 Financial Assistance SSVF V4 Percent of AMI (SSVF Eligibility) V5 Last Permanent Address V6 VAMC Station Number V7 SSVF HP Targeting Criteria V8 HUD-VASH Voucher Tracking V9 HUD-VASH Exit Information METADATA ELEMENTS Date Created Date Updated Data Collection Stage Information Date Project Identifier Enrollment ID User Identifier Personal ID Household ID Signed Consent REQUIRED COLLECTION POINTS AND METADATA ELEMENTS TABLE SUMMARY Required s Data Elements with Multiple s Data Elements with a Single Base Metadata Project Identifier, Personal ID, and Household ID Exhibit 1: 3.917B Flow Chart

5 SUMMARY OF CHANGES Revision History Date Version Revision 4/1/ Release of 2017 for Vendors 5/22/ Data Element Structure - Annual Assessment dates clarified to reflect the anniversary date of the head of household. 2.5 Method for Tracking ES removed requirement for PATH collection P4 Connection with Soar required for VA: SSVF all components R17 Project Completion Status - required collection for BCP-Prevention also R18 Counseling - typographic errors corrected VA Program Collection Requirements correct project typing, corrected element visibility requirements V1 Veterans Information - required for GPD and HCHV also V7 SSVF HP Targeting Criteria removed requirement for HUD-VASH 6/2/ Bed and Unit Inventory Emergency Shelter bed type fields and responses modified to align with AHAR and HIC requirements. R13 Family Critical Issues removed requirement to map data HMIS DATA DICTIONARY OVERVIEW Introduction 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 its congressional mandate to report to Congress 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 the 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, report to congress, 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. This 2004 document 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 Dictionary and Data Manual. Both documents supersede the previously released HMIS Data Standards. The release of this 2017 HMIS Data Dictionary and its companion Data 1

6 Standards Manual, are the documentation of requirements for the programming and use of all HMIS systems and comparable database systems, 1 effective October 1, An HMIS software must be able to collect all the data elements defined within this HMIS Data Dictionary, support the system logic, including dependencies, identified in this document, and ensure that the data collection and the visibility of data elements is appropriate to the project type and federal funding source for any given project. Communities may elect to add data elements or maintain historical data element collection beyond what is specified in this Data Dictionary 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. HMIS 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. HMIS Data Standard Documents The Data Standard Dictionary and Manual contain the foundations for the data contained within an HMIS. The Project Descriptor Data Element Manual builds upon information in the Data Dictionary to provide further information for an HMIS Lead s on the elements required by all projects for set up in the HMIS. Manual Name & Link Intended Audience Contents HMIS Data Standards Dictionary HMIS Data Standards Manual HMIS Project Descriptor Data Elements Manual HMIS Vendors & HMIS Lead Agencies HMIS Lead Agencies & HMIS Users HMIS Lead Agencies The manual provides the detailed information required for system programming on all HMIS element and response required to be included in HMIS software. It delineates data collection requirements, system logic, and contains the and tables and numbers. The manual also includes critical information about data collection stages, federal partner data collection required elements, and metadata data elements. The manual provides a review of all of the Universal Data Elements and Program Descriptor Data Elements. It contains information on data collection requirements, instructions for data collection, and descriptions that the HMIS User will find as a reference. The Project Descriptor Manual is designed to provide specific information about the Project Descriptors required to be set-up in the HMIS by the HMIS Lead Agency. 1 Comparable databases are required for use by providers of services for victims of domestic violence, as described in the VAWA. 2

7 HMIS Federal Partner Program Manuals These manuals contain specific and detailed information on project set up for each of the federal partners participating in HMIS including: HMIS project typing, the specific data elements required for collection, 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 federal partner, and approved by both entities prior to publishing. Manual Name & Link CoC Program HMIS Manual ESG Program HMIS Manual HOPWA Program HMIS Manual PATH Program HMIS Manual RHY Program HMIS Manual Intended Audience HMIS Lead Agencies HMIS Users Grantees HMIS Lead Agencies HMIS Users Recipients Subrecipients HMIS Lead Agencies HMIS Users Grantees HMIS Lead Agencies HMIS Users Grantees HMIS Lead Agencies HMIS Users Grantees Federal Partner U.S. Department of Housing and Urban Development Office of Special Needs Assistance Programs CoC Program information link U.S. Department of Housing and Urban Development Office of Special Needs Assistance Programs ESG Program information link U.S. Department of Housing and Urban Development Office of HIV/AIDS Housing HOPWA Program information link U.S. Department of Health and Human Services Substance Abuse and Mental Health Services Administration PATH Program information link U.S. Department of Health and Human Services Administration for Children and Families Family and Youth Service Bureau Contents 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. 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 The manual assists in project set up of all of the Housing Opportunities for Persons with AIDS (HOPWA) program components. 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. 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. 3

8 Manual Name & Link VA Program HMIS Manual Intended Audience HMIS Lead Agencies HMIS Users Grantees Federal Partner RHY Program information link Department of Veterans Affairs Contents This manual assists in projects set up for the Veteran s homeless programs. Programs on HMIS include: SSVF and GPD programs of the VA. ABOUT THIS DICTIONARY HMIS Concepts and Terms Continuum of Care (CoC) is used 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, that provides 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 Rule 2 (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. 2 As of June, 2016 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. 4

9 Data Element Structure Every data element required by HUD and the Federal partners to be stored within an HMIS is specified in this document. The following format is used to describe each data element: Field # & Response(s) Dependent to Field # & Response # The name of the element. The field name and any response options associated with the field. Most elements contain responses of client doesn t know and client refused. Data not collected continues to be identified as a response option in this HMIS Data Dictionary. It is not a response option necessary in every system or in every element. The element is required for use by any HMIS system which requires a response to an element before allowing the user to move forward in the system. Adding the response option of data not collected enables a user who did not collect or simply does not have the information to enter a response that does not present a false answer. HMIS systems which require entry of any element for the system to progress must implement the data not collected response for all elements that require a response. [System Note: data not collected will equate to missing data or null values as appropriate for transfer and reporting purposes.] Dependent fields and dependent response options identify the Field and 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 may elect to make dependencies visible/invisible; colored for completion/shaded out; etc. are up to each software developer. The type of data element (project descriptor, universal, program-specific or metadata) which indicates the level at which data are collected, whether they apply to all funding sources, and their relationship to other data. 1. Project Descriptor Data Elements (PDDE) are the required elements that define the individual projects within the HMIS system. They are initially entered at the setup of each project within an HMIS. They must be updated by the HMIS Administrator on a regular basis as information within the elements are subject to change and are critical for report generation. 2. Universal Data Elements (UDE) are client level data elements required for collection by all projects participating in HMIS, regardless of project type or funding source. 3. Program-Specific Data Elements are client level elements required by a specific federal program or program component. Common Elements (CE) are the first subset of the program-specific data elements that are required for collection by most of the federal partners. When combined with the UDEs, these elements comprise the building blocks for much of the reporting generated by an HMIS. Individual Federal Partner Program Elements are the second subset of the program-specific data elements. These elements are listed under the federal partner program which maintains the element. There are elements maintained by one partner and shared with one other. When combined with UDE s and Common Elements these elements comprise specific project level reporting generated by an HMIS. 4. Metadata Elements are system generated data about data elements documenting required metadata collection for all of the above element types. 5

10 Funder: Program- Component Project Type Applicability Data Collected About Identifies the federal department, the program, and the program component which requires the collection of the element. Project type(s) refers to element 2.4 Project Type and identifies the HMIS project type required to collect and report the data element. Identifies the universe of client(s) for whom an element response is required (e.g. All Clients, Heads of Household, Adults, etc.). Data may be collected about a wide group (e.g. all household members) but may be further limited in data reporting specifications. Please note: all unaccompanied youth are their own Head of Household. The term unaccompanied youth has been removed from the Data Dictionary as it was redundant and confusing at times. There are occasions where one or more youth present together at project start. In these instances, each youth should be in their own household and therefore will be their own head of household. The point(s) at which the data must be able to be collected in an HMIS. For data elements with multiple collection points (e.g. Project Start, Occurrence Point, Project Exit), each record must be stored with the appropriate Data Collection Stage (as listed in metadata element 5.3). Data elements with only a single collection point need not be stored with any particular data collection stage, since their data collection point is inherent in their requirements. Record creation Indicates the element is required to be collected when the client record is created. Elements collected at record creation should have one and only one value for each client in an HMIS. Data are collected and entered into the HMIS, responses must be reviewed for accuracy at each project start and edited as necessary to make corrections or to improve data quality. Project start (stored with Data Collection Stage of Project Start for elements with multiple collection points) Indicates the element is required to be collected at every project start. Elements collected at project start must have an Information Date that matches the client s Project Start Date. Information must be accurate as of the Project Start Date. When a data element with multiple collection points is collected at project start, it must be stored with a Data Collection Stage of project start. There should be one and only one record with a Data Collection Stage of project start for each relevant data element for any given project start. Data may be edited by users associated with the project to correct errors or omissions; such edits will not change the data collection stage associated with the record. Occurrence Point/Update Indicates the element may be collected and entered at any point during a project stay to track changes over time or document the occurrence of events (e.g. a service is provided). These types of records must be able to be entered at any point during the project stay. Some data elements are collected once per project stay. For others, the system must be able to support a theoretically unlimited number of records per project stay, each with a distinct Information Date. The Information Date should reflect the date on which the information is collected and/or the date for which the information is relevant for reporting purposes. Information must be accurate as of the Information Date, regardless of when it is collected or entered into the HMIS. Data may be edited by users associated with the project to correct errors or omissions; such edits will change neither the data collection stage nor the information date unless it is explicitly altered by the user. 6

11 Annual assessment (stored with Data Collection Stage of Annual Assessment ) Data elements required for collection at annual assessment must be entered with an Information Date of no more than 30 days before or after the anniversary of the head of household s Project Start Date, regardless of the date of the most recent update or any other annual assessment. Information must be accurate as of the Information Date. The data collection stage may not be inferred from the Information Date, although the field must have an Information Date recorded with it. To be considered reportable to HUD as an annual assessment, data must be stored with a Data Collection Stage of annual assessment. The Annual Assessment must include updating both the head of household s record and any other family members at the same time. There should be one and only one record for each data element annually with a Data Collection Stage recorded as annual assessment associated with any given client and Enrollment ID within the 60-day period surrounding the anniversary of the head of household s Project Start Date. Regardless of whether the responses have changed since project start or the previous annual assessment, a new record must be created for each subsequent annual assessment such that it is possible to view a history, by date, of the values for each data element. Data may be edited by users associated with the project to correct errors or omissions; such edits will change neither the data collection stage nor the information date unless they are explicitly altered by the user. Project exit (stored with Data Collection Stage of Project Exit for elements with multiple collection points) Indicates the element is required to be collected at every project exit. Elements collected at project exit must have an Information Date that matches the client s Project Exit Date. Information must be accurate as of the Project Exit Date. When a data element with multiple collection points is collected at project exit, it must be stored with a Data Collection Stage of project exit. There should be one and only one record with a Data Collection Stage of project exit for each relevant data element for any given project exit. Data may be edited by users associated with the project to correct errors or omissions; such edits will not change the data collection stage or the information. Post exit (stored with Data Collection Stage of Post Exit for elements with multiple collection points) Indicates the element may be collected after project exit for a period of no longer than six months. This is a new data collection stage in 2017 and its functionality and impact on reporting will be assessed prior to the next data standards update. Logically required data collection or system structure information for HMIS software development purposes. Other System Issues Information on rationale, conditions, constraints, etc. that may be applicable to a specific element and are important for HMIS software development purposes. element in Specifications where the data standard element is located. Primary file in Specifications where the data standard element is located V1 Changes Made Documentation of changes to the element from the 2014 Data Dictionary Version 5 to the 2017 Data Dictionary. 7

12 PROJECT DESCRIPTOR DATA ELEMENTS Project descriptor data elements are intended to identify the organization, specific project, and project details to which an individual client record in an HMIS is associated. The project descriptors are generally managed in an HMIS by a system administrator, not a user. They are created at initial new project setup within the HMIS and are intended to be updated, as needed, on a regular basis by the system administrator, no less than once annually. If data within project descriptor data elements can be entered or updated by a user, then the HMIS system administrator must have oversight and review ability. This section describes the data to be recorded in HMIS for each project descriptor data element and its relation to each project entering data. The project descriptor data elements create a basis for identifying the organization, project, project type, and federal partner Funder(s). 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. This year, HUD has re-implemented the requirement that the CoC must collect program information in the HMIS on all continuum projects within its jurisdiction, regardless of whether the program participates in the 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 2.1 Organization Identifiers Organization Identifiers Field 1 & Response Organization ID auto generate Field 2 & Response Organization Name Project Descriptor Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Organizations Initial HMIS project setup, reviewed/updated no less than annually An Organization ID must be assigned to each project via a system generated number or code. Each organization must receive a distinct identifier that is consistently associated with that organization. 8

13 Each organization must also be able to be associated with one or more projects. The name of the organization must be captured in text within the HMIS. Other System Issues An HMIS must allow the HMIS Lead to activate and deactivate an organization. An HMIS application may permit the creation of a common name field more familiar to users for use within the application while retaining the legal name for use in reporting. <Organization> Organization 2017 V1 Changes Made None 2.2 Project Identifiers Project Identifiers Field 1 & Response Project ID auto generate Field 2 & Response Project Name Field 3 & Response Operating Start Date Field 4 & Response Operating End Date Project Descriptor Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Projects Initial HMIS project setup, reviewed/updated no less than annually A Project ID must be assigned to each project via a system generated number or code. Each project must receive an identifier that is unique within the HMIS and consistently associated with that project. Each project must be associated with an organization (data element 2.1); separate projects operated by the same agency must be associated with the same Organization ID. The name of the project must be captured in text within the HMIS. 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. Operating start date should reflect 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. Operating end date should reflect 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. 9

14 Other System Issues An HMIS application may permit the creation of a common name element more familiar to users for use within the application while retaining the legal name for use in reporting. <Project> Project 2017 V1 Changes Made Two new fields were added (Operating Start Date and Operating End Date) to enable activation and de-activation of a project. Clarification to also provided due to questions received by HUD. 10

15 2.3 Continuum of Care Code Continuum of Care Code Field 1 & Response Continuum Code - HUD-assigned CoC codes for the project location [text 6 characters] Project Descriptor Funder: Program-Component All Programs All Components Project Type Applicability Data Collected About Other System Issues All HMIS Project Types All Continuum Projects Initial HMIS project setup, reviewed/updated no less than annually Collect at initial setup. There is a many-to-one relationship between this data element and 2.2 Project Identifiers; there may be multiple current records of this data element at any given time. Add, edit, or remove associations with CoCs as needed to reflect changes. Projects may be funded to operate in one or more CoCs. The system must allow for a project to be associated with every continuum of care in which the project operates, although only the CoC Codes for which the project will be entering data into the HMIS must be recorded. Projects may be funded to provide for housing and/or services to clients residing in only one CoC (e.g. CoC: Transitional Housing), or they may be funded for housing and/or services across multiple CoCs (e.g. VA: SSVF). The system must allow for multiple codes selected per project. It must be possible to associate a project with the CoC code for every geographic area in which the project operates and for which it will be entering data into the HMIS. If the HMIS produces CoC-level reporting on 2.7 Bed and Unit Inventory (AHAR and/or HIC) for more than one continuum, records of inventory must be separate and associated with the CoC where the inventory is located. If the system sets a default value for the CoC Code, it should be the CoC code for the continuum operating the HMIS. For data quality purposes, HUD strongly encourages that CoC Codes in this data element be used to populate an option list of CoC Codes for data element 3.16 Client Location. <ProjectCoC> ProjectCoC 2017 V1 Changes Made Updated guidance instructing systems to allow for multiple CoC codes to be selected per project. 11

16 2.4 Project Type Project Type Field 1 & Responses Continuum Project Field 2 & Responses Project Type 1 Emergency Shelter 2 Transitional Housing 3 PH - Permanent Supportive Housing (disability required for entry) 4 Street Outreach 5 RETIRED 6 Services Only 7 Other 8 Safe Haven 9 PH Housing Only 10 PH Housing with Services (no disability required for entry) 11 Day Shelter 12 Homelessness Prevention 13 PH - Rapid Re-Housing 14 Coordinated Assessment Dependent A Dependent to If Services Only for Project Type Field 2 & Response 6 Affiliated with a residential project Dependent B Dependent to If Yes for Affiliated with a residential project Dependent A & Response 1 Project ID(s) of residential project(s) affiliated with SSO Project Descriptor Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Continuum Projects Initial HMIS project setup, reviewed/updated no less than annually Other System Issues Collect once at initial setup. System stores collected project type and retains for historical purposes. Allow edits if changes or corrections for data entry error. A project can only have one project type assigned; there is a one-to-one relationship between this data element and data element 2.1 Project Identifiers. A project must be able to identify multiple affiliated residential projects if yes to Dependent A. A continuum project refers to all projects within the Continuum of Care that provide housing and/or services for homeless persons. A Continuum project is 12

17 not limited to those projects funded by HUD and should include all the federal partner projects and all other federally or non-federally funded projects functioning within the Continuum. General rules of project typing: 1. A project is to be assigned a type based on the lodging or service it is providing. 2. If an organization operates more than one residential project type, each type must be set up in HMIS as a separate project. (For example, an emergency shelter and a transitional housing project must be set up as two separate projects in HMIS, even if they are funded by the same source). 3. A residential project that is funded under one or more separate grants to provide supportive services to 100% of clients of the residential project, may 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. 4. A project that provides street outreach must be typed 4 Street Outreach. (Note: a street outreach project that also has a direct service component serving persons other than people living on the streets or in a place not meant for human habitation will require two separate projects to be set up in an HMIS a 4- Street Outreach and a 6- Services Only ). 5. A project that provides only services (other than street outreach), has associated housing outcomes, and is not limited to serving clients of one or more specific residential project should be typed as 6 Services Only and Affiliated with a Residential Project will be No. 6. A project that provides only services (other than street outreach), has associated housing outcomes, and is restricted by its grant agreement to serve only clients of one or more specific residential projects should be typed as 6 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. 7. A project that provides only services (other than street outreach) that are stand alone supportive services and have no associated housing outcomes should be typed as 7 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 7 Other. A project funded to provide ongoing case management should be typed 6 Services Only. ) Project Type guidance is also available in the individual HMIS Program Handbooks (ESG, CoC, HOPWA, RHY, PATH, VA). Note: Projects which only provide services and are funded under the HUD CoC Program after FY 2014 which provide services exclusively to clients of a single residential project type (other than emergency shelter) will be identified in

18 Federal Partner Funding Sources with the component type of the residential project(s) and not Services Only. These projects must still be classified with a Project Type of Services Only. For the sake of consistency, it is recommended that Dependent B is selected from a drop down list created from element 2.2 Project Identifiers that includes the Project Names and IDs for all non-emergency shelter projects. <Project> and <Affiliation> Project (and Affiliation for ResProjectID) 2017 V1 Changes Made None 2.5 Method for Tracking Emergency Shelter Utilization Method for Tracking Emergency Shelter Utilization Field 1 & Responses Emergency Shelter Tracking Method 0 Entry/Exit Date (e/e) 3 Night-by-Night (nbn) Project Descriptor Funder: Program-Component HUD:CoC No component requires data collection HUD:ESG Collection required for all ES components HUD:HOPWA Collection required for Hotel/Motel ES e/e components HUD:HUD-VASH - No component requires data collection HUD:RHSAP - No component requires data collection HHS: RHY - Collection required for BCP ES e/e components VA:SSVF No component requires data collection Project Type Applicability 1: Emergency Shelter Data Collected About All Emergency Shelters Initial HMIS project setup, reviewed/updated no less than annually Collect at initial setup. System stores collected method and retains for historical purposes. There is a one-to-one relationship between this data element and 2.2 Project Identifiers. Other System Issues One method must be identified in an HMIS for each emergency shelter project. Reporting and outcomes will differ depending on the method utilized by the shelter. The entry/exit method should be used for all shelters which require an entry, a continuous stay, and an exit. The length of stay will be calculated based on the number of nights between project start and project exit and performance measurement will include changes from project start and project exit data collection stages. Funder preference for emergency shelter projects is the use of the project start/exit date method except for projects where clients are permitted to enter and exit on an irregular basis (e.g. mass shelter). The night-by-night method should be used for shelters which allow clients to enter and exit on an irregular basis and do not require a continuous stay and 14

19 must instead rely on a method of tracking bed nights. In this method (1) all data required to be collected at project start is collected the first time the client stays at the shelter; (2) the project records every discrete date (or series of dates) that the client utilizes a bed; (3) the system maintains historical data on the nights sheltered; (4) 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; and (5) the client may be exited or the system may be designed to automatically generate an exit after an extended absence. 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 new night-by-night model. <Project><TrackingMethod> Project 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 2.6 Federal Partner Funding Sources Field 1 & Responses Federal Partner Funding Sources Federal Partner Program and Components 1 HUD:CoC Homelessness Prevention (High Performing Comm. Only) 2 HUD:CoC Permanent Supportive Housing 3 HUD:CoC Rapid Re-Housing 4 HUD:CoC Supportive Services Only 5 HUD:CoC Transitional Housing 6 HUD:CoC Safe Haven 7 HUD:CoC Single Room Occupancy (SRO) 43 HUD:CoC - Youth Homeless Demonstration Program (YHDP) 8 HUD:ESG Emergency Shelter (operating and/or essential services) 9 HUD:ESG Homelessness Prevention 10 HUD:ESG Rapid Rehousing 11 HUD:ESG Street Outreach 35 HUD: Pay for Success 36 HUD: Public and Indian Housing (PIH) Programs 12 HUD:Rural Housing Stability Assistance Program 13 HUD:HOPWA Hotel/Motel Vouchers 15

20 14 HUD:HOPWA Housing Information 15 HUD:HOPWA Permanent Housing (facility based or TBRA) 16 HUD:HOPWA Permanent Housing Placement 17 HUD:HOPWA Short-Term Rent, Mortgage, Utility assistance 18 HUD:HOPWA Short-Term Supportive Facility 19 HUD:HOPWA Transitional Housing (facility based or TBRA) 20 HUD:HUD/VASH 21 HHS:PATH Street Outreach & Supportive Services Only 22 HHS:RHY Basic Center Program (prevention and shelter) 23 HHS:RHY Maternity Group Home for Pregnant and Parenting Youth 24 HHS:RHY Transitional Living Program 25 HHS:RHY Street Outreach Project 26 HHS:RHY Demonstration Project 27 VA: CRS Contract Residential Services 29 VA:Domiciliary Care*** 37 VA:Grant Per Diem Bridge Housing 38 VA:Grant Per Diem Low Demand 39 VA:Grant Per Diem Hospital to Housing 40 VA:Grant Per Diem Clinical Treatment 41 VA:Grant Per Diem Service Intensive Transitional Housing 42 VA:Grant Per Diem Transition in Place 30 VA:Community Contract Safe Haven Program*** 32 VA:Compensated Work Therapy Transitional Residence*** 33 VA:Supportive Services for Veteran Families 34 N/A Field 2 & Response Grant Identifier Field 3 & Response Grant Start Date ([date field]) Field 4 & Response Grant End Date ([date field]) Project Descriptor Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Projects Initial HMIS project setup, reviewed/updated no less than annually Collect at initial setup. This is a transactional data element; a single project may have multiple current and historical records. Allow corrections for data entry error. An HMIS must allow projects with multiple Funder sources and multiple grants (with potentially different grant terms) from the same funding source to record and store all funding sources for the project. Other System Issues The federal funding sources listed in Field 1 & Response are the federal partner programs and their project components who have agreed either to participate in HMIS or are otherwise considered continuum projects. An HMIS may elect to identify other funding sources as may be appropriate to the CoC, but must 16

21 have available the identification of all the sources identified in Field 1 & Response. A grant identifier is to be assigned to each federal program being used for funding for the project. The grant identifier may be the grant number or any other identification system utilized by the CoC. All sub-grantees of a principal grant should use the same grant identifier as the principal grantee as a method of allowing for aggregated reporting by the principal grantee. <Funder> Funder 2017 V1 Changes Made Addition of response option 35 PIH and 36 PFS. Retired responses 28 VA Community Contract Residential Treatment Program and 31 VA: Grant Per Diem response and replaced it the six new GPD component types (response 37-42) Element Footnotes Renamed response 27 from Community Contract Emergency Housing to VA: CRS Contract Residential Services (which now includes both the former Community Contract Emergency Housing and Residential Treatment Programs) ***These VA programs are not required to enter client-level data although Project Descriptor Data Elements must be recorded. 2.7 Bed and Unit Inventory Field 1 & Response Field 2 & Response Field 3 & Response Field 4 & Response Field 5 & Responses Field 6 & Response Field 7 & Response Field 8 & Responses Bed and Unit Inventory Information Information date Inventory start date (date) Inventory end date (date) CoC Code Household type 1 Households without children 3 Households with at least one adult and one child 4 Households with only children Bed inventory (integer) Unit inventory (integer) If 2.7 Project Type = Emergency shelter Bed Type 1 Facility-based beds 2 Voucher beds 3 Other beds 17

22 Field 9 & Responses If 2.7 Project Type = Emergency shelter Availability 1 Year-round 2 Seasonal 3 Overflow Field 10 & Response Veteran bed inventory (integer) Field 11 & Response Youth bed inventory (integer) Field 12 & Response If 2.7 Project Type = PH Permanent supportive housing Chronically homeless bed inventory (integer) Field 13 & Response HMIS participating beds (integer) Project Descriptor Funder: Program-Component All Programs All Components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 3: PH- Permanent Supportive Housing 8: Safe Haven 9: PH- Housing Only 10: PH- Housing with Services 13: PH- Rapid Re-Housing Data Collected About All Residential Projects Initial HMIS project setup, reviewed at least annually and updated as needed to reflect changes. A project may have multiple current and historical records of inventory. Inventory for RRH projects should be counted and recorded consistent with HIC guidance to reflect the numbers of RRH participants who have moved into permanent housing. Projects that serve more than one household type must have a separate inventory record for each household type. Emergency shelters with more than one bed availability (year-round, seasonal, overflow) or more than one bed type (facility-based, voucher, other) must have separate records for each bed availability, bed type, and household type. New inventory any inventory added since the date of the last HIC should be recorded in a separate record, as should inventory under development (i.e., fully funded but not yet available). Changes over time should be documented such that a historical record of inventory is retained. Minor day-to-day fluctuations need not be recorded, but differences due to significant changes in project operations should be entered as they occur. Where there are multiple records for a single project for the same household type (and, for emergency shelters, the same bed availability), the record with the most recent Information Date should be considered current as of a single date or within any given date range. For any inventory record, it must be possible to identify the CoC with which the inventory is associated. 18

23 When a project adds inventory, a new record should be added with an Information Date and Inventory Start Date that reflect the date of the increase. Inventory under development (i.e., beds for which funding has been approved but are not yet available) should also be separate using the current date as the Information Date and the date that the beds are expected to be available as the Inventory Start Date. When a project reduces inventory, but will continue to serve the same household type with a smaller number of beds, a new record should be added with an Information Date of the effective date of the decrease; the same Inventory Start Date from the previous record should be used. The earlier record should be closed out by recording an Inventory End Date that is the day prior to the effective date of the decrease. When a project is eliminating all inventory for a given household type, an Inventory End Date reflecting the last date on which beds were available should be entered for the existing record. Changes in the number of HMIS participating beds; the number of beds dedicated for chronically homeless, Veteran, or youth clients should be documented by closing out the old record with an Inventory End Date that is the date before the effective date of the change. A new record should be created with an Information Date that is the effective date of the change; the same Inventory Start Date from the previous record should be used. At annual review, if there are separate records for beds of the same type and all Inventory Start Dates are more than one year prior to the most recent HIC, the individual records should be closed out by recording an Inventory End Date that is the day prior to the current date. A new record should be created to combine the total inventory of the individual records using the current date as the Information Date and the earliest Inventory Start Date from the individual records. Other System Issues These fields must be transactional, meaning they must be able to record multiple values over time. <Inventory> Inventory 2017 V1 Changes Made CoC Code has been added to clarify that inventory is specific to the continuum in which it is located; for projects that operate in multiple CoCs, it must be possible to count inventory separately for each. Data element has been updated to correspond with AHAR and HIC requirements; system logic has been updated to clarify data entry requirements. Inventory Start Date and Inventory End Date, previously optional, are required. Specific age categories for youth beds have been removed as they are no longer a part of the HIC. 2.8 Additional Project Information Additional Project Information 19

24 Field 1 & Response Field 2 & Response Field 3 & Response Field 4 & Responses Field 5 & Responses Field 6 & Response Field 7 & Responses Field 8 & Responses Field 9 & Responses Field 10 & Responses Field 11 & Responses Field 12 & Responses Information date CoC Code Geocode (6 digits) Target Population 1 DV: Domestic violence victims 3 HIV: Persons with HIV/AIDS 4 NA: Not applicable Victim services provider Project ZIP code (5 digits) From look up table provided by HUD code the following geography types based on ZIP code 1 Urban 2 Suburban 3 Rural Housing type 1 Site-based single site 2 Site-based clustered / multiple sites 3 Tenant-based - scattered site Project street address 1 (text) Project street address 2 (text) Project city (text) Project state (2 letters) Project Descriptor Funder: Program-Component All Programs All Components Project Type Applicability Data Collected About 1: Emergency Shelter 2: Transitional Housing 3: PH- Permanent Supportive Housing 8: Safe Haven 9: PH- Housing Only 10: PH- Housing with Services 13: PH- Rapid Re-Housing All Projects Initial HMIS project setup, reviewed at least annually and updated as needed to reflect changes. Collect at initial setup. For projects that operate in a single continuum, there is a many-to-one relationship between this data element and 2.1 Project Identifiers, although at any given time, only one record for this data element will be 20

25 Other System Issues current. For projects that operate in multiple CoCs, there is a similar many-toone relationship with 2.3 Continuum of Care Code. Information must be confirmed at least annually. Data entry errors should be edited to correct; a new record should be created to document a change in information. A new record is only required if a change has occurred; the Information Date of the new record should reflect the date of the change. Not all fields are required for all projects; it should be possible to leave all address fields blank. Geocode, ZIP code, and address fields should reflect the location of the project s principal site or, for multiple site projects, the location in which the majority of the project s clients are housed. Tenant-based scattered site projects are only required to complete the geocode and ZIP code fields and may use the administrative address if they wish to complete the remainder of the address fields. HUD will release a crosswalk of ZIP codes with a geography type for each. This must be incorporated as a table into HMIS applications and used to autopopulate the geography type field. The crosswalk will not be available immediately but will be required for use in the AHAR; until it is available, the geography type field should be left blank. <Geography> Geography 2017 V1 Changes Made Relevant fields from 2.8 Site Information and 2.9 Target Population have been combined in a single data element. Optional status was removed from the element as it is required for the AHAR. The data element must be available for use by CoCs in all HMIS applications by October 1, CoCs that use HMIS to produce the HIC must complete data entry for all projects prior to HIC submission; CoCs that participate in the AHAR must complete data entry for all projects no later than October 1,

26 UNIVERSAL DATA ELEMENTS HMIS Universal Data Elements are elements required to be collected by all projects using the software as an HMIS. Projects funded by any one or more of the federal partners must collect the Universal Data Elements, as do projects that are not funded by any federal partner (e.g. missions) but are entering data as part of the Continuum of Care s HMIS implementation. Universal data elements enable the HMIS the ability to record unique, unduplicated client records, establish participation in a project within a date range, and identify clients who meet time criteria for chronic homelessness. 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.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 Living Situation In the 2017 HMIS Data Standards, Data Element 4.17 Residential Move-In Date was significantly modified and became universal data element 3.20 Housing Move-In Date. 3.1 Name Name Field 1 & Response First (text) Field 2 & Response Middle (text) Field 3 & Response Last (text) Field 4 & Response Suffix (text) Field 5 & Responses Name Data Quality 1 Full name reported 2 Partial, street name, or code name reported Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients 22

27 Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected information. Users associated with projects that serve any given client must be able to edit data to correct errors or reflect changes in client responses. Other System Issues Systems may elect to utilize an extra field(s) for alias or for notes on name changes. <Client>< > Client 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 3.2 Social Security Number Social Security Number Field 1 & Response Social Security Number Field 2 & Responses SSN Data Quality 1 Full SSN reported 2 Approximate or partial SSN reported Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected nine-digit SSN in one field and the appropriate SSN data quality in another. Users associated with projects that serve any given client must be able to edit data to correct errors or reflect changes in client responses. Other System Issues The HMIS may include hyphens or other punctuation within the SSN to improve readability, but the SSN must be exportable as a single alphanumeric field containing a maximum of nine characters and no punctuation. HMIS solutions and HMIS administrators (if the system permits) may designate special non-numeric characters (e.g., the letter x) to indicate missing digits and otherwise devise methodologies to allow entry and effective matching of partial SSNs. Because missing digits may appear in any one of the nine placeholders, it is critical for the system to have a mechanism to indicate which digits were missing when entering partial SSNs; an alphabetic character must be interpreted as a placeholder. 23

28 The HMIS may elect to add an additional field, in a manner defined by the system, for clients who do not have a SSN to facilitate merging duplicated records. <Client>< > Client 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 3.3 Date of Birth Date of Birth Field 1 & Response Date of Birth Field 2 & Responses DOB Data Quality 1 Full DOB reported 2 Approximate or partial DOB reported Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected DOB in one field and the appropriate DOB data quality type in another. Users associated with projects that serve any given client must be able to edit data to correct errors or reflect changes in client responses. Other System Issues One date-format field for birth dates should be created in the HMIS database. Date of birth must be exportable in the [date field] format. <Client>< > Client 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 24

29 3.4 Race Race Field 1 & Responses Race (as many as are applicable) 1 American Indian or Alaska Native 2 Asian 3 Black or African American 4 Native Hawaiian or Other Pacific Islander 5 White Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected information. Users associated with projects that serve any given client must be able to edit data to correct errors or reflect changes in client responses. The HMIS must accommodate the recording of up to five race response categories per client. Other System Issues Client doesn t know, Client refused, and Data not collected are not races; they are explanations for missing race data. None of these three responses are valid in conjunction with any other response. <Client><Race> Client 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 3.5 Ethnicity Field 1 & Responses Ethnicity Ethnicity n-hispanic/non-latino 1 Hispanic/Latino Universal Funder: Program-Component All Programs All Components 25

30 Project Type Applicability Data Collected About All HMIS Project Types All Clients Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected information. Users associated with projects that serve any given client must be able to edit data to correct errors or reflect changes in client responses. None <Client><Ethnicity> Other System Issues Client 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 3.6 Gender Gender Field 1 & Responses Gender 0 Female 1 Male 2 Trans Female (MTF or Male to Female) 3 Trans Male (FTM or Female to Male) 4 Gender Non-Conforming (i.e. not exclusively male or female) Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected information. Users associated with projects that serve any given client must be able to edit data to correct errors or reflect changes in client responses. Other System Issues All prior response option 4 other may change to the new response 4 Doesn t identify as male, female, or transgendered. The same field number may be used in the system and wording may simply be updated to doesn t identify as male, female, or transgender in order to protect the unduplication and reporting capacities of the system already constructed. <Client>< > Client 2017 V1 Changes Made Wording change on response No data mapping required. 26

31 Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 3.7 Veteran Status Veteran Status Field 1 & Responses Veteran Status Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Adults Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected information and retains for historical purpose. Users associated with projects that serve any given client must be able to edit data to correct errors, reflect changes in client response or status, or to enter a response for a client who has turned 18. Other System Issues Users are not required to ask clients under 18 about veteran status; this does not mean that systems are required to hide or exclude this data element from data entry forms. Users may enter No for any client under 18. Systems may be programmed to automatically create a response for clients who turn 18 while enrolled; the auto-generated response should be No. <Client><VeteranStatus> Client 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. 3.8 Disabling Condition Field 1 & Responses Disabling Condition Disabling Condition 27

32 Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project start (Edit as necessary to reflect new information) There is a one-to-one relationship between this data element and 5.6 Enrollment ID. System stores collected information and retains for historical purpose. A user must be able to set the value of this data element to Yes independent of any other data element. Other System Issues If all Special Needs elements are present for completion in the HMIS application for a particular project, then disabling condition may be inferred to be yes from an answer of yes to the dependent field in those elements expected to be of long continued and indefinite duration and substantially impairs ability to live independently. Disabling condition may either be entered by the user independently of any other special need field, or data in this field may be inferred by the responses to ability to live independently. If the system auto-populates Disabling Condition, a user must be able to override a system-generated no with yes. Further, if Disabling Condition is auto-populated with yes based solely on a qualifying record for data elements (i.e., the user-entered response was something other than yes ) and that record is later deleted or edited such that it doesn t meet the criteria for Disabling Condition, the auto-populated yes response must revert to the user s original response. Regardless of the response to this data element, if a client has a Physical Disability, Developmental Disability, Chronic Health Condition, HIV/AIDS, Mental Health Problem, and/or Substance Abuse issue (data elements ) that meets the criteria for a disabling condition (Dependent Field A = Yes ), reporting should always count the client as having a Disabling Condition. <Enrollment><DisablingCondition> Enrollment 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic Project Start Date Project Start Date Field 1 & Response Project Start Date ([date field]) Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients 28

33 Other System Issues Project Start Collect once at each project start; there is a one-to-one relationship between this data element and 5.6 Enrollment ID. System stores collected information and retains for historical purpose. The project start date is: for Street Outreach projects it is the date of first contact with the client. for Emergency Shelters it is the night the client first stayed in the shelter for the consecutive shelter period from entry to exit. Night by night shelters, which use a bed-night tracking method will have a project start date and will allow clients to re-enter as necessary without exiting and restarting for each stay for a specified period. for Safe Havens and Transitional Housing it is the date the client moves into the residential project (i.e. first night in residence). for all types of Permanent Housing, including Rapid Re-Housing it is the date following application that the client was admitted into the project. To be admitted indicates the following factors have been met: 1) Information provided by the client or from the referral indicates they meet the criteria for admission (for example if chronic homelessness is required the client indicates they have a serious disability and have been homeless long enough to qualify though all documentation may not yet have been gathered ; 2) The client has indicated they want to be housed in this project; 3) The client is able to access services and housing through the project. The expectation is the project has a housing opening (on-site, site-based, scattered-site subsidy) or expects to have one in a reasonably short amount of time for all other types of Service projects including but not limited to: services only, day shelter, homelessness prevention, coordinated assessment, health care it is the date the client first began working with the project and generally received the first provision of service. With these 2017 Data Standards, the date from 3.10 Project Start Date for all PH project entries, except RRH, prior to October 1, 2017 are to be replicated to show in both the new 3.10 Project Start Date element and the 3.20 Housing Move-In Date. The movement of this data corresponds to the previous definition of Project Start Date as the date the household moved into housing and is intended to maintain the data for active reporting as well as longitudinal research. The project start date must be exportable in the [date field] format. <Enrollment><EntryDate> Enrollment 2017 V1 Changes Made Renamed from Project Entry Date Significant changes to the definition of the element s use for permanent housing projects. 29

34 Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic Project Exit Date Project Exit Date Field 1 & Response Project Exit Date ([date field]) Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Exit Collect once at each project exit; there is a one-to-one relationship between this data element and 5.6 Enrollment ID. System stores collected information and retains for historical purpose. Other System Issues The project exit date indicates a client has left the project. For residential projects this is the date of move out. For some services-only projects a record may need to remain open an indefinite period and an exit date recorded only when the client completes the service, is no longer in need of the service, has asked to be exited, or has gone missing. A client with an open record (i.e. project start without a project exit) for a CoC defined extensive length of time in a shelter, outreach, or prevention program type may be either automatically exited from the project (exit date = date of auto exit) or may be flagged for user intervention and exit. The CoC must be involved in the determination of extensive length of time and to which projects the solution is to be applied. This may be accomplished via program setup functionality that may include a data field in each project s setup/profile to record the period of no client contact after which a client would be flagged for a default exit, or in any other manner the HMIS elects. For systems that require all shelter 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 an HMIS solution that automatically enters the exit date as the day after the entry date for clients of the overnight project. If a client is in a project for a single day and has received some service but has not slept in a bed overnight (i.e., starts and stops before midnight of same day) the Project Exit Date may be the same as the Project Start Date. The project exit date must be exportable in the [date field] format. <Exit><ExitDate> Exit 30

35 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic Destination Field 1 & Responses Destination Destination Type 24 Deceased Emergency shelter, including hotel or motel paid for with emergency shelter 1 voucher 15 Foster care home or foster care group home 6 Hospital or other residential non-psychiatric medical facility 14 Hotel or motel paid for without emergency shelter voucher 7 Jail, prison or juvenile detention facility 25 Long-term care facility or nursing home 26 Moved from one HOPWA funded project to HOPWA PH 27 Moved from one HOPWA funded project to HOPWA TH 11 Owned by client, no ongoing housing subsidy 21 Owned by client, with ongoing housing subsidy 3 Permanent housing (other than RRH) for formerly homeless persons Place not meant for habitation (e.g., a vehicle, an abandoned building, 16 bus/train/subway station/airport or anywhere outside) 4 Psychiatric hospital or other psychiatric facility 10 Rental by client, no ongoing housing subsidy 31 Rental by client, with RRH or equivalent subsidy 19 Rental by client, with VASH housing subsidy 28 Rental by client, with GPD TIP housing subsidy 20 Rental by client, with other ongoing housing subsidy 29 Residential project or halfway house with no homeless criteria 18 Safe Haven 22 Staying or living with family, permanent tenure 12 Staying or living with family, temporary tenure (e.g. room, apartment or house) 23 Staying or living with friends, permanent tenure 13 Staying or living with friends, temporary tenure (e.g. room apartment or house) 5 Substance abuse treatment facility or detox center 2 Transitional housing for homeless persons (including homeless youth) 17 Other 3 exit interview completed 31

36 Dependent A Dependent to If Other for Type of Residence Field 1 & Response 17 text box for Specify Where Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Exit Collect once at each project exit; there is a one-to-one relationship between this data element and 5.6 Enrollment ID. System stores collected information and retains for historical purpose. Other System Issues Users may find it helpful for systems to display exit destinations using the same screen order as to facilitate data quality. This is optional but suggested for consideration. <Exit>< > Exit 2017 V1 Changes Made Wording change to response option 3; Addition of a response option 31. Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic Relationship to Head of Household Relationship to Head of Household Field 1 & Responses Relationship to Head of Household 1 Self 2 Head of household s child 3 Head of household s spouse or partner 4 Head of household s other relation member (other relation to head of household) 5 Other: non-relation member Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start Collect once at each project start; there is a one-to-one relationship between this data element and 5.6 Enrollment ID. System stores collected information and retains for historical purpose. There must be one and only one individual for whom Relationship to Head of Household is Self (head of household) for each project start. If the household is composed of adults and children, an adult must be indicated as the head of household. 32

37 Other System Issues If the individual designated as head of household exits the project while other members remain, users must be able to edit the Relationship to Head of Household for all household members such that an individual present for the entire project stay is designated as head of household and relationships to the head are correct for other members (including the individual exiting the program). All members of the household accepted into a specific housing project or applicable to a service project are recorded within an HMIS and must either be the Head of Household or have an identified relationship to the Head of Household. The term Head of Household is not intended to mean the leader of the house, rather it is to identify one client by which to attach the other household members. Other than ensuring that an adult is indicated as the head of household in a household composed of adults and children, there are no requirements for the identification of the Head of Household established within these standards. Continuums may elect a method of identification and/or Funders may have a preference. It is expected that both the Head of Household and the household member are always in the database together in the same household at a particular project The system must allow for the Head of Household to leave the household and have the household maintain the same Household ID while assigning a new Head of Household. The system must allow for persons to enter or exit the household without having to complete a full program exit and new project start of the entire household. <Enrollment><RelationshipToHoH> Enrollment 2017 V1 Changes Made Clarification that an adult must be made the head of household if an adult is present. An HMIS may but is not required to enforce the requirement. Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic Client Location Client Location Information Date (date) Field 1 & Response HUD assigned CoC code for the client s location Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types 33

38 Data Collected About Other System Issues Head of Household Project Start, Update It must be possible to associate all project stays with one or more (for clients who move while enrolled) Continuum of Care Codes. This data element must be user-entered for all projects with more than one Continuum of Care Code identified in Project Descriptor Data Element 2.3. It may be auto-populated for projects that operate in a single CoC. Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Data is time sensitive and may change over the project stay; there is a many-to-one relationship between this data element and 5.9 Household ID. System must allow for updated information collection if change occurs because a client has moved and must record the date the information was collected with a data collection stage of project update, and retains all updates for historical purpose. To allow projects operating in multiple continuums to enter data into a single host HMIS and provide data to each of the continuums in which they are serving clients, a continuum must be identified for each project start. The Continuum of Care Code will be used in continuum reporting in the host HMIS to exclude irrelevant data; it will also be used as a parameter for data export to provide relevant data to other continuums. Data are to indicate the location of the client s current residence and must be updated if the client moves into a different CoC. Household data must move based on the Head of Household s identified location. Systems may set up defaults to the continuum code of the HMIS implementation, but must be able to accept any other continuum code identified in data element 2.3 for the project. For data quality, it is recommended that the CoC codes used for this element should be limited to the same CoC codes used for element 2.3 Continuum of Care Code. <EnrollmentCoC> EnrollmentCoC 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic Housing Move-In Date Field 1 & Response Housing Move-In Date Housing Move-in Date (date) Universal 34

39 Funder: Program-Component All Programs All Permanent Housing Components Project Type Applicability 3: PH-Permanent Supportive Housing 9: PH-Housing Only 10: PH-Housing with Services (no disability required for entry) 13: PH-Rapid Re-Housing Data Collected About Heads of Household Occurrence Point (At move-in must be entered if/when a household moves into any type of permanent housing, regardless of funding source or whether the project is providing the rental assistance) Housing Move-In Date must be between the Project Start Date and Project Exit Date. It may be the same date as Project Start if the client moves into housing on the date they were accepted into the program. There is a one-to-one relationship between this data element and 5.9 Household ID. Users must be able to edit data to correct errors. Other System Issues For purposes of the Housing Inventory Count and other point-in-time reporting, households with a Project Start date who do not have a Housing Move-In Date at the point in time must be excluded from counts of persons in permanent housing. With the addition of this data element to a wider variety of project types in the 2017 Data Standards, systems must retroactively add the data element for non-rrh projects and populate it with the existing 3.10 Project Start Date. This corresponds to the previous definition of Project Entry Date for non-rrh projects as the date the household moved into housing and enables longitudinal reporting, although the length of time to housing placement will not be valid for clients entering prior to October 1, <ResidentialMoveInDate> Enrollment 2017 V1 Changes Made Renamed from 4.17 Residential Move In Date Moved element from Project Specific to Universal Data Element Use of the element expanded to include all types of permanent housing. Retain all data that was formerly in element 4.17 Residential Move in Date (from RRH) in this new element and replicate data as instructed above Living Situation The former universal data elements 3.9 Residence Prior to Project Start and 3.17 Length of Time on the Streets, in an Emergency Shelter or in a Safe Haven were combined into one element Living Situation in 2014 v5. The element was split into two sub-elements which use only the fields and responses necessary for the population being asked the question A is to be used for all persons entering a Street Outreach, Emergency Shelter or Safe Haven project and 3.917B is to be used for persons entering all other HMIS project types. The internal HMIS field numbers for the fields and dependents of the sub-elements MUST be the same for like responses. With this separation and clarification, the definition of chronic homelessness as identified in the final rule in the Federal Register published December 5, 2015 is able to be fully reported through an HMIS. 35

40 3. 917A Living Situation For persons entering HMIS Project Type: Street Outreach, Emergency Shelter, & Safe Haven Field 1 & Responses Field 2 & Responses Living Situation (A) Type of Residence : HOMELESS SITUATION 16 Place not meant for habitation 1 Emergency shelter, including hotel or motel paid for with emergency shelter voucher 18 Safe Haven 27 Interim Housing : INSTITUTIONAL SITUATION 15 Foster care home or foster care group home 6 Hospital or other residential non-psychiatric medical facility 7 Jail, prison or juvenile detention facility 24 Long-term care facility or nursing home 4 Psychiatric hospital or other psychiatric facility 5 Substance abuse treatment facility or detox center : TRANSITIONAL AND PERMANENT HOUSING SITUATION 14 Hotel or motel paid for without emergency shelter voucher 23 Owned by client, no ongoing housing subsidy 21 Owned by client, with ongoing housing subsidy 3 Permanent housing (other than RRH) for formerly homeless persons 22 Rental by client, no ongoing housing subsidy 19 Rental by client, with VASH subsidy 25 Rental by client, with GPD TIP subsidy 20 Rental by client, with other housing subsidy (including RRH) 26 Residential project or halfway house with no homeless criteria 12 Staying or living in a family member s room, apartment or house 13 Staying or living in a friend s room, apartment or house 2 Transitional housing for homeless persons (including homeless youth) Length of stay in prior living situation 10 One night or less 11 Two to six nights 2 One week or more, but less than one month 3 One month or more, but less than 90 days 4 90 days or more, but less than one year 5 One year or longer 36

41 Field 3 & Responses Approximate date homelessness started: (date) [date field] Field 4 & Responses (Regardless of where they stayed last night) Number of times the client has been on the streets, in ES, or SH in the past three years including today 1 One Time 2 Two times 3 Three times 4 Four or more times Field 5 & Responses Total number of months homeless on the street, in ES, or SH in the past three years 101 One month (this time is the first month) (integers 2-12) 113 More than 12 months Universal Funder: Program-Component All Programs All Components which are typed as Street Outreach, Emergency Shelter or Safe Haven. Project Type Applicability 1: Emergency Shelter 4: Street Outreach 8: Safe Haven Data Collected About Head of Household and Adults Project Start This element, 3.917A is required for all projects which are typed in the HMIS as Emergency Shelter (either night by night or entry/exit method), Street Outreach, and Safe Haven. No substitution in language or form may be made in this element. Other System Issues This element requires no dependencies and all fields are to be visible and entered by the user. Collect once at each project start; there is a one-to-one relationship between this data element and 5.6 Enrollment ID. System stores collected information and retains for historical purpose. Users must be able to edit data to correct errors or to enter a response for a client who has turned 18. Responses to this data element must always reflect living situation and circumstances as of the Project Start Date and not at the time of collection. The data contained in this element must be mapped over in all HMIS implementations from the former 3.9 and 3.17 elements. The internal field numbers for each of the fields and dependents contained within this element MUST be the same as the field numbers used for 3.917B.* <Enrollment>< > 37

42 Enrollment 2017 V1 Changes Made Wording changes for Field 1 Response option 3 and 20 Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic B Living Situation For persons entering: Transitional Housing, any type of Permanent Housing, Services Only, Day Shelter, Homelessness Prevention, or Coordinated Entry Project The logic for 3.917B is also described in the flow chart in Exhibit 1 Field 1 & Responses Living Situation (B) Type of Residence : HOMELESS SITUATION 16 Place not meant for habitation 1 Emergency shelter, including hotel or motel paid for with emergency shelter voucher 18 Safe Haven 27 Interim Housing : INSTITUTIONAL SITUATION 15 Foster care home or foster care group home 6 Hospital or other residential non-psychiatric medical facility 7 Jail, prison or juvenile detention facility 24 Long-term care facility or nursing home 4 Psychiatric hospital or other psychiatric facility 5 Substance abuse treatment facility or detox center : TRANSITIONAL AND PERMANENT HOUSING SITUATION 14 Hotel or motel paid for without emergency shelter voucher 23 Owned by client, no ongoing housing subsidy 21 Owned by client, with ongoing housing subsidy 3 Permanent housing (other than RRH) for formerly homeless persons 22 Rental by client, no ongoing housing subsidy 19 Rental by client, with VASH subsidy 25 Rental by client, with GPD TIP subsidy 20 Rental by client, with other housing subsidy (including RRH) 26 Residential project or halfway house with no homeless criteria 12 Staying or living in a family member s room, apartment or house 13 Staying or living in a friend s room, apartment or house 2 Transitional housing for homeless persons (including homeless youth) 38

43 Field 2 & Responses Length of stay in the prior living situation 10 One night or less 11 Two to six nights 2 One week or more, but less than one month 3 One month or more, but less than 90 days 4 90 days or more, but less than one year 5 One year or longer 8 Client doesn't know DEPENDENCIES FOR INSTITUTIONAL SITUATIONS Field 2A for Institutional Did you stay less than 90 days? Situations Dependency Logic If No no other response options required. If Yes use Field #2 response options 10, 11, 2, 3 and go to Field 2C DEPENDENCIES FOR TRANSITIONAL and PERMANENT HOUSING SITUATIONS Field 2B for Housing Did you stay less than 7 nights? Situations Dependency Logic If No no other response options required. If Yes use Field #2 response options 10, 11, and go to Field 2C DEPENDENCY FOR YES TO 2A OR 2B Field 2C For yes to 2a or 2b On the night before did you stay on the streets, ES or SH Dependency Logic If No no other response options required. If Yes go to Field 3, followed by Field 4 and then Field 5 ELEMENTS FOR CHRONIC HOMELESSNESS Field 3 & Responses Approximate date homelessness started: (date) [date field] Field 4 & Response (Regardless of where they stayed last night) Number of times the client has been on the streets, in ES, or SH in the past three years including today 1 One Time 2 Two times 3 Three times 4 Four or more times 39

44 Field 5 & Responses Total number of months homeless on the street, in ES, or SH in the past three years 101 One month (this time is the first month) (integers 2-12) 113 More than 12 months Funder: Program-Component All Programs All Components Project Type Applicability 2: Transitional Housing 3: PH Permanent Supportive Housing (disability required for entry) 6: Services Only 7: Other 9: PH Housing Only 10: PH Housing with Services (no disability required for entry) 11: Day Shelter 12: Homelessness Prevention 13: PH: Rapid Re-housing 14: Coordinated Assessment Data Collected About Head of Household and Adults Project Start This element, 3.917B, is required for all projects which are typed in the HMIS as any project type other than Emergency Shelter (either night by night or entry/exit method), Street Outreach, and Safe Haven. No substitution in language or form may be made in this element. Collect once at each project start; there is a one-to-one relationship between this data element and 5.6 Enrollment ID. System stores collected information and retains for historical purpose. Element 3.917B may not be used by Emergency Shelter Street Outreach or Safe Haven projects in the HMIS. Other System Issues Users must be able to edit data to correct errors or to enter a response for a client who has turned 18. Responses to this data element must always reflect living situation and circumstances as of the Project Start Date and not at the time of collection. The data contained in this element must be mapped over in all HMIS implementations from the former 3.9 and 3.17 elements. The HMIS must be able to create dependencies for this element. Data for the fields of this data element should be logically consistent. It is strongly recommended that the HMIS is programmed to enforce these rules or to notify users when inconsistent data has been entered. If there is a yes response then the next response elements must be available for data entry. If there is any other response then the next response element must either be hidden or darkened or in some other way identified as not to be completed. 40

45 The internal field numbers for each of the fields and dependents contained within this element MUST be the same as the field numbers used for 3.917A <Enrollment>< > Enrollment 2017 V1 Changes Made Wording changes for Field 1 Response option 3 and 20 Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. PROGRAM SPECIFIC DATA ELEMENTS To meet the statutory and regulatory requirements of federally funded programs using HMIS, additional elements are required for different funding sources. The Program Specific Data Elements are elements that are designed and managed by at least one of the HMIS federal partner programs. Some of the program specific data elements are collected across most federal partner programs: these are called Common Program Specific Data Elements. The rest of the elements are limited to either a single federal partner program or a single component of one of the federal partner programs. An HMIS must have the ability to enable and restrict visibility of elements based on the funding needs of the program. An HMIS may do this in whatever manner they choose (hard coding, customization via system administrators, etc.). HMIS vendors should note that no federal partner expects that any project would have all elements visible to the user. The strong preference among the federal partners is that only the elements required for the programs that fund a specific project are visible to the users at that project. Program specific guidance issued through HUD and the individual federal partner in the HMIS Program Manuals provides program setup and visibility information and definitions relevant for the partner. 41

46 COMMON DATA ELEMENTS The HMIS Federal Partners have cooperatively developed these elements. For each Program-Specific Data Element, multiple response categories are provided. Projects may choose to capture more detailed information (or finer response categories) if this information can be exactly mapped to the required response categories described in this section. For reporting purposes, an HMIS must be able to produce required reports using the response categories exactly as they are presented in this section. 4.2 Income and Sources 4.3 Non-Cash Benefits 4.4 Health Insurance 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 In the 2017 HMIS Data Standards, Data Element 4.1 Housing Status was retired from use and 4.17 Residential Move-In Date was significantly modified and became universal data element 3.20 Housing Move-In Date. 4.2 Income and Sources Field 1 & Response Field 2 & Responses Income and Sources Information Date (date information was collected) [date field] Income from Any Source If yes for Income from any source Indicate all sources and dollar amounts for the source that apply Field 3 & Responses Earned income (i.e. employment income) Dependent A Dependent to Monthly Amount [currency/decimal] Field 3 & Response 1 Field 4 & Responses Unemployment Insurance 42

47 Dependent B Dependent to Monthly Amount [currency/decimal] Field 4 & Response 1 Field 5 & Responses Supplemental Security Income (SSI) Dependent C Dependent to Monthly Amount [currency/decimal] Field 5 & Response 1 Field 6 & Responses Social Security Disability Insurance (SSDI) Dependent D Dependent to Monthly Amount [currency/decimal] Field 6 & Response 1 Field 7 & Responses VA Service-Connected Disability Compensation Dependent E Dependent to Monthly Amount [currency/decimal] Field 7 & Response 1 Field 8 & Responses VA Non-Service-Connected Disability Pension Dependent F Dependent to Monthly Amount [currency/decimal] Field 8 & Response 1 Field 9 & Responses Private disability insurance Dependent G Dependent to Monthly Amount [currency/decimal] Field 9 & Response 1 Field 10 & Responses Worker s Compensation Dependent H Dependent to Monthly Amount [currency/decimal] Field 10 & Response 1 Field 11 & Responses Temporary Assistance for Needy Families (TANF) [or use local name] Dependent I Dependent to Monthly Amount [currency/decimal] Field 11 & Response 1 Field 12 & Responses General Assistance (GA) [or use local name] 43

48 Dependent J Dependent to Monthly Amount [currency/decimal] Field 12 & Response 1 Field 13 & Responses Retirement Income from Social Security Dependent K Dependent to Monthly Amount [currency/decimal] Field 13 & Response 1 Field 14 & Responses Pension or retirement income from a former job Dependent L Dependent to Monthly Amount [currency/decimal] Field 14 & Response 1 Field 15 & Responses Child support Dependent M Dependent to Monthly Amount [currency/decimal] Field 15 & Response 1 Field 16 & Responses Alimony and other spousal support Dependent N Dependent to Monthly Amount [currency/decimal] Field 16 & Response 1 Field 17 & Responses Other source Dependent O Dependent to Monthly Amount [currency/decimal] Field 17 & Response 1 Dependent P Dependent to If Yes for Other Source Field 17 & Response 1 Text box for Specify Source Field 18 & Response Total Monthly Income [.00] Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components except ES-nbn HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components HHS:RHY Collection only required for MGH, TLP and Demo VA:SSVF Collection required for all components VA:GPD Collection required for all components Project Type Applicability All HMIS Project Types 44

49 Data Collected About Heads of Households and Adults Project Start, Update, Annual Assessment, and Project Exit There is a many-to-one relationship between this data element and 5.6 Enrollment ID. The system must record the data collection stage for each record of this data element. Users are required to collect at project start, annual assessment, and project exit. Systems must allow users to create update records to document changes between required collection points. Allow corrections for data entry errors at all stages. Other System Issues Data for the fields of this data element should be logically consistent. It is recommended that the HMIS is programmed to enforce these rules or to notify users when inconsistent data has been entered. If there is a yes response to Income from any source then at least one source of income must be identified. If a source is identified, then a Monthly amount must be entered. If a Monthly amount is entered for any source, then a Total monthly income amount is required. If there is a no to Response 2 Income from any source then the HMIS must automatically record all sources as no and leave dollar amounts null or $0.00. Note: When a client has income, but does not know the exact amount, a Yes response should be recorded for both the overall income question and the specific source, and the income amount should be estimated. To reduce data collection and reporting burden Systems are encouraged to auto-calculate total monthly income to avoid mathematical errors and reduce data collection (generate a $0.00 for total monthly income if Income from any source = no ) If a client reports receiving income, an HMIS may be designed such that projects only need to directly enter yes for the income source the client receives and have the HMIS automatically generate a no response for the other income sources. The HMIS may facilitate data accuracy by automatically changing a no in income from any source to a yes if source(s) and dollar amount(s) are indicated. Updates are required for persons aging into adulthood. The income amounts recorded in an HMIS in Income and Sources do not necessarily equate to documentation of income for rent calculation purposes. A rental calculation may not be estimated and has additional sources. Vendors may elect to develop rent calculation tools but should not rely on the income and sources fields for calculations. <IncomeAndSources> IncomeBenefits 2017 V1 Changes Made Wording change: Corrected the name of Social Security Disability Insurance (Field 6) 45

50 4.3 Non-Cash Benefits Field 1 & Response Field 2 & Responses Non-Cash Benefits Information Date (date information was collected) [date field] Non-Cash Benefits from Any Source If yes for Non-cash benefits from any source Indicate all sources and dollar amounts for the source that apply Field 3 & Responses Supplemental Nutrition Assistance Program (SNAP) (Previously known as Food Stamps) Field 4 & Responses Special Supplemental Nutrition Program for Women, Infants, and Children (WIC) Field 5 & Responses TANF Child Care services (or use local name) Field 6 & Responses TANF transportation services (or use local name) Field 7 & Responses Other TANF-funded services Field 9 & Responses Other source Dependent A Dependent to If Yes for Other Source Field 9 & Response 1 Text box for Specify Source Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components except ES-nbn HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components 46

51 Project Type Applicability Data Collected About Other System Issues HHS:RHY Collection only required for BCP (HP and ES), MGH, TLP and Demo VA:SSVF Collection required for all components VA:GPD Collection required for all components All HMIS Project Types Heads of Households and Adults Project Start, Update, Annual Assessment, and Project Exit The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Data for the fields of this data element should be logically consistent. It is recommended that the HMIS is programmed to enforce these rules or to notify users when inconsistent data has been entered. If there is a yes response to Non-cash benefits from any source then at least one source of non-cash benefit must be identified. If there is a no response to Non-cash benefit from any source then the HMIS must automatically record all sources as no. To reduce data collection and reporting burden If a client reports receiving non-cash benefits, an HMIS may be designed such that projects only need to directly enter yes for the benefit source the client receives and have the HMIS automatically generate a no response for the other benefit sources. The HMIS may facilitate data accuracy by automatically changing a no in Receiving non-cash benefits from any source to a yes if source(s) are indicated. Updates are required for persons aging into adulthood. Non-cash benefits may be entered into more detailed categories as long as these categories can be aggregated into the above-stated non-cash benefits. Format clarification provided that each non-cash benefit source is its own field. <NonCashBenefits> IncomeBenefits 2017 V1 Changes Made Removed 2 fields and their respective no/yes response options: #8 Section 8, public housing, or rental assistance, and # 10 Temporary rental assistance 4.4 Health Insurance Field 1 & Response Field 2 & Responses Health Insurance Information Date (date information was collected) [date field] Covered by Health Insurance If yes for Covered by Health Insurance 47

52 Indicate all sources that apply Field 3 & Responses MEDICAID Field 4 & Responses MEDICARE Field 5 & Response State Children s Health Insurance Program (or use local name) Field 6 & Responses Veteran s Administration (VA) Medical Services Field 7 & Responses Employer Provided Health Insurance Field 8 & Responses Health Insurance obtained through COBRA Field 9 & Responses Private Pay Health Insurance Field 10 & Responses State Health Insurance for Adults (or use local name) Field 11 & Responses Indian Health Services Program Field 12 & Responses Other (if yes to other) Specify source) (text) Dependent A Dependent to If No for each of the health insurance sources no Fields 3-11 & Response 0 Reason HOPWA FIELD ONLY 1 Applied; decision pending 2 Applied; client not eligible 3 Client did not apply 4 Insurance type N/A for this client 48

53 Program Specific Funder: Program-Component HUD: CoC Collection required for all components HUD:ESG Collection required for all components except ES-nbn HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components HHS:RHY Collection required for all components VA:SSVF Collection required for all components VA:GPD Collection required for all components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start, Update, Annual Assessment, and Project Exit The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues Data for the fields of this data element should be logically consistent. It is recommended that the HMIS is programmed to enforce these rules or to notify users when inconsistent data has been entered. If there is a yes response to Covered by health insurance then at least one source of health insurance must be identified. If there is a no response to Covered by health insurance then the HMIS must automatically record all sources as no". To reduce data collection and reporting burden If a client reports Covered by health insurance as yes an HMIS may be designed such that projects only need to directly enter yes for the health insurance received. The HMIS may automatically generate a no response for the other non-cash benefit sources. The HMIS may facilitate data accuracy by automatically changing a no in Covered by health insurance to a yes if source(s) are indicated. <HealthInsurance> IncomeBenefits 2017 V1 Changes Made None 4.5 Physical Disability Field 1 & Response Field 2 & Responses Physical Disability Information Date (date information was collected) [date field] Physical Disability 49

54 If Yes for Physical Disability Dependent A Dependent to Expected to be of long continued and indefinite duration and substantially Field 2 & Response 1 impairs ability to live independently Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components HHS: RHY Collection required for all components VA:SSVF No component requires data collection VA:GPD Collection required for all components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start, Update, and Project Exit Collect at project start and project exit. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues HMIS may choose to only display dependent questions if user selects the appropriate response. <Disabilities> Disabilities 2017 V1 Changes Made Removed dependent elements: Documentation of disability and severity on file, and Currently receiving services/treatment for this disability. 4.6 Developmental Disability Field 1 & Response Field 2 & Responses Developmental Disability Information Date (date information was collected) [date field] Developmental Disability 50

55 Dependent A Dependent to Field 2 & Response 1 If Yes for Developmental Disability Expected to substantially impair ability to live independently Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components HHS: RHY Collection required for all component VA:SSVF No component requires data collection VA:GPD Collection required for all component Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start, Update, and Project Exit Collect at project start and project exit. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues HMIS may choose to only display dependent questions if user selects the appropriate response. <Disabilities> Disabilities 2017 V1 Changes Made Removed dependent elements: Documentation of disability and severity on file, and Currently receiving services/treatment for this disability. 4.7 Chronic Health Condition Field 1 & Response Field 2 & Responses Chronic Health Condition Information Date (date information was collected) [date field] Chronic Health Condition 51

56 If Yes for Chronic Health Condition Dependent A Dependent to Expected to be of long continued and indefinite duration and substantially Field 2 & Response 1 impairs ability to live independently Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components HHS: RHY Collection required for all components VA:SSVF No component requires data collection VA:GPD Collection required for all components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start, Update, and Project Exit Collect at project start and project exit. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues HMIS may choose to only display dependent questions if user selects the appropriate response. <Disabilities> Disabilities 2017 V1 Changes Made Removed dependent elements: Documentation of disability and severity on file, and Currently receiving services/treatment for this disability. 4.8 HIV/AIDS Field 1 & Response Field 2 & Response HIV/AIDS Information Date (date information was collected) [date field] HIV/AIDS 52

57 Dependent A Dependent to Field 2 & Response 1 If Yes for HIV/AIDS Expected to substantially impair ability to live independently Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components VA:SSVF No component requires data collection VA:GPD Collection required for all components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start, Update, and Project Exit Collect at project start and project exit. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues HMIS may choose to only display dependent questions if user selects the appropriate response. <Disabilities> Disabilities 2017 V1 Changes Made Removed dependent elements: Documentation of disability and severity on file, and Currently receiving services/treatment for this disability. 4.9 Mental Health Problem Field 1 & Response Field 2 & Response Mental Health Problem Information Date (date information was collected) [date field] Mental Health Problem 53

58 If Yes for Mental Health Problem Dependent A Dependent to Expected to be of long continued and indefinite duration and substantially Field 2 & Response 1 impairs ability to live independently Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components HHS: RHY Collection required for all components VA:SSVF No component requires data collection VA:GPD Collection required for all components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start, Update, and Project Exit Collect at project start and project exit. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues HMIS may choose to only display dependent questions if user selects the appropriate response. <Disabilities> Disabilities 2017 V1 Changes Made Removed dependent elements: Documentation of disability and severity on file, and Currently receiving services/treatment for this disability. Additionally, removed PATH ONLY dependent D and E if yes responses that PATH no longer requires Substance Abuse Field 1 & Response Substance Abuse Information Date (date information was collected) [date field] 54

59 Field 2 & Responses Dependent A Dependent to Field 2 & Response(s) 1-3 Substance Abuse Problem 1 Alcohol abuse 2 Drug abuse 3 Both alcohol and drug abuse If Alcohol abuse, Drug abuse, or Both alcohol and drug abuse for Substance Abuse Problem Expected to be of long continued and indefinite duration and substantially impairs ability to live independently Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components HHS:PATH Collection required for all components HHS: RHY Collection required for all components VA:SSVF No component requires data collection VA:GPD Collection required for all components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start, Update, and Project Exit Collect at project start and project exit. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues HMIS may choose to only display dependent questions if user selects the appropriate response. <Disabilities> Disabilities 2017 V1 Changes Made Removed dependent elements: Documentation of disability and severity on file, and Currently receiving services/treatment for this disability. Additionally, removed PATH ONLY dependent D if both /how confirmed responses that PATH no longer requires. 55

60 4.11 Domestic Violence Field 1 & Response Field 2 & Responses Dependent A Dependent to Field 2 & Response 1 Dependent B Dependent to Field 2 & Response 1 Domestic Violence Information Date (date information was collected) [date field] Domestic Violence Victim/Survivor If Yes for Domestic Violence Victim/Survivor When experience occurred 1 Within the past three months 2 Three to six months ago (excluding six months exactly) 3 Six months to one year ago (excluding one year exactly) 4 One year ago or more If Yes for Domestic Violence Victim/Survivor Are you currently fleeing? Program Specific Funder: Program-Component HUD:CoC Collection required for all components HUD:ESG Collection required for all components HUD:HOPWA Collection required for all components HUD:HUD-VASH - Collection required for all components HUD:PFS Collection required for all permanent housing projects HUD:RHSAP - Collection required for all components VA:SSVF No component requires data collection VA:GPD Collection required for all components Project Type Applicability Data Collected About All HMIS Project Types Head of Household and Adults Project Start, Update The system must record the appropriate collection stage for each element. Allow corrections for data entry errors at all stages. Data are time sensitive and may change over the project stay. System must allow for updated information collection if change occurs, must record the date 56

61 the information was collected with a data collection stage of project update, and must retain all updates for historical purpose. Other System Issues None <DomesticViolence> HealthAndDV 2017 V1 Changes Made None 4.12 Contact Contact Field 1 & Response Information Date (date of contact) [date field] Field 2 & Responses Staying on Streets, ES, or SH 2 Worker unable to determine Program Specific Funder: Program-Component HUD:CoC Collection only required for Street Outreach HUD:ESG Collection only required for Street Outreach and ES - nbn HHS:PATH Collection required for all components HHS: RHY Collection only required for Street Outreach Project Type Applicability 1:Emergency Shelter night by night method only 4:Street Outreach 6:Services Only Data Collected About Head of Household and Adults Occurrence Point (At the Time of Contact) The data in this element are transactional data; each time there is a contact a record of the contact must be recorded and including the date and the homeless status. There is a many-to-one relationship between this data element and 5.6 Enrollment ID. Other System Issues The first contact would be the contact made at project start. A contact would be expected to be made on the date of engagement. There may or may not be a contact made at project exit. One record of contact is required as an update for each contact made along with the response to Field 2 which may change over the project stay. <ServiceFAReferral> Services 2017 V1 Changes Made Field 2 and responses changed from Location of Contact to Staying on Streets, ES or SH 4.13 Date of Engagement Date of Engagement 57

62 Field 1 & Response Date of Engagement (date) [date field] Program Specific Funder: Program-Component HUD:CoC Collection only required for Street Outreach HUD:ESG Collection only required for Street Outreach and ES - nbn HHS:PATH Collection required for all components HHS: RHY Collection only required for Street Outreach Project Type Applicability 1:Emergency Shelter night by night method only 4:Street Outreach 6:Services Only Data Collected About Head of Household and Adults Occurrence Point (At the Point of Engagement) Only one date of engagement is allowed between the project start date and project exit date. There is a one-to-one relationship between this data element and 5.6 Enrollment ID. Other System Issues If a client returns to the project at a later date the previous date of engagement does not apply to the new project stay. The data must be reentered based on the situation during the new project stay. It is possible that a case may be closed without the client becoming engaged and thus null in that client record. <Enrollment> Enrollment 2017 V1 Changes Made Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic Bed-night Date Bed-night Date Field 1 & Response Bed-night Date (date) [date field] Program Specific Funder: Program-Component HUD: ESG Collection required for ES - nbn Project Type Applicability 1: Emergency Shelter - nbn method (Applicability extends to all nbn method shelters that are not funded through ESG but also participate in HMIS.) Data Collected About All Clients Occurrence Point (As Provided) Collect once for each bed night utilized. Other System Issues A bed night date indicates that the client has utilized a bed in a night-by-night shelter on that date. The system must be able to store a theoretically unlimited number of bed night dates for any Enrollment ID associated with a night-bynight shelter. There must be a record of a bed night on the project start date into the shelter; any additional bed night dates must be after the project start date and before the project exit date. 58

63 The bed-night date must be exportable in the [date field] format. <ServiceFAReferral> Services 2017 V1 Changes Made Renumbered formerly 4.14E No other changes made Housing Assessment Disposition Housing Assessment Disposition Field 1 & Responses Assessment Disposition 1 Referred to emergency shelter/safe haven 2 Referred to transitional housing 3 Referred to rapid re-housing 4 Referred to permanent supportive housing 5 Referred to homelessness prevention 6 Referred to street outreach 7 Referred to other continuum project type 8 Referred to a homelessness diversion program 9 Unable to refer/accept within continuum; ineligible for continuum projects 10 Unable to refer/accept within continuum; continuum services unavailable 11 Referred to other community project (non-continuum) 12 Applicant declined referral/acceptance 13 Applicant terminated assessment prior to completion 14 Other/specify Dependent A Dependent to If Other/ specify for Assessment Disposition Field 1 & Response 14 Text box Program Specific Funder: Program-Component HUD: CoC Collection required for all components which provide Coordinated Assessment HUD: ESG Collection required for all components which provide Coordinated Assessment VA: SSVF Collection required for all components which provide Coordinated Assessment VA: GPD Collection required for all components which provide Coordinated Assessment Project Type Applicability 14: Coordinated Assessment (or other depending on CoC design of Coordinated Assessment system) Data Collected About Head of Household Project Exit Collect once at or by project exit or when the information is known. System stores collected information as project exit information and retains for historical purpose. Other System Issues Unknown 59

64 <HousingAssessmentDisposition> Exit 2017 V1 Changes Made None INDIVIDUAL FEDERAL PARTNER PROGRAM ELEMENTS These elements are listed under the federal partner program which maintains the element. There are elements maintained by one partner and shared with one other. When combined with UDE s and Common Elements these elements form the basis of data collection requirements for specific project level reporting generated by an HMIS. 60

65 CoC Program Element Visibility Collection Requirements The elements shown are only those in which at least one CoC program component is required to collect information. Program Specific Components and Project Types Component Project Type # Project Type Name Homelessness Prevention (High Performing Communities Only) 12 Homelessness Prevention Permanent Housing PSH 3 PH PSH (disability required) Permanent Housing -RRH 13 PH - Rapid Re-Housing Supportive Services Only Refer to CoC Program HMIS Manual Transitional Housing 2 Transitional Housing Legacy Safe Haven*** 8 Safe Haven Legacy SRO**** 9 PH-Housing Only Program Specific Visibility Collection Requirements Number Element Homelessness Prevention Permanent Supportive Housing Rapid Re- Housing Supportive Services Only Transitional Housing 4.2 Income and Sources x x x x x 4.3 Non-Cash Benefits x x x x x 4.4 Health Insurance x x x x x 4.5 Physical Disability x x x x x 4.6 Developmental Disability x x x x x 4.7 Chronic Health Condition x x x x x 4.8 HIV/AIDS x x x x x 4.9 Mental Health Problem x x x x x 4.10 Substance Abuse x x x x x 4.11 Domestic Violence x x x x x 4.12 Contact 4.13 Date of Engagement * 4.18 Housing Assessment Disposition CA CA CA CA CA W5 Housing Assessment at Exit x ***Data collection for Safe Haven Use ESG Emergency Shelter nbn ****Data collection for SRO Use CoC PSH X = data collection is required * = data collection is required only for Supportive Services Only - Street Outreach projects CA = data collection is determined by how the CoC has structured the coordinated assessment in their area. Placement of the element would be required for any project that is conducting a coordinated assessment. This may be across multiple projects or sited in a central access point or coordinated intake center. * 61

66 ESG Program Element Visibility Collection Requirements The elements shown are only those in which at least one ESG program component is required to collect information. Program Specific Components and Project Types Component Project Type # Project Type Name Emergency Shelter (operating and/or essential services) 1 Emergency Shelter Homelessness Prevention 12 Homelessness Prevention Rapid Rehousing 13 PH - Rapid Re-Housing Street Outreach 4 Street Outreach Program Specific Visibility Collection Requirements Number Element ESG e/e ESG nbn Homelessness Prevention RRH Street Outreach UDE All Universal Data Elements x x x x x 4.2 Income and Sources x x x x 4.3 Non-Cash Benefits x x x x 4.4 Health Insurance x x x x 4.5 Physical Disability x x x x x 4.6 Developmental Disability x x x x x 4.7 Chronic Health Condition x x x x x 4.8 HIV/AIDS x x x x x 4.9 Mental Health Problem x x x x x 4.10 Substance Abuse x x x x x 4.11 Domestic Violence x x x x x 4.12 Contact x x 4.13 Date of Engagement x x 4.14 Bed Night x 4.18 Housing Assessment Disposition CA CA CA CA CA W5 Housing Assessment at Exit x X = data collection is required CA = data collection is determined by how the CoC has structured the coordinated assessment in their area. Placement of the element would be required for any project that is conducting a coordinated assessment. This may be across multiple projects or sited in a central access point or coordinated intake center. 62

67 HOPWA Program Element Visibility Collection Requirements The elements shown are only those in which at least one HOPWA program component is required to collect information. Program Specific Components and Project Types Component Project Type # Project Type Name Hotel/Motel 1 Emergency Shelter Short Term Housing 1 Emergency Shelter Housing Information 6 Services Only Permanent Housing TBRA 3 PH Permanent Supportive Housing Permanent Housing Facility Based 3 PH Permanent Supportive Housing Permanent Housing Placement (PHP) 6 Services Only Short Term Rent, Mortgage, Utility Assistance (STRMU) 12 Homelessness Prevention Transitional Housing (TH) 2 Transitional Housing Supportive Services Only not in conjunction with housing (SSO) 6 Services Only ** If the project is only funded to provide services (e.g. case management only) refer to the Supportive Services Only description in the CoC Program HMIS Manual to assist in the determination of project typing. Program Specific Visibility Collection Requirements Number Element Hotel/ Motel Short Term Housing Housing Info Permanent Housing TBRA Fac. Based PHP STRMU TH SSO UDE All Universal Data Elements x x x x x x x x 4.2 Income and Sources x x x x x x x x 4.3 Non-Cash Benefits x x x x x x x x 4.4 Health Insurance x x x x x x x x 4.5 Physical Disability x x x x x x x x 4.6 Developmental Disability x x x x x x x x 4.7 Chronic Health Condition x x x x x x x x 4.8 HIV/AIDS x x x x x x x x 4.9 Mental Health Problem x x x x x x x x 4.10 Substance Abuse x x x x x x x x 4.11 Domestic Violence x x x x x x x x W1 Services Provided - HOPWA x x x x x x x x W2 Financial Assistance Provided - HOPWA x x W3 Medical Assistance x x x x x x x x W4 T-cell (CD4) and Viral Load x x x x x x x x W5 Housing Assessment at Exit x x x x x x x x X = data collection is required 63

68 HUD-HOPWA Required Elements W1 W2 W3 W4 W5 Services Provided HOPWA Financial Assistance HOPWA Medical Assistance T-cell (CD4) and Viral Load Housing Assessment at Exit W1 Services Provided HOPWA Services Provided - HOPWA Field 1 & Response Date of Service (date) [date field] Field 2 & Responses Type of Service 1 Adult day care and personal assistance 2 Case management 3 Child care 4 Criminal justice/legal services 5 Education 6 Employment and training services 7 Food/meals/nutritional services 8 Health/medical care 9 Life skills training 10 Mental health care/counseling 11 Outreach and/or engagement 12 Substance abuse services/treatment 13 Transportation 14 Other HOPWA funded service Program Specific Funder: Program-Component HUD: HOPWA Collection required for all components Project Type Applicability 1: Emergency Shelter e/e method 2: Transitional Housing 3: PH-Permanent Supportive Housing 6: Services Only 12: Homelessness Prevention Data Collected About All Clients receiving services Occurrence Point (As Provided) Note: HOPWA requires that all stayers at the end of their annual operating year and prior to the generation of their Annual Report (CAPER or APR) enter all services provided through the end of the operating year. Data are time sensitive and may change over the project stay. System must allow for multiple records per project stay to record each instance and must record the date the service was provided. 64

69 Other System Issues The data in this element are transactional data; each time the service is delivered a record of the date of service and the service element must be maintained. If service benefits entire household, it may be recorded solely for the Head of Household. <ServiceFAReferral> Services 2017 V1 Changes Made Renumbered formerly 4.14C No other changes made. W2 Financial Assistance HOPWA Financial Assistance - HOPWA Field 1 & Response Date of Financial Assistance (date) [date field] Field 2 & Responses Financial Assistance Type 1 Rental assistance [collect for PHP and STRMU and PH-TBRA] 2 Security deposits [collect for PHP] 3 Utility deposits [collect for PHP] 4 Utility payments [collect for PHP and STRMU] 7 Mortgage assistance [collect for STRMU] Field 3 & Response Financial Assistance Amount (amount) Program Specific Funder: Program-Component HUD: HOPWA- Collection required for PHP and STRMU only as indicated above Project Type Applicability 6: Services Only 12: Homelessness Prevention Data Collected About Head of Household Occurrence Point (As Provided) Data are time sensitive and may change over the project stay. System must allow for multiple records per project stay to record each instance and must record the date the financial assistance was provided. Other System Issues The data in this element are transactional data; each time there is financial assistance provided a record of the assistance must be recorded including the date and financial assistance information. Records of financial assistance should be attached to the Head of Household. <ServiceFAReferral> Services 2017 V1 Changes Made Renumbered formerly 4.15A No other changes made. W3 Medical Assistance Field 1 & Response Medical Assistance Information Date (date information was collected) [date field] 65

70 Field 2 & Responses Receiving Public HIV/AIDS Medical Assistance Dependent A Dependent to If No for Receiving Public HIV/AIDS Medical Assistance Field 2 and Response 0 Reason 1 Applied; decision pending 2 Applied; client not eligible 3 Client did not apply 4 Insurance type N/A for this client Field 3 & Responses Receiving AIDS Drug Assistance Program (ADAP) Dependent B Dependent to If No for Receiving AIDS Drug Assistance Program (ADAP) Field 3 & Response 0 Reason 1 Applied; decision pending 2 Applied; client not eligible 3 Client did not apply 4 Insurance type N/A for this client Program Specific Funder: Program-Component HUD: HOPWA Collection required for all components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 3: PH-Permanent Supportive Housing 6: Services Only 12: Homelessness Prevention Data Collected About All Household Members with HIV/AIDS Project Start, Update, Project Exit The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. 66

71 Other System Issues None <MedicalAssistance> IncomeBenefits 2017 V1 Changes Made Renumbered formerly 4.39 No other changes made. W4 T-cell (CD4) and Viral Load T-cell (CD4) and Viral Load Field 1 & Response Information Date (date information was collected) [date field] Field 2 & Responses T-Cell (CD4) Count Available Dependent A Dependent to If a yes to T-Cell (CD4) Count Available then Field 2 & Response 1 T-cell Count (integer between ) Dependent B - Dependent to If a number is entered in the T-Cell (CD4) count then Dependent A & Response How was the information obtained 1 Medical Report 2 Client report 3 Other Field 3 & Responses Viral Load Information Available t Available 1 Available 2 Undetectable Dependent A Dependent to If Viral Load Information Available then Field 3 & Response 1 Count (integer between ) Dependent B - Dependent to If a number is entered in the Viral Load count then Dependent A & Response 2 How was the information obtained 1 Medical Report 2 Client report 3 Other Program Specific Funder: Program-Component HUD: HOPWA Collection required for all component Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 3: PH-Permanent Supportive Housing 67

72 Data Collected About Other System Issues 6: Services Only 12: Homelessness Prevention Only Clients funded in a HOPWA project presenting with HIV/AIDS Project Start, Update, Annual Assessment, Project Exit Collect at project start and project exit. Data should be updated every 6 months following project start thru to project exit and at a minimum at Annual Assessment. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. It is recommended that an HMIS only display this question as dependent to HMIS Data Standards Element 4.8 (HIV/AIDS) where the response is yes (1). If possible the system should limit the numeric range of the viral load information available response option 1 available to 21 to 999,999 as a response of 20 or less is associated with an undetectable viral load. <Disabilities> Disabilities 2017 V1 Changes Made Renumbered formerly 4.47 No other changes made. W5 Housing Assessment at Exit Field 1 & Responses Housing Assessment at Exit Housing Assessment at Exit 1 Able to maintain the housing they had at project entry 2 Moved to new housing unit 3 Moved in with family/friends on a temporary basis 4 Moved in with family/friends on a permanent basis 5 Moved to a transitional or temporary housing facility or program 6 Client became homeless moving to a shelter or other place unfit for human habitation 7 Client went to jail/prison 10 Client died Dependent A Dependent to If Able to maintain the housing they had at project entry for Housing Field 1 & Response 1 Assessment at Exit Subsidy information 1 Without a subsidy 2 With the subsidy they had at project entry 3 With an on-going subsidy acquired since project entry 4 Only with financial assistance other than a subsidy 68

73 Dependent B Dependent to If Moved to new housing unit for Housing Assessment at Exit Field 1 & Response 2 Subsidy information 1 With on-going subsidy 2 Without an on-going subsidy Program Specific Funder: Program-Component HUD: CoC Collection required only for Homelessness Prevention component HUD: ESG Collection required only for Homelessness Prevention component HUD: HOPWA Collection required for all components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 3: PH-Permanent Supportive Housing 6: Services Only 12: Homelessness Prevention Data Collected About All Clients Project Exit Collect once at each project exit. System stores collected information as project exit information and retains for historical purpose. Other System Issues None <ExitHousingAssessment> Exit 2017 V1 Changes Made None 69

74 PATH Program Element Visibility Collection Requirements The elements shown are only those in which at least one PATH program component is required to collect information Program Specific Components and Project Types Component (Population Focus) Project Type # Project Type Name Street Outreach (Persons who generally reside in a place not meant for human habitation (e.g. streets, abandoned buildings, etc.) Supportive Services (Persons who generally reside in a place meant for human habitation, or who are at risk of homelessness) 4 Street Outreach 6 Services Only Program Specific Visibility Collection Requirements Number Element Street Outreach Services Only UDE All Universal Data Elements x x 4.2 Income and Sources x x 4.3 Non-Cash Benefits x x 4.4 Health Insurance x x 4.5 Physical Disability x x 4.6 Developmental Disability x x 4.7 Chronic Health Condition x x 4.8 HIV/AIDS 4.9 Mental Health Problem x x 4.10 Substance Abuse x x 4.12 Contact x x 4.13 Date of Engagement x x P1 Services Provided - PATH Funded x x P2 Referrals Provided - PATH x x P3 Path Status x x P4 Connection with SOAR x x X = data collection required = data collection is optional at the discretion of the grantee 70

75 HHS-PATH Only Required Elements P1 P2 P3 P4 Services Provided PATH Funded Referrals Provided - PATH PATH Status Connection with SOAR P1 Services Provided PATH Funded Services Provided PATH Funded Field 1 & Response Date of Service (date) [date field] Field 2 & Responses Type of PATH FUNDED Service Provided 1 Re-engagement 2 Screening 14 Clinical assessment 3 Habilitation/rehabilitation 4 Community mental health 5 Substance use treatment 6 Case management 7 Residential supportive services 8 Housing minor renovation 9 Housing moving assistance 10 Housing eligibility determination 11 Security deposits 12 One-time rent for eviction prevention Program Specific Funder: Program-Component HHS: PATH Collection required for all components Project Type Applicability PATH: 4: Street Outreach 6: Services Only Data Collected About Head of Household and Adults Occurrence Point (As Provided) Data are time sensitive and may change over the project stay. System must allow for multiple records per project stay to record each instance and must record the date the service was provided. Other System Issues The data in this element are transactional data; each time the service is delivered a record of the date of service and homeless status of the client must be added. If a service benefits the entire household, it must be recorded for the Head of Household. PATH only records services that are PATH funded. If providers want to collect other services, then a separate element must be created to distinguish PATH funded services from non-path funded services. PATH reports will only include persons who received services who are enrolled. <ServiceFAReferral> Services 71

76 2017 V1 Changes Made Renumbered formerly 4.14A No other changes made. P2 Referrals Provided PATH Referrals Provided PATH Field 1 & Response Date of Referral (date) [date field] Field 2 & Responses Type of Referral 1 Community Mental Health 2 Substance Use Treatment 3 Primary Health/ Dental Care 4 Job Training 5 Educational Services 6 Housing Services 11 Temporary Housing 7 Permanent Housing 8 Income Assistance 9 Employment Assistance 10 Medical Insurance Dependent A Dependent to If any Type of Referral made Field 2 & Responses 1-10 Select Outcome for each 1 Attained 2 Not attained 3 Unknown Program Specific Funder: Program-Component HHS: PATH Collection required for all components Project Type Applicability 4: Street Outreach 6: Services Only Data Collected About Heads of Household and Adults Occurrence Point (As Provided) Data are time sensitive and may change over the project stay. System must allow multiple records per project stay to record each instance and must record the date the referral was provided. Other System Issues The data in this element are transactional data; each time there is a referral a record of the referral must be recorded. Multiple types of the same referral may be made over the course of project enrollment. Each referral should have an outcome response. Referral outcome is being shown as a dependent response. However, the responses of attained, not attained, or unknown may have better ways of presentation for data collection than as dependent fields as the response may not be known simultaneous with identification of the referral. Vendors may elect means other than a dependent field to improve data quality. The information is required on reporting. 72

77 PATH only will report on persons who received services who are enrolled. <ServiceFAReferral> Services 2017 V1 Changes Made Renumbered formerly 4.16A Collection of data related to referrals to job training, educational services, and housing services were optional response options and are now required. P3 PATH Status PATH Status Field 1 & Response Date of Status Determination (date) [date field] Field 2 & Responses Client Became Enrolled in PATH Dependent A Dependent to If No for Client Became Enrolled in PATH Field 2 & Response 0 Reason not enrolled 1 Client was found ineligible for PATH 2 Client was not enrolled for other reason(s) Program Specific Funder: Program-Component HHS: PATH Collection required for all components Project Type Applicability 4: Street Outreach 6: Services Only Data Collected About Head of Household and Adults Occurrence Point (At Determination; collect once, at or before exit, when the status is determined) Collect once at or before each project exit. System stores collected information and retains for historical purpose. Other System Issues Only one PATH status date and response is allowed for each project stay. If a client exits and returns to the project later, the previously entered enrollment data does not apply and a new response must be entered based on this new project start and project exit service period. If the HMIS supports requiring elements, then this element and its dependent response should be required for PATH at project exit and the client should not be able to be exited without a response to this element. This element is critical to PATH reporting. <PATHStatus> Enrollment 2017 V1 Changes Made Renumbered formerly 4.20 No other changes made. 73

78 P4 Connection with SOAR Connection with SOAR Field 1 & Responses Connection with SOAR Program Specific Funder: Program-Component HHS: PATH Collection required for all components VA: SSVF all components Project Type Applicability PATH: 4: Street Outreach 6: Services Only SSVF: 12 Homelessness Prevention 13 PH-RRH Data Collected About Head of Household and Adults Project Start, Update, Annual Assessment and Exit The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues If the SOAR program is locally available CoC s may find this element helpful to their CoCs for implementation in programs other than PATH. <ConnectionWithSOAR> Exit 2017 V1 Changes Made Renumbered formerly 4.21 Element now shared with VA SSVF which requires collection on it for both their Homelessness Prevention and Rapid Re-Housing projects 74

79 Pay for Success (PFS) Program Element Visibility Collection Requirements The elements shown are only those in which at least one PFS program component is required to collect information Program Specific Components and Project Types Component Project Type # Project Type Name Permanent Housing 10 PH Housing with Services (no disability required for entry) Program Specific Visibility Collection Requirements Number Element Permanent Housing 4.2 Income and Sources x 4.3 Non-Cash Benefits x 4.4 Health Insurance x 4.5 Physical Disability x 4.6 Developmental Disability x 4.7 Chronic Health Condition x 4.8 HIV/AIDS x 4.9 Mental Health Problem x 4.10 Substance Abuse x 4.11 Domestic Violence x 4.18 Housing Assessment Disposition CA X = data collection is required CA = data collection is determined by how the CoC has structured the coordinated assessment in their area. Placement of the element would be required for any project that is conducting a coordinated assessment. This may be across multiple projects or sited in a central access point or coordinated intake center. 75

80 RHY Program Element Visibility Collection Requirements The elements shown are only those in which at least one RHY program component is required to collect information Program Specific Components and Project Types Component Project Type # Project Type Name Basic Center Project (which provides shelter) 1 Emergency Shelter Basic Center Project (which also provides preventative services instead of or prior to shelter) 12 Homelessness Prevention Maternal Group Home 2 Transitional Housing Street Outreach Program 4 Street Outreach Transitional Living Program 2 Transitional Housing RHY Demonstration Program Specific Visibility Collection Requirements Number Element Determination based on funding opportunity BCP es BCP - p MGH SOP TLP DEMO UDE All Universal Data Elements x x x x x x 4.2 Income and Sources x x x 4.3 Non-Cash Benefits x x x x x 4.4 Health Insurance x x x x x x 4.5 Physical Disability x x x x x x 4.6 Developmental Disability x x x x x x 4.7 Chronic Health Condition x x x x x x 4.9 Mental Health Problem x x x x x x 4.10 Substance Abuse x x x x x x 4.12 Contact x 4.13 Date of Engagement x R1 Referral Source x x x x x R2 RHY: BCP Status x x R3 Sexual Orientation x x x x x x R4 Last Grade Completed x x x x x R5 School Status x x x x x R6 Employment Status x x x x x R7 General Health Status x x x x x R8 Dental Health Status x x x x x R9 Mental Health Status x x x x x R10 Pregnancy Status x x x x x x R11 Formerly a Ward of Child Welfare/Foster Care Agency x x x x x R12 Formerly a Ward of Juvenile Justice System x x x x x R13 Family Critical Issues x x x x x R14 RHY Service Connections x x x x x R15 Commercial Sexual Exploitation/Sex Trafficking x x x x x x 76

81 Number Element BCP BCP es - p MGH SOP TLP DEMO R16 Labor Trafficking x x x x x x R17 Project Completion Status x x x x R18 Counseling x x x x x R19 Safe and Appropriate Exit x x x x x R20 Aftercare x x x x x HHS-RHY Only Required Elements X = data collection is required R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16 R17 R18 R19 R20 Referral Source RHY-BCP Status Sexual Orientation Last Grade Completed School Status Employment Status General Health Status Dental Health Status Mental Health Status Pregnancy Status Formerly a Ward of Child Welfare/Foster Care Agency Formerly a Ward of Juvenile Justice System Family Critical Issues RHY Service Connections Commercial Sexual Exploitation/Trafficking Labor Exploitation/Trafficking Project Completion Status Counseling Safe and Appropriate Exit Aftercare Plans In the 2017 HMIS Data Standards, Data Element 4.16B Referral Provided - RHY and 4.38 Family Unification Achieved were both retired from use by RHY. Please note: All unaccompanied youth are their own Head of Household. The term unaccompanied youth has been removed from the Data Dictionary as it was redundant and confusing at times. There are occasions where one or more youth present together at project start, in these cases each youth should be in their own household and therefore will be their own head of household with data collected about them as appropriate to the project they are entering. Note: In 2017 HUD funded 10 Youth Homeless Demonstration Programs (YHDP) across the country. These programs, locally and nationally, may elect to use some of the RHY elements to more fully understand the population and factors necessary for ending youth homelessness. HMIS systems must allow the RHY elements to be utilized by YHDP programs as they are developed. Local HMIS Administrators of the YHDP communities will be involved in planning and training efforts to fully understand the use of these elements in this way. 77

82 R1 Referral Source Field 1 & Responses Dependent A Dependent to Field 1 & Response 7 Referral Source Referral Source 1 Self-Referral 2 Individual: Parent/Guardian/Relative/Friend/Foster Parent/Other Individual 7 Outreach Project 11 Temporary Shelter 18 Residential Project: 28 Hotline: 30 Child Welfare/CPS 34 Juvenile Justice 35 Law Enforcement/ Police 37 Mental Hospital 38 School 39 Other Organization If Outreach Project: FYSB for Referral Source is selected Number of times approached by outreach prior to entering the project (Box for integer response) Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Other System Issues None <EntryRHY> Enrollment 2017 V1 Changes Made Renumbered formerly 4.34 Response options were streamlined and decreased to reduce data collection burden. Previous responses entered are required to be mapped to these new more streamlined responses (Field numbers from 2014 were maintained for mapping and tracking purposes) 78

83 R2 RHY BCP Status RHY BCP Status Field 1 & Response Date of Status Determination (date) [date field] Field 2 & Responses Youth Eligible for RHY Services Dependent A Dependent to If No for Youth Eligible for RHY Services Field 2 & Response 0 Reason why services are not funded by BCP grant 1 Out of age range 2 Ward of the State Immediate Reunification 3 Ward of the Criminal Justice System Immediate Reunification 4 Other Dependent B Dependent to If Yes for Youth Eligible for RHY Services Field 2 & Response 1 Runaway youth 99 Data Not Collected Program Specific Funder: Program-Component HHS: RHY Collection required for BCP only Project Type Applicability 1: Emergency Shelter e/e method 12: Homelessness Prevention Data Collected About All Clients Project Start Collect once. System stores collected information as update information and retains for historical purpose. Other System Issues Only one RHY status date and only one response for FYSB Youth is allowed for each project stay. If a client returns to the project at a later date the previous data does not apply and must be entered based on this project start and project exit date service period. Youth who identify as no to FYSB Youth are also not homeless under the HUD definition of homelessness. Therefore, these youths should be excluded from all PIT/HIC reporting on the project. Data on these youth who are identified as no to FYSB Youth does transmit in the RHY export for the national data transfers, but is filtered out in analysis. If the system supports required elements, then this element should be required for RHY:BCP-es funded projects and the client should not be able to exit the project without a response to this element. <RHYBCPStatus> 79

84 Enrollment 2017 V1 Changes Made Renumbered formerly 4.22 Reworded Field 2 from FYSB Youth to Youth Eligible for RHY Services Data collection stage changed from Update to Project Start. Dependent B added. R3 Sexual Orientation Sexual Orientation Field 1 & Responses Sexual Orientation 1 Heterosexual 2 Gay 3 Lesbian 4 Bisexual 5 Questioning / Unsure Program Specific Funder: Program-Component HHS: RHY Collection required for all components Project Type Applicability 1: Emergency Shelter e/e method 2: Transitional Housing 4: Street Outreach 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Other System Issues None <EntryRHY> Enrollment 2017 V1 Changes Made Renumbered formerly 4.23 No other changes made. R4 Last Grade Completed Last Grade Completed Field 1 & Responses Last Grade Completed 1 Less than Grade 5 2 Grades Grades Grades Grade 12 / High school diploma 80

85 6 School program does not have grade levels 7 GED 10 Some college 11 Associate s degree 12 Bachelor s degree 13 Graduate degree 14 Vocational certification Program Specific Funder: Program-Component HUD:HUD-VASH - Collection required for all components HHS: RHY Collection required for all components except for Street Outreach VA: SSVF Collection required for all components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 3: Permanent Supportive Housing 12: Homelessness Prevention 13: PH Rapid Re-Housing Data Collected About Head of Household and Adults Project Start, Project Exit Collect once at each project start. System stores collected information as project start or project exit information and retains for historical purpose Other System Issues None <LastGradeCompleted> EmploymentEducation Renumbered formerly V1 Changes Made Project exit added to collection point. R5 School Status Field 1 & Responses School Status School Status 1 Attending school regularly 2 Attending school irregularly 3 Graduated from high school 4 Obtained GED 5 Dropped out 6 Suspended 7 Expelled 81

86 Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start, Project Exit Collect once at each project start and project exit. System stores collected information as project start or project exit information and retains for historical purpose. Other System Issues None <SchoolStatus> EmploymentEducation 2017 V1 Changes Made Renumbered formerly 4.25 Project exit added to collection point. R6 Employment Status Employment Status Field 1 & Response Information Date (date information was collected) [date field] Field 2 & Responses Employed Dependent A Dependent to If Yes for Employed Field 2 & Response 1 Type of Employment 1 Full-time 2 Part-time 3 Seasonal / sporadic (including day labor) Dependent B Dependent to If No for Employed Field 2 & Response 0 Why Not Employed 1 Looking for work 2 Unable to work 3 Not looking for work Program Specific Funder: Program-Component HUD: HUD-VASH Collection required for HUD/VASH-OTH HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention 82

87 Data Collected About Head of Household and Adults Project Start, Project Exit The system must record the appropriate collection stage for each element. System stores collected information as project start or project exit information and retains for historical purpose. None <Employment> EmploymentEducation Other System Issues 2017 V1 Changes Made Renumbered formerly 4.26 Project exit added to collection point. R7 General Health Status General Health Status Field 1 & Responses General Health Status 1 Excellent 2 Very good 3 Good 4 Fair 5 Poor Program Specific Funder: Program-Component HUD: HUD-VASH Collection required for HUD/VASH-OTH HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start, Project Exit Collect once at each project start and project exit. System stores collected information as project start or project exit information and retains for historical purpose. Other System Issues None <HealthStatus> HealthAndDV 2017 V1 Changes Made Renumbered formerly 4.27 No other changes made. 83

88 R8 Dental Health Status Dental Health Status Field 1 & Responses Dental Health Status 1 Excellent 2 Very good 3 Good 4 Fair 5 Poor Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start, Project Exit Collect once at each project start and project exit. System stores collected information as project start or project exit information and retains for historical purpose. Other System Issues None <HealthStatus> HealthAndDV 2017 V1 Changes Made Renumbered formerly 4.28 No other changes made. R9 Mental Health Status Mental Health Status Field 1 & Responses Mental Health Status 1 Excellent 2 Very good 3 Good 4 Fair 5 Poor Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 84

89 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start, Project Exit Collect once at each project start and project exit. System stores collected information as project start or project exit information and retains for historical purpose. Other System Issues None <HealthStatus> HealthAndDV 2017 V1 Changes Made Renumbered formerly 4.29 No other changes made. R10 Pregnancy Status Pregnancy Status Field 1 & Responses Pregnancy Status Dependent A Dependent to If Yes for Pregnancy Status Field 2 & Response 1 Due Date (date) [date field] Program Specific Funder: Program-Component HHS: RHY Collection required for all components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 4: Street Outreach 12: Homelessness Prevention Data Collected About Female - Head of Household and Adults Project Start, Update Collect once at each project start. Data are time sensitive and may change over the project stay. System must allow for updated information collection as change occurs, must record the date the information was collected with a data collection stage of project update, and retains all updates for historical purpose. There may be multiple records of this data element per project stay; each Other System Issues time there is pregnancy, a record of the pregnancy must be recorded. If Due Date is unknown, default to January first of current year. <HealthStatus> HealthAndDV Renumbered formerly V1 Changes Made No other changes made 85

90 R11 Formerly a Ward of Child Welfare/Foster Care Agency Formerly a Ward of Child Welfare/Foster Care Agency Field 1 & Responses Formerly a Ward of Child Welfare or Foster Care Agency Dependent A Dependent to If Yes for Formerly a Ward of Child Welfare or Foster Care Agency Field 1 & Response 1 Number of Years 1 Less than one year 2 1 to 2 years 3 3 to 5 or more years Dependent B Dependent to If Less than one year for Number of Years Dependent A & Response 1 Number of Months (1-11) Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Other System Issues HMIS may choose to only display dependent questions if user selects the appropriate response. <EntryRHY> Enrollment 2017 V1 Changes Made Renumbered formerly 4.31 No other changes made. R12 Formerly a Ward of Juvenile Justice System Field 1 & Responses Dependent A Dependent to Field 1 & Response 1 Formerly a Ward of Juvenile Justice System Formerly a Ward of Juvenile Justice System If Yes for Formerly a Ward of Child Welfare or Foster Care Agency Number of Years 86

91 1 Less than one year 2 1 to 2 years 3 3 to 5 or more years Dependent B Dependent to If Less than one year for Number of Years Dependent A & Response 1 Number of Months (1-11) Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Other System Issues <EntryRHY> Enrollment 2017 V1 Changes Made Renumbered formerly 4.32 No other changes made. HMIS may choose to only display dependent questions if user selects the appropriate response. R13 Family Critical Issues Field 9 & Responses Field 11 & Responses Field 15 & Responses Field 21 & Responses Field 22 & Responses Field 24 & Responses Family Critical Issues Unemployment - Family member Mental Health Issues - Family member Physical Disability Family member Alcohol or Substance Abuse - Family member Insufficient Income to support youth - Family member Incarcerated Parent of Youth 87

92 Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Start Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Other System Issues None <EntryRHY> Enrollment 2017 V1 Changes Made Renumbered formerly 4.33 Renamed formerly Young Persons Critical Issues Response options were streamlined and decreased to reduce data collection burden. No mapping required. (Field numbers from 2014 were maintained for tracking purposes) R14 RHY Service Connections RHY Service Connections BCP-P BCP-ES TLP&MGH SOP DEMO Field 1 & Response Date of Service (date) [date field] X X X X Field 2 & Responses Type of RHY Service X X X X Community service/service learning 2 (CSL) X X 7 Criminal justice /legal services X X X X 5 Education X X X X 6 Employment and/or training services X X 14 Health/medical care X X X X 26 Home-based Services X 8 Life skills training X X X X Parenting education for youth with 10 children X X X X Post-natal newborn care (wellness 27 exams; immunizations) X X 12 Post-natal care for mother X X 13 Pre-natal care X X 28 STD Testing X X 29 Street-based Services X 17 Substance abuse treatment X X X X 18 Substance Abuse Ed/Prevention Services X X X X 88

93 Funder:Program-Component HHS: RHY Collection required for components as outlined above Project Type Applicability 1: Emergency Shelter e/e method 2: Transitional Housing 6: Services Only 12: Homelessness Prevention Data Collected About Head of Household and Adults Occurrence Point (At First Service) Data is collected once per service provided at the time of the first provision of service. Data are time sensitive and may change over the project stay. The system must allow for multiple records per project stay to record each instance and must record the date the new information was collected. Other System Issues If service benefits entire household, it may be recorded solely for the Head of Household. <ServiceFAReferral> Services 2017 V1 Changes Made Renumbered formerly 4.14B Renamed formerly Services Provided-RHY Data collection has been reduced. The 2015 V5 response option number remain and indicate data previously collected under that response option should remain associated with those numbers, but wording of the response should be updated to reflect the response indicated above. Previous responses entered under expired responses are required to be mapped to these new more streamlined responses. R15 Commercial Sexual Exploitation/Sex Trafficking Commercial Sexual Exploitation/Sex Trafficking Field 1 & Responses Ever received anything in exchange for sex (e.g. money, food, drugs, shelter) Dependent A Dependent to If Yes for Ever received anything in exchange for sex Field 1 & Response 1 In the last three months Dependent B Dependent to If Yes for Ever received anything in exchange for sex Field 1 & Response 1 How many times

94 or more Dependent C Dependent to If Yes for Ever received anything in exchange for sex Field 1 & Response 1 Ever made/persuaded/forced to have sex in exchange for something Dependent D Dependent to If Yes for Ever made/persuaded/forced to have sex in exchange for something? Dependent C & Response 1 In the last three months? Program Specific Funder: Program-Component HHS: RHY Collection required for all components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 4: Street Outreach 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Exit Collect once at each project exit. System stores collected information as project exit information and retains for historical purpose. Other System Issues HMIS may choose to only display dependent questions if the user selects the appropriate response. If mouse over/hover functionality is available in the system for explanations/definitions, RHY requests the information to read as follows: Field 1: Have you ever received anything in exchange for having sexual relations with another person, such as money, food, drugs or shelter? Dependent B: How many times have you received something in exchange for having sexual relations with another person, such as money, food, drugs or shelter? Dependent C: Did someone ever make you or persuade you to have sex with anyone else in exchange for something such as money, food, drugs or shelter? <ExitRHY> Exit 90

95 2017 V1 Changes Made Renumbered formerly 4.35A Name updated Collection point changed from Project Start to Project Exit. R16 Labor Exploitation/Trafficking Field 1 & Responses Field 2 & Responses Labor Exploitation/Trafficking Ever afraid to quit/leave work due to threats of violence to yourself, family, or friends Ever promised work where work or payment was different than you expected Dependent A Dependent to If Yes for either Workplace violence threats OR Workplace promise Field 1 & 2 Response 1 difference - Felt forced, coerced, pressured or tricked into continuing the job Dependent B Dependent to If Yes for either Workplace violence threats OR Workplace promise actual Field 1 & 2 Response 1 difference - In the last 3 months Program Specific Funder: Program-Component HHS: RHY Collection required for all components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing; 4: Street Outreach 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Exit 91

96 Other System Issues Collect once at each project exit. System stores collected information as project exit information and retains for historical purpose. HMIS may choose to only display dependent questions if the user selects the appropriate response. If mouse over/hover functionality is available in the system for explanations/definitions, RHY requests the information to read as follows: Field 1: Have you ever been afraid to leave or quit a work situation due to fears of violence or other threats of harm to yourself, family or friends? Field 2: Have you ever been promised work where the work or payment ended up being different from what you expected? Dependent A: Did you feel forced, coerced, pressured or tricked into continuing this job? Dependent B: Have you had any jobs like these in the last three months? <ExitRHY> Exit 2017 V1 Changes Made Renumbered formerly 4.35B Name update Collection point changed from Project Start to Project Exit. R17 Project Completion Status Field 1 & Responses Project Completion Status Project Completion Status 1 Completed project 2 Youth voluntarily left early 3 Youth was expelled or otherwise involuntarily discharged from project If Youth was expelled or otherwise involuntarily discharged from project for Dependent A Dependent to Project Completion Status Field 1 & Response 3 Select the major reason 1 Criminal activity/destruction of property/violence 2 Non-compliance with project rules 3 Non-payment of rent/occupancy charge 4 Reached maximum time allowed by project 5 Project terminated 6 Unknown/disappeared Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach and BCP-Prevention Project Type Applicability 1: Emergency Shelter 92

97 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Exit Collect once at each project exit. System stores collected information as project exit information and retains for historical purpose. Other System Issues None <ExitRHY><ProjectCompletionStatus> Exit 2017 V1 Changes Made Renumbered formerly 4.37 Response options were streamlined (Dependent A removed) and decreased to reduce data collection burden. R18 Counseling Counseling Field 1 & Responses Counseling received by client Dependent A Dependent to If Yes Identify the type(s) of counseling received Field 1 & Response 1 1 Individual 2 Family 3 Group including peer counseling Dependent B Dependent to If yes, Identify the number of sessions received by exit Field 1 & Response 1 1 (integers 1-48+) Field 2 & Response Total number of session planned in youth s treatment or service plan 1 (integers 1-48+) Field 3 & Responses A plan is in place to start or continue counseling after exit Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Project Exit Collect once at each project exit. System stores collected information as project exit information and retains for historical purpose. Other System Issues None 93

98 <ExitRHY> Exit 2017 V1 Changes Made New element R19 Safe and Appropriate Exit Field 1 & Responses Field 2 & Responses Field 3 & Response Safe and Appropriate Exit Exit destination safe as determined by the client Exit destination safe as determined by the project/caseworker 2 Worker does not know Client has permanent positive adult connections outside of project 2 Worker does not know Field 4 & Response Client has permanent positive peer connections outside of project 2 Worker does not know Field 5 & Response Client has permanent positive community connections outside of project 2 Worker does not know Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach and Homelessness Prevention Project Type Applicability 1: Emergency Shelter 2: Transitional Housing Data Collected About Head of Household and Adults Project Exit Collect once at each project exit. System stores collected information as project exit information and retains for historical purpose. Other System Issues None <ExitRHY> Exit 2017 V1 Changes Made New element 94

99 R20 Aftercare Plans Aftercare Plans Field 1 & Response Information Date (date information was collected) [date field] Field 2 & Responses Aftercare was provided Dependent A Dependent to If yes Identify the primary way it was provided Field 1 1 Via /social media 2 Via telephone 3 In person: one-on-one 4 In person: group Program Specific Funder: Program-Component HHS: RHY Collection required for all components except for Street Outreach Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 12: Homelessness Prevention Data Collected About Head of Household and Adults Post Exit Information may be entered post exit for a period of up to 180 days at which point no data should be entered. Any data entered prior to the date of exit or after the 180 th day will not be considered in reporting or exports. Either multiple primary ways (dependent A) must be able to be identified in one entry or there must be the ability to have multiple instances of the element to support data entry for a youth who received aftercare via multiple methods. Other System Issues New process may be required to reopen a record with an exit to record Aftercare information. <ExitRHY> Exit 2017 V1 Changes Made Renumbered formerly 4.36 Renamed formerly Transitional, Exit-care or Aftercare Plans and Actions This element has been repurposed from an element asking if aftercare was expected to be provided to was aftercare provided. Response options were streamlined. Previous responses do not require mapping. Data collection stage changed from Project exit to Post exit. RHSAP Program Element Visibility Collection Requirements Project Types and Program Specific Visibility for each program component have not yet been defined for RHSAP. 95

100 U1 Worst Housing Situation Worst Housing Situation Field 1 & Responses Worst Housing Situation Program Specific Funder: Program-Component HUD: RHSAP - Collection required for all components Project Type Applicability Unknown at time of publication Data Collected About All Clients Project Start Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Other System Issues As of the publication of this Data Dictionary RHSAP does not have federal funding. Upon receipt of federal funding by HUD for RHSAP this element should become active. <EntryRHSP> Enrollment 2017 V1 Changes Made Renumbered formerly 4.40 No other changes made. 96

101 VA Program Element Visibility Collection Requirements Program Specific Components and Project Types Component Project Type # Project Type Name SSVF - RRH 13 PH: Rapid Re-Housing SSVF Homelessness Prevention 12 Homelessness Prevention HCHV CRS: EH 1 Emergency Shelter HCHV: Low Demand Safe Haven 8 Safe Haven GPD: Bridge Housing 2 Transitional Housing GPD: Low Demand 8 Safe Haven GPD: Service Intensive Transitional Housing 2 Transitional Housing GPD: Hospital to Housing 2 Transitional Housing GPD: Clinical Treatment 2 Transitional Housing GPD: Transition in Place 9 Permanent Housing Only HUD/VASH and HUD/VASH-OTH 3 PH PSH VA Program Specific Element Visibility Collection Requirements # Element SSVF- RRH SSVF HP HCHV/ CRS: EH HCHV/ LDSH GPD Bridge GPD Low Demand GPD Serv. Intensive TH GPD HtoH GPD- Clinical Treat. UDE All Universal Data Elements x x x x x x x x x x 4.2 Income and Sources x x x x x x x x x x 4.3 Non-Cash Benefits x x x x x x x x x x 4.4 Health Insurance x x x x x x x x x x 4.5 Physical Disability x x x x x x x x 4.6 Developmental Disability x x x x x x x x 4.7 Chronic Health Condition x x x x x x x x 4.8 HIV/Aids x x x x x x x x 4.9 Mental Health Problem x x x x x x x x 4.10 Substance Abuse x x x x x x x x 4.11 Domestic Violence x x x x x x x x V1 Veteran s Information x x x x x x x x x x V2 Services Provided SSVF x x V3 Financial Assistance SSVF x x V4 Percent of AMI (SSVF Eligibility) x x V5 Last Permanent Address x x V6 VAMC Station Number x x V7 SSVF HP Targeting Criteria x P4 Connection with SOAR x x R4 Last Grade Completed x x X = data collection required = data collection is optional at the discretion of the grantee 97 GPD TIP

102 HUD/VASH and HUD/VASH Other Program Specific Element Visibility Collection Requirement # VA Required Elements V1 V2 V3 V4 V5 V6 V7 V8 V9 Element HUD/VASH UDE All Universal Data Elements x x 4.2 Income and Sources x x 4.3 Non-Cash Benefits x x 4.4 Health Insurance x x 4.5 Physical Disability x x 4.6 Developmental Disability x x 4.7 Chronic Health Condition x x 4.8 HIV/Aids x x 4.9 Mental Health Problem x x 4.10 Substance Abuse x x 4.11 Domestic Violence x x 4.18 Housing Assessment Disposition CA CA V1 Veteran s Information x x V5 Last Permanent Address x x V6 VAMC Station Number x x V8 HUD-VASH Voucher Tracking x V9 HUD-VASH Exit Information x R4 Last Grade Completed x x R6 Employment Status x R7 General Health Status x Veteran s Information Services Provide - SSVF Financial Assistance SSVF Percent of AMI (SSVF Eligibility) Last Permanent Address VAMC Station Number SSVF HP Targeting Criteria HUD -VASH Voucher Tracking HUD/VASH Exit Information HUD/VASH- OTH X = data collection required Some of the Veteran s Administration Programs also use these other federal partner elements: P3 Connection with Soar R4 Last Grade Completed R6 Employment Status R7 General Health Status In the 2017 HMIS Data Standards, Data Element 4.49 Use of Other Crisis Services was retired from use by the VA. 98

103 V1 Veteran s Information Field 1 & Response Field 2 & Response Field 3 & Responses Field 4 & Responses Field 5 & Responses Field 6 & Responses Field 7 & Responses Field 8 & Responses Field 9 & Responses Veterans Information Year Entered Military Service (year) Year Separated from Military Service (year) Theatre of Operations: World War II Theatre of Operations: Korean War Theatre of Operations: Vietnam War Theatre of Operations: Persian Gulf War (Operation Desert Storm) Theatre of Operations: Afghanistan (Operation Enduring Freedom) Theatre of Operations: Iraq (Operation Iraqi Freedom) Theatre of Operations: Iraq (Operation New Dawn) 99

104 Field 10 & Responses Theatre of Operations: Other Peace-keeping Operations or Military Interventions (such as Lebanon, Panama, Somalia, Bosnia, Kosovo) Field 11 & Responses Branch of the Military 1 Army 2 Air Force 3 Navy 4 Marines 6 Coast Guard Field 12 & Responses Discharge Status 1 Honorable 2 General under honorable conditions 6 Under other than honorable conditions (OTH) 4 Bad conduct 5 Dishonorable 7 Uncharacterized Program Specific Funder: Program-Component HUD:HUD-VASH - Collection required for all components VA:SSVF - Collection required for all components VA:GPD - Collection required for all components VA:HCHV Collection required for all components Project Type Applicability 1: Emergency Shelter 2: Transitional Housing 3: PH- Permanent Supportive Housing 8: Safe Haven 9: PH Housing Only 12: Homelessness Prevention 100

105 13: PH-Rapid Re-Housing Data Collected About All Veterans Record Creation There is a one-to-one relationship between this data element and 5.8 Personal ID. System stores collected information. Other System Issues None <ClientVeteranInfo> Client 2017 V1 Changes Made Renumbered formerly 4.41 Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. V2 Services Provided SSVF Services Provided - SSVF Field 1 & Response Date of Service (date) [date field] Field 2 & Responses Type of Service 1 Outreach services 2 Case management services 3 Assistance obtaining VA benefits 4 Assistance obtaining/coordinating other public benefits 5 Direct provision of other public benefits 6 Other (non-tfa) supportive service approved by VA Dependent A Dependent to If Assistance obtaining VA benefits Field 2 Response 3 1 VA vocational and rehabilitation counseling 2 Employment and training services 3 Educational assistance 4 Health care services Dependent B Dependent to If Assistance obtaining/coordinating other public benefits Field 2 Response 4 1 Health care services 2 Daily living services 3 Personal financial planning services 4 Transportation services 5 Income support services 6 Fiduciary and representative payee services 7 Legal services child support 8 Legal services eviction prevention 9 Legal services outstanding fines and penalties 10 Legal services restore/acquire driver s license 101

106 11 Legal services other 12 Child care 13 Housing counseling Dependent C Dependent to If Direct provision of other public benefits Field 2 Response 5 1 Personal financial planning services 2 Transportation services 3 Income support services 4 Fiduciary and representative payee services 5 Legal services child support 6 Legal services eviction prevention 7 Legal services outstanding fines and penalties 8 Legal services restore/acquire driver s license 9 Legal services other 10 Child care 11 Housing counseling Dependent D Dependent If Other(Non-TFA) Supportive Service approved by VA to Field 2 Response 6 text box for Specify Program Specific VA:SSVF Collection required for all components Project Type Applicability 12: Homelessness Prevention 13: PH-Rapid Re-Housing Data Collected About All Clients receiving services Occurrence Point (As Provided) Services will be recorded as they are provided. The system must allow for a theoretically unlimited number of records per project stay. Users must be able to edit existing records and delete records entered in error. Other System Issues Services will be recorded for the head of household (only) unless a specific service is of benefit only to a particular household member. <ServiceFAReferral> Services 2017 V1 Changes Made Renumbered formerly 4.14D No other changes made. V3 Financial Assistance SSVF Financial Assistance - SSVF Field 1 & Response Date of Financial Assistance (date) [date field] Field 2 & Response Financial Assistance Amount (amount) Field 3 & Responses Financial Assistance Type 1 Rental assistance 4 Utility fee payment assistance 102

107 2 Security deposit 3 Utility deposit 5 Moving costs 8 Transportation services: tokens/vouchers 9 Transportation services: vehicle repair/maintenance 10 Child Care 11 General housing stability assistance - emergency supplies 12 General housing stability assistance - other 14 Emergency housing assistance Program Specific Funder: Program Component VA:SSVF Collection required for all components Project Type Applicability 12:Homelessness Prevention 13:PH-Rapid Re-Housing Data Collected About All Clients receiving financial assistance Occurrence Point (As Provided) Financial assistance will be recorded as it is provided. The system must allow for a theoretically unlimited number of records per project stay. Users must be able to edit existing records and delete records entered in error. Other System Issues Financial assistance will be recorded for the head of household (only) unless a specific service is of distinct benefit only to a particular household member. <ServiceFAReferral> Services 2017 V1 Changes Made Renumbered formerly 4.15B No other changes made. V4 Percent of AMI (SSVF Eligibility) Percent of AMI (SSVF Eligibility) Field 1 & Responses Household Income as a Percentage of AMI 1 Less than 30% 2 30% to 50% 3 Greater than 50% Program Specific Funder: Program-Component VA:SSVF Collection required for all components Project Type Applicability 12: Homelessness Prevention 13: PH-Rapid Re-Housing Data Collected About Head of Household Project Start Collect once at each project start; there is a one-to-one relationship between this data element and 5.9 Household ID. System stores collected information as project start information and retains for historical purpose. 103

108 Other System Issues 2017 V1 Changes Made Renumbered formerly 4.42 Name changed. V5 Last Permanent Address The system may not automatically calculate this field unless the VA Annual Income worksheet is part of the HMIS and the field is calculated from that worksheet. Calculation from Income and Sources is prohibited. <EntrySSVF> Enrollment Last Permanent Address Field 1 & Response Street Address Field 2 & Response City Field 3 & Response State Field 4 & Response Zip Code Field 5 & Responses Address Data Quality 1 Full address reported 2 Incomplete or estimated address reported Program Specific Funder: Program-Component HUD:HUD-VASH - Collection required for all components VA:SSVF Collection required for all components Project Type Applicability 3: PH Permanent Supportive Housing 12: Homelessness Prevention 13: PH-Rapid Re-Housing Data Collected About Head of Household Project Start Collect once at each project start. System stores collected information as project start information and retains for historical purpose. Other System Issues None <EntrySSVF> Enrollment 2017 V1 Changes Made Renumbered formerly 4.43 No other changes made. V6 VAMC Station Number Field 1 & Response VAMC Station Number VAMC Station Number [drop down list of all VAMC Station codes and names] Program Specific 104

109 Funder: Program-Component HUD:HUD-VASH - Collection required for all components VA:SSVF Collection required for all components Project Type Applicability 3: PH Permanent Supportive Housing 12: Homelessness Prevention 13: PH-Rapid Re-Housing Data Collected About Head of Household Project Start Collect once at each project start. Other System Issues Valid VAMC Station Numbers are up to 8 alphanumeric characters and should correspond to the VA service location (as opposed to 3.16 Client Location). SSVF grantees will be provided with station numbers that correspond to their service locations. Station Numbers are provided to vendors through the HMIS Vendor HUB. No information date or data collection stage is required; the effective information date is the Project Start Date and data are only collected at project start; there is a one-to-one relationship between this data element and 5.9 Household ID. <EntrySSVF> Enrollment 2017 V1 Changes Made Renumbered formerly 4.45 Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. Field 1 changed from text field to drop-down list of all VAMC Station codes and names. V7 SSVF HP Targeting Criteria Referred by Coordinated Entry or a homeless assistance provider to prevent the Field 1 & Responses household from entering an emergency shelter or transitional housing or from staying in a place not meant for human habitation. (0 points) Field 2 & Responses Current housing loss expected within days days days 3 More than 21 days (0 points) Field 3 & Responses Current household income is $0 (0 points) Field 4 & Responses Annual household gross income amount % of Area Median Income (AMI) for household size % of AMI for household size 2 More than 30% of AMI for household size (0 points) 105

110 Field 5 & Responses Field 6 & Responses Sudden and significant decrease in cash income (employment and/or cash benefits) AND/OR unavoidable increase in non-discretionary expenses (e.g., rent or medical expenses) in the past 6 months (0 points) Major change in household composition (e.g., death of family member, separation/divorce from adult partner, birth of new child) in the past 12 months (0 points) Field 7 & Responses Rental Evictions within the Past 7 Years 0 4 or more prior rental evictions prior rental evictions 2 1 prior rental eviction 3 No prior rental evictions (0 points) Currently at risk of losing a tenant-based housing subsidy or housing in a Field 8 & Responses subsidized building or unit (0 points) Field 9 & Responses History of Literal Homelessness (street/shelter/transitional housing) 0 4 or more times or total of at least 12 months in past three years times in past three years 2 1 time in past three years 3 None (0 points) Head of household with disabling condition (physical health, mental health, Field 10 & Responses substance use) that directly affects ability to secure/maintain housing (0 points) Criminal record for arson, drug dealing or manufacture, or felony offense Field 11 & Responses against persons or property (0 points) Field 12 & Responses Registered sex offender (0 points) Field 13 & Responses At least one dependent child under age 6 (0 points) Field 14 & Responses Single parent with minor child(ren) (0 points) Household size of 5 or more requiring at least 3 bedrooms (due to age/gender Field 15 & Responses mix) (0 points) Field 16 & Responses Any Veteran in household served in Iraq or Afghanistan 106

111 Field 17 & Responses Field 20 & Response Field 21 & Response Project Type Applicability Funder: Program- Component Data Collected About Other System Issues 2017 V1 Changes Made V8 HUD-VASH Voucher Tracking Field 1 Field 2 & Responses (0 points) Female Veteran (0 points) HP applicant total points (integer) Grantee targeting threshold score (integer) Program-Specific 12: Homelessness Prevention VA:SSVF Collection required for all components Head of Household Project Start Collect and enter results of SSVF Homelessness Prevention Stage 2 Targeting Criteria Screening as of the date of project start; there is a one-to-one relationship between this data element and 5.9 Household ID. Records must be editable in order for users to correct data entry errors. There are redundancies between this data element and other data collection, including 3.8 Disabling Condition, 4.2 Income and Sources, V1 Veteran s Information, V4 Percent of AMI (SSVF Eligibility), and data related to household composition. Consistency in responses for this data element and others will be used in evaluation of SSVF data quality. <EntrySSVF> Enrollment Renumbered formerly 4.48 Clarifications to regarding relationships between data elements; no change is intended, but updates will be required in systems not consistent with this logic. HUD-VASH Voucher Tracking Information date [date field] Voucher change 1 Referral package forwarded to PHA 2 Voucher denied by PHA 3 Voucher issued by PHA 4 Voucher revoked or expired 5 Voucher in use veteran moved into housing 6 Voucher was ported locally 7 Voucher was administratively absorbed by new PHA 8 Voucher was converted to Housing Choice Voucher 9 Veteran exited voucher was returned 10 Veteran exited family maintained the voucher 107

112 11 Veteran exited prior to ever receiving a voucher 12 Other Dependent A Dependent to If Other Field 2 & Response 12 text box for Specify Program Specific Funder: Program-Component HUD:HUD-VASH Collection required for HUD/VASH-OTH Project Type Applicability 3: PH Permanent Supportive Housing Data Collected About Head of Household/Veteran Project Start, Update, and Project Exit There may be only one response per Information Date. The system must record the appropriate collection stage for each element. Systems must also allow for update information if a change occurs mid-year. Allow corrections for data entry errors at all stages. Other System Issues None <ServiceFAReferral> Services 2017 V1 Changes Made NEW element V9 HUD-VASH Exit Information HUD-VASH Exit Information Field 1 Case Management Exit Reason 1 Accomplished goals and/or obtained services and no longer needs CM 2 Transferred to another HUD-VASH program site 3 Found/chose other housing 4 Did not comply with HUD-VASH CM 5 Eviction and/or other housing related issues 6 Unhappy with HUD-VASH housing 7 No longer financially eligible for HUD-VASH voucher 8 No longer interested in participating in this program 9 Veteran cannot be located 10 Veteran too ill to participate at this time 11 Veteran is incarcerated 12 Veteran is deceased 13 Other Dependent B Dependent to If Other Field 1 & Response 13 text box for Specify Program Specific Funder: Program-Component HUD:HUD-VASH Collection required for HUD/VASH-OTH Project Type Applicability 3: PH Permanent Supportive Housing Data Collected About Head of Household/Veteran 108

113 Project Exit The system must record the appropriate collection stage for each element. Other System Issues None <ExitVASH> Exit 2017 V1 Changes Made NEW element METADATA ELEMENTS The term metadata is often defined as data about data. Instead of capturing information about a project or a client, Metadata Elements capture information about the data itself: when it was collected, when it was entered into HMIS, who entered it, and which project is responsible for it. The Metadata Elements are intended to facilitate reporting from HMIS, to simplify the writing of programming specifications, and to provide an audit trail. These elements do not represent an attempt to standardize the way that an HMIS stores data. As long as the HMIS is able to accomplish the purposes identified for the Metadata Elements, the software is not required to use the exact metadata elements listed here. 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 5.5 Project Identifier 5.6 Enrollment ID 5.7 User Identifier 5.8 Personal ID 5.9 Household ID 5.10 Signed Consent 5.1 Date Created Date Created Field 1 & Response [date field] Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Records Record Creation HMIS auto-generated. HMIS must have the ability to identify the date on which a record was first created in HMIS for any data element. Data elements that are collected together on a single form may share a single Date Created. HMIS users 109

114 and system administrators must not have the ability to enter or to modify the information in this Metadata Element. Other System Issues The HMIS must store this metadata for all client-level data elements. It is not necessary that this information be displayed in the user interface of the HMIS, but it must be accessible in the programming of reports. Date Created must not change when a data element is edited. If two client records representing the same person are merged, the earliest Date Created must be retained for data elements for which the HMIS stores only one value per client (e.g., name, SSN, date of birth). attribute: DateCreated <*><DateCreated> (Field collected across multiple files) 2017 V1 Changes Made None 5.2 Date Updated Date Updated Field 1 & Response [date field] Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Data Elements Record Add / Edit HMIS auto-generated. Created by the HMIS when a record for any data element is first created, and updated by the HMIS every time the record is saved by an HMIS user Other System Issues The HMIS must be able to determine, for all data elements, the date on which it was last edited by a user. Each time a user saves data, the HMIS must store the current date as the Date Updated with the data being saved. Data elements that are collected together on a single form may share a single Date Updated. HMIS users or system administrators must not have the ability to enter or to modify the information in this metadata element. attribute: DateUpdated <*><DateUpdated> (Field collected across multiple files) 2017 V1 Changes Made None 5.3 Data Collection Stage Field 1 & Response Data Collection Stage Data Collection Stage 1 Project start 2 Project update 5 Project annual assessment 110

115 3 Project exit 6 Post exit Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Data Elements with multiple data collection stages Client Data Entry of Specified Elements HMIS auto-generated or HMIS user selected. Other System Issues An HMIS must be able to distinguish between data collected at project start, project update (during a project stay), and at project exit. Data elements that are collected together on a single form may share a single Data Collection Stage. HMIS users should not have the ability to create more than one record per data element at either project start or project exit (e.g., for a single project stay, a client should have one and only one record of Income and Sources identified as project start). The system must allow a user to save a dated record for a client s annual assessment as an annual assessment. The response categories correlate to response categories defined in the and specifications. An annual assessment is required as noted in the collection stage for some Program Specific Elements. The Annual Assessment must include updating both the head of household s record and any other family members at the same time. Elements for which a collection point of annual assessment is required must be collected at least once annually for each client. An Annual Assessment must occur between months 11 and 13 annually for all HUD funded projects. The Information Date must be no more than 30 days before or after the anniversary of the head of household s Project Start Date; information must be accurate as of the Information Date. The date range of the Annual Assessment is based entirely around the head of household s Project Start Date, not on the date of the client s or head of household s previous assessment. For all projects which require an annual assessment, data collected as part of an annual assessment must have a Data Collection Stage of annual assessment. There should be one and only one record for each data element with a Data Collection Stage of annual assessment within the 60-day period surrounding the anniversary of the head of household s Project Start Date. Regardless of whether or not the responses have changed since project start or the previous annual assessment, a new record must be created for each annual assessment such that it is possible to view a history, by date, of the values for each data element. attribute: DataCollectionStage <*><DataCollectionStage> (Field collected across multiple files) 111

116 2017 V1 Changes Made Project update was clarified in the Data Element Structure section of this document. A Post Exit stage has been added. 5.4 Information Date Information Date Field 1 & Response [date field] Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About As Specified in Data Element Definitions Client Program-Specific Data Entry This Metadata Element is a hybrid in that it pertains to the client data and not directly to the client, but it will be entered in HMIS by users. Throughout the Data Dictionary this Metadata Element has been added to the data elements where it applies (e.g. Income and Sources, with Response 1 Information Date). The metadata element is included here to provide further information for HMIS vendors and system administrators. Data that is collected only at initial HMIS project start (e.g., Name, Social Security Number) does not require an Information Date. Data that is collected only at project start or only at project exit, may be assumed to have an Information Date that matches the Project Start Date or Project Exit Date, respectively or an HMIS may require that a user specify the date. Data elements that are collected together on a single form may share a single Information Date. Other System Issues This Metadata Element is applicable to all elements which can change over time. attribute: InformationDate <*><InformationDate> (Field collected across multiple files) 2017 V1 Changes Made None 5.5 Project Identifier Project Identifier Field 1 & Response Project Identifier (2.2) of the project that entered or edited the data Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types 112

117 Data Collected About Specified Data Elements Record Add / Edit HMIS auto-generated or HMIS user selected. Data elements that are collected together on a single form may share a single Project Identifier. In order to report on data quality on a project s report, it is first necessary to establish that the project in question was responsible for the data. Other System Issues This is a basic requirement that assumes a simple relationship between clients and projects. In circumstances where one project may be responsible for entering data that would appropriately appear on another project s required report (e.g., a central intake point), it may be necessary to create a more sophisticated method to establish responsibility for the data entered. Unique Identifier: ProjectID <*><ProjectID> (Field collected across multiple files) 2017 V1 Changes Made None 5.6 Enrollment ID Enrollment ID Field 1 & Response A unique project start identifier used to associate data with a particular period of service. Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Enrollment Level Data Record Add HMIS auto-generated. The data element should be created by the HMIS at the time that the record of a project start is first entered into HMIS, and should be stored with any data that pertains to that particular period of service. Data elements that are collected together on a single form may share a single Project Identifier. An HMIS should be able to correlate data to a specific project stay. Other System Issues This metadata element must be stored with all elements identified in this document as having a collection point Project Start Unique Identifier: EnrollmentID <*><EnrollmentID> (Field collected across multiple files) 2017 V1 Changes Made Renamed from 5.6 Project Entry ID 5.7 User Identifier Field 1 & Response User Identifier A unique ID used to associate data with the user who entered and/or edited it 113

118 Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Records All Data Entry HMIS generated. Other System Issues Each authorized user of an HMIS must have a unique identifier stored in the HMIS. Every time data is entered or edited in HMIS, the HMIS must keep a record of which user entered or edited the data based on the credentials supplied at the time of login. The data element should be stored with any Universal or Program-Specific Data Element entered or edited in an HMIS. It must be possible to determine, for all client-level data, which user entered it in HMIS. Each time a user saves data, the HMIS must store the User Identifier of that particular user with the data being saved. Data elements that are collected together on a single form may share a single User Identifier. HMIS users must not have the ability to enter or to modify the information in this Metadata Element. If a data element is edited, the system must retain the original value, along with the User Identifier of the user who entered it, in addition to storing the new value and the User Identifier of the editing user. attribute: UserID <*><UserID> (Field collected across multiple files) 2017 V1 Changes Made None 5.8 Personal ID Personal ID Field 1 & Response Personal ID (HMIS Generated) Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Record Creation Generate one. A Personal ID is an automatically generated identifier created by the HMIS application. A Personal ID must be permanent and unique to a single individual within an HMIS implementation. Other System Issues A Personal ID must be created, but there is no required format if there is a single unique Personal ID for every client and it contains no personally identifying information. The Personal ID must be able to be attached to the same individual when served by multiple projects. 114

119 There is a one-to-one relationship between Personal ID and 3.1 Name, 3.2 Social Security Number, 3.3 Date of Birth, 3.4 Race, 3.5 Ethnicity, 3.6 Gender, and 3.7 Veteran Status. Search functionality must exist to facilitate linkage of the same person with their Personal ID as they are served by different projects within the continuum. There are multiple ways to accomplish this. The recommended method of search by users for clients in open record systems is for users to enter a combination of personal identifying information (Name, SSN, Date of Birth, and/or Gender) into the HMIS application and have the application search for matching records. If a match is found and a Personal ID is retrieved, the same Personal ID will be assigned to the client, i.e. the same record is used. If no matches are found, a new automatically generated Personal ID is assigned to the client. Variations or other methods may also be utilized by vendors if the system is designed to mitigate duplicate record entry. HMIS must have functionality to allow the HMIS Lead to de-duplicate multiple records with distinct Personal ID s that are identified as representing the same individual based on identifying information. <Client><PersonalID> Client 2017 V1 Changes Made Renumbered formerly 3.13 and repositioned as Metadata No change but clarification on one-to-one relationship necessary 5.9 Household ID Household ID Field 1 & Response Household ID (HMIS Generated) Metadata Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start A Household ID will be assigned to each household at each project start and applies for the duration of that project stay to all members of the household served. The Household ID must be automatically generated by the HMIS application to ensure that it is unique. The Household ID has no meaning beyond a single enrollment; it is used in conjunction with the Project ID, Project Start Date, and Project Exit Date to link records for household members together and indicate that they were served together. Other System Issues The Household ID is to be unique to the household stay in a project; reuse of the identification for the same or similar household upon readmission into the project is unacceptable. Persons may join a household with members who have already begun a project start or may leave a project although other members of the household remain 115

120 in the project. A common Household ID must be assigned to each member of the same household. Persons in a household (either adults or children) who are not present when the household initially applies for assistance and later join the household should be assigned the same Household ID that links them to the rest of the persons in the household. The early departure of a household member would have no impact on the Household ID. An HMIS may, but is not required to, utilize a Global Household ID at record creation upon initial entry into an HMIS based on the person(s) presenting together as a household at the time of initial entry. A Global Household ID is a value which spans an entire HMIS implementation representing a collection of persons who have been in a household together. Assignment of a client in or out of a global household at a specific project need not immediately affect the client s data at other projects. If, for example, one household member exits from a household in project A and that household is also being served in project B, there is no requirement to alter the household configuration at project B. <Enrollment><HouseholdID> Enrollment 2017 V1 Changes Made Renumbered formerly 3.14 and repositioned as Metadata 5.10 Signed Consent Signed Consent Field 1 & Response Signed Consent (HMIS Generated) Universal Funder: Program-Component All Programs All Components Project Type Applicability All HMIS Project Types Data Collected About All Clients Project Start This is a placeholder metadata element. HUD and the federal partners have determined that client level consent is required to SHARE data (not to collect the data) in an HMIS. Logically then data transfer requires information to be able to be submitted or omitted from some types of transfer dependent on consent. HUD will implement a process by which to consider the issues both technical and legal related to data transfer, but is placing this item in the metadata to have HMIS Vendors recognize the need and begin to consider how it will need to be implemented within their own system and considering their diverse user base. Other System Issues None <Enrollment><Consent> Enrollment 2017 V1 Changes Made NEW 116

121 REQUIRED COLLECTION POINTS AND METADATA ELEMENTS TABLE SUMMARY Required s Users must be able to enter each data element at the appropriate point in time, as identified in each individual data element definition and summarized in the table below. Data Elements with Multiple s Data elements with multiple collection points must be recorded with 5.3 Data Collection Stage. There may be no more than one record per Enrollment ID of any multiple-point data element with a Data Collection Stage of project start or project exit. Users must be able to create a theoretically infinite number of records per Enrollment ID with a data collection stage of update or annual assessment for multiple-point data elements. Data Elements with a Single Data elements with a single collection point may be recorded with 5.3 Data Collection Stage, but it is not required. There may be no more than one record per Enrollment ID of any data element collected only at project start, only at project exit, or only post-exit. Users must be able to create a theoretically infinite number of records per Enrollment ID for single-point data elements with a plain X in the Update / Occurrence Point column in the table below. There may be no more than one record per Enrollment ID for single-point data elements with X (0 1) in the Update / Occurrence Point column in the table below. Base Metadata 5.1 Date Created, 5.2 Date Updated, and 5.7 User Identifier are not shown in the table below; these base metadata elements are required for every data element. Data elements collected on a single form / stored as fields in one record of a table may share a single set of this base metadata as long as the data elements, as they are defined by this Dictionary, are collected at the same point. Example 1: Personal ID, SSN, Date of Birth, Race, Ethnicity, Gender, Veteran Status, and Veteran Information all exist at the same level / have a one-to-one relationship with one another. They may share a Date Created, Date Updated, and User ID. Example 2: Project Start Date and Project Exit Date both have a one-to-one relationship with Enrollment ID, but have different collection points. In order to evaluate timeliness of data entry, Project Start Date and Project Exit Date must have separate base metadata elements. Project Identifier, Personal ID, and Household ID Because 3.10 Project Start Date initiates an enrollment, the creation of this data element is assumed to also create 5.6 Enrollment ID. Along with the Enrollment ID, Project Start Date must also be associated with 5.5 Project Identifier, 5.8 Personal ID, and 5.9 Household ID. The relationship of each of these metadata elements to Enrollment ID is one-to-one. Every record for any enrollment-related data element (e.g., every data element requiring Enrollment ID) is associated with a single project, client, and household through the Enrollment ID. 117

122 s Update/ Occurrence Point Record Project Annual Project Post DE Element Creation Start Assessment Exit -Exit 3.1 Name X 3.2 Social Security X Number 3.3 Date of Birth X 3.4 Race X 3.5 Ethnicity X 3.6 Gender X 3.7 Veteran Status X 3.8 Disabling Condition X X 3.10 Project Start Date 3 X X 3.11 Project Exit Date X X 3.12 Destination X X Required Metadata Elements Enrollment ID Data Collection Stage 3.15 Relationship to Head X X of Household 3.16 Client Location X X X X 3.20 Housing Move-In X (0 1) X Date Living Situation (A) X X and (B) 4.2 Income and Sources X X X X X X 4.3 Non-Cash Benefits X X X X X X 4.4 Health Insurance X X X X X X 4.5 Physical Disability X X X X X X 4.6 Developmental X X X X X X Disability 4.7 Chronic Health X X X X X X Condition 4.8 HIV/AIDS X X X X X X 4.9 Mental Health X X X X X X Problem 4.10 Substance Abuse X X X X X X 4.11 Domestic Violence X X X X 4.12 Contact X X 4.13 Date of Engagement X (0 1) X 4.14 Bed-Night Date X X Project Start Date also requires 5.5 Project ID, 5.8 Personal ID and 5.9 Household ID; other enrollment-related data elements must be linked to those metadata elements through 5.6 Enrollment ID. 118

123 Record Creation Project Start s Update/ Occurrence Point Annual Assessment Project Exit X Post -Exit Required Metadata Elements Enrollment ID X Data Collection Stage DE Element 4.18 Housing Assessment 4 Disposition W1 Services Provided - X X HOPWA W2 Financial Assistance - X X HOPWA W3 Medical Assistance X X X X X W4 T-cell(CD4) and Viral X X X X X X Load W5 Housing Assessment at Exit X X P1 Services Provided- X X PATH Funded P2 Referrals Provided - X X PATH P3 PATH Status X (0 1) X P4 Connection with X X X X X X SOAR R1 Referral Source X X R2 RHY-BCP Status X X (0 1) X R3 Sexual Orientation X X R4 Last Grade Completed X X X X R5 School Status X X X X R6 Employment Status X X X X R7 General Health Status X X X X R8 Dental Health Status X X X X R9 Mental Health Status X X X X R10 Pregnancy Status X X X X R11 Formerly a Ward of X X Child Welfare or Foster Care Agency R12 Formerly a Ward of X X Juvenile Justice System R13 Family Issues X X R14 RHY Service X X Connections 4 It must be possible to enter 4.18 Housing Assessment Disposition prior to exit; it must be entered at exit if a record does not already exist. 119

124 Record Creation Project Start s Update/ Occurrence Point Annual Assessment Project Exit Post -Exit Required Metadata Elements Enrollment ID DE Element R15 Commercial Sexual X X Exploitation R16 Labor Exploitation X X Data Collection Stage R17 Project Completion X X Status R18 Counseling X X R19 Safe and Appropriate Exit X X R20 Aftercare Plans X X U1 Worst Housing Situation X X V1 Veteran's X X 5 Information V2 Services Provided - X X SSVF V3 Financial Assistance - X X SSVF V4 Percent of AMI (SSVF X X Eligibility) V5 Last Permanent X X Address V6 VAMC Station X X Number V7 SSVF HP Targeting X X Criteria V8 HUD-VASH Voucher X X X X X Tracking V9 HUD-VASH Exit X X Information 5 Projects required to collect V1 Veteran s Information must enter the data at record creation for veterans who do not already have a client record in HMIS. For veterans who already have a record in HMIS but do not have V1 Veteran s Information, these projects must add the information to the existing client record at the time of first enrollment. 120

125 Exhibit 1: 3.917B Flow Chart START B Type of Residence Homeless Situation Institutional Situation TH/PH Situation DK/R/M Length of Stay Less than 90 days Length of Stay Less than 7 nights If NO END IF YES If NO END On the night before Did you stay on the streets, ES or SH Approximate date homelessness started IF YES If NO END Number of times homeless on the streets, ES or SH in the past 3 years Number of months homeless on the streets, ES or SH in the past 3 years END 121