Today’s blog post is a special excerpt from our HIFIS Administration Masterclass.
Disclaimer: ACRE Consulting is not a legal expert, and this should therefore not be taken as legal advice! Definitely check with your legal and privacy people before you do anything about consent.
It's pretty much a given that at some point, you're going to have at least one client that doesn't want to consent to information collection. In some communities, this is very common, while in others it's a rarity. (We're not sure why! We think it might have to do with the culture that has developed locally?) So, what are you to do?
What you should do is check with your legal support, before you start using HIFIS 4. Ask them, and follow their advice.
Your legal support is there to help you with this particular challenge. Ultimately, if you have a privacy compliance challenge, they'll be the ones dealing with it, and you could get in very big trouble. However, we can share with you what some other communities have opted to do.
No Consent = No HIFIS File
Some communities take a hard line approach and say that if a client doesn't provide consent, they don't go into HIFIS 4 at all. That's theoretically the correct answer, but leads to some operational challenges. What about shelters that need to report on their daily occupancy? They could run a report that pulls data from HIFIS, but each bed-night must be linked to a client file. No client files for non-consenting clients means that the reports pulling HIFIS data will be inaccurate.
Communities in this group tend to have a side practice. They rely on HIFIS 4 for reporting, but also have to keep a manual tally sheet or something similar to say "we also provided this many bed-nights/other services to non-consenting clients."
The advantage of this approach is that it's legally very safe, while the drawback is that you have an annoying manual work-around. Also, it remains to be seen how well it works in practice, which depends heavily on how well-trained your staff are. If, for example, you're using Enforce Consent, then a new or poorly trained staff might attempt to add a client, see an option that says "Declined to Share" (or “Declined - Anonymous”), and think they are allowed to put the client into HIFIS 4 without consent. Note that client files cannot be deleted, not by anyone.
No Consent = No Services
Technically speaking, consent to collection of information is distinct from consent to receive services. So you could have a situation in which a client refuses information collection but agrees to stay in a shelter. Some communities, therefore, could possibly have separate consents - one to receive services, one for information collection. However, other communities might come to the decision that the collection of information about clients is necessary to be able to provide services. That's entirely possible - you may need to know who has restraining orders against whom, or know a client's age, veteran status, or source of income to determine program eligibility. In fact, it's an easy argument to be made.
Some communities, therefore, have decided that if a client doesn't provide consent, partner agencies cannot serve them. The client doesn't go into HIFIS, but you don't need a manual tally sheet to count the non-consenting clients, so your HIFIS 4 reports are accurate.
The advantage, therefore, is there's no manual work-around and your reports are accurate. The drawback, however, is that it creates barriers for clients. And it's possible your legal support (or other stakeholders) won't like this approach, since consent to data collection is distinct from consent to receive services.
No Consent = Anonymous Services Only
At the time of writing, HIFIS includes a few places where you can simply record that you interacted with an anonymous client. These are:
Group Activities
Encampments
Turnaways
Diversion
In both Group Activities and Encampments, you can choose whether to connect client files, or simply record “Anonymous Attendees” or “Anonymous Clients.” This is a truly anonymous mechanism as you’re just counting the number of people - you say something like “34 people attended my hot lunch program.” You do not have to create a client file first and it’s very easy to use this method - intuitive for staff and no special workflow needed.
In Turnaways, you can choose to either “Add Turnaway” or “Add Anonymous Turnaway.” In Diversion, you click “Add Diversion” then there is an option to indicate if it was anonymous or not. In both of these cases, if the anonymous option is selected, the record is created and automatically linked to a built-in HIFIS client called "Anonymous, Anonymous" (client ID 1) (more on that later). So when you review your list of Diversions or Turnaways, they will be listed with the Client Name of “Anonymous, Anonymous.”
However, the main drawback of this approach is that it’s limited. There are only a few types of services you can record in this way. What happens if you need to record someone’s anonymous shelter stay? Of course, this method doesn’t work. Some communities might say that if a client doesn’t consent to information collection, they can attend a drop-in centre but not stay overnight, similar to the previous approach.
No Consent = Use One Anonymous File
As mentioned, there's already built-in to HIFIS one client called "Anonymous, Anonymous" (client ID 1) which is used for some things in the software. So, it's not too much of a stretch to say that all non-consenting clients could be consolidated into a single anonymous client file. Therefore, all services that are provided to non-consenting clients could all be attached to the same single anonymous client file.
Here’s how that’s different from the previous approach: you could, say, add an Express Good. There’s no “anonymous” option, but you can type the name “Anonymous, Anonymous” in the client search box and manually select that client. Then you proceed normally.
This has the advantage of protecting client privacy, and also not requiring manual work-arounds. Your reports will work, and it doesn't create barriers for clients. Your legal support will probably like this idea, too.
However, there's a drawback. Most shelters have their HIFIS installation set up to prevent a single client from being booked into more than one bed. It's a setting called "Allow Concurrent Book-Ins." Most service providers (and service managers) like to prevent concurrent book-ins, which means that they don't run the risk of having clients occupying multiple beds, or using up multiple bed-nights on the same night. After all, a single client can only be in one place at a time. So if you have two non-consenting clients both staying in shelters at the same time, you could only book in the client "Anonymous, Anonymous" once.
To deal with this drawback, you'd either need to make a few copies of the Anonymous, Anonymous client file (but how many?), or allow concurrent book-ins. If you create multiple copies of the Anonymous Anonymous file, things start to get messy and confusing (when do I use Anonymous2 versus Anonymous3?), but if you allow concurrent book-ins, then you could have other data problems like double-counting bed-nights. As you can see, this approach works to a certain extent, at which it starts to fall apart.
(We’ve proposed that HIFIS be improved to accomodate anonymous book-ins.)
A second drawback we’ve heard about from communities is that they have service providers that do this so frequently that the Anonymous, Anonymous client ends up with so much data that if you try to access their file directly, you end up with a time-out error. But of course, there’s probably no reason you’d need to access that file, so maybe it’s not a big deal.
No Consent = Individual Anonymized Files
To deal with the above challenge, some communities have a practice in which they add non-consenting clients to HIFIS 4 anyway. Each client gets their own file. However, in order to respect their clients' preferences, they create a semi-anonymous file, with a name like "Anonymous 12345" and attach the services to that file. They assign the client file Declined to Share (or Declined - Anonymous) consent, and typically they only record minimal data about the client - just enough to make their reports accurate.
However, this approach is not without its problems. First, you'd need to be able to identify that "Anonymous 12345" is really John Smith, which means you're probably having a manual list somewhere. This could potentially lead to legal problems - if you can identify that Anonymous 12345 is really John Smith, then you're collecting identifiable personal information, which is what the client said you couldn't do by not providing consent. You're not really not collecting their information. Be prepared for your legal support to challenge this approach (but it really is what some communities are doing)!
The second reason why this can be problematic is from a usability point of view. You could end up with hundreds of anonymous client files, and the client list is sorted alphabetically so clients named "Anonymous" show up near the top. So any time a staff opens the list of clients, the first thing they'll see is a list of anonymous files. Also, it may be easy or difficult for a staff person to locate the anonymous file they want, so they could somehow get into the practice of adding multiple anonymous client files for a single person. Or they might attach services to the wrong file, which might matter, or it might not (that's why staff might do it - because they think it doesn't matter). Also, the more staff see anonymous files in HIFIS, the more they might believe and accept that it's fine when client's don't consent; they can just put them into HIFIS 4 anyways. That's not something you necessarily want to encourage.
However, there is an advantage to this approach. If you start working with a client who doesn't provide consent and give them their own HIFIS 4 file, then a few days or a week later they provide consent, you can simply take the existing client file, add Explicit Consent, and convert it to a normal client file.
No Consent = Declined to Share / Declined - Anonymous
There are some communities and service providers out there that, when a client declines information collection, they add them to HIFIS with their real name and indicates that their consent is “Declined to Share.” (By the way, it’s “Declined - Anonymous” in 60.4 and under and “Declined to Share” in 60.5 and higher, so I’m using the terms interchangeably here.)
Is this allowed? Maybe. In Ontario, under MFIPA, there doesn’t appear to be an actual requirement for clients to consent, and under PHIPA, there’s a section on implied consent. We are not legal advisers here, and we aren’t intimately familiar with what the case is in other provinces either. But the point is that you might be okay with adding clients with real names to HIFIS without them signing the consent form. But we strongly recommend a comprehensive conversation with your legal support before you officially endorse this approach.
(I said that some communities and service providers are doing this anyway. It remains to be seen whether they’re going to get in trouble for it someday or not.)
No Consent = A Training Issue
One last thing that we'd like to add. We started this lesson by mentioning that non-consenting clients is sometimes a big issue in communities and sometimes pretty minor. This often comes down to language used, the perspectives of staff, and how clients are asked for consent. These are all things that can be addressed through training.
Here are some examples of how training could help:
Training could reinforce that when clients agree to data sharing, staff have to do less paperwork, since they can now access the data the client provided at another intake point. It saves the staff time if the client signs, so they might try harder to obtain consent.
Training could show how clients can access more/better/faster services if they agree to share information. Staff want what's best for the client, so if they see a benefit, they'll be more positive and encouraging when presenting the form to clients.
Training could reinforce that privacy is being taken seriously, and teach staff how clients' information will be protected, through auditing or user rights, and who will have access. Staff that understand these features can better communicate them with clients, and can provide this information to clients who are reluctant.
Of course, training can also ensure that staff are following policies and procedures. But don't overlook the other ways in which training can help with consent!
Comments