HIFIS Feedback

There are a lot of fields that cannot be made mandatory or disabled, for no particular reason other than that functionality has not been programmed. It would be ideal if ALL fields could be configurable in this way. See also https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/hidden-not-just-disabled-fields

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.

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

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.

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

On waiting lists, there is a date range filter, and the default setting is 1 week. That means that by default it only shows waiting lists that have been created within the last 1 week. I always tell staff to immediately change the filter to "All," but it's confusing to staff why it says there are no waiting lists when there are some they use daily. My suggestions: Remove the date filter that's filtering by Start Date of Waiting ListReplace it with an Active/Inactive filterAdd an End Date field to the Waiting List, so you can "close off" a waiting list that's no longer in use.

Recently it's come to my attention that BC Housing has disabled the Geographic Region field on the Client Vitals screen. The news that one community has disabled that particular field is not a surprise to me, nor should it shock you. I generally recommend to every community that asks that they should probably disable this field. I wrote a blog post about it back in 2018. https://www.acreconsulting.ca/blog/75778-geo-region-vitals The reason why it's not useful is because it's so vague about how it should be used optimally - should it contain where the client is from, currently is, or is intending to move to? However, the only situation where I can think of that the Geographic Region field is actually useful is if you have a very large catchment area, like a province-wide database. Like in BC. One would presume that you'd then use the Geographic Region filter to filter clients and only show the ones in your local area. You could use this filter for BNLs for example, in the Coordinated Access module. Which is what the Coordinated Access module does, and I'm told that planned modifications to any reports that respect Geographic Regions would also use the same behaviour. In other words, this field is not useful for 90% of instances, and of the 10% where it is useful, at least some are not using it because they too don't feel that it's useful. I propose that one of two things happens: either get rid of the Geographic Region field on the Client Vitals screen, or automatically update it. The latter could be a relatively easy fix: any time a client stays in a shelter, or has a housing history record (or potentially receives a service), the Geographic Region field on the vitals screen should automatically be populated with the Geographic Region on the housing history/stay/service provider. There's some nuance to this - I'd probably create an application setting that would turn this behaviour on or off, somewhat like the default file numbers setting. You'd also need to define what happens if the geographic region field for the most recent record is blank, but that's relatively easy to sort out.

HIFIS allows you to mark some beds as “Mobile” but then you can’t move them from room to room. If you have a cot or a crib or some mats that do need to move around, this is a problem. You’d need to add a bunch of extra beds and mark them out of service most of the time; and you couldn’t rely on HIFIS for measuring your capacity.

After upgrading to HIFIS 4.0.59.7.1 from HIFIS 4.0.59.4, we received several complaints that some of our clients were no longer appearing in search results. These clients were active but not visible in the search results using any of the All, Active, Inactive and Deceased filters. Initial troubleshooting found that these ‘missing’ clients had all been merged with other client profile(s) in the past and had active Declined – Anonymous and Explicit consents assigned to their profile from the client merge process. A client’s consent is evaluated as part of the criteria used to determine whether the client should appear in search results.  For clients with both Declined-Anonymous and Explicit consents, the Declined – Anonymous consent is evaluated first. When the Declined consent is from a different service provider than the service provider the user performing the search is logged in to, the client will not appear in the search results. Consent evaluation order used in HIFIS 4.0.59.7.1 Declined - Anonymous Consent without an Expiry Date.Explicit Consent that does not have an Expiry Date or the Expiry date occurs in the future.Declined - Anonymous Consent with an Expiry Date. Workaround / Fix As a workaround/fix for this issue, the consent evaluation order was modified to check for Explicit consent first. Explicit Consent that does not have an Expiry Date or the Expiry date occurs in the future.Declined - Anonymous Consent without an Expiry Date.Declined - Anonymous Consent with an Expiry Date. This was done by modifying the vw_ClientSearch database view and updating the ISNULL() code on lines 48 and 57. Before ISNULL(C2.ConsentID,ISNULL(CX.ConsentID,C2E.ConsentID)) AS ConsentID After ISNULL(CX.ConsentID,ISNULL(C2.ConsentID,C2E.ConsentID) After making this change, the ‘missing’ clients appeared in search results.