Client privacy is a primary concern for a number of communities who are considering using HIFIS 4.
It can be quite a challenge to understand the legal implications of what communities should be doing and should not be doing on this front, but here is a good resource to understand Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA). Many Provinces and Territories also have their own regulations, but they are frequently modeled after PIPEDA.
In general though, you can think about protecting a client’s information in a few different ways:
- Make sure that you are transparently explaining to the client what you are collecting and what you are using their information for, and obtain their explicit, informed consent to do so
- Limiting who (which staff, which organizations) has access to the client file, and making sure that they are appropriately trained on protecting client information
This blog post is going to focus on the first portion, consent. Here’s an overview of how HIFIS 4 handles consent.
Consent in HIFIS 4
There is a section in HIFIS 4 where you can add a record that a client has provided consent to allow the collection and use of their personal information. This section is optional. Some communities elect not to use this component, assuming that if a client has been added to HIFIS, it’s because they’ve consented and there is a paper record of it somewhere.
However, HIFIS provides you with the option to upload a scanned copy of a consent form as an attachment, potentially doing away with the need to keep paper records.
In HIFIS, consent is governed by a Start Date and an End Date. The Start Date corresponds with the date the client provides consent, of course. The End Date corresponds with whatever date the consent expires. In some communities, consent expires after a pre-determined period of time, such as one year or two years. Even in communities where this is not the case, a client could rescind, revoke, or withdraw consent, which is similar to consent expiring. If the client withdraws consent, a user would add (or update) the End Date for the client’s consent record to indicate that the consent for this client is no longer valid, and a new one is required.
There is a HIFIS setting that communities can control defining the default consent expiry period. For example, if you indicate that consent expires in 1 year, then each new consent record will automatically have an End Date set for 365 days after the consent Start Date.
There is a HIFIS setting that communities can control which makes consent mandatory. This creates three changes to the way the software acts.
First, when a client is being added, the user adding the client must additional add a record of consent for the client, otherwise they won’t be able to actually add the client. They won’t be able to save, creating a new client file, without providing a consent record.
Second, the client’s current consent status is displayed prominently under their profile picture. A consent status is Active if there is a consent record with a Start Date before or equal to today, and either a blank End Date, or an End Date after or equal to today.
Third, if a client does not have an active consent record, the client file becomes read-only. In other words, users can still access the client file and the content within, but they can’t make any changes. For example, they wouldn’t be able to book the client into a shelter without active consent. If the user tries to make any changes, they get a pop-up message like this one:
Wait what? I hear some of you saying. You can still access the file without the client having active consent? That doesn’t make sense!
Most legal frameworks in Canada state that the withdrawal of consent is not retroactive. For example, here is an excerpt from a FAQ about Ontario’s Personal Health Information Protection Act:
A withdrawal of consent is not retroactive. For example, this means that where a disclosure has been made on the basis of consent, the custodian is not required to retrieve the information that has already been disclosed. However, the custodian must stop disclosing the personal health information as soon as the notice of withdrawal is received. A withdrawal of consent would not apply to a collection or use that had already occurred prior to receiving the notice of withdrawal. It would only apply to new collections of personal health information and future uses for the purpose of which the consent was initially obtained.
This is the way that expired consent works in HIFIS 4, based on legislation like that one. If a client withdraws consent, their data does not get hidden, removed, or destroyed. But it does mean that no new information about the client can be added.
There are three types of consent that HIFIS 4 allows: Explicit, Inherited, and Declined – Anonymous.
- Explicit consent is selected whenever the client has explicitly said “yes, you can collect my information,” whether that is a verbal consent or a written consent form. Note that some municipal legal departments – and potentially some provinces – don’t accept verbal consent, so just because it says so in this blog does not mean you can accept verbal consent in your community!
- Inherited consent is selected whenever the individual consenting is a dependent minor and another family member is providing consent on their behalf.
- There is a HIFIS setting that communities can control defining the minimum age of consent. Clients below that age must provide Inherited consent, and clients at least that age must provide Explicit consent.
- Declined – Anonymous consent is used to hide a client from being accessed by other service providers. See more discussion below.
Declined – Anonymous consent
When you add a new client, you can select Declined – Anonymous as the consent type. What this does is it means that the client file will be hidden or invisible to other service providers. In other words, if the client Annie goes to Shelter 1, and they create a client file for her, and they indicate her consent type is Declined – Anonymous, then they can work with her file as normal. But then, if Annie goes to Shelter 2, and they try to search for her, they won’t be able to find her file, and they’ll have to create a new client file for her, since the first one is inaccessible to them.
Note that you can only make a client Declined – Anonymous when the client is first being created, which means that it is only an option if you have enabled the Enforce Consent setting.
An explanation from the HIFIS Development Team:
Once a client has been exposed to the shared system, they cannot be locked down to a single provider with Declined – Anonymous consent again.
This is why we only allow Declined – Anonymous consent to be set at client creation, because at that point there is no chance of exposure to other service providers. Once a client becomes accessible to the entire cluster they can have transactions at other providers, or even be accessed by users at other providers.
If we were to bring the client back to Declined – Anonymous status, it would break all of the records that were ever attached to the client from outside the initial Service Provider, these Service Providers wouldn’t even be able to access their own records. As an example, I’m sure you can see the problems that would arise if the client was switched back to Declined – Anonymous consent while they happened to be booked in at another Service Provider.
If a client is ever exposed to the system and wishes to go back to Declined – Anonymous status, the ideal procedure would be:
- Expire the shared/Explicit consent on the initial Client record.
- Create a new Client record for the person with Declined – Anonymous consent.
- Work with the new Client record exclusively at the Service Provider that created them.
- If they ever agree to be exposed again, add a new Explicit consent to the new instance of that client.
- Merge the new Client record with their previous Client record.
- Continue using the single client.