This post is part of the series Privacy in HIFIS 4
Other posts in this series:
One of the pillars of protecting client information is making sure that the only people accessing a client’s information are the people that need that information to be able to serve the client. A previous article discussed limiting user access to files via attestation, but that’s not the only tool in your toolbox.
Service Provider Visibility Settings
A shelter that only serves adult men does not need to be able to access client files for women and children, and they probably don’t need to access youth either. Similarly, a youth-serving agency doesn’t need to be able to access files for seniors or infants.
In HIFIS 4, we can limit what clients each service provider has access to via their Service Provider Settings.
We have the ability to define age ranges (for example, youth are 16-24, or 18-29, or 14-18) and specify what client groups this service provider has the ability to access.
When service provider settings are configured in this way, users logged in at the service provider are completely unable to access clients that don’t meet these visibility criteria. For example, a shelter for adult females may state that they serve clients aged 18 and older, but if maybe one time they try to serve a client who is 17 years and 11 months old, they will be completely unable to access her file. They could try creating a client file, but then after the file is created they wouldn’t be able to open the file, or locate it. Searching for that client’s name would yield no results. These settings are inflexible in that way (but you could get around it by changing the settings to include 17-year-old females in the client list).
Another limit is that it treats gender as binary, so it doesn’t handle transgender or other non-binary clients well. Also, this feature isn’t very useful for family shelters, who don’t target their clients based on gender or age (technically, they might serve all ages and genders).
Restricting the Client List
A second way to limit access by staff to only clients they are supposed to be accessing is to restrict the client list.
This means that when a staff goes to the client list (Front Desk > Clients) they will not see a list of all the clients in the cluster. Instead, they will see a search box.
Staff can use this box to search for a client’s name. Then, after they search, they are provided with a list of clients who match the search criteria, as well as an Add Client button. This feature forces staff to know who they’re looking for as opposed to casually browsing through a list of clients.
Administrators can also specify the minimum number of characters needed to conduct a search, which can tighten or loosen the results list.
A challenge with this approach, though, is that it can have a negative impact on data integrity. Two agencies could have a shared client and not even know it, if the client has multiple variants or spellings of their name. For example, one agency might know a client as Billy Connolly and a second agency might know the same client as William Conley. If users at both agencies only search for the spelling that they know about, it might take years before anyone notices that they are the same client.
Individual Access to Irrelevant Clients
An individual staff member can be granted access (or have access revoked) to Inactive, Deceased, and/or Hidden clients.
Each client has a State that is either Active (default), Inactive, or Deceased. At present, this state can be changed manually, though in the future there may be a way to automatically inactivate clients that have not received services recently.
Users can be restricted from accessing Inactive and/or Deceased clients, since they are no longer relevant (i.e. clients that are no longer being served). Clients without access can still locate client files, and see that such clients exist, but they cannot open the files to review their contents.
Each client is also considered Visible or Hidden. Not all staff can make a client Hidden; this is most frequently used by agencies that serve victims of domestic violence in a shared context. Users can be restricted from being able to see Hidden clients, but this works slightly differently than the previous setting. Hidden clients cannot be found, even by searching for them by name. This behaviour is similar to the service provider settings not granting access to that client.