2. Project Descriptor Data Elements (PDDE)

2.01 Organization Information

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

Project Setup Instruction: Organization Information is assigned once for each organization. Record the organization's legal name. The 'Organization Name' must be reviewed annually to ensure accuracy. There must be only one organizational identifier and name for each organization that has projects which operate in the HMIS implementation.

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

An organization's legal name is not always the name by which it is commonly known in the community. Some HMIS implementations include an additional field to track more familiar “common names” for organizations, but this is not required.

System Logic and Other System Issues: An 'Organization ID' must be assigned to each project via a system generated number or code. Each organization must receive a distinct identifier that is consistently associated with that organization. Each organization must also be able to be associated with one or more projects. The name of the organization must be captured in text within the HMIS.

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.

FY2022 Revision Summary: None.

2.01 Data Element Fields and Responses:

Field  Number

Field Name

Dependency

Response Category/
Data Type

Descriptions

1

Organization ID

None

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

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

2

Organization Name

None

[Text]

The organization's legal name.

3

Victim Service Provider

None

0

No

 

1

Yes

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

2.01 Specifications:

Data Collected About All Organizations
Funder/Program Component All Programs - All Components
Project Type Applicability All HMIS Project Types
XML <Organization>
CSV Organization
Collection Point Initial HMIS project setup, reviewed/updated no less than annually

 

2.02    Project Information

Rationale: To uniquely identify each project entering data into the HMIS, as well as any residential continuum projects not participating in HMIS, and to associate each project with the specific type of lodging or services provided and the details about those project types. The 'Project ID' is used to link project descriptor information in other data elements to the specific project, and also to link clients and their enrollment data to the project.  Data related to project type is necessary to identify corresponding data collection requirements and for reporting purposes. The element also identifies whether the project is a continuum project or a non-continuum project, the relationship of a 'Services Only' project to a housing project as necessary, and the method for tracking emergency shelter utilization, if applicable. Finally, HOPWA funded projects are classified as 'Medically Assisted Living Facilities' at this stage of project set up.

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

In separate fields, record the project's name, operating start date, operating end date (if applicable), whether the project is a continuum project, and the project type, residential affiliation, ES tracking method and HOPWA Medically Assisted Living Facility status. While the project name is not required to match grant agreements, the project name should be consistent with the name used across reports (e.g.: Annual Performance Report and Housing Inventory Count). This information must be reviewed at least annually to ensure accuracy. Often the project will have a common name that is used by the community for the specific project but may also have different names on formal grant agreements and perhaps even a different name in the HMIS. HMIS software solutions may elect to create another field for the entry of additional names of the project for ease of access purposes, but it is not required.

Residential projects that operate in multiple CoCs that cross HMIS systems must be documented in each CoC's HMIS, even in cases where all client data are entered into a single CoC's HMIS and the data provided to other CoC's HMIS via data transfer. For more information about setting up projects that operate in multiple CoCs, please refer to Section 1.2 Introduction to Project Descriptor Data Elements.

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

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

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

Record whether the project contributes client data to the HMIS in the 'HMIS Participating Project' field.

To answer "Yes" to 'HMIS Participating Project' means that a project collects all required data elements according to funder requirements and local CoC Policies and Procedures within the CoC's designated HMIS implementation, or that data is submitted to the CoC's designated HMIS implementation at least once a year to cover the whole year of required client data collected by the project. (Federal Register/Vol.69 No.146/Friday, July 30, 2004)

If a combination of non-HMIS participating clients and HMIS participating clients are present in the project, the project must have two Project Information records in set up in HMIS, one with 'HMIS Participating Project' marked "Yes" and one with 'HMIS Participating Project' marked "No."

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

Record the method used to track the nights that a client stays at a project in 'Emergency Shelter Tracking Method.' One method must be identified in an HMIS for each emergency shelter project. Reporting and outcome requirements will differ depending on the method utilized by the shelter.

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

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

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

  2. All clients in the closing HMIS shelter project must be exited

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

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

 

Projects that target certain populations are advised that nothing in these standards allows for circumventing fair housing laws. The Fair Housing Act prohibits discrimination because of, among other things, familial status. Except where otherwise permitted by the federal program statute, housing covered under the Fair Housing Act may not deny admission to households with children.

 

