Home → ServicePoint → 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.
Household Data sharing is an optional feature in ServicePoint designed to ease the data entry burden for households by collecting common data elements where the answer is exactly the same for all members. The user will fill out the Household Data Sharing Assessment, save the common answers, and then continue with the typical workflow by going through each household member in the appropriate assessment and completing the rest of the answers that are different.
It will not be necessary to use Household Data Sharing if none of the answers are exactly the same for all the household members and when working with Single households. It may useful to adjust your intake forms to make it easier to see which data elements are the same across the household.
How to Use Household Data Sharing
Follow the HMIS workflow to complete the steps to create the Household, add the Release of Information, and enter the household into your program using Add Entry/Exit (HMIS Workflow Steps 2-5). Once inside the Entry/Exit Data screen, users will notice a section heading in the Entry Assessment area called Household Data Sharing with a button called Add Household Data (See Figure 1).
Figure 1: How to find the Household Data Sharing assessment.
Click the Add Household Data button (Red circle in Figure 1.) A popup window titled Household Data Sharing will appear. See Figure 2.
Figure 2: Household Data Sharing Assessment
Note: In some instances, not all of the data elements will be answered. Data elements that are not answered will still show '--Select--' for the answer; these will be answered in the regular assessment after the Household Data Sharing assessment has been saved.
Notice the common data element answers will be saved in each household member's default assessment.
Warning: Do not select some of the household members, answer some questions then change the checkmarks, and then answer other questions. That will not work; it will create layers of overlapping and conflicting data and will cause data quality issues.
From this point, proceed through the standard data entry workflow and answer the rest of the questions for each household member. Notice that the data elements answered within Household Data Sharing assessment have been saved into the full assessment.
The following process details how to answer the Exit Assessment. You will need to fill out the applicable parts of the assessment and click "Save" and then move to the next household member using the Household Members list on the left. Once you have finished with all household members then click "Save & Exit".
Housing Status at Exit
The Housing Status should already show an answer based on the clients answer at Entry. If the Housing Status at Exit is different than the answer already given, then choose the correct response. If you are exiting a client into another program, you need to answer how the client is exiting the current program, not what the client's status will be in the new program.
Income at Exit
The Income questions will already have answers based on what was entered for the client at Entry and possibly updates during their stay.
If you have any changes to income that occurred within past 30 days that have not already been entered via Entry (if it's within 30 days of program entry) or Backdate Mode (if it's a change that occurred during the stay) then you will need to enter those changes now.
You may need to update some or all of these elements depending on the type of income change:
Possible Income at Exit situations:
1. No recorded income and exiting with no income
If the client has no reported income and they are leaving with no income then you do not need to change any of the Income questions. The income questions should be already No, 0, and no sub-assessment records and they should be left this way.
2. No recorded income but exiting with income
If the client had no income previously and now has income within 30 days of exit, then you need to change "Income Received from any source in the past 30 days?" to "Yes", replace the "0" in "Total Monthly Income" with their new monthly income total, then Add an Income sub-assessment record to create a new record of that Income.
3. Has recorded income but is exiting with no income
If the client had income and is no longer receiving any income, then you need to change "Income received from any source in the past 30 days?" to "No", replace the amount in "Total Monthly Income" with "0" and Edit ($) the Monthly Income sub-assessment record(s) and put an End Date(s) on the income(s) that ended (do not change "Receiving Income Source" inside the sub-assessment , it should stay set to "Yes" so the reports can tally the months that they did have the income).
4a. Has recorded income and is exiting with same income (no change in amount or source)
If the client had income previously and is exiting with the same Income from the same source, then you do not need to change anything on the income.
4b. Has recorded income and is exiting with different income (change in amount and/or source)
If the client already had income and is exiting with different income then you would leave "Income received from any source in the past 30 days?" set to "Yes", then enter their new monthly income into "Total Monthly Income."
Depending on the changes in the Sources of Income you will need to do some of the following:
When an Income ends:
Click the pencil next to the Monthly Income sub-assessment record that has ended and add an End Date on the Income Source. Do not change Receiving Income Source inside the sub-assessment to No.
When an existing Income amount changes:
Click the pencil next to the Monthly Income sub-assessment record that has ended and add an End Date on the Income Source. Do not change Receiving Income Source inside the sub-assessment to No.
Add an Income sub-assessment record for that Income Source with the new amount. Leave the End Date blank.
When a new Income is gained
Add an Income sub-assessment record for that Income Source with the new amount. Leave the End Date blank.
Regardless of the combination in this example (4b) you should wind up with at least one Income that has an amount and no End Date.
Non-cash Benefits at Exit
Changes to non-cash benefits at exit should be handled in the same manner as Income with the exception that you don't have a Total Monthly Income amount question to include. Also, depending on the benefit, there may not be a dollar amount inside the sub-assessment.
Interims and Follows Ups is a new ServicePoint feature designed to record changes in Income or Non-Cash Benefits during a program stay (Interim) and after a program stay (Follow Up).
This feature will allow you to update Income and Non-Cash Benefits that have occurred for the client as a general change, or as the result of a recertification or Annual Assessment. It will also allow you to record that a recertification of Income or Non-Cash Benefits was performed when there was no change to Income. This is especially important for programs where the client stays in your program more than 365 days.
Some Important Points:
How to Enter Interims:
These instructions assume the following:
Once the Annual Assessment or recertification has been completed, or the client informs you of a change to income or benefits, their HMIS record will need to be updated. Follow the steps below to update the client's record in HMIS.
1. Login to ServicePoint. If necessary, click Enter Data As and select the correct provider.
2. Click ClientPoint, find the client that needs an update in the Search screen, and open the record.
3. On the Summary tab, in the Entry/Exits dashlet, find the relevant Entry and click the pencil icon for the Entry Date. (See Figure 1.)
Figure 1
4. Click "Save & Continue" on the Edit Entry Data window. (See Figure 2.)
Figure 2
5. There will be two new columns in the Entry/Exit data. One for Interims and one for Follow Ups. Click the Interim icon
for one of the household members. (See Figure 3.)
Figure 3
6. Click "Add Interim Review" in the Interim Reviews window. (See Figure 4)
Figure 4
7. The Add Interim Review window will appear. (See Figure 5.) Make sure all the household members' boxes are checked; regardless of if any of them have any changes.
Figure 5
8. Select the Review Type. "Annual Assessment" refers to the annual review agencies are required to complete on all clients. "Update" refers to any other kind of interim done, whether it is a 90-day recertification or just an update to the client income or non-cash benefits that happens during a program stay. Note: The Review Type is very important for APR reporting. If an Annual Assessment is typed as an "Update", it will not show correctly.
9. Set the Review Date to the date the review was performed or the date the client provided information about the change.
10. Click "Save & Continue". (See Figure 5.)
11. The Entry Exit Interim Review window will come up. (See Figure 6.) The Interim Review Date reflects the date entered for the when the review occurred. If no data has changed for any of the household members, simply click "Save & Exit". (See Figure 6.)
Figure 6
12. If there was a change, change the answers to reflect the income or benefit status for the client and click "Save & Exit". If there were changes on multiple clients in the household, use the Household Members sidebar to switch to to their record and make the necessary changes. (See Figure 7.)
Figure 7
13. An entry will be created in the Interim Reviews box which will show a count of all the members of the household in the single Interim record. (See Figure 8.) Click "Exit".
Figure 8
14. On the Households portion of the Entry screen, notice that each member of the household has been included in the Interim record regardless of any individual changes. (See Figure 9.) Also, the answers that were updated in the Interim record will not show on the Entry
Assessment. This is due to the Interim updates occurring after the Entry Date. The Entry Assessment only shows answers that are effective on the Entry Date.
To Make Changes to an Existing Interim Review
Perform the following steps to make changes to the answers for an existing Interim Review.
1. Click an Interim icon (See Figure 9).
Figure 9
2. Click the pencil next to the Review that requires a change.
3. Click "Save & Continue".
4. Select the correct answer to the data element that needs to be changed.
5. Click "Save & Exit" to return to the Interim Reviews window.
6. Click Exit to return to the Entry/Exit Data window.
How to Enter Follow Ups:
Client outcomes can be tracked by entering Follow Up data. Follow ups occur after the client has exited the program. Perform the following steps to track client follow up information.
1. Login to ServicePoint. If necessary, click Enter Data As and select the correct provider.
2. Click ClientPoint, find the client that needs an update in the Search screen, open the record.
3. On the Summary tab, in the Entry/Exits dashlet, find the relevant Entry and click the pencil icon for the Exit Date. (See Figure 10)
Figure 10
4. Click "Save & Continue". (See Figure 11.)
Figure 11
5. Click on a Follow Ups icon for one of the household members. (See Figure 12.)
Figure 12
6. Click "Add Follow Up Review" on the Follow Up Reviews window. (See Figure 13.)
Figure 13
7. Check the box for all the household members, even if no changes occurred for some members. (See Figure 14.)
Figure 14
8. Select the Review Type. For Follow Ups this will usually be General Review. Note: The Review Type does not reflect in any reporting.
9. Set the date as the date the case manager completed the follow up with the client.
10. Click "Save & Continue". (See Figure 14.)
11. The Entry Exit Follow Up Review window will appear. (See Figure 15.) If nothing has changed, click "Save & Exit". This will record that there was no change for each household member. (See Figure 17.) If changes did occur for any of the data elements on the Follow Up assessment, make those changes as appropriate to each household member with any change. (See Figure 15.)
Figure 15
12. A record is displayed in the Follow Ups Review box. It will also provide a count of all the members of the household in the single Follow Up record. (See Figure 16.)
13. Click "Exit".
Figure 16
14. Each member of the household will be included in the Follow up record regardless of if anything changed. The answers that were updated in the Follow Up record will not be show on the Exit Assessment. This is due to the Follow Up update occurring after the Exit Date. The Exit Assessment only shows answers that are effective up to the client's Exit Date.
To Make Changes to an Existing Follow Ups Review
Perform the following steps to make changes to a Follow Ups record.
1. Click a Follow Ups icon (Figure 17).
Figure 17
2. Click the pencil next to the Follow Up question that requires a change.
3. Click Save & Continue
4. Select the correct answer.
5. Click the Save & Exit button to return to the Follow Ups Review window.
6. Click Exit to return to the Entry/Exit Data window.
Interim Reviews for Income Changes
Effectively, Interim Reviews allow you to create a pencil with a date you need to record an event occurred for the client, in this case, income changes.
For example: If you are PSH and you meet with your client once a year and find out that the client had an income change 5 months ago, but just talked to them yesterday and learned about the change, make the Interim Review date yesterday and align the changes based upon yesterday. If you find out about changes at Exit, don’t make an Interim Review, just Exit the client and make the changes through the Exit Assessment, aligning everything around the Exit Date.
In summary
Income Update Examples
Whether you are updating income through an Interim Review, or an Exit Assessment you will need to review the Income for each adult in the household (including a child’s SSI/SSDI/Child Support that is being recorded on the appropriate adult) and record the new income data using the examples below:
Client had no income but is updating with income
If the client had no income previously and now has income:
Client had income but now has no income
If the client had income previously and is no longer receiving any income:
Client has income and now has different income (change in amount and/or source)
These examples for are a client who already has some income but has had a change either to the amount of income from a single source, or they have multiple income sources and one has changed but the other remain:
When one income source ends but other income sources still remain
When an existing income source changes amount
For example: Client has a part-time job and gets a 2nd part time job. You update the Total Monthly Income, then end date the existing Earned Income sub-assessment and replace it with a new Earned Income sub-assessment
When a new income source is gained and there are other incomes that are continuing
Client has no changes to income
These last two examples might happen if you are a PSH program doing an Annual Assessment and there are no changes to income. You have to create an Interim Review set as Annual Assessment but may not have anything to change. If you aren’t a PSH or TH with clients staying over 365 days needing re-certification, you won’t create Interim Reviews when there are no changes.
These might also be the case for any client at Exit who had no income and leaves with no Income, or has some income recorded that doesn’t change as they exit.
Client had no income and is at review still has no income
If the client has no reported income and they still have no income then you do not need to change any of the Income questions. The income questions should be:
Client has income and is maintaining the same income (no change in amount or source)
If the client had income previously and is maintaining the same Income from the same source(s) then you do not need to change anything on the income.
Each client should have at least one Case Management Service Transaction to indicate that client's intake process.
Each client should also have a second Service Transaction of some kind besides Case Management. It does NOT have to be financial; it can be "Housing Search and Placement".
As your client progresses through your program, users should update any services given, such as rental payments.
For each recertification, there should be one Case Management Service Transaction.
So, a typical collection of Services Transactions for a client might be:
Date | Service | Activity Represented |
5/1/2014 | Case Management | Intake |
6/15/2014 | Housing Search and Placement | Found housing for the client |
6/15/2014 | Rental Payment | Paid first month's rent |
6/15/2014 | Deposit Payment | Paid deposit |
7/1/2014 | Rental Payment | Paid 2nd month's rent |
8/1/2014 | Case Management | Recertification |
8/1/2014 | Rental Payment | Paid 3rd month's rent |
Starting May 6, 2019 users can use the automated 'Forgot Password' feature to reset lost or forgotten password without the need to contact an administrator.
You can download and review the printed instructions attached to this page for more details.