This post is part of the series Privacy in HIFIS 4
Other posts in this series:
As previously discussed, client privacy is a key concern for communities using HIFIS 4. One of the approaches to protect client privacy is to restrict who has access to a given client file.
A tool that HIFIS 4 provides to support this approach is called Attestation. It’s one of multiple tools that can be made use of, but it’s simple to set up.
When Attestation is active, when an agency first serves a client, someone from that agency needs to Attest that they are in fact serving the client, and they’re not just snooping into the client file for fun.
When a client file is pulled up for the first time, the user will see a pop-up window prompting them for Attestation. The user can click Yes, to say they are Attesting, or No, they are not. If the user clicks Yes, they move forward to view the client’s file; if they click No, they are returned to the previous screen.
Note that there’s nothing stopping a User from just clicking the “Yes” button. The User who is Attesting doesn’t need to provide a rationale or proof in order to Attest. However, this action is logged, so it can be audited.
Attestation is enabled through the Cluster Settings, and a HIFIS administrator can also customize the text that is displayed on the pop-up window.
Service Provider-Level Attestation
To be clear, Attestation is logged at the Service Provider level, not the User level.
So, if a client enters the House of Hope Shelter, whichever User first does the intake Attests on behalf of the whole House of Hope Shelter. After that User Attests, everyone else that works at House of Hope Shelter has access to the client file. So in a sense, the best Attestation text would be along the following lines: “I attest that my agency is serving this client.”
From the HIFIS Development Team:
Regardless of what your Enforce Consent setting is, enabling Attestation will prompt a user to ‘Attest’ that they are working with the client before HIFIS directs the user to any of the client’s pages. This will happen the first time a client is accessed at an organization (creating a client automatically accepts an attestation record for the logged in organization in the background), afterwards other users at the same organization can access that client without having to attest. This is mainly used in shared environments where a client may only use 2 of the 5 Service Providers in a given cluster, until the client visits one of the 3 other providers they will be required to attest to working with that client before opening that client’s page.
Consent and Attestation
Attestation is separate from Consent, but if you both Enable Attestation and Enforce Consent, something new happens in HIFIS.
Normally, when a client’s Consent record is inactive and Enforce Consent is on, users can access the client file but it is read only. If you have Enable Attestation on and Enforce Consent on, users can’t access client files that have inactive Consent at all, if they hadn’t previously Attested that they were serving the client.
For example, let’s say you have two shelters, House of Hope Shelter and Mary’s Place Shelter. Let’s imaging Jane is a client that stayed at Mary’s Place (and someone there Attested) but never stayed at House of Hope (and so nobody there Attested). Then Jane’s consent expires – maybe automatically after a year has passed. Her consent status now becomes inactive. After Jane’s consent is inactive, if someone tries to access her file from Mary’s Place (where someone has previously Attested), they can access her file, but can’t modify it without active consent. However, if someone tries to access her client file from House of Hope, they can’t access it at all. First they see an Attestation prompt, then they will see a Consent prompt. Only after providing both Attestation and a new Consent will House of Hope be able to access anything within Jane’s file.
From the HIFIS Development Team:
Now if you have Enforce Consent enabled and Attestation disabled, when a client’s Explicit consent expires their record becomes ‘read-only’ in the system – until a provider obtains new explicit consent from that client. If you enable Attestation, we can further enhance the behaviour of the ‘read-only’ client records by restricting the access to organizations that attested to working with that client prior to the consent expiring. A client with expired consent would not disappear from searches done by organizations that never attested to working with the client, these organization can still search for the client in the system, but the only action they can take with the client is adding a new consent record.
Continue reading this series:
A Primer on Limiting Access to Client Files