Record whether a HOPWA-funded project is a "Medically Assisted Living Facility" or not, or that the project is not HOPWA funded (HOPWA funding source will also be identified at 2.06 Funding Sources).

System Logic and Other System Issues:  'Project ID' must be assigned to each project via a system generated number or code. Each project must receive an identifier that is unique within the HMIS and consistently associated with that project. Each project must be associated with one and only one organization (data element 2.01); separate projects operated by the same agency must be associated with the same 'Organization ID.' The name of the project must be captured in text within the HMIS. An HMIS application may permit the creation of a common name element more familiar to users for use within the application while retaining the legal name for use in reporting.

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. A project must be able to identify multiple affiliated residential projects if “yes” to Dependent A.

One 'Emergency Shelter Tracking 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. Utilization of the night-by-night method does not mean that an HMIS must identify a client in a specific bed. If the HMIS supports a custom module that identifies clients in a bed, that module may continue to be used. However, use of that module does not necessarily equate with the night-by-night model.

FY2022 Revision Summary: Add "Medically Assisted Living Facility" (Field 9). Clarify System Logic and Other System Issues. Define 'Operating Start Date' and 'Operating End Date' in the case of 'HMIS Participating Project' changes.

2.02 Data Element Fields and Responses:

Field Number

Field Name

Dependency

Response Category/
Data Type

Descriptions

1

Project ID

None

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

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

2

Project Name

None

[Text]

The project's name. While the project name is not required to match grant agreements, the project name should be consistent with the name used across reports (e.g.: Annual Performance Report and Housing Inventory Count).

3

Operating Start Date

None

[Date]

The first day on which a project provided (or will provide) services and/or housing. For projects that began operating prior to October 1, 2012, the start date may be estimated if it is not known. Projects that are fully funded but have not yet begun operating may be entered with a future project start date that reflects the date the project will begin providing services.

If a project's 'HMIS Participating Project' status changes, 'Operating Start Date' should indicate the start date of the changed 'HMIS Participating Project' status if it is a new iteration of the project in HMIS due to HMIS Participating Project' status changes only.

4

Operating End Date

None

[Date]

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

If a project's 'HMIS Participating Project' status changes, 'Operating End Date' should indicate the end date of the former 'HMIS Participating Project' status.

5

Continuum Project

None

0

No

 

1

Yes

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

6

Project Type

None

12

Homelessness Prevention

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

4

Street Outreach

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

1

Emergency Shelter

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

2

Transitional Housing

A project that provides temporary lodging and is designed to facilitate the movement of homeless individuals and families into permanent housing within a specified period of time, but no longer than 24 months. Requirements and limitations may vary by program, and will be specified by the funder.

11

Day Shelter

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

8

Safe Haven

A project that offers supportive housing that (1) serves hard to reach homeless persons with severe mental illness who came from the streets and have been unwilling or unable to participate in supportive services; (2) provides 24-hour residence for eligible persons for an unspecified period; (3) has an overnight capacity limited to 25 or fewer persons; and (4) provides low demand services and referrals for the residents.

13

PH - Rapid Re-Housing

A permanent housing project that provides housing relocation and stabilization services and short- and/or medium-term rental assistance as necessary to help a homeless individual or family move as quickly as possible into permanent housing and achieve stability in that housing.

3

PH - Permanent Supportive Housing (disability required for entry)

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

10

PH - Housing with Services (no disability required for entry)

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

9

PH - Housing Only

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

14

Coordinated Entry

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

6

Services Only

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

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

  • One residential project AND

    • Does not offer to provide services for all the residential project clients; OR

    • Only serves clients for a portion of their project stay (e.g.: provides classes); OR

    • Information sharing is not allowed between residential project and service provider.

  • Multiple residential projects of the same project type (e.g. multiple PH:PSH) AND

    • Does not serve all the residential project clients; OR

    • Information sharing is not allowed between residential projects and service provider.

  • Multiple residential projects of different project types (e.g. PH:RRH and PH:PSH)

  • Emergency Shelter(s)

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

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

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

7

Other

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

A

Affiliated with a residential project

Field 6, Response 6

0

No

 

1

Yes

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

B

Project ID(s) of residential project(s) affiliated with SSO

Field A, Response 1

[List of HMIS Residential Project IDs]

Residential Project Types are: 1, 2, 3, 8, 9, 10, 13

C

Emergency Shelter Tracking Method

