HIFIS Feedback

It would be great if we could customize the labels of the fields in HIFIS. For example, in the Incidents module, (1) I always get people asking me what "Disposition" means, (2) it might be nice to change the label of the field "Attachments" to "Upload Incident Report", and (3) it would be handy to change the label of "Location" to something else that a service provider might find useful, like "Room" or "Building" - "Location" is a bit vague. I'm not specifically picking on the Incidents module - this is a general request for all fields - the ability to modify how fields are labelled.

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 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)

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

HIFIS automated emails (account creation, password reset) are missing some vital information like the person's username and the URL to the HIFIS instance! I'd like to update the email to include at a minimum the person's username and the HIFIS url, but it would be great to be able to include some custom text in these emails, such as a link to training materials or help documentation.

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. For example, some transitional facilities use the Admissions module and their clients should be "Transitional."

Because so many staff work at more than one service provider, many staff should be making the conscious decision of which service provider to log in at, instead of always going to the default for their user profile. Not giving them the choice means that they could log in at the wrong service provider, fail to notice, and then accidentally add some records that are attributed to the wrong service provider. That would result in an accuracy and access problem. This could be a privacy concern: say, I open a client file and record a private client comment, but attributed to the wrong service provider would result in the wrong people having access, and therefore would constitute a breach of personal information. Rather than undoing all your hard work (because I actually do prefer the new login screen), I propose this specific solution: Add a new Application Setting which governs whether the Service Provider field should show up on the login screen. This would allow communities to choose which login screen they prefer, and everyone is happy.Communities choosing to "Hide Service Provider on Login" would experience the current behaviour, and the "Default Service Provider" field in the User Profile should be a mandatory field.Communities choosing to "Show Service Provider on Login" would see the "Default Service Provider" field in the User Profile be an optional field. However, the Service Provider field will still show on the Login screen. If there is a Default Service Provider selected for the user, that Service Provider should be pre-selected, but staff should still have the option to change it. Some users may not have a Default Service Provider selected, so they would be forced to choose a Service Provider every time. While you are at it, it seems like an oversight that the selected Default Service Provider can be one that the user account doesn't have access to. And since the Default Service Provider field is mandatory, it automatically selects the first alphabetical Service Provider, regardless of whether the user can access that Service Provider or not. Can we filter the Default Service Provider drop-down menu to only include Service Providers that the user has access to?

The script for the "Most Recent Triage" column lists eligible VI-SPDAT types, which do not include the latest versions, and the script for the "Most Recent Assessment" column says, basically, anything not a Triage is an assessment. So the VI-SPDAT v3 series would show up under Assessments and not Triage.

Citizenship & Country of Birth. If you select Canadian Citizen - Born in Canada, then Country of Birth should automatically select Canada and you shouldn't be able to change it. If you select pretty much anything else, you shouldn't be able to select Canada as Country of Birth. Consents. You can have multiple active consents, including consents of different types. So for example, you can create a Declined - Anonymous consent, and then later create an Explicit consent, but that leaves the Declined - Anonymous one open. Reservations + Admissions. You can have a reservation for Client A and then when Client A arrives, you could book them in normally, ignoring the reservation, and then the same client has both a current bed and a reservation for one. Income. You can have more than one Primary source of income. Veterans. You can have a child veteran. Or you can have a veteran - canandian armed forces who is a refugee. Indigenous. Should ALL people identifying indigenous status be Canadian Citizen - Born In Canada? Or what happens if you have, say, an American with indigenous identity? Should they be non-indigenous? So maybe what should happen is you ask about citizenship first and then if they say born in canada, then the indigenous status question appears (like some other areas of the software where a field is hidden unless you do X). if they don't say born in canada, the value captured is automatically "not indigenous"? Overlapping Housing History records are possible. Overlapping Housing History and Stay records are also possible.