HIFIS 4

Reports can get archived when the version of the report itself gets updated, but can I put in a request for a way to manually archive/delete reports our community doesn't use anymore? For example, the Unique Identifier List is also irrelevant now that 59 exists, and multiple of the new reports have 59 and 60 versions.

We are currently running build 4.0.59.5. I have an consent related enhancement request to submit for a future HIFIS patch. We would like to be able to disable the “Explicit” consent type option in the consent drop down when creating a client or a consent record. When we upgraded our HIFIS instance from 58 to the 59 version, we selected the option to convert all our Explicit consent records into Coordinated Access + Explicit consent, since our consent form already included consent for entry into the Coordinated Access system. We are running into a process issue where we can not stop users from selecting the “Explicit” option when creating new consent records, when really they should be selecting Explicit + Coordinated Access consent. This results in clients being created with only the Explicit record (just like they used to be prior to v59) and thus are missing from the CA list, even if they meet all the other criteria. We have tried to train workers not to use the “Explicit” option, but unfortunately we have a lot of users who are not understanding this requirement to get their clients into the CA system, even after multiple reminders. The only way we can fix this currently is our HIFIS coordinator reviewing a custom report and adding the missing CA consent. If we had some other way to prevent “Explicit Only” clients from being created, it would increase our data quality for the ESDC export as well as save our coordinator a lot of time manually reviewing the files that have explicit consent but are missing CA consent. This would affect the add client screen (with enforce consent) where we would like the ability to remove “Explicit” as an option. This would also affect the Client Management -> Consent screen As well as the Enforce Consent popup when that setting is enabled.

Add a new module to allow users to record the provision of financial assistance (i.e. First & Last Month’s Rent, Moving Costs, Damage Deposit, Rental Arrears, Utility Arrears, Debt Relief, etc.) Why? No current way to record (closest is Goods & Services) Lots of communities provide this service How? Simplest way would be to add a new tab to Goods & Services I would prefer a new module (appears on Front Desk Menu as Financial Assistance) Fields required: Date and time, type (see above), amount (dollars), program, caseworker Priority: High Future add-ons You could attach this record to Financial Profile (Assets) You could add a feature for repayable loans You could have users specify whether this is one-time assistance or recurring You could combine this with the Housing Subsidies module in some way – I’d suggest adding an optional field to Financial Assistance that is a single select drop-down, that pulls the client’s housing records, and you could associate the Financial Assistance with Housing

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

Create customizable procedures, triggered by some condition, that prompt staff to enter certain information in a certain order. The Problem HIFIS has places for users to record a wide variety of information, but they must do so on separate screens. A typical intake form for a new client at a shelter might ask for data points that require a staff to navigate to 10 or more different pages in HIFIS! There is no way to make a module mandatory or remind them to enter data. Users must take the initiative to add data points Communities often struggle with low data completion percentages in non-mandatory data points. Notable examples: source of income, previous address, contributing factors The Proposed Solution Define some triggers when a workflow might begin Allow communities to customize or create a workflow (a procedure or process) that would prompt staff to go to the next requested data point Example Workflow: Adding a New Client After a user clicks Save on the Add Client screen (perhaps a new button “Save and Start Workflow”), they are immediately taken through the following steps: Add Housing History (they could have the option to “Save and Add Another Housing” or “Save and Continue”), then, Add Incomes (again, save and add another or save and continue), then, Add Contributing Factor (with option to add another or continue), then, End of workflow. User is brought to Client Vitals. Example Workflow: Shelter Intake After Absence After a user begins a Book In for a client (i.e. clicks the Book In button), the software checks to see if there is a Housing History or Stay record for the previous night. If not: Add Housing History with an automatic Start Date of the last known Housing or Stay, and an End Date of the current date, then, End of workflow. User is brought to Add Book In. _Note that this is a great opportunity to add in a Diversion procedure as well!_ The Advantages of this Solution Increased data completion Clarity for staff as to what data is expected (e.g. staff with limited training would be more easily able to intuit what is expected of them) and where it should go Faster, more efficient use of the software for many users

Allow users to subscribe to notifications about clients Why? Make life easier for case managers How? For each client, add a button that allows the user to “Follow” them User gets a message anytime something is updated in the client’s file (check audit log) Future add-ons Create a user dashboard that has a list of all clients I’m following/working with Auto “Follow” any client for which you are the Case Manager

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.

New Supportive Housing module, similar to that described in ACRE Consulting's report. [ <u> https://www.acreconsulting.ca/feature-recommendations</u> ]( https://www.acreconsulting.ca/feature-recommendations )