Bing Maps API is being deprecated

For most users, Bing Maps will stop working on June 30, 2025. New HIFIS instances are already unable to create new Bing Maps keys. This means that on June 30, 2025 any feature that has to do with mapping will stop functioning. That includes: Directory of Services mapHousing Unit Search mapGoods & Services and Group Activities geo-taggingOutreach mapEncampments geo-tagging and map display

15043: Missing shelter on Bed Availability tab

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

Book-in family can't be modified

Users are not able to remove familly members from the book in page when using the admissions module from the Client Management page.

Case end date is not mandatory

When changing the case status from Open to Closed (any), the End Date appears but is not mandatory. You can save the case status as closed without providing an end date. This causes a disconnect in the data; cases may appear ongoing (no end date) but with a status indicating they are closed.

Case Management > View All Session Details Blank

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.

Duplicate Clients in CA module (Consent)

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. Related to: https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-income https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/bug-in-ca-module-first-episode https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-first-episode https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-families

13408: Change Diversion Alert icon

Right now, the icon for recent diversion is the same as active service restriction. I suggest changing it to the attached.

Add timestamp to Encampments

Just has a date, no time.

16393: Failed Housing Placements keep a client active

When you have a Housing Placement with the status of "Housing Placement Failed," the client will remain active indefinitely. This is because the coding relies on the existence of a follow-up, but follow-ups are not possible and therefore can never exist if the Housing Placement is failed.

Client Service Delete supercedes rights

