HIFIS 4

Create a user template that includes Service Providers and Rights, to speed up user creation. The Problem User have a set of rights at each Service Provider (this is not the problem) Each user account needs to be configured individually, even when it should be identical to that of a co-worker. A user could have 10 different sets of rights at 10 Service Providers It’s time-consuming and confusing to set up user accounts and mistakes often happen For the following two example users, an administrator would need to manually go through and define rights at Shelter A, then define rights at Shelter B, then define rights at Shelter C, etc. Example User: Secondary Rights Steve Let’s imagine Steve works at Shelter A. He logs in at Shelter A but also needs some access to data belonging to Shelters B and C. In order to achieve that, he needs to be granted access to 3 Service Providers and be configured with different rights at each. Shelter A: General shelter staff rights Shelter B: No ability to log on, but can read case files and VI-SPDATs belonging to this agency Shelter C: No ability to log on, but can read VI-SPDATs completed here Example User: Manager Madeline Let’s imagine Madeline is a manager at Shelter A. Because the shelters in her community work together very closely, all shelters have agreed that managers can ban staff from the other shelters in exceptional circumstances, and communicate important notices with each other. Shelter A: General shelter manager rights Shelter B, C, and D: Can create Service Restrictions and Bulletins The Proposed Solution Allow administrators to define a user template, which is a combination of Service Providers and the Rights for each Service Provider, and/or Give administrators the ability to clone an existing user (copy Roles, Service Providers, and Rights) The Advantages of this Solution User accounts are set up without error (less troubleshooting) Increased user acceptance by new users (no more “I can’t do X that my co-worker can”) Reduced administrative burden to administrators (faster to set up accounts) Because it would be easier, communities may be more willing to customize data sharing to suit their needs instead of coming up with workarounds (i.e. through reporting)

Not a bug report today but a challenging intended behaviour. I'm not sure which version this new feature was introduced, but there is a newish feature that prohibits adding new consent records when one already exists. However, this creates challenges for users when they see that a client's consent is about to expire . This problem was brought to my attention by Kristina in Niagara Region, where they make use of the automatic consent expiry feature. They use enforce consent plus automatic expiry after 365 days. So the problem goes like this: A user cannot record a new consent record until after the existing consent record expires. This is true even if they set a start date for the new consent to be some time in the future. So for example, if today is Feb 2 and the consent is supposed to expire on Feb 3, they cannot add a new consent record starting Feb 3. Moreover, if the consent is supposed to expire today, Feb 2, they cannot add a consent record with today's date because the consent has not yet expired (there's no time attached, so it expires at midnight when it becomes Feb 3). They can only add a new consent record if the original consent has expired on Feb 1 or earlier. This is problematic because it prevents staff from being proactive. "Hey Steve, I see your consent is about to expire next week, let's have a conversation." With some clients, obtaining consent is more than just simply getting a signature. Staff can ONLY obtain new consent AFTER the old one has already expired, which means that it's possible for clients to be unable to receive services for a day or two, or have staff be unable to make changes to the client file for days or more. There could be a theoretically simple workaround, which is to have the conversation early, and then adjust the end date for the current consent record. If I alter the end date to say that the original consent ended on Feb 1 instead of Feb 3, now I can add a new consent starting Feb 2. However, when there is a shared cluster and a shared client, the first consent record may be owned by a different service provider than the one that is currently serving the client. Therefore, the user currently interacting with the client may be unable to modify the original consent record. So this potential workaround does not always help staff. An administrator could do that, but that places a significant administrative burden on the administrator who shouldn't really have to be involved in this. The simplest way to solve this behavioural challenge is to keep the validation, but rather than comparing the current date  to the first consent record's expiry date, instead compare the start date  of the second consent record to the first consent record's expiry date. There are other possible solutions, but that's the quickest fix, I think.

Users are not able to delete a family history if it was created by accident.

Users are not able to modify the look-up tables in the Waiting list module.

Users can be given the right to delete health records and medication records from a clients file. However, there is no button to delete these records.

When a client is added as a witness in the incident module, there is no entry in the Client Activity Log.

When a user uses the "Create and add member" option in the Family module, HIFIS doesn't create an audit log entry.

There is a right option to delete comments in the client details module. HIFIS does not give users the option to delete comments.