HIFIS Feedback

We updated our production environment to build 60.3 on Wednesday and have noticed some inconsistencies between the “Chronic Homelessness Y/N” field from the CA module and what is reported under the new “Chronically Homeless” Yes/No field available on the client profile. We use the CA module in order to run our local prioritization, so it’s important that we understand how it’s working and why the Y/N fields aren’t matching with what HIFIS is saying for the client on their profile. This example client shows “Yes” for the new Chronically Homeless field on the client profile. Please see the relevant housing history for this client below as well. From the CA Module, looking for this same client, he is reporting “N” under Chronic Homelessness Y/N. Here is a query demonstrating the relevant fields: SELECT CA.ClientID ,CA.HomelessIn365Days ,CA.HomelessIn1095Days ,CA.ChronicallyHomelessYN FROM vw_CoordinatedAccess as CA WHERE ClientID = 125 I am attempting to troubleshoot to trace the issue back to the source, but I thought I would start by reporting it and provide a sample query to the devs to demonstrate the issue. SELECT CA.ClientID ,CA.HomelessIn365Days ,CA.HomelessIn1095Days ,CA.ChronicallyHomelessYN as CAChronicallyHomelessYN ,HIFIS_Clients.IsChronicallyHomelessYN as ClientProfileChronicallyHomelessYN FROM vw_CoordinatedAccess as CA INNER JOIN HIFIS_Clients on CA.ClientID = HIFIS_Clients.clientID WHERE CA.ChronicallyHomelessYN <> HIFIS_Clients.IsChronicallyHomelessYN The following query is currently giving us 126 results (with 1376 total results from vw_CoordinatedAccess). 69 of the 126 are showing Y for Chronic in the CA Module, and N for Chronic on the client profile. The remaining 57 are showing N for Chronic in the CA Module, and Y for Chronic on the client profile.

In 4.0.60.3, on pageload for Add Incident, the police-specific fields (Charges Laid, Police Badge, and Police Report Number) are displayed by default, instead of hidden by default. If the value of Emergency Services changes (i.e. add "Fire Dept" to the field), the police-specific fields disappear.

Updating to 60.2 is slow because 60.2 introduces a new script that calculates chronicity for all clients, and takes ages. But we would expect that updating from 60.2 --> 60.3 or 60.3 --> 60.4 should run more quickly, right? Turns out that the update scripts to 60.3 and 60.4 will re-run the chronicity script introduced in 4.0.60.2 causing unnecessary slowness during update.

Currently, can't make the attachments field in Consent module mandatory or disabled.

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 dischargeThe user clicks saveHIFIS detects that one of the "housed" options has been selected, and redirects the client to the Add Housing History screenThe Add Housing History screen should automatically enter the start date = the date of the book-outThe 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.

Sometimes a user account might get added with a typo, or in contravention of a naming policy. It would be great if we could be able to modify user accounts.

The Coordinated Access module shows duplicated clients when clients have multiple open Coordinated Access consents. (Which could occur when you merge two client files.) Workaround: close one of the open Coordinated Access consent records.

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.

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.

In testing 60.3 we have found an issue with records duplicating under the Financial Profile area. This appears to be affecting all 4 tabs within the Financial Profile section. Whenever you add a record under Income, Expenses, Assets or Debts when there is already a record, the new record is added multiple times. For example, I added a “Employment - Casual" record under Incomes on client # 5624 on the demo site. Adding the first record seems to work properly.I then added a new income record for “OW” and two were createdI then added another new record for “Panhandling” which was created 3 times.Adding a fourth record for “Disability Benefits” resulted in 4 records being created

In testing 60.3 we have found an issue with the “View All Session Details” button in the Case Management area. To see this, create a new case management record, or open a client that already has an open case management record, either from Front Desk > Case Management, or from Client Management > Case Management. Then Click on the Display button to view the details. What we expect to see here is a summary of all sessions attached to the case management record. In our production environment (v4.0.59.7.1) we see a summary of all sessions attached to the case management record.

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.

Users are able to admit someone to shelter who has and expired consent. But when they go to discharge the client THEN HIFIS alerts the user that the consent is expired, and they are unable to discharge the individual without completing a new consent (note: the consent didn't expire while the person was admitted to shelter, it had expired months prior). Sometimes the user is alerted when an individuals consent has expired upon admission so it's not an all the time thing.

Fields can be disabled but this just greys them out and doesn't hide them. It would be great if we could hide fields we don't want shown, or ones we don't want shown all the time. Then, it would be ideal for communities to be able to customize which fields are hidden by default and which ones are not. Theoretically, I would have 4 tiers: Visible by default and mandatoryVisible by default and optionalHidden by default and optional (with an option to show field)Hidden and disabled (with no option to display, so like always hidden, completely removed)

I am hoping for a pop up to occur when someone's consent is about to expire in X number of days. And in Administration of the installation there should be setting for how many days in advance of the expiry, the pop up should occur. Kind of similar to how HIFIS allows you to set an inactivity threshold, we would like there to be a setting for 'consent is about to expire pop-up threshold.'