Field 6 Response 1

0

Entry/Exit Date (e/e)

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

3

Night-by-Night (nbn)

The night-by-night method may be used by some high-volume shelters and shelters where a significant proportion of clients spend a night at the shelter as needed on an irregular basis. The night-by-night method relies on creating a separate record of each individual date on which a client is present in the shelter as a means for calculating length of stay and implies that the emergency shelter is generally unable to collect as much client data at project exit as an emergency shelter that uses an entry/exit method for tracking utilization. In this method: (1) entry information is collected the first time that a client stays at the shelter (2) the project records every discrete date (or series of dates) that the client utilizes a bed; (3) the HMIS maintains historical data on the nights a client is sheltered; (4) the client may be exited when shelter staff has information that indicates that the client is unlikely to return to the shelter or the system may be designed to automatically generate an exit (dating back to the day after the last bed night) after an extended absence; and (5) for reporting purposes, a client's length of stay in the project will be based on the actual number of bed nights and not on the period of time from entry to exit.

D

Housing Type

Field 6 Responses 1, 2, 3, 8, 9, 10, 13

1

Site-based - single site

All clients are housed in a single project facility.

2

Site-based - clustered/ multiple sites

Clients are housed in more than one project facility in multiple locations, but more than one client is housed in each project facility. The facility locations are owned, operated, or sponsored by the project.

3

Tenant-based - scattered site

Clients have leases or other occupancy agreements and are housed in residences that are not owned or managed by the project.

7

HMIS Participating Project

None

0

No

"No" indicates that no persons residing in or being served by this project have client data collected about them in the Universal Data Elements, Common Data Elements, and Federal Partner Program Specific Elements in the Continuum's HMIS.

1

Yes

"Yes" indicates that all persons residing in or being served by this project have client data collected about them in the Universal Data Elements, Common Data Elements, and Federal Partner Program Specific Elements in the Continuum's HMIS.

8

Target Population

None

1

DV: Domestic Violence victims

At least 75% of persons served by the project must be victims of domestic violence.

3

HIV: Persons with HIV/AIDS

At least 75% of persons served by the project must be persons with HIV/AIDS.

4

NA: Not applicable

Neither of the other response categories applies.

9

HOPWA-funded Medically Assisted Living Facility

None

0

No

HOPWA-funded project is not a Medically Assisted Living Facility

1

Yes

HOPWA-funded project is a Medically Assisted Living Facility

2

Non-HOPWA Funded Project

Project is not HOPWA funded

2.02 Specifications:

Data Collected About All Projects
Funder/Program Component All Programs - All Components
Project Type Applicability All HMIS Project Types
XML <Project><TrackingMethod><Affiliation>
CSV Project and Affiliation
Collection Point Initial HMIS project set up, reviewed/updated no less than annually

 

2.03    Continuum of Care Information

Rationale: To associate each project entering data into the HMIS, as well as any residential continuum projects not participating in HMIS, with one or more Continuum of Care (CoC) for reporting and data exchange purposes.  For more information about setting up projects that operate in multiple CoCs, please refer to Section 1.2 Introduction to Project Descriptor Data Elements

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

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

Information must be reviewed and updated at least annually. Data entry errors should be edited to correct the error.

'Geocode,' 'Project ZIP code,' and 'Project Street Address' fields must reflect the location of the project's principal lodging site or, for multiple site projects, the area in which most of the project's clients are housed. Tenant-based scattered site projects and Victim Services Providers are only required to complete the geocode and ZIP code fields and may use mailing or administrative address information if they wish to complete the remainder of the address fields. When there are multiple records of Continuum of Care Information because of a single project's association with different CoCs, the geocodes will differ. The geocode must be located within the CoC in the same record.

System Logic and Other System Issues:  There is a many-to-one relationship between this data element and 2.02 Project Information; there may be multiple current records of this data element at any given time. Add, edit, or remove associations with CoCs as needed to reflect changes. There must be a one-to-one relationship to Project Information if the project only serves one CoC (most common).  

Projects may be funded to provide for housing and/or services to clients residing in only one CoC (e.g., CoC: Transitional Housing), or they may be funded for housing and/or services across multiple CoCs (e.g.: VA: SSVF). The system must allow for multiple codes to be selected per project. It must be possible to associate a project with the CoC code for every geographic area in which the project operates and for which is will be entering data into the HMIS.

