Home → Data Entry → Printer Friendly Version
To understand why the Bed and Unit Utilization Report is important, it is important to know about the Annual Homelessness Assessment Report (AHAR, aka the LSA), which is a report that HUD submits to Congress every year. All data that we upload to the AHAR comes from your HMIS data. HUD expects the data to fall within boundaries they consider reasonable. Any data that does not fit within their specifications causes an error and requires either a change to the data or an explanation. An area that typically causes great difficulties is HUD's expectation of Bed Utilization rates fall between 65% and 105%. Your Bed Utilization Rate gives an idea of how full your program is on a given night.
Bed Utilization:
Generally speaking, Bed Utilization is a measure of how many clients are being served as compared to the total number of beds reported on the Housing Inventory Chart (HIC).
If the Bed Utilization percentage is too high, either the number of beds
reported on the HIC is low or you are perhaps not exiting your
households from HMIS in a timely way or you are serving larger families
than was anticipated.
If the Bed Utilization percentage is too low, your project either served fewer households than was anticipated, not all your households got entered into HMIS, or the number of beds reported on the HIC is too high. If you are unsure of which is the case, please contact the HMIS Department at COHHIO for help.
To check your data for accuracy, you should log into R minor elevated. (See below for how that works.)
Unit Utilization:
Unit Utilization is the average number of households who were served in your project, divided by the number of units reported on the HIC. In this calculation, a household can be a single individual or multiple family members and to get your total Unit Count, we add together the number of units reported for your family beds and the number of beds reported for your individual beds.
Unit Utilization is not currently used in any HUD reporting or in any CoC-level scoring or monitoring. This could change, however.
How it's all calculated:
Instead of measuring utilization only on the last Wednesday of each month, we are now counting bed nights* and dividing total bed nights served by total possible bed nights* served.
* A bed night is a single night in a bed.
Example A: Client A enters a shelter on May 1 and exits on May 5. They spent four nights in the shelter, so that was 4 bed nights from that client alone in the month of May for that shelter.
Example B: PSH Project A served 10 people every single night in the month of June. Each client was served 30 bed nights during that month, and since there were 10 clients, that PSH project served a total of 300 bed nights for the month of June.
* Total possible bed nights is calculated based on how many beds or units a project has x how many days are in the given month.
Example C: PSH Project B has 5 beds. That project's total possible bed nights for the month of April (which has 30 days in it) is 30 x 5, which is 150.
Example D: Using what we know from Example B of PSH Project A's total
bed nights for the month of June, let's calculate what their bed
utilization was for that month. They have 11 beds and June has 30 days
so since 11 x 30 = 330 possible bed nights. Their bed utilization is bed
nights (300) divided by possible bed nights (330), which is: 91%!
Please refer to the Bed Utilization guidance here for instructions on how to run and interpret the report.
Download the attached document.
Permanent Supportive Housing (PSH) and Rapid Re-Housing (RRH) are both considered permanent housing project types and as such, a single household would normally be prioritized for either RRH or PSH. On rare occasions, a household may need to be served in both RRH and PSH. Recording this kind of scenario in HMIS is tricky because even though it is allowed, we do not want the data to incorrectly make it appear as if a household was served with duplicative resources. For more information, please check the Ohio Balance of State training and guidance about Rapid Rehousing and Permanent Supportive Housing.
End users should keep the following in mind when thinking about how to
record Entry, Move-In, and Exit Dates in HMIS for households served by both RRH
and PSH:
1. There should only be one Move-In Date between a project stay’s Entry and Exit Dates.
2. A Move-In Date should only fall within one project stay’s Entry and Exit Dates.
3. When a Move-In Date = the Exit Date, it will count as being “between” a project stay’s Entry and Exit Dates.
Following are some example scenarios that outline how to manage HMIS data
entry for households served by both RRH and PSH.
Scenario 1: Household prioritized
for PSH is moving into an RRH unit until the PSH unit becomes available.
April 2, 2020: household is prioritized for and accepted into PSH, but a PSH unit isn’t available until July
April 15, 2020: household moves into a RRH unit because their medical needs are so great and they cannot find the temporary housing they need until July
July 1, 2020: the PSH unit becomes available, lease is signed
July 15, 2020: household moves into the PSH unit
Table 1 shows how the entry and exits dates for the RRH and PSH projects should be recorded in HMIS for Scenario #1:
|
Project |
Entry
Date |
Move
In Date |
Exit
Date |
|
RRH |
4/2/2020 |
4/15/2020 |
7/14/2020 |
|
PSH |
7/15/2020 |
7/15/2020 |
? |
Table 1
Note that the Entry – Exit date range does not overlap with the PSH’s Entry – Exit date range. This is necessary because PSH and RRH are both permanent housing project types, and any overlaps will be read as serving the same household with redundant services. Any overlap of Move-In Date – Exit Dates in PH project types would indicate a household was sleeping in two places at once, which is not possible.
The RRH’s Exit Date must be the Move-In Date – 1 day because the Move-In Date of the PSH project must fall outside the RRH’s Entry – Exit date range.
This workflow will throw Data Quality warnings because the PSH Entry Date = the Move-In Date, but that is ok. Warnings are meant to flag unusual situations, and this should be an unusual situation. In this case, there is no need to correct anything based on the warning.
Table 2 provides general guidance about how entry, exit, and move-in dates should be determined and recorded in HMIS when clients are served by both RRH and PSH projects in Scenario 1:
|
Project |
Entry
Date |
Move
In Date |
Exit
Date |
|
RRH |
Date the HH accepted to the RRH project |
Date the HH literally moved into the RRH unit |
Move-In/Entry Date of the PSH project MINUS 1 day |
|
PSH |
Date the HH moved into the PSH unit |
Date the HH moved into the PSH unit |
Date the HH stops receiving PSH services. |
Table 2
Scenario 2: Household
prioritized for PSH but moving costs and/or security deposit is being paid by
RRH.
In this scenario, the household is moving into a PSH unit, so there will
only be one Move-In Date. Please note that moving costs and deposits are often allowable
expenses for PSH projects. If PSH projects need assistance to determine what
funds or budgets may be used for these costs, please contact the CoC team.
April 2, 2020: household is prioritized for and accepted into PSH, but the RRH project will pay their moving costs and/or security deposit
April 12, 2020: household moves into the PSH unit
Table 3 shows how the Entry and Exits Dates for the RRH and PSH projects should be recorded in HMIS for Scenario #2:
|
Project |
Entry
Date |
Move
In Date |
Exit
Date |
|
RRH |
4/2/2020 |
[no Move-In Date] |
4/11/2020 |
|
PSH |
4/12/2020 |
4/12/2020 |
? |
Table 3
Note that the Entry – Exit date range does not overlap with the PSH’s Entry – Exit date range. This is necessary because PSH and RRH are both permanent housing project types, and any overlaps will be read as serving the same household with redundant services.
The RRH’s Exit Date must be the Move-In Date – 1 day because
the Move-In Date of the PSH project must fall outside the RRH’s Entry – Exit
date range.
This workflow will throw Data Quality warnings because the PSH Entry Date = the Move-In Date, but that is ok. Warnings are meant to flag unusual situations, and this should be an unusual situation. In this case, there is no need to correct anything based on the warning.
Table 4 provides general guidance about how entry, exit, and
move-in dates should be determined and recorded in HMIS when clients are served
by both RRH and PSH projects in this type of scenario:
|
Project |
Entry
Date |
Move
In Date |
Exit
Date |
|
RRH |
Date the HH accepted to the RRH project for moving costs/security deposit expenses only |
[no move-in date because the HH is not moving into a RRH unit] |
Move-In/Entry Date of the PSH project MINUS 1 day |
|
PSH |
Date the HH moved into the PSH unit |
Date the HH moved into the PSH unit |
Date the HH stops receiving PSH services. |
Table 4
Hi all!
In R minor elevated, you may have noticed some new Errors/Warnings in the Data Quality reporting. We have been working on a data analysis for the purposes of increasing Rapid Rehousing dollars to our CoC but there are many discrepancies in the way households are being assigned a “Destination” at Exit. This problem is making it difficult to determine how much more money is needed.
HUD suggests that when it is not clear what a particular Destination should be case managers should select the closest approximation of where a household is going at Exit. However, there are times when we can choose the correct Destination with confidence. Examples of these can be found in the new Errors/Warnings in R minor elevated:
A household who goes from an Emergency Shelter (for example) into a Rapid Rehousing unit should have a Destination from the Emergency Shelter stay of “Rental by client, with RRH or equivalent subsidy”. If that household is entering a Rapid Rehousing project in the Balance of State CoC or the Mahoning CoC, that household would also have an Entry Exit into the Rapid Rehousing project.
A household who goes from an Emergency Shelter (for example) into Permanent Supportive Housing should have a Destination from the Emergency Shelter stay of “Permanent housing (other than RRH) for formerly homeless persons”. If that household is entering a PSH project in the Balance of State CoC or the Mahoning CoC, that household would also have an Entry Exit into the Rapid Rehousing project.
A household who goes from an Emergency Shelter (for example) into Transitional Housing should have a Destination from the Emergency Shelter stay of “Transitional housing for homeless persons (including homeless youth)”. If that household is entering a TH project in the Balance of State CoC or the Mahoning CoC, that household would also have an Entry Exit into the TH project.
|
Project Type |
Project Type’s HUD Definition |
Corresponding Destination |
|
A project that offers temporary shelter (lodging) for the homeless in general or for specific homeless populations. Requirements and limitations may vary by program, and will be specified by the funder. |
Emergency shelter, including hotel or motel paid for with emergency shelter voucher, or RHY-funded Host Home shelter |
|
|
Transitional Housing (TH) |
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. |
Transitional housing for homeless persons (including homeless youth) |
|
Safe Haven (SH) |
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. |
We no longer have any Safe Havens in the Balance of State so
this will rarely be the correct Destination (unless you’re in Region 6), but
if there is an Exit to our old Safe Haven, it should be:
|
|
PH - Rapid Re
|
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. |
Rental by client, with RRH or equivalent subsidy |
|
PH – Permanent Supportive Housing (PSH) |
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. |
Permanent housing (other than RRH) for formerly homeless persons |
In our HMIS, every provider name has a suffix at the end of its name like “- ES” or “- RRH”. These abbreviations are detailed in the table above in the Project Type column.
Household goes from Unsheltered to Rapid Rehousing
|
Provider Name |
Entry Date |
Exit Date |
Destination |
|
Unsheltered |
3/1/2020 |
4/1/2020 |
Rental by client, with RRH or equivalent subsidy |
|
Ashtabula – RRH |
3/20/2020 |
|
[still in project] |
Household goes from Transitional Housing to Permanent Supportive Housing
|
Provider Name |
Entry Date |
Exit Date |
Destination |
|
Ashtabula – TH |
3/1/2020 |
4/1/2020 |
Permanent housing (other than RRH) for formerly homeless persons |
|
Ashtabula – PSH |
3/20/2020 |
|
[still in project] |
Household goes from Unsheltered to a Domestic Violence Shelter who does not participate in HMIS
|
Provider Name |
Entry Date |
Exit Date |
Destination |
|
Unsheltered |
3/1/2020 |
4/1/2020 |
Emergency shelter, including hotel or motel paid for with emergency shelter voucher, or RHY-funded Host Home shelter |
Household goes from an Emergency Shelter to Rapid Rehousing
|
Provider Name |
Entry Date |
Exit Date |
Destination |
|
Ashtabula - ES |
3/1/2020 |
4/1/2020 |
Rental by client, with RRH or equivalent subsidy |
|
Ashtabula – RRH |
3/20/2020 |
|
[still in project] |
Four new Errors and six new Warnings have been added, but they represent only two main ideas:
Please watch the video above for more explanation and check R minor elevated to ensure that your Destinations have been answered correctly. Check the Guidance section for detailed information about any individual Error/Warning.
Status Updates are used to document changes to income, benefits, insurance, or domestic violence history for one or many clients while an enrollment is still open. If a change is found during the exit interview the changes can be documented during the exit interview/exit assessment.
You can find detailed instructions on creating Status Updates or Annual Assessments on this page.
How Do I Conduct a Program Status/Annual Assessment?
Each client should have at least one Case Management Service Transaction to indicate that client's intake process.
Each client may also have a second Service Transaction of some kind besides Case Management.
As your client progresses through your program, users should update any services given, such as rental payments.
For each month enrolled, there should be at least one Case Management Service Transaction.
So, a typical collection of Services Transactions for a client might be:
| Date | Service | Activity Represented |
| 5/1/2024 | Case Management | Intake |
| 6/15/2024 | Case Management | Found housing for the client |
| 6/15/2024 | Rental Assistance | Paid first month's rent |
| 6/15/2024 | Security Deposit | Paid deposit |
| 7/1/2024 | Rental Assistance | Paid 2nd month's rent |
| 7/1/2024 | Case Management | Client needs ongoing rental assistance |
| 8/1/2024 | Case Management | Recertification |
| 8/1/2024 | Rental Assistance | Paid 3rd month's rent |