HIFIS Feedback

Lots of clients are having duplicated client housing status change records. For example: clients becoming chronically homeless every day; clients becoming housed 4 times in the same day, etc.

From time to time I encounter an issue or hear about an issue where a user's rights don't seem to be having the intended behaviour. Well, I'm not sure if this is the root cause or not, but I have discovered a large number of duplicated record in the HIFIS_User_Rights table. For example, here's four identical copies of the same user having the same right at the same organization. However, more distressingly, sometimes they don't match. Here you see the same right, same user/organization, and two records saying the right IS allowed and one right saying that it is NOT allowed. I am not sure how significant this finding is, but I thought I would share it with you in hopes that it might help with troubleshooting something. Somewhat interestingly, this seems to be most prevalent for one user at one organization in my database, and this is what their rights looks like. In other words, not attached to a rights template, and very minimal rights. For this specific UserOrganizationRightsID, there are 539 rows. The user has been granted a total of 4 rights at this organization.

We've observed inconsistencies in client states within HIFIS, for example, some clients are marked as 'Active' despite not receiving services in over 90 days, while others are marked as 'Inactive' even though they still have open case management goals. In HIFIS, client state is updated by the [dbo].[sp_checkClientState] stored procedure. This procedure can be executed for an individual client or for all clients in the database. When run for all clients, it processes them in sequential batches of 5,000 (e.g., ClientID 1–5,000; 5,001–10,000; etc.). However, gaps in the ClientID sequence can cause the procedure to skip clients. For example, our database contains a gap between ClientIDs 25,000 and 35,000. As a result, the client state for all clients with a ClientID above 25,000 may not be updated. Explanation When processing all clients, the [dbo].[sp_checkClientState] procedure relies on the [dbo].[fn_checkClientStateData] function to retrieve client state data for each batch. If no data is returned for a given batch (e.g., when a gap exists in the ClientID range) the [dbo].[sp_checkClientState] procedure exits early. This prevents the remaining client batches from being evaluated, leading to incomplete or inaccurate client state data.

In HIFIS_Clients, a bunch of clients are having null values stored for RecentActivityModuleTypeID and RecentActivityDateTime​ , despite having actions in their file that constitute activity. So far I cannot detect any commonality between the clients who do have a Recent Activity, and those who don't have any. Affected software elements Clients Approaching Inactivity reportRecent Inactivity reportCoordinated Access moduleAny custom report that includes a "days since last activity" calculation

Every night, the stored procedure sp_checkClientState is supposed to run, which is supposed to check each client's date of last activity and update their activity/inactivity status accordingly. It appears that this procedure is not always being called when it is supposed to, which is resulting in a number of issues related to activity/inactivity.

New Supportive Housing module, similar to that described in ACRE Consulting's report. Reference: https://www.acreconsulting.ca/products/178360

When creating new services (Admissions, Case Management, Housing Placements, Reservations, SPDAT, Storage, Turnaways etc..) for a client in HIFIS 4.0.60.4.2, the 'RecentActivityModuleTypeID' and 'RecentActivityDateTime' fields in the HIFIS_Clients table are not updated to reflect the client's most recent activity. This can result in inaccurate data shown in the 'RecentInteractionDateTime' and 'SinceLastActivityDays' fields in the vw_CoordinatedAccess and vw_CoordinatedAccessExport views.

Known bug that happens a LOT! Clients show up as “Unknown” housing status even when there is data that should give them a different status! More detail in the comments.

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.