The system should set a default for the CoC Code, which should be the CoC Code for the continuum operating the HMIS. The CoC Codes in this data element are expected to be used to populate an option list of CoC Codes for data element 3.16 Client Location when one is required.

It must be possible to leave address fields blank. HUD will release a regularly updated crosswalk of ZIP codes and a geography type for each. 'Geography type' must correspond to the HUD crosswalk; geography types may not be locally defined.

FY2022 Revision Summary: None.

2.03 Data Element Fields and Responses:

Field Number

Field Name

Dependency

Response Category/
Data Type

Descriptions

1

Continuum Code

None

[Text][6 characters: XX-XXX]

HUD-assigned CoC codes for the project location

CoC Codes as published by HUD annually. The format of these CoC codes is 2 letters (state abbreviation), a dash, and 3 numbers, e.g., XX- 999. The HMIS software may provide a drop- down list of valid CoC Codes or require manual entry.

2

Geocode

None

[6 digits]

Geocode associated with the geographic location of the project's principal site. HUD provides a list of geocodes as part of the annual CoC Program competition.

3

Project Street Address 1

None

[Text]

The street address of the project's principal site or, for scattered site projects, the address in which most of the project's clients are housed. For tenant-based scattered site projects, the field may be left blank or the administrative address may be used.

4

Project Street Address 2

None

[Text]

 

5

Project City

None

[Text]

 

6

Project State

None

[2 letters]

Standard state abbreviation

7

Project ZIP Code

None

[5 digits]

The ZIP code of the project's principal site or, for scattered site projects, the ZIP code in which most of the project's clients are housed.

8

Geography Type

None

1

Urban

 

 

 

 

2

Suburban

 

 

 

 

3

Rural

 

2.03 Specifications:

Data Collected About All Continuum Projects
Funder/Program Component All Programs - All Components
Project Type Applicability All HMIS Project Types
XML <ProjectCoC>
CSV ProjectCoC
Collection Point Initial HMIS project set up, reviewed/updated no less than annually

 

2.06    Funding Sources

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

Project Setup Instruction: The funding sources listed in Field 1 are the federal partner programs and their project components that have agreed either to participate in HMIS or are otherwise considered continuum projects. There are also response options for 'Other funding source' and 'NA.'

All continuum projects that receive funding from any of the funding sources identified in this element must record: the name of the federal program and grant component; a grant identifier; grant start date; and grant end date. Each project must include as many Funding Source records as is necessary to identify all the funding sources for the project that appear on the list. Identification of additional funding sources is not required.

When a project is funded by multiple grants and 100% of clients served by the project receive lodging and/or services under each of the grants, a single project may be set up in HMIS as long as it is configured such that data collection and reporting requirements for each funder are satisfied.

When a project is funded by multiple grants and different clients receive lodging and/or services under different grants, it must be possible to identify which clients were served by which grant (or grants) and any grant-level reporting must exclude clients not specifically served under the grant. In general, this is accomplished in one of two ways:

The 'Grant identifier' must uniquely identify the grant, although several projects may share the same grant identifier if they are, in fact, funded under the same grant but split into separate projects in HMIS. This may happen, for example, when a grant has multiple sub-grantees and needs to be able to identify which clients were served by each of the subgrantees, or when a single grant funds services that fall under different project types.

Correctly identifying each grant's 'Start Date' and 'End Date' allows for inclusion or exclusion of certain projects in grant- or system-level reporting. For example, this information is critical in the generation of income measures for the system performance measures.

The system administrator must regularly collect and review funding source information, grant start, and grant end dates from all projects. The information is required to be reviewed and updated, if necessary, at least annually, but HUD and the federal partners strongly recommend reviewing the grant identifiers before any HUD or federal partner-required reporting or data transfers.

Additional information on federal partner programs and related project setup guidance can be found in the applicable HMIS Federal Partner Program Manuals on the HUD Exchange.

System Logic and Other System Issues:  This is a transactional data element, a single project may have multiple current and historical records. Allow corrections for data entry errors. An HMIS must allow projects with multiple Funder sources and multiple grants (with potentially different grant terms) from the same funding source to record and store all funding sources for the project.

FY2022 Revision Summary: New Funding Sources added: "HUD: CoC - Joint Component RRH/PSH," “HUD: HOME,” “HUD: HOME (ARP),” “HUD: PIH (Emergency Housing Voucher).”

