HIFIS Feedback

Introduce new behaviour in HIFIS to allow better tracking of referral completion, recording referrals in more circumstances, and referring clients to other service providers inside HIFIS. Reference: https://www.acreconsulting.ca/products/216596-HIFIS-Improvement-Project-Referrals

In previous versions, HIFIS handled a blank "minimum age of consent" as if there was no minimum. Starting in 60.3, users get an alert about the minimum age of consent even if the minimum age is left blank, and upon clicking the save button, they get an error and are unable to proceed.

Imagine a client with, say, a medical alert (e.g. epilepsy) who also is an intravenous drug user. This is a situation that would logically result in multiple watch concerns or behavioural risk factors. However, the flag currently only shows the presence or absence of any such factors, and the tooltip only indicates that the client has factor(s). This means that the second (and third, and fourth) factors have a tendency to get lost, as users don't notice that a new one was added. When a client has multiple Watch Concerns or Behavioural Risk Factors, the flag should appear multiple times, once for each record. In addition, the tooltip should say what the factor is (e.g. "Medical Alert") instead of the type of record (e.g. "Watch Concern").

If attempting to use the Contributing Factors module to record a higher number of factors (say, more than 1-3), then it can be tedious as they all need to be added one at a time. Instead, we suggest that the "Add Contributing Factor" screen have the Contributing Factor drop-down menu be multi-select. We do not suggest a change to the data structure, simply have a way to add multiple Contributing Factors easily at the same time. Each record would be independent from each other after they are added. The same approach can also be taken with Watch Concerns and Behavioural Risk Factors.

In some modules, like Case Management, Client Vitals, and Housing Placements, there are already multiple tabs displayed. The Custom Tables get inserted as a new tab at the end. This is relatively easy to access and navigate. For other modules, like Turnaways, Admissions, and Goods & Services, the workflow makes it highly unlikely that users will ever see that a Custom Table exists for that module. For example, in order to add a Custom Table to the Turnaways module, a user must: 1) add a turnaway record, click save, 2) be redirected back to the turnaways list, 3) click on the Display button for the turnaway that was just created, 4) click on the Custom Tables tab, 5) click on Add Custom Table record. Most users are just going to save the turnaway and move on, so they won't even see that a custom table exists. In these situations, it would be preferable if the custom table were displayed inline at the bottom of the existing form, like on the Add Client screen - at the top there is a section about consent, then in the middle there is a section about the client, then there is a bottom section about housing history. In short, the preferred display depends highly on which module the Custom Table is attached to. Some are quite usable, and some are entirely unusable. Potentially, there could be a setting for each table to ask whether the questions should be displayed inline or in a separate tab.

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.

Sometimes a user account might get added with a typo, or in contravention of a naming policy. It would be great if we could be able to modify user accounts.

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.