HIFIS has many features that come to access to client files, including:
Clients with “Decline to Share” Consent
Demographic visibility settings
Setting up multiple Clusters
Hiding some clients
However, a gap remains when it comes to preventing specific Users from accessing specific Clients.
Example: The outreach worker “Ann” has an ex-boyfriend “Bill,” and their relationship did not end well. Bill enters the shelter system as a client, but does not want Ann accessing his file.
There is nothing that can be done when a client does not want a specific staff accessing their file, but are generally okay with data collection and sharing. There are two approaches that can be taken, neither of which is ideal:
Implement a more extreme form of protection (i.e. the client added to HIFIS with “Decline to Share” consent), which may have other consequences for the client such as not being able to access some services or not being on the By-Name List; or,
Acknowledge that such access cannot be prevented technologically, and instead turn to monitoring for misuse.
The problem with the latter solution, however, is that there is no good way to monitor for misuse. You’d need to keep a separate list somewhere with your problematic user-client pairs, then open up each user’s or client’s audit log, and scan through for any reference to the other party. Talk about inefficient!
Enter: The Conflicts Module
The Conflicts module in HIFIS serves little function for most front-line staff. You can record that a client has a conflict with another person, but can’t really do anything about it. As a result, the module tends to be unused, which presents an opportunity.
Instead of utilizing the Conflicts module for the benefit of front-line staff, use the Conflicts module for administrative and auditing purposes. You can leave it completely disabled for 97% of users, but still put it to good use. Here’s how:
When a client has a specific request or requirement that a particular user not access their data, that request gets forwarded to an administrator. The administrator adds a Conflict in the Conflicts module, selecting the client and the user.
Now, you are able to cross-reference the conflict against actions in the audit log. Essentially, when there is an action in the audit log that includes the client and the user, that happened while the conflict is ongoing, that’s a red flag.
We’ve even created a helpful report to make monitoring this a breeze!
Looking for a way to monitor when users are accessing clients they shouldn't?
Check out our Audit Boot Camp report: Unauthorized File Access!
Comments