2.06 Data Element Fields and Responses:

Field Number

Field Name

Dependency

Response Category/ Data Type

Descriptions

1

Funder Program and Components

None

1

HUD: CoC - Homelessness Prevention (High Performing Communities 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)

49

HUD: CoC - Joint Component RRH/PSH

44

HUD: CoC - Joint Component TH/RRH

8

HUD: ESG - Emergency Shelter (operating and/or essential services)

9

HUD: ESG - Homelessness Prevention

10

HUD: ESG - Rapid Re-housing

11

HUD: ESG - Street Outreach

47

HUD: ESG - CV

35

HUD: Pay for Success

12

HUD: Rural Housing Stability Assistance Program

13

HUD: HOPWA - Hotel/Motel Vouchers

14

HUD: HOPWA - Housing Information

15

HUD: HOPWA - Permanent Housing Placement (facility based or TBRA)

16

HUD: HOPWA - Permanent Housing Placement

17

HUD: HOPWA - Short-Term Rent, Mortgage, Utility assistance

18

HUD: HOPWA - Short-Term Supportive Facility

19

HUD: HOPWA - Transitional Housing (facility based or TBRA)

48

HUD: HOPWA - CV

36

HUD: Public and Indian Housing (PIH) Programs

20

HUD: HUD/VASH

52

HUD: PIH (Emergency Housing Voucher)

50

HUD: HOME

51

HUD: HOME (ARP)

21

HHS: PATH - Street Outreach & Supportive Services Only

22

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

23

HHS: RHY - Maternity Group Home for Pregnant and Parenting Youth

24

HHS: RHY - Transitional Living Program

25

HHS: RHY - Street Outreach Project

26

HHS: RHY - Demonstration Project

27

VA: CRS Contract Residential Services

37

VA: Grant Per Diem - Bridge Housing

45

VA: Grant Per Diem - Case Management/Housing Retention

40

VA: Grant Per Diem - Clinical Treatment

39

VA: Grant Per Diem - Hospital to Housing

38

VA: Grant Per Diem - Low Demand

41

VA: Grant Per Diem - Service Intensive Transitional Housing

42

VA: Grant Per Diem - Transition in Place

30

VA: Community Contract Safe Haven Program

33

VA: Supportive Services for Veteran Families

46

Local or Other Funding Source (Please Specify)

34

N/A

A

If local or other, please specify

Field 1 Response 46

[Text]

 

2

Grant Identifier

None

No Specified Format

The 'Grant Identifier' may be the grant number assigned by the federal partner or any other grant identification system used by the federal partner, grantee or the CoC, unless a specific grant identifier is required by the federal partner.

3

Grant Start Date

None

[Date]

The start date of the grant

4

Grant End Date

None

[Date]

The grant end date may remain empty until the term of the grant ends. If the exact same grant source and component is renewed (with the exception of projects funded by HHS:RHY), the grant end date is not required to be entered. The grant end date may remain empty until such time as the renewal(s) end.

2.06 Specifications:

Data Collected About All Projects
Funder/Program Component All Programs - All Components
Project Type Applicability All HMIS Project Types
XML <Funder>
CSV Funder
Collection Point Initial HMIS project set up, reviewed/updated no less than annually

 

2.07    Bed and Unit Inventory Information

Rationale: To record bed and unit inventory information for each residential project entering data into the HMIS, as well as any residential continuum projects not participating in HMIS, for use in tracking utilization, data quality analysis, and reporting.  

Project Setup Instruction: At a minimum, an HMIS must have an accurate record of bed and unit inventory information for all continuum residential projects. These data must be finalized and accurately entered by the time of the Housing Inventory Count. The 'Inventory Start Date' for these records should reflect the date on which they first became available under the relevant project; if the precise date is not available, an estimate may be used.

A project may have multiple current records of inventory:

For example, a project serving single adults that has 100 beds, of which 20 are seasonal, would have two bed and unit inventory records. One record is for the 80 facility-based year-round beds for households without children and a second record is for the 20 facility-based seasonal beds for households without children.

