documents findability management paperless passwords security

DO Encrypt, DON’T Panic

DO Encrypt your data, and DON’T PANIC. Health Practitioners are required to secure their patient data, both in Canada and the US. Here’s what that means for Psychologists in Ontario.

Or, What the ‘strong encryption’ requirement means to Psychologists (regarding Fact Sheet #16 issued by the Information Privacy Commissioner of Ontario).

Why I’m writing this: I have a number of friends and associates who are Certified Psychologists in Ontario, and have been asked, casually, what exactly this fact sheet means.

Bottom line:  If you are a Psychologist providing health information to a health network provider, or a user of health information in the sense of PHIPA and its regulations, you need to secure all portable healthcare data as below. If you are NOT, you DO NOT have to.  If you do, or if you aren’t sure, please keep reading…

The office of the Information Privacy Commissioner (IPC) of Ontario recently issued ‘Fact Sheet #16” which gives a preliminary description of what ‘Strong Encryption’ means for portable devices. This is being circulated by the College of Psychologists of Ontario (CPO), and has been a cause for some concern for practicing psychologists. These orders directly affect two organizations, and have broad implications for all other organizations who operated under the PHIPA statute and its regulations.

In my career, I’ve been involved in a number of security initiatives and certifications, so I’m going to spell out what this means to you as a practicing professional in the field. I am also corresponding with the author of the Fact Sheet, who has been very helpful. This is NOT legal advice, nor does it establish a client relationship between us; I am happy to write suitable security policy statements for organizations I consult to, and help select suitable encryption systems, and help conduct Threat and Risk Assessments.

Background: two breaches of privacy have led to explicit compliance orders from the IPC’s office, HO-004 and HO-007 respectively, which are requirements to remedy inadequate protection of data on devices which were potentially accessed by unauthorized third parties when the devices were lost or stolen. This is a serious breach of both law and privacy, and it is entirely avoidable. These compliance orders call for the use of Strong Encryption, and Fact Sheet #16 spells out what that means.

In a nutshell: Encryption is a technology for processing data such that possession of the encrypted data does not reveal anything to an unauthorized third party, within reasonable cost and time bounds. ‘Strong’ in this context is a framework for specifying the attributes of a full system that uses encryption as an assurance for the privacy of data. While a tutorial on how this is done is beyond the scope of this article, the key attributes are that a very very large number of computations would be needed to derive the original text from the encrypted text, and that does not leave exploitable ‘holes’ in the system that make the encryption and assurance of privacy meaningless. The number of computations and system safeguards are intended to be sufficiently large so that the information remains effectively inaccessible for the lifetime in which release of it could cause harm. In the health care context, this means that you, as a practitioner, have a duty to protect the data using current best practice techniques that are intended to protect the data for the lifetime of the patient.

Fact Sheet #16 requires that seven major attributes are needed to comply with the intent of ‘Strong Encryption’ in HO-004 and HO-007.
1. Secure implementation: The fact sheet mandates the use of encryption solutions that have encryption modules certified according to FIPS 140-2. Your encryption hardware or software vendor will be able to assure you of this, and should be able to tell you the certification number of the FIPS 140-2 certificate being used. Truecrypt, Ironkey, and others definitely qualify.
2. Secure and managed encryption keys: This means that the keys must be ‘long’ and are themselves secured so that they cannot be stolen.
3. Secure authentication of users: This means that the user has to ‘log in’ before even trying to access the encrypted data.
4. No unintended creation of encrypted data: This means that a temporary file cannot be created for the convenience of software or the user accessing the data, as that file could cause a potential privacy breach, unless specifically authorized by a responsible individual who will assume responsibility for its care and destruction.
5. Identified, authorized, and trained users: This means that the users need to be explicitly listed, authorized, and given encryption access and training on what it means to have access to encrypted data. The appropriate analogy is that if you are given a key to a vault, or even your neighbour’s house, you are now responsible for the contents, and anything that happens to it.
6. Encryption by default: This means that health data must be preserved such that it’s always encrypted, not something that has to be explicitly remembered every time.  As a side note, this also implies that file-level encryption is NOT OK, and full system or at least directory-level encryption are mandated.  Save file-level encryption for data transfer, NOT use, and NOT for storage.
7. Availability and information lifecycle protection: This means that the data must remain available even if the person who is entrusted with it is unavailable or has forgotten their passwords. For large organizations, this may be handled by so-called ‘enterprise solutions’ which have centralized key management. For smaller organizations, specifically those NOT a formal “healthcare information provider” in the sense of the acts, you can and should have a documented plan for what happens if you lose the keys, and what happens when the information is no longer your responsibility.
8. Threat and Risk Assessment: This means that the solutions to the above requirements need to have a formal Threat and Risk Assessment (TRA). The preferred and approved methodology was originally developed by the RCMP, but has been transferred to the Communications Security Establishment Canada (CSE), and may be found here. Note that a formal TRA IS REQUIRED for Health Information Network Providers, but this does NOT have to be a huge undertaking for all projects and organizations, and is only a legal requirement for organizations and individuals who are healthcare information providers who are making services available for the benefit of other healthcare providers. In this context, it is a requirement for formal documentation of what the potential for loss of privacy is, what the risks of that loss are, and mitigation or remediation of those risks. Note also that this is a requirement of the Personal Health Information Protection Act, (PHIPA) and its regulations, not specific to this Fact Sheet.

So what does all that mean?

If you are a Psychologist providing health information to a health network provider, or a user of health information in the sense of PHIPA and its regulations, you need to secure all portable healthcare data as below. If you are NOT, you DO NOT have to. As a matter of practice, the same practices should be necessary for fixed or remotely accessed systems, as well. The incidents referenced in the Information Privacy Commissioner orders are wake-up calls to all health care providers; lost portable devices must be effectively ‘destroyed’ in the sense of PHIPA’s mandate to securely destroy confidential data, and this is what Strong Encryption provides; the data is no longer accessible, and therefore is effectively ‘destroyed.’

To be exempt from these requirements, avoid keeping health data if you possibly can, through (for example) removal of personally identifying data where not needed. If you are required to handle healthcare data, encrypt it if you have to keep it, as above, and document what you do. Don’t let the data outside of the ‘secure encrypted box.’ Know who has access to data, and why. Assess where your precautions could break down, and document them. Rely on the umbrella of the organization that you work for, and support their duty to secure data as above.

If you are independently collecting data, be sure you have a backup and transfer plan for when you are no longer in charge of that data (e.g. out of the country, the project ends, etc.). This is the Right Thing To Do even if you are NOT required to do so by the relevant laws!

If there’s interest, I’ll do a follow up post on some relevant tools; what you choose has a lot to do with how your data is used (especially stored and  transferred), and what the risks are.  There are excellent tools available on all platforms.  Please also feel free to contact me

As always, cordial regards,
David Keldsen

By Dak

Father, leader, writer, scientist, visionary.

Technical software development leader (CTO, VP). Excels when improving and turning around teams, putting better tools and software architectures in place, and getting better outcomes.

2 replies on “DO Encrypt, DON’T Panic”

In separate correspondence, a friend from Yahoo! Inc. mentioned this risk:


That said, the primary concerns for data losses of the practicing Psychologist kind are stolen or lost USB keys and laptops. But if you really want to protect against the scenario in that cartoon, there’s a way in TrueCrypt.



[…] This post was mentioned on Twitter by Kanguru Solutions, David A. Keldsen/Dak. David A. Keldsen/Dak said: DAKworks DRAFT FOR COMMENT: What the ‘strong encryption’ requirement means to Psychologists (regarding Fact Sheet … […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.