HIFIS 4

I have noticed that while the housing history determines a client's housing status based on the housing type, there is no such determination made when the client has a stay. In particular, some shelters might be transitional, which should have the client's housing status be listed as transitional, not homeless. When the client's most recent record is a stay, it should look up the service provider type to determine what the housing status should be. Some of the service provider types are things like "supportive housing" and so if they were using the admissions module for their housing, for some reason, the client should be listed as housed, not homeless or transitional.

When a client does a book-out, the Reason for Discharge field is mandatory. If the user selects one of the housed options, like "Housed - Independent" for example, HIFIS should automatically be adding a Housing History record. Here's what I'd like to see: A user does a book-out and on the Book Out screen, selects a housed option in reason for discharge The user clicks save HIFIS detects that one of the "housed" options has been selected, and redirects the client to the Add Housing History screen The Add Housing History screen should automatically enter the start date = the date of the book-out The Add Housing History screen should automatically select the Housing Type (looked up from the Reason for Discharge) The user can then add the rest of the details and hit save. This would go a long way to ensuring that housing status and housing transitions are being calculated correctly, and make the CHR have better data, and result in less work for shelter staff.

What is an encampment? It's a group of tents together in an area that I can see when I walk down the street (or through the woods, or wherever). But an important aspect of encampments is that they change over time. Today, there might be 10 tents, next week there might be 15, and in the spring, there might be only 5 remaining. The point is that there are kind of two key data points here: where the encampment is and when. Now the Encampments module does contain both of these elements, but here's the problem: it's not possible for someone to pull the data in such a way that allows them to track a single encampment over time. Let's dive into this a little deeper: There's an encampment in Kingston called Belle Park. It's in the news, everybody knows about it. So I'm an outreach worker. I go to Belle Park and then load up HIFIS. I can create a new Encampment in HIFIS, name it Belle Park, and say there are 10 people there. And today is November 13. That's fine. But what happens next week? I come back again, and now there are 12 people. So I have two choices: I can edit the existing Encampment record, and replace the count of there being 10 people last week with a record that there are now 12 people. The single "Encampment" record can only store one population count. Or, I can create a new Encampment. I choose the latter. So now I've created a second Encampment record, it's also called Belle Park, and it has 12 people. But now what am I supposed to do about the dates? For the first Encampment record, am I supposed to add an End Date? Because there are still people in the Encampment. What am I supposed to do for the Start and End Date for the second Encampment? It's really not clear what you'd use the dates for, so I can foresee that you'd have like 20 copies of "Belle Park" that are all "Active" and have random dates associated with them that don't make sense. And the important thing is I can't roll them up, I can't categorize them so that I can track trends over time, because the Encampment field is a free text instead of a drop-down. So if I spell Belle Park with lower case versus upper case those count as different things, and maybe there might be other terms people might use like "Belle Park Encampment" or "Belle Island" or "Belle Tent Park" that once again are not the same. So the Encampments module is conflating two important but related concepts: The first is a physical location. The physical location of the Encampment. I would call this record in HIFIS an Encampment. Belle Park is the encampment, not Belle Park on November 13. The second is a population count on a date-stamp. This is somewhat like a PIT count. On Nov 13, we found 23 people. On Nov 15, we found 25 people. So you need a bunch of sub-records of counts, connected to the parent record. The parent record being the Encampment. I would call the sub-records Encampment Counts or just Counts or Enumerations.  You could conceptualize it like a Case file that has multiple Sessions within it; a Housing Placement has multiple follow-ups; etc.

It would be nice to add Comments/Notes to the Encampments module.

One shelter is missing from the Bed Availability tab in Admissions while it has beds and is present in the Bed Availability view.