A project may have multiple historical records of inventory. Changes over time should be documented such that a historical record of inventory is retained. Minor day-to-day fluctuations need not be recorded, but differences due to significant changes in project operations should be entered as they occur. For example, if a project spends down its annual operating budget in 6 months instead of 12 months, this could be considered a significant change to the inventory. While what constitutes significant change is left to the community to define, your inventory should be reflective of the reality of residential project operations and data quality comparisons between the number of available beds, occupied beds, and persons enrolled in the projects.

While inventory counts must be accurately recorded within the last week of each of the months of January, April, July, and October (to satisfy APR & LSA inventory accuracy), the CoC should attempt to backdate the date associated with the revised inventory to the actual date that the significant inventory change occurred. More frequent updates for significant changes are encouraged, but not required. When the CoC updates the inventory records, they could enter several changes at once to accurately reflect the history of significant changes or a step-down of changes in inventory. Or, if a significant inventory change has occurred over a period of weeks, the CoC could pick a single date in the middle of the period to make the increase/decrease effective, so the average inventory and utilization comparison will be aligned. CoCs are not expected to update small variations in inventory that are temporary.

System Logic and Other System Issues: A project may have multiple current and historical records of inventory. For any inventory record, it must be possible to identify the CoC with which the inventory is associated. For projects that operate in a single continuum, there is a many-to-one relationship between this data element and 2.02 Project Information, although at any given time, only one record for this data element will be current. For projects that operate in multiple CoCs, there is a similar many-to-one relationship with 2.03 Continuum of Care Information.

If the HMIS produces CoC-level reporting on 2.07 Bed and Unit Inventory Information for more than one continuum (e.g., Longitudinal Systems Analysis or Housing Inventory Counts), records of inventory must be separate and associated with the appropriate Continuum of Care Information record.

Data entry errors should be corrected; a new record should be created to document a change in information. A new record is only required if a change has occurred. Not all fields are required for all projects.

FY2022 Revision Summary: Clarified instruction for updates and significant changes.

2.07 Data Element Fields and Responses:

Field Number

Field Name

Dependency

Response Category/ Data Type

Descriptions

1

Inventory Start Date

None

[Date]

The date on which the inventory became available, or, for inventory under development, the date on which it is expected to become available.

2

Inventory End Date

None

[Date]

The last date that an inventory record is relevant:

  • For current records, 'Inventory End Date' should be blank.

  • For records that are being closed out because a change that requires a new record has occurred, 'Inventory End Date' will be the day before the effective date of the change.

  • For inventory that is no longer available, 'Inventory End Date' will be the last date that beds were available.

3

CoC Code

None

[as identified in data
element 2.03 Continuum of Care Code]

Projects that operate in more than one CoC must have separate Bed and Unit Inventory records for inventory located in each CoC. From the CoC codes entered in data element 2.03, indicate the CoC code associated with the inventory record.

4

Household Type

None

This specifies the household type (at project entry) served by beds and units in a given inventory record. Projects that serve more than one household type must have separate records of inventory for each household type.

1

Households without children

Beds and units typically serving households with adults only. This includes households composed of unaccompanied adults and multiple adults.

3

Households with at least one adult and one child

Beds and units typically serving households with at least one adult and one child.

4

Households with only children

Beds and units typically serving households composed exclusively of persons under age 18, including one-child households, multi-child households or other household configurations composed only of children.

5

Emergency Shelter Bed Types

2.02 Project Type = 'Emergency Shelter'

1

Facility Based Beds

Beds (including cots or mats) located in a residential homeless assistance facility dedicated for use by persons who are homeless.

2

Voucher Beds

Beds located in a hotel or motel and made available by the homeless assistance project through vouchers or other forms of payment.

3

Other Beds

Beds located in a church or other facility not dedicated for use by persons who are homeless.

6

Emergency Shelter Bed Availability

2.02 Project Type = 'Emergency Shelter'

Availability is recorded to identify whether the beds and units are available on a planned basis year-round, seasonally, or on an ad hoc or temporary basis, as demand indicates.

1

Year Round

Year-round beds and units are available on a year-round basis.

2

Seasonal

Seasonal beds are not available year-round, but instead are available on a planned basis, with set start and end dates, during an anticipated period of higher demand.

3

Overflow

Overflow beds are available on an ad hoc or temporary basis during the year in response to demand that exceeds planned (year-round or seasonal) bed capacity.

7-12

Dedicated Bed Inventory

