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

Although obviously people shouldn’t be collecting information for non-consenting clients, there is a big sticking point and that’s shelter use. Shelters need to report on bed nights and occupancy, and if they give a bed to a client who didn’t consent to information collection, they’re put in a difficult position. What to do? The options are: Book in the client Anonymous, Anonymous. But this client is still bound by the concurrent stays rules, so cannot be in two beds at the same time. If there are two non-consenting clients occupying any two shelter beds at the same time, this is a problem.Don’t record it in HIFIS at all. But then the HIFIS data is unreliable, and you can’t run a year-end report, or do a data export to INFC, that is actually true. And people might think the bed is available because HIFIS says so, so make inappropriate referrals.Create a series of fake clients, like Anon 1 and Anon 2, so they can be booked in concurrently. This is the option a lot of communities take, but it then causes a proliferation of clients named “Anonymous” or “Anon,” which makes the database messy and actually discourages users from getting real consent. Since this is really only a big problem in Admissions (concurrent book-ins), I propose a solution like in Turnaways: Add Anonymous Book-In. Same as the way Turnaways handle anonymous clients, but for the Admissions module.

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

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)

The Contacts module is problematic for many reasons, but one of them is that the Contact being added must first exist in the database. Aside from the workflow challenges related to this (see https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/add-create-and-add-contact-button-to-contact-module), this is also problematic from a privacy perspective. In order to add, for example, a client's next-of-kin, they must be added as a Person in HIFIS, added to the People table, which means that person is shared and publically searchable by everyone else. There isn't even an option to control who can access which People via something similar to Declined - Anonymous consent. It would be great if the "Add Contact" form did not require selecting an existing Person. Instead, have a free text field to enter the client's name and phone number. The record should exist ONLY in the context of the client file, not in a big shareable database.

In the Diversion workflow, there is a "Create and Add Contact" button on page 4. However, no such button exists in the actual Contacts module, making the Contacts module very difficult to actually use.