An interpretation of CQC Requirements 12-322 (data transfers) and 12-209 (data processed outside of the UK)
I was recently asked about this, especially in respect of the transfer of xray images or other correspondence via email, but also the transfer of data in general outside of the practice. What does the IG Toolkit have to say about this, and how should this be interpreted? Firstly, a disclaimer: I am not a lawyer, and practices should make their own decisions about specific aspects of CQC compliance. I am a highly experienced IT professional, with tons of relevant experience of dental practices and their systems, and a good understanding of Data Protection and other relevant legislation.
Let’s concentrate first on data transfer, beginning with the simplest of these sections, 12-209. Whilst there may be exceptions to this rule of thumb, from my experience with dental practices I would take the view that there is typically no need for any data to leave the UK/EU, so compliance with this requirement should be fairly easy to achieve. All sorts of problems and hurdles arise if you do have data leaving the UK/EU area, requiring risk assessment and documentation, obtaining consent from the patients, and testing against the Data Protection Act and “DH Guidance” (whatever the latter is, since it is not properly referenced/linked to). Typically the only data leaving the UK/EU for most dental practices will be their remote backup data if using an online backup service such as Mozy or Carbonite. A brief look though the comparison of remote backup services here: http://en.wikipedia.org/wiki/Comparisonofonlinebackupservices will give you an idea of where your practice data ends up (column headed “server location”). Since there are so many remote backup providers to choose from, it seems to me to be self-evident that you might as well choose a supplier that is UK or EU only. It may be that in fact there is no risk at all, and indeed Mozy (for example) specifically reference their compliance with EU Safe Harbour Privacy Principles (see http://mozy.com/privacy/) which should make them compliant with the relevant EU directive; nonetheless, it would seem prudent to avoid data leaving the UK/EU at all if possible. Dental IT Ltd’s remote backup service is (easily) the UK’s most compliant data backup service. This is covered in a separate article.
It could of course also be argued that data which is sent via email to a Gmail or Hotmail account is sending data outside of the UK, even if both correspondents are within the UK. However since the use of email is specifically referenced in requirement 12-322 I will consider the specific technical recommendations within this section to be more relevant. Further, the requirement does not say that data should never leave the UK/EU, but that when it does, the organisation should assess and document risks. Finally, 12-322 specifically alludes to the distinction between “bulk” data (a database with multiple patient records) and individual records, with the former of course requiring particular care. My suggestion, therefore, is to adopt and document a practice policy on electronic transmission of patient records, which will cover off both requirements.
Requirement 12-322 (Secure Transfer and Receipt of Information)
It is worth absorbing the first half of this requirement in detail and considering it in the context of the dental practice and its data. Although the document makes plain that transfers of personal information should always be safe, it is clear that only certain categories of data should be afforded the highest level of protection – this includes for example DNA records or finger prints, credit card details, physical or mental health conditions. It also goes on to examine in some detail the impact of the loss of the information to the individual. In other words, if the data in question goes missing or is acquired, what effect could this have on the individual? Without in any way downplaying the importance of confidentiality of patient records, it seems clear to me that sending, for example, an email to another dentist with an intra-oral xray image attached, could not really be classed as HIGHLY sensitive information, nor could it be described as information that could cause any harm to the individual if lost and acquired by someone else. In short, it seems unlikely (unless the individual concerned was, perhaps, a celebrity or similar) that anyone else would be remotely interested in acquiring this type of data. This is common sense really, and it is good that the requirement recognises this. As a result of IG, I have come across practices and dentists who have become so concerned about confidentiality and patient records, that it even becomes difficult to do our job to support them (we often need to access IT systems and have visibility of data in order to support IT networks). I see nothing in IG toolkit which suggests that every bit of data has to be protected at the highest level. What IS important, and is entirely reasonable, is to identify and consider what information is given out and in what context, and to agree and document appropriate policies for handling that information. There are various methods of transfer likely to be relevant here, so let’s consider email first:
The requirement states that NHSmail is the only approved method of emailing patient information, but seems to suggest that this is only if NHSmail is able to be used by both sender and recipient. The wording is ambiguous, but I interpret this as meaning that if you can use NHSmail, you should, which is fair enough. Whilst this will be on occasion applicable to dental practices (any dentist should be able to get an NHSmail account for communicating with their local dental hospital, for example), this will certainly not be the most regular method of email for most dental practices. It goes on to say that other email services should “meet NHS encryption requirements”. It does not specifically define what this means, and the comment itself is not referenced, so to seek clarification you need to dig deeper, and trawl through the third party documents referred to at the end of the requirement. 1 of these is particularly relevant:
Points 19-21 in this document are clear that patient information sent via email should be encrypted, and it correctly presents the most realistic option here is an encrypted attachment. The level of encryption required is specified as that meeting NHS encryption standards. Let us consider Microsoft Office documents, as these are generally the standard applications used for document creation. It has been possible in most generations of Microsoft Office to password protect (which also encrypts) documents. However if you are using any version of Office prior to 2007 (that is, Office 2000, Office 2003, Office XP) you should consider the password protection in these worthless, and certainly not compliant – there have been software tools widely available for some years which are able to crack documents password protected by these versions’ (40 bit) encryption methods. Office 2007 and newer are able to password protect/encrypt documents as standard to AES 128 bit level. In fact, this is lower than that specified in the NHS encryption guide (see: http://systems.hscic.gov.uk/infogov/security/encryptionguide.pdf) , which suggests AES 256 as the minimum level. This is, in my view, entirely over the top, given that there is no tool which can currently “break” AES 128 bit level encryption. Documents could be compromised using “brute force” methods of cracking, using a fast computer to generate repeated password attempts, however with a 128 bit algorithm, even the fastest computers would take years to crack a document with a half decent password. See for example:
In the table on this webpage you can see that, by using a decent 8 character length password with a mix of upper and lower case letters and punctuation, it would take a brute force attempt up to 692 years to crack a password of this nature! Thus the requirement to take the encryption to AES 256 seems over the top to say the least. To be fully compliant, your IT supplier can alter this configuration on the system so that AES 256 becomes the default, however the document does say: “These algorithms should be used with a recommended minimum key length of 256 bits where available. This is the standard we are moving towards and whilst tactical deployments of less robust encryption are acceptable for now this should be kept under review and stronger encryption introduced when practicable.”
Other options for encrypting attachments include PDF (Adobe Acrobat portable document format) files, which can be password protected/encrypted, and zip (compressed) files. Practices could either use free PDF software (we recommend PDF Creator as it is Open Source: http://www.pdfforge.org/pdfcreator) or Adobe’s own Acrobat software. Please be careful installing any software onto your system, as some free software comes with spyware and adware that could infect your machine and slow it down; ideally your IT support should handle this for you. PDF Creator can create documents with up to 128 bit AES encryption; the latest versions of Acrobat (from X) support 256 bit AES. Windows is able to zip up files and folders by default, but not to password protect them. For this you would need a utility such as Winzip (www.winzip.com), or 7zip (http://www.7-zip.org/) which also supports 128 or 256 AES encryption standards.
Note that, when sending password-protected attachments, the IG guidelines specifically state that no patient identifiable information (such as their name) should be in the subject line or content of the email itself; this is because emails are not encrypted at all and are about as secure as a postcard! The password itself needs to be supplied to your correspondent. The guidelines do not cover this, but I suggest that sending by separate email would not be a good idea. A phone call would probably suffice.
Aside from remote backup and email, other forms of electronic communication and storage should be considered and “ticked off” for compliance against these requirements. In the typical dental practice these would be:
Data taken offsite (or sent through the post) in electronic form on electronic portable media, such as tape, external hard drive, or writeable CDs or DVDs, or flash/USB storage. In each case, the data must be encrypted. If this is backup data, this can usually be configured within the software itself. In the case of files, you could either elect to password protect the files (as above, using various methods), or protect the entire file system using, for example, HP’s security suite, or Microsoft’s Bitlocker; the latter is available on Windows 7 Pro and Windows 8 Pro machines, but works best on those PCs equipped with a TPM module (a hardware module on the motherboard to store cryptographic keys).
SMS/texting. In this case the requirements specifically acknowledge that a simple appointment reminder is probably low risk, however no more information should be present on the text than needs to be: for example, I would suggest that the text simply states the next appointment date/time and does not mention what the category of treatment is, or any preparation required for the treatment, or any specialist involved that would “reveal” the nature of the treatment.
Fax and telephone conversations. Although these are likely to be low risk, they should form part of the risk assessment and information flow “mapping”. If you still use a fax (and please consider moving away from fax if you can!) there are specific common sense guidelines related to its usage that should be followed. (See points 32-35)
Finally, please check out your website; especially if you have any forms on there which the patient or another dentist completes, to submit details to request an appointment, a referral, or to complete any medical history etc. The architecture and routing must be considered in detail here: it is simple enough to enable https (secure website using SSL technology) so that the connection from the client to the website is encrypted, but then the data has to be stored in an encrypted format, and transmitted/retrieved to/from the practice in an encrypted form as well – this is not trivial to accomplish and will require relevant expertise on the part of the developer.
Avoid transferring data out of the UK/EU full stop. You should also consider whether the transfer needs to happen at all (see Caldicott principles – details in section 29 of requirement 12-322).
If the transfers are required, all data should be protected and encrypted to the highest standards possible.
All transfers of data outside of the practice, in whatever electronic format, should be considered, risk assessed and documented.
Emails: Use NHSmail if at all possible and relevant. If not, then send the main content within an attachment, which is itself encrypted (using for example 7zip/winzip or the application’s encryption capabilities). Consider and document your process.
Remote (internet based) Backups: Check your supplier’s remote backup software to ensure that it uses UK/EU datacentres to store your practice data, and that the data is transmitted and stored securely. Consider and document your process.
Local backups taken offsite (e.g. tapes, hard drives, flash drives): Ensure the backup software that creates the backups has encryption enabled. Consider and document your process.
CDs, DVDs or other media sent through the post to a colleague or hospital: As per email, ensure that the content is encrypted using for example 7zip/winzip or the application’s encryption capabilities. Consider and document your process.
SMS/texting: ensure minimal information here, appointment reminder only. Consider and document your process.
Fax/telephone: Low risk but still consider and document.
Website: Ensure that if your website collects and data, it does so securely (via encrypted https)
Last edited: 11 September 2014