All beds that have been funded by HUD or another federal partner that are dedicated to one or more of the following subpopulations must be recorded in the appropriate category. The number of beds for each subpopulation is a subset of the total bed inventory for a given project and must be equal to or less than the total bed inventory. Each category in fields 7-13 are expected to be mutually exclusive and should sum to the total beds provided in field 14. A dedicated bed is a bed that must be filled by a person in the subpopulation category (or a member of their household) unless there are no persons from the subpopulation who qualify for the project located within the geographic area. DedicatedPLUS beds do not qualify as Dedicated beds and should not be included in the Dedicated Bed Inventory unless the project has a subset of the DedicatedPLUS beds that are dedicated per the definitions below.

7

Beds dedicated to chronically homeless (CH) Veterans

None

[Integer]

The number of beds that are dedicated to house chronically homeless veterans and their household members.

8

Beds dedicated to youth Veterans

None

[Integer]

The number of beds that are dedicated to house homeless youth (persons up to age 24) veterans and their household members.

9

Beds dedicated to any other Veterans

None

[Integer]

The number of beds that are dedicated to house non-CH and non-youth veterans and their household members.

10

Beds dedicated to chronically homeless youth

None

[Integer]

The number of beds that are dedicated to house chronically homeless youth (persons up to age 24) and their household members.

11

Beds dedicated to any other youth

None

[Integer]

The number of beds that are dedicated to house non-CH and non-veteran homeless youth (persons up to age 24) and their household members.

12

Beds dedicated to any other chronically homeless

None

[Integer]

Beds dedicated to non-youth, non-Veteran chronically homeless. The number of beds that are dedicated to house chronically homeless persons and their household members.

13

Non-dedicated beds

None

[Integer]

All other (non-dedicated) beds not already accounted for in fields 7-12. The number of non-dedicated to CH, youth or veteran beds used to house homeless persons and their household members.

14

Total Bed Inventory

None

The sum total of the [integers] from fields 7 through 13 [Integer]

The 'Bed Inventory' is a count of the total number of beds available for occupancy as of the 'Inventory Start Date.' The number of beds is generally equivalent to the number of persons a lodging project can house on a given night and, for Emergency Shelters, should be counted distinctly for each combination of 'Bed Type' and 'Availability.' For projects that serve multiple household types, but where a precise number of beds are not designated exclusively for a particular type of household, the total number of beds may be distributed among the household types served by the project using one of the following methodologies:

  • Divide the beds based on how the bed(s) were used on the night of the HIC. If the facility is not at full capacity on the night of the count, then extrapolate the distribution based on the prorated distribution of those who are served on the night of the count.

  • Divide the beds based on average utilization. For example, a project has 100 beds that could be used by either households with only children or households with at least one adult and one child. If one-half of the beds are used by persons in households with only children on average and the other half are used by persons in households with at least one adult and one child, then record 50 beds for households with only children, and for the 50 beds for households with at least one adult and one child in the HIC.

Projects that only have units and no fixed number of beds can estimate the number of beds based on average household size using a multiplier factor (e.g., a project with 30 family units and an average family size of 3 would record 90 beds). Projects that provide housing rental assistance and have a fixed number of vouchers should determine the number of beds and units based on the number of vouchers currently funded and available for use. Projects that provide emergency shelter or housing rental assistance vouchers and without a fixed number of units or vouchers (e.g., Emergency Shelter-hotel/motel project, Rapid Re- Housing, some scattered site PH-Permanent Supportive Housing) should determine the number of beds (and units) based on the maximum number of persons (and households) who can be housed on a given night.

15

Total Unit Inventory

None

[Integer]

The 'Unit Inventory' is a count of the total number of units available for occupancy as of the 'Inventory Start Date.' Projects that do not have a fixed number of units (e.g., a congregate shelter project) may record the bed inventory, the number of residential facilities operated by the project, or the number of rooms available as the unit integer. For additional  instructions, see 'Bed Inventory,' above.

2.07 Specifications:

Data Collected About All Residential Projects
Funder/Program Component All Programs - All Components
Project Type Applicability

Emergency Shelter

Transitional Housing

PH - Permanent Supportive Housing

Safe Haven

PH - Housing Only

PH - Housing with Services

PH - Rapid Re-Housing

XML <Inventory>
CSV Inventory
Collection Point Initial HMIS project set up, reviewed/updated no less than annually