With the Client Service Delete right, users can delete services belonging to a single client that they look up, regardless of what service provider owns the service. This feels like an oversight: why can a user who has no rights to Shelter A (and therefore can't Display or Edit a Stay belonging to Shelter A) be able to Delete a Stay belonging to Shelter A? This feels like an oversight. Also related to https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/deleting-services-is-problematic

16034: RecentActivityDateTime is null

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

Client's Recent Activity not Updating

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.

15240: Client State Accuracy Impacted by Gaps in ClientIDs

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.

Unable to add HIFIS Users in 4.0.60.5

Unable to add users. Click on the "Save" button, page reloads, but no error message is shown and the user account is not created. NOTE: This issue is only affecting a small subset of users. https://www.loom.com/share/53cd0dd923d14ab992c611bc419beb69?sid=bf5df7ac-6b40-4c43-a25f-cfb200b8bfbe

Visiting a Client Vitals screen updates the "Last Updated By" field

Present in 60.3 and 60.4

Waiting List Timeouts (Error 500)

When a wait list is used on an ongoing basis (around 3000 total waiting list records including closed records) it starts to get really slow and eventually time out entirely (500 error) when trying to open a client waiting list entry for edit. Users are unable to view a waiting list entry or save information.

Edit Clients in Waiting List rights issue

Looks like there is a bug in the rights surrounding Waiting Lists. I give my users the following: Add Clients to Waiting Lists  Display Client in Waiting List Edit Clients in Wating Lists (note, there is a typo in this one) Front Desk List List of Clients in a Waiting List List of Waiting Lists And from the Client - Waiting List, this is what they can see: In other words, they can Display Client in Waiting List and click the Manage Clients button (whatever right that is), but not Edit Clients in Waiting Lists.  There should be an edit button here. If I give the user the additional permission: Edit Waiting List Records They see the extra edit button on the Client - Waiting List: So the Edit Button on the Client - Waiting List seems to be tied to the "Edit Waiting List Record" right, but it should be tied to "Edit Clients in Waiting Lists"

Encampments missing from audit log

13152: Book-Out leads to Add Housing History

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.

15092: Effective Date field is ignored for Bed Status History

When you're indicating that a bed had a status change, say, last week (i.e. Edit Bed), the Effective Date field is ignored. So if I changed this bed to be out of service as of October 1, the date that actually gets stored for the bed status change date is today (current timestamp). Recording: https://www.loom.com/share/3e975079b0044fc68aa620b5fef018c8?sid=72945616-2547-4bfe-a2e5-59239537e8af

Case Management > View All Session Details Blank

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.

Users are unable to see programs associated with a case management record.

Changes to Geographic Region (Vitals) not stored in Client Vitals history

15091: Deceased status change date should = date of death

If someone marks a client as Deceased, there's an optional date of death field. However, the date that is recorded for the status change (i.e. Active > Deceased) is the data entry date. If someone isn't informed about a client's death until much later, HIFIS should reflect the actual date of death as opposed to the date that someone recorded it.

Reverse colours for Client Visible/Hidden

Now that the binary toggles are blue/red, it's really clear which values are YES and which ones are NO. For the "Client is" Hidden/Visible toggle, Visible appears to be the NO option, which seems backwards.

14971: Editing Client Vitals sets Chronically Homeless Status to 'No'

When editing a client’s vitals in HIFIS 4.0.60.3 and 60.4, the HIFIS application sets the client’s Chronically Homeless status to ‘No’, regardless of the client's current Chronically Homeless status. This may cause the Chronically Homeless status of some clients to be reported incorrectly by the application.

Re-label consents

It would be nice to be able to re-label consent types. For example, a community may not like the name "Declined - Anonymous" and want to label it differently, like maybe they only use it for victims of domestic violence so they might call it "DV client." Or, they may want to call the "Explicit" consent something like "Signed HIFIS Consent Form." Furthermore, it would be nice to perhaps have different copies of these. Particularly if a consent form is being deprecated, it might be nice to, say, have two versions of the Explicit consent (obviously you wouldn't be using them at the same time), but like, one called "2019 Consent Form" and one called "2022 Consent Form." This could help reduce some confusion, like if I see a client has several expired Explicit consents, I would know a little bit more about whether the client has since signed the new form and then withdrew consent, or whether they only had the old consent and still need to sign the new one. The conversation a staff would have might be different in those two cases. So please introduce most of the normal look-up table behaviour for consent types. Let us add a custom value, and have it roll-up to a default value and have HIFIS use the behaviour of the roll-up value. We could have “Signed HIFIS form” rolling up to “Explicit” and “Provided verbal consent” also rolling up to “Explicit.” Disabling “Declined - Anonymous” consent and replacing it with “Declined to share” and replacing “Inherited” with “Guardian provided consent.”

Ability to disable explicit consent option

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.

Alert for upcoming consent expiry

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.'

Make consent uploads mandatory

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

Don't create two records for CA + Explicit Consent

Stop bundling the two types of consent together. Right now, Explicit consent (and only Explicit) consent governs whether the data is shared in HIFIS. CA consent governs whether the data shows up in the CA module. And CA consent can only be provided if Explicit consent is also present. So clients must have two different consent records, both with different start and end dates and attachments and so on. One problem with this is when you open up a client file, you cannot tell if a client (see attached) has just Explicit consent, or whether they have Explicit + CA consent. So a lot of clients have only Explicit consent because nobody notices the error, ever. How about this: the client only has one type of consent at a time. If someone provides CA consent, then we record a record that says "Coordinated Access" consent was provided. And a client's data is shared if either CA consent or Explicit consent is provided. So instead of a typical client having two different consent records, they only have one - either Explicit, or Coordinated Access.

Deceased client procedure

Deceased clients can do all sorts of things that they shouldn't, like: be booked in, or remain booked in, to shelterhave open case fileshave open housing placements or housing loss prevention recordshave open subsidiesreally, have open anythings My suggestion is when you make a client Deceased, have a little procedure that occurs, with a popup for the user that says "the following records will be closed:" and then list everything that's open for the client and close them all. When there is a reason required, like reason for discharge, then the reason should automatically be deceased. Then have an "okay to proceed" button.

Encampments mixes up two concepts

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.

Encampment Notes

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

Financial Profile records duplicating

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

14708: Error editing Group Activity record with "Current Location"

What I was doing when I found the issue: Editing a group activity where the initial location was set using the "Current Location" option, or when setting a new location using "Current Location" What should have happened was: Successfully updating the Group Activity record What actually happened was: ELMAH error message type="System.FormatException" message="Input string was not in a correct format." source="mscorlib" detail="System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) Has this happened more than once? Yes The version of HIFIS I’m using is: 60.3

Housing Placement dates

There's incorrect behaviour when you try to modify some dates in Housing Placements. You can Move In and specify the move-in date, but if you make an error, it's difficult to change. Yes you can modify the Start Date in the corresponding Housing History record, but the Move In Date on the HP record does not update.When you Secure a Unit, you can specify the Housing Secured date. When you Add and Secure a Unit, you can't specify the Housing Secured DateYou can't modify the Housing Secured Date after the Housing Has been secured, in the case that a staff makes an error

Police fields shown on Incidents on page load

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.

Editing Field Dictionary

All users, regardless of the users’ rights, can edit the field dictionary in HIFIS.

15148: Not redirected to Custom Reports tab after uploading a custom report.

In previous versions of HIFIS (e.g., 4.0.59.7.1) the browser was redirected to the Custom Reports tab after uploading a custom report. This is no longer occurring in HIFIS 4.0.60.4. Instead, when uploading a custom report in 4.0.60.4, the following occurs: • After pressing the Save button, a green ‘Data Saved’ balloon is shown in the top right corner of the screen. • The browser remains on the ‘Add Report Form’, but the title of the ‘Add Report’ form is changed to ‘Report Generator | [Report Name]. • Clicking the Cancel button on the Add Report form OR clicking the Reports > Report Manager menu item redirects to an empty version of the ‘Add Report’ form. ticket 15148 - identified as a bug to be fixed in a future version.

If you add a user when the minimum password length > 14, user fails to save

When a user is created in HIFIS, they get a temporary password of 14 characters. If the minimum password length is > 14 characters, then the new user creation will generate an error - the error is basically that the password doesn't meet the requirements. BUT this error is not visible, so the page just reloads with no error message visible.

Stored procedure sp_CheckClientState not being initiated

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.

60.4 Deceased Clients are inactive

in updating to 60.4 - all of our Clients that were previously deceased were marked as inactive. HICC is aware and is currently working on a solution 🤞

Activity status derived from audit log not service dates

There is an issue when determining when a client becomes active/inactive. It is derived from the audit log  but it should not be. So I just added a Goods & Services transaction. By all accounts, adding a Goods & Services transaction counts as activity. I added it to a currently inactive client, but I backdated the start date to a week ago. However, the client State Change History indicates that the client only became active today, and they should have become active last week.  I continue to suggest that activity should be determined from the HIFIS_Services table, not the HIFIS_AuditLog table for this reason.

Can't modify attestation text

On 60.2.1, go to Cluster Settings and modify Attestation text. Hit save. It should say green "Data saved." However, open the Cluster settings again and you will see that the change has not been applied.

Clients disappearing after consent expires

When a client that previously had Declined - Anonymous consent, but subsequently has an Explicit consent, and then the Explicit consent expired, the client will revert to being hidden from the previous Declined - Anonymous consent. The client can only be activated again by the original service provider. This seems to be related to a fix/new in 4.0.59.6 https://hifisfeedback.acreconsulting.ca/announcements/40596

13401: Can not Edit or Delete a Subsidy

In 60.2 you cannot edit or delete a subsidy. When trying to edit, you get a "Loading" message that never clears. When trying to delete you receive an error in the right corner that says item failed to delete. Tested for both Housing Placement and Housing Loss Prevention. Added and secured a unit.Moved inWent to the Subsidy tab within the Housing Placement record and added a new subsidy Once created I used the edit option (pencil) to try and edit and it kept loading I went back to the record and tried to delete the subsidy and received the item failed to delete.

"Get New Reports" right causes unintended additional access

An admin staff I was working with was concerned that they could access reports that were "private" to only one service provider, while they were logged in somewhere else. So I tested it out and figured out the root issue. For context though, here's the steps to reproduce: Configure a CUSTOM report to only be visible at one Service Provider. In my screenshot above, the SP I have is "Region of Oz"Grant a user access to ONLY a service provider that is not the one selected above. Give them rights that include Log On, Display Reports, Generate Reports, and View Report Manager (but no other rights in the Report Manager category)Log in as that user. Go to the Report Manager and attempt to locate the report.Report should NOT appear, as expected (this is good)Now, modify the same user account and grant the right to "Get New Reports"Log in as that user. Go to the Report Manager and attempt to locate the report.The report WILL now appear, along with every other report that exists in HIFIS. I think that the Get New Reports right is probably intended to provide access to HIFIS Reports (not Custom Reports) that have not yet been deployed to the HIFIS instance. But I don't think it's supposed to grant access to Custom Reports that have been uploaded but are attached to other service providers a user doesn't have access to.

Clients active despite 90+ days of inactivity

In 60.4 Clients are active way past the 90 day threshold (and are reactivated during the update) some of these clients have never had a service and are active despite being created years ago- causing the numbers of active clients to Spike. HICC is aware of this and is currently working on the issue

60.4 Deceased Clients are inactive

in updating to 60.4 - all of our Clients that were previously deceased were marked as inactive. HICC is aware and is currently working on a solution 🤞

Being booked at a shelter no longer refreshes activity daily - 60.4

Clients currently in shelter appear to not have their activity status reset every day if they are actively booked into shelter. So instead of 0 days, all clients who have been booked in shelter are showing last activity day as the day of the update instead of 0 days.

14971: Editing Client Vitals sets Chronically Homeless Status to 'No'

When editing a client’s vitals in HIFIS 4.0.60.3 and 60.4, the HIFIS application sets the client’s Chronically Homeless status to ‘No’, regardless of the client's current Chronically Homeless status. This may cause the Chronically Homeless status of some clients to be reported incorrectly by the application.

Updating to 60.3 or 60.4 is slow

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.

Financial Profile records duplicating

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

Case Management > View All Session Details Blank

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.

Housing Status: Incorrectly displaying as "Unknown"

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.

14885: Chronic Homelessness mismatch

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.

13465: Duplicated Unknown housing status on client created date

I have a total of 36 clients. I found the issue for 7 clients including Anonymous, Anonymous, that's around 20% of clients affected. I tested the demo site and the issue is present for over 1200 clients. Here are some examples of affected clients: all clients between 2,881 and 2,895 inclusive; 2,723; 800; 259.... there's lots.It's always duplicated Unknown status. Every time. I haven't found a duplicated status that wasn't Unknown.It's always the same client becoming unknown a bunch of times at the exact same timestamp.The timestamp is the same timestamp as the client created date.There are always 77 copies of the duplicated unknown status. The number 77 probably has to do with something in my database. I tested on demo.hifis.ca and the number was 615. I don't know what I have 77 of and demo.hifis.ca has 615 of, but there's probably something. In 4.0.60.2.1

Rights to Client Vitals

When we assign rights to a user, either via individual rights or a Template, sometimes the rights related to client vitals don't apply properly. So in the section Client Details > Vitals, there are 4 rights. I commonly want to assign Add Vitals, Edit Vitals, and Display Vitals, but not Ability to Hide Clients. If I individually check off the rights, then the user won't actually have access to the Vitals tab. However, if I hit the "select all" parent right, and then remove Ability to Hide Clients, the rights the user has end up being exactly the same, but it works properly in that case. So there's something misconfigured, but I don't know what exactly. Here's a video: https://www.loom.com/share/405270bb37db481ebe414982f14f4c7e?sid=38ccf871-6bca-41c0-9216-819d63fc84de

Client Search not working as expected

The Client Search is really different than in our current production version (4.0.59.4). Is it working the way you expect it to? For example, to get to my client John William Test (Alias 1 Jonathan Silly Pants), it no longer works to search jo te or wi pa. john test doesn't work either, you have to type in test, john. But jonathan silly works. Is that by design? Absurdly, han sil works.

Diversion does not count as activity

Adding a Diversion record does not make a client active or keep a client active

Housed Safely Last Night missing from workflow

On the Diversion Attempt screen (one-page version) there is a field called "Housed Safely Last Night" However, I'm noticing that the same field is not present anywhere in the Diversion Workflow, not on any page. I believe it should be on page 3, which is about Last Night's Housing.

Group Activities not in Audit Log

This is a duplication of https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/actions-missing-in-audit-log but it’s important enough to merit its own post. When a client is added as an attendee in a Group Activity, there is no corresponding record generated in the Audit Log. However, adding the client to the Group Activity does count as activity, so the client’s date of recent activity is updated and if they were inactive, they become active once more.

Parent Service Provider only shows service providers in current cluster

On the Add/Edit Service Provider screens, the Parent Service Provider drop-down menu only shows service providers in the current cluster.

Display issue on HIFIS header on login screen

I noticed when I resized my browser, my v60 instance is no longer displaying aligned. My browser width at the time was about 980px.

Reset Password Link broken

In 4.0.60, when users are sent a password reset link, the host (first) portion of the URL is missing. For example, it will say: "Please click the following link to reset your password: /Account/ResetPassword/123456" Instead of the necessary: "https://acre.hifis.site/Account/ResetPassword/123456"

14971: Editing Client Vitals sets Chronically Homeless Status to 'No'

When editing a client’s vitals in HIFIS 4.0.60.3 and 60.4, the HIFIS application sets the client’s Chronically Homeless status to ‘No’, regardless of the client's current Chronically Homeless status. This may cause the Chronically Homeless status of some clients to be reported incorrectly by the application.

Financial Profile records duplicating

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

Case Management > View All Session Details Blank

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.

Updating to 60.3 or 60.4 is slow

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.

HIFIS automatically marks clients as "Not a Veteran" if their age falls between 50 and 62, regardless of their actual veteran status.

Present in 60.3, fixed in 60.4

Housing Status: Incorrectly displaying as "Unknown"

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.

14885: Chronic Homelessness mismatch

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.

Pagination missing on Client Search

When you use the Client Search, results show but the ability to navigate to another page is missing, so if your search result returns more than X clients, they cannot be found.

Users are not able to delete diversion records from the Client Service Delete module.

Can't merge clients in 60

An error related to merging clients has been brought to my attention in v60. It looks like merging any two clients throws an error. Notably though, there seems to be multiple errors thrown, and it seems somewhat random which error message you get. I've seen at least 3 different ones.

Can't close case file in 4.0.60.1

When closing a case, get an error saying "The value '## Days' is not valid for TotalElapsedTime."

Date of Death

In 4.0.60.1, the Date of Death field is now, inexplicably, a drop-down menu that contains no values.

Edit Diversion shows different screen for workflow vs form

I'm not clear on, once you do a Diversion Workflow versus a Diversion Form, why the software remembers whether it was a Workflow or Form, and shows a different Edit form accordingly. First of all, this is unnecessary - the Workflow is only useful in the moment, and not helpful if you have to edit it for some reason. For example, maybe you want to change the Referred From field, because the client didn't disclose it initially. If you edit the "Diversion Workflow, it'll take you back to editing page 7 and you have to first remember what page the Referred From field is on and then navigate through all the pages back to it. That's cumbersome for the user. It also seems simpler from a development standpoint to store the data equally and not care how it was entered, much like how it doesn't matter if you do an "Express Goods" transaction or a "Goods & Services Transaction," the data is stored exactly the same and it looks the same after you've recorded it. So, in conclusion, there should be one consistent Edit Diversion screen that you get to when you hit the Edit button, regardless of which way the Diversion was recorded, and it should take you to a one-page form that has all of the fields on one screen.

Blank service DateEnd for Diversions

When a Goods & Services record is attached to a Diversion record, HIFIS_Services.DateEnd is NULL.

Follow-up on Diversion should not be mandatory

In the Diversion module, the "Scheduled Follow-up" field should be optional, not mandatory. For context, here's why it needs to be optional and not mandatory: First and foremost, because there is no option to actually do a follow-up in the Diversion module! This means that every single Diversion has either an "upcoming" follow-up or a "past due" follow-up, and they are flagged as requiring attention, but there's no way to dismiss the alert saying they require attention. Second, because not every Diversion requires follow-up. Sometimes a person is diverted by buying them a bus ticket back to their home community, in which case it might be difficult to follow up. And in other cases, it might simply be so clear that you're successful that a follow-up is not needed. Or, if you end up booking them into shelter, then you're going to be working with them in the context of them being a shelter guest and you probably wouldn't want to go back and update the Diversion record. Third, because neither the Housing Placement module nor the Housing Loss Prevention module, which seem to be being replicated here, actually require scheduled follow-ups, so it's inconsistent.

Canceling the Edit Diversion makes it Abandoned

If you Edit a Diversion sort of by accident, and then hit "Cancel" to say, oops I don't mean to actually change anything, it says it will set the status to "Abandoned" which seems counter-intuitive. The user has already created a Diversion attempt and saved it with a status other than "Abandoned," so the Diversion attempt was actually not Abandoned. But, in attempting to avoid overwriting data, the user could unintentionally overwrite the actual status of the Diversion, which seems backwards to me.

Add Goods & Services in Diversion fails to save

When I try to add a Goods record OR a Services record while completing a Diversion - either the Diversion Workflow, or from the Edit Diversion screen, it fails to save if Programs are a mandatory field for Express Goods / Express Services.

13110: Outreach List shows all Goods & Services/Group Activities

It has come to my attention that all Goods & Services and Group Activities are being now listed on the Outreach List, regardless of if they have a location or anything like that. This strikes me as problematic. There are plenty of times you would provide a Goods & Services transaction that's not Outreach, and same goes for Group Activities. It just seems a bit weird to have every single one of these transactions show up on the Outreach List, when many of them. As a very simple fix, I'd suggest perhaps that only Goods & Services and/or Group Activities with a captured Service Location should show up on this list.

Map view on outreach shows services for other providers

In /Outreach/ServicesList there should only be outreach services for the current service provider visible. On the Standard View (i.e. list) the correct services show up. On the Map View, it shows services for other service providers.

Chronic homelessness not working properly

In 4.0.60.1, clients are becoming chronically homeless multiple times, and also becoming chronically homeless at the wrong time.

History of chronic homelessness is missing

If a client was chronically homeless but isn't anymore, say if they were in shelters from Jan 1 2022 to July 1 2022, then the records relating to chronic homelessness disappear. I would expect there to be a record saying that they became chronically homeless on, say, July 1 2022 (ish), and then another record saying they stopped being chronically homeless on, say, January 1 2023 (ish). So I'd expect to see two records here. What I'm actually seeing is, if the client is still chronically homeless, there'll be a record saying that they became chronically homeless on July 1 2022. But if the client is no longer chronically homeless, that record gets deleted, so there is no record that they ever were chronically homeless.

"Diversion workflow steps" shows to users without right

A user with rights to everything in the Diversion module (HIFIS Modules > Diversion) but without rights to anything in Administration (including Administration > Diversion Workflow Steps). The Administration menu appears for this user with the option Diversion Workflow Steps. When the user clicks on it, they get a "you don't have rights" error message. The bug is that the option should not appear in the Administration menu at all.

v3 VI-SPDAT rights are a mess

There's a new category for the latest versions, instead of putting them under the matching category as before Several rights are inconsistently named. VI-F-SPDAT vs F-VI-SPDAT and TAY-VI-SPDAT vs Y-VI-SPDAT Doubled up on Y-VI-SPDAT v2 rights and no VI-SPDAT v3 rights

Pagination missing on Client Search

When you use the Client Search, results show but the ability to navigate to another page is missing, so if your search result returns more than X clients, they cannot be found.

Client Search not working as expected

The Client Search is really different than in our current production version (4.0.59.4). Is it working the way you expect it to? For example, to get to my client John William Test (Alias 1 Jonathan Silly Pants), it no longer works to search jo te or wi pa. john test doesn't work either, you have to type in test, john. But jonathan silly works. Is that by design? Absurdly, han sil works.

The sort function in the Directory of Services is not working.

The Client Information and Client Management menus are missing when users view the "State Change History" log.

Users are unable to see programs associated with a case management record.

Case Management > View All Session Details Blank

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.