Conducting regular unit inspections is an important part of a successful housing program. According to the <u>Landlord Engagement Toolkit</u> , “Making sure units meet property standards and are in good condition is important for tenant health and wellbeing, and increases the chance that tenants will take good care of their home and pay their rent in full. Unit inspections show landlords that the program is serious and professional and has good values, which also improves the program’s reputation in the community. Move-in inspections, with photos or even room-by-room videos, can ensure that damage deposits are returned and the program is not charged for pre-existing damages. Unit inspection checklists and tools can help program providers and participants make informed renting decisions.” In addition to its utility in a Housing First context, unit inspections are often conducted regularly by landlords, and it would be beneficial to make HIFIS more useful for social housing landlords. Moreover, some subsidy programs require regular unit inspections as a condition of receiving financial assistance. Therefore, there would be value added both for caseworkers and program managers, but also for landlords, funders, and program participants if users could record unit inspections in HIFIS. Fortunately, there is an existing piece of HIFIS that we can leverage here. The “Status” field in the Housing Unit module includes an existing drop-down menu containing values such as “Excellent” or “In need of repair.” There is also a “Status Date” field.&nbsp;&nbsp; An oddity of the Housing Unit module is that there are two status fields, one entitled “Status” and the other entitled “Occupancy Status.” The Status field, however, asks about the _condition_ of the unit. This situation is confusing to users. For clarification, we recommend relabelling the “Status” field to “Condition,” and that is the terminology we will be using from here on out. Action Item UI-1: Relabel “Status” field on Add Housing Unit and Display Housing Unit screens to “Current Condition” Action Item UI-2: Relabel “Status Date” field on Add Housing Unit and Display Housing Unit screens to “Condition Date” Action Item UI-3: Relabel “Status” field in Housing Unit List filter to “Condition” Currently, a history is stored of changes to the Condition field in the database. However, this information is not available to any end users of the software. It is proposed that a new tab be added to the Housing Unit, in addition to Details, Address, Photos, and Maintenance. This tab should be titled “Inspection History” and should display this history. Action Item UI-4: Add “Inspection History” tab to Housing Unit module Action Item UI-5: Add corresponding rights to access Inspection History tab Once the Inspection History tab exists, users should be able to go to that screen directly and to update the unit’s Condition. There is an issue present in many parts of HIFIS where in order to change one thing about a record, clients require rights to Edit the entire record, which is problematic. For example, in order to modify the end date of a Service Restriction, users need the ability to Edit all fields within the Service Restriction. In the context of Housing Units, because all fields are editable from the Edit screen, giving a user permission to change the Condition of a Housing Unit, they would also have the ability to change the Service Provider that owns the Housing Unit, or the Rent, or the Address, all of which would be extremely problematic. We are proposing that changes to the Condition be handled on a different screen than the Edit Housing Unit screen. This will require a new form, to “Add Unit Inspection.” The first change will be to move the Condition and Condition Date fields from the Edit Housing Unit screen to the Add Unit Inspection screen. Action Item UI-6: Add “Add Unit Inspection” button to Inspection History tab in Housing Unit module _Mock-up: Add Unit Inspection screen could look something like this_ Action Item UI-7: Create a new “Add Unit Inspection” screen with the existing “Condition” and “Condition Date” fields Action Item UI-8: Remove “Condition” and “Condition Date” from the Edit Housing Unit screen However, simply having a Condition and a Condition Date does not sufficiently capture data necessary for a unit inspection. A review of existing unit inspection resources reveals that most unit inspection forms are dozens if not hundreds of questions long, with attention to the smallest detail. Such a detailed checklist, however, wouldn’t necessarily meet the needs of users either, as many will find it too time consuming while others may be required to use a specific form. A happy medium is proposed: in addition to the Condition and Condition Date, add a generous Comments box as well as the ability to upload attachments. Unit Inspections: Proposed Fields | ID | Field | Type | Mandatory? | Description | | 1 | Housing Unit Record | Automatic | n/a | Automatically links to the current <u>Housing Unit Record</u> | | 2 | Client Housing Record | Special | n/a | Automatically links to the current <u>Client Housing Record</u> . If unoccupied (i.e. unit inspection is being conducted after move-out or prior to move-in), this field would be null. | | 3 | Condition | Single- select | Yes | Uses the existing House Status lookup table | | 4 | Condition Date | Date | Yes | Defaults to the current date. | | 5 | Inspected By | Single- select | Yes | Uses the User list; defaults to the current user. | | 6 | Comments | Text Area | No | Memo type field with rich text editor | | 7 | Inspection Checklist | Attachment | No | Intended to allow a user to upload a copy of a unit inspection checklist | | 8 | Unit Photos | Attachment | No | Unlike other attachment fields in HIFIS, this field should allow multiple attachments. Accepts only image files. | | 9 | Next Inspection Due | Date | No | | Action Item UI-9: Add fields to Add Unit Inspection screen as per table above The Inspection History tab should List the following fields: Condition Date (Field 4) Condition (Field 3) “Tenant” which should indicate the name of the client in a linked Client Housing Record (Field 2), or be blank Inspected By (Field 5) “Checklist?” which should indicate with a checkmark or Yes/No whether there is an attachment in Inspection Checklist (Field 7) “Photos?” which should indicate with a checkmark or Yes/No whether there is any attachment in Unit Photos (Field 8) Action Item UI-10: Add list of fields to Inspection History tab as per list above It would not be particularly helpful to list the “Next Inspection Due” for every row in a table indicating the history of Unit Inspections. Instead, it would be useful to display the most recent “Next Inspection Due” date (i.e. the date attached to the most recent Unit Inspection record) somewhere useful for staff. One option is to display the text “Next Inspection Due:” followed by this date on the Inspection History tab above the table of records. Another option would be to display the same information on the Housing Unit Details tab. Action Item UI-11: Display the next upcoming “Next Inspection Due” date for a Housing Unit HIFIS also includes a little-known feature that photos can be attached to a Housing Unit. This is rarely used, but has potential to be useful. It would be more useful if it was easier to add photos to that module. Therefore, it is recommended that photos from a Unit Inspection be added to the Photos tab of the Housing Unit. Action Item UI-12: Add Unit Inspection photos automatically to the Photos tab of the Housing Unit

Add ability to better track rental and utility arrears. This is of high importance for housing-related programs, for multiple reasons. First, it is common for homeless clients to have accrued arrears with certain landlords, that would prohibit the landlord from accepting them as a tenant in the future, at least until the arrears are paid. Similarly, clients may have accumulated utility arrears with similar conditions. Therefore, it is necessary for caseworkers helping clients to find housing to know about and address arrears situations. Caseworkers need to know who arrears are owed to, the amount of the arrears, and whether there’s a repayment plan in place. _Screenshot: Current Add Financial Debt screen_ Second, eviction prevention programs are often very interested in knowing what a client owes, because assisting them with their arrears is one of the primary things an eviction prevention program does. Finally, it’s important for landlords to track arrears, but a more likely use of the software is for caseworkers who support clients in housing to stay on top of arrears to prevent evictions. HIFIS 4 already contains a place where users can track arrears, called the Debts module, but it is sadly lacking in utility. As an example, there is a mandatory drop-down field in this module called “Debt Type” but it only contains one option: “Debt.” At a bare minimum, this list should be expanded. Some suggested options include: Rent Arrears Utility Arrears Telecommunications Arrears Credit Card Debt Student Loan Business Loan Personal Loan Automobile Loan Payday Loan Mortgage Medical Bills Legal Fees Unpaid Taxes Unpaid Fines Street Debt Action Item A-1: Expand “Debt Type” lookup table default options A second issue with the Debts module is that it does not capture information that is most useful to users. One key piece of information that is missing is who the debt is owed to. It is proposed that this field should contain a list of Places (i.e. Directory of Services), but that this field should be optional. It may also be useful to have an “Other” option in this drop-down. Action Item A-2: Add “Owed To” field to Debts module Participants in focus groups also identified the need for further information. In particular, they expressed the need to know whether a repayment plan was in place. In addition, the ability to attach documents would be useful. These documents would generally be assumed to behave like other documents, and would also appear in the Client Documents List, as usual. Action Item A-3: Add “Repayment Plan” boolean field to Debts module Action Item A-4: Add attachment field to Debts module The current “Country” and “Province/Territory” fields in the Debts module are not particularly relevant. The utility of these fields is unclear, and it is suggested that the possibility of removing these fields be investigated. Action Item A-5: Remove “Country” and “Province/Territory” fields from Debts module _Mock-up: New Add Financial Debt screen could look more like this_ Another issue with the Debts module is it is unclear how it should be used to manage changing debts. Each Debt record has an amount and a start date and an end date. If a client owes $1000, then pays off $100 and now owes $900, how should that be recorded? If interest increases it to $925, how can a user easily capture that? One option is to add an end date to the old record and start a new record with the new amount, but that is a cumbersome process. Alternatively, a user could change the amount, but that erases the history (a similar challenge as in <u>Rent Adjustments</u> ). Action Item A-6: Keep a history of Debt adjustments, and display this information As in Action Item RA-3: Create a “Add Rent Adjustment” form, a separate form could be created that simply allows a user to update the current Debt amount, along with a date. A similar discussion could be had (as in Rent Adjustments) as to whether it is also necessary to include a “Reason for Adjustment” field. Alternatively, adjusting the Debt amount could be part of the Edit Debt screen that would allow a user to change the Amount value, while somehow keeping a record that the amount was changed and what the previous and current values are. This would be a model more akin to how Statuses are updated in the Waiting List module. Action Item A-7: Add a way to easily update Debt amounts Regardless of the specific approach undertaken, the Start Date and End Date fields seem problematic, as it is unclear to users how they should be used. Given the preferred method of use, it may be most logical to remove the Start and End Date fields altogether, and have them replaced by a series of update dates. Or, perhaps the Start Date and End Date are hidden from the user, and are automatically populated: the Start Date with the first date listed, and the End Date with the date attached when the Amount reaches 0. It is still necessary to be able to indicate which Debts are “active” and which are “archived,” but this can simply be achieved by reviewing what the current Debt amount is. Action Item A-8: Reconfigure Start Date and End Date fields; a Debt should be considered active if its current value is not $0.00, regardless of the Start and End Dates. In order to accommodate some of these suggestions, the database structure and rights may need to be altered somewhat. Currently, Assets and Liabilities (Debts) are bundled together. If users have rights to one, they have rights to the other. Similarly, they are both stored in the same table, with the same fields (a Debt is simply a negative Asset). It is suggested that these be split into two distinct entities, with updated rights and database to illustrate this. Action Item A-9: Separate rights for Assets and Liabilities (Debts) into two categories Action Item A-10: Separate Assets and Debts into two separate database tables

Add the ability to track a client’s changes in rent while living at the same address. A significant challenge for some users supporting clients in housing is that rents change over time. It’s not uncommon for a standard rental agreement to have an annual increase in rent, but a bigger challenge comes when a client is living in rent-geared-to-income (RGI) housing, which means that a change in income results in a change in rent. In all of the places in HIFIS that allow a caseworker to record a client’s rent, rent is a static field. Changing the rent amount would lead others to believe that the rent is and has always been set at the new amount and would remove any record of the client paying rent at the older amount. _In an interview, a participant shared that due to changing rent, they are in the practice of adding an end date to a client’s Housing History records and creating a new, duplicated Housing History record with the new rent amount but the same address. This is problematic because it has the unintended consequence of making it look like the client has a short duration of housing. By most analyses, it would appear as if the clients in question are moving every year or so and that the community as a whole has difficulty with their previously homeless clients maintaining their housing for any length of time._ Rather than creating an entirely new sub-module to simply track rent increases, there is a logical place for this data to be stored: in the Expenses module. The Expenses module currently tracks all ongoing financial obligations a client is responsible for, and already includes an option for rent. _Screenshot: Existing Expenses module with sample Rent expenses displayed_ When a user creates a Client Housing Record and fills out the Rent field, an Expense record should automatically be created with the type of “Rent” and a Start Date equal to the Start Date of the housing record. This Expense record should not be editable and should be linked to the client housing record. Action Item RA-1: Automatically create an Expense with the type “Rent” when a Client Housing Record exists with a Rent value We envision an extra tab on a client’s housing record (i.e. Housing History) that displays changes in rent over time. This could be entitled “Rent Adjustments” or something similar. This would display all linked Expense records for this housing record, along with the relevant dates and amounts. Because we suggest using the existing Expenses functionality, we anticipate that this would not be an overly onerous enhancement. An alternative approach would be to display changes in rent over time at the bottom of the Display Housing History screen. This could function similarly to how the Waiting List module handles status changes. Action Item RA-2: Create a way to display the history of Rent Adjustments on a Housing History record _Screenshot: Display Client Waiting List Information (note Status History at the bottom)_ Users now need a way to update a client’s rent. From the Rent Adjustments tab, there could be a button labelled “Adjust Rent.” Clicking this button should lead to a form titled “Add Rent Adjustment.” This new form would only need a few fields: “Reason for Adjustment,” “New Rent Amount” and “Rent Adjustment Date.” The Reason for Adjustment field should be a single-select drop-down field requiring the following values: Increase due to inflation Rent-sharing arrangement Change in client income Renovations Other Action Item RA-3: Create a “Add Rent Adjustment” form, and a “Add Rent Adjustment” button to reach it, with corresponding rights _Mock-up: Add Rent Adjustment screen could look like this_ Users should be able to edit existing Rent Adjustments, in case one was made in error. Action Item RA-4: Add the ability for users to Edit Rent Adjustment, with corresponding rights It is recommended that the Rent field be removed from the Edit Housing History screen. In addition, on the Display Housing History screen, the “Rent” field should be relabeled to “Current Rent” and only show the most recent/current Rent value. Action Item RA-5: Adjust existing fields on Edit Housing History and Display Housing History to reflect the new functionality Whenever the rent is adjusted, the Expense record containing the previous rent amount should gain an end date equal to the rent adjustment date. Action Item RA-6: Automatically update Expense records derived from Rent when corresponding Housing records are updated It is somewhat confusing that there is currently a Rent field in a Housing Unit Record, and also a Rent field in a Client Housing Record, but that these exist independently of each other. The Rent field in the Housing Unit record should contain the most recent known rent for that unit, and should update whenever there is a change. Action Item RA-7: When rent is adjusted, update the Rent field on the Housing Unit to contain the same value The combined result of these enhancements should be: A user can automatically see the client’s rent amounts for all addresses in the Financial Profile \> Expenses page, without having to double-enter this data; A user can see all of the rent increases for a particular unit over time when pulling up the Housing History record; Users should be able to track rent adjustments over time without much difficulty; and, A user can look up the Housing Unit to see what the current rent is, rather than an outdated or blank value.