General Data Protection
Regulation (GDPR)

Public Statement – 5th April 2018 – Rev 1.0



This document serves as our statement to our customers regarding what we understand of GDPR, and what we’re doing to help our customers in their road to compliance.

Please note the revision number at the top of this document. Further revisions will be added in the coming months as we further investigate GDPR, and release more information. For this reason, we ask that you refrain from printing this document, as it will likely be replaced in the next release.

The first thing to note when approaching GDPR, is that it’s not just about data storage, nor yet is it just about data. While some providers may boast ‘100% GDPR compliance’, you need to understand the scope of that claim, as it can only refer to the software provider, or aspects of the software.

To our knowledge, there is no ‘one size fits all’ software that ticks every box, and makes you GDPR compliant over night, and while we will outline some of the key points, you will still need to conduct your own internal investigations of your policies to ensure your business is GDPR ready.

Please also note that while we are able to give guidance, and provide you with reference material for GDPR compliance, this is not a legally binding document, and you may still need to seek official legal advice if you are unsure of any areas of the GDPR.

While the new laws will come into effect on 25th May 2018, the ICO have noted that in cases where companies are found to not be compliant after this date, leaneance and provisions may be made for companies that can show they are actively working to become compliant, and in these cases, the ICO can take the opportunity to work closely with these companies to assist them in their compliance – so by the simple fact that you’ve taken the time to read this document, you’ve already taken the first important step to GDPR compliance!

On 25th May 2018 the new EU General Data Protection Regulation (GDPR) will officially become enforceable. While GDPR was officially implemented in the UK in 2016, the two years following on were pre agreed to be a ‘cooling off period’, meaning UK businesses would have that period of time to become ‘compliant’, and the laws would not be enforceable until that period finishes (25th May 2018).

For many businesses, the new regulation came by surprise, with the majority of businesses not becoming aware of the changes until mid – late 2017, and most not further investigating the implications until early 2018.

We’ve been working through 2017 with a number of advisory firms, and utilising the guidance provided by the Information Commissioner’s Office (The ICO) to heavily investigate both our internal data policies, along with our role in the software we provide, as ‘Data Processors’. As a result of this, we will be implementing a number of internal changes, including policy and document updates, along with changes to our software utilisation. We will also be rolling out tools to our users (The Data Controllers) to aid them in their road to GDPR compliance.

In this document, we hope to outline some of the key notes of the GDPR changes, how they affect us, and how they might affect your usage of our software. We’ll also be detailing what we’ll be providing you, as a user.

Key Definitions

To understand the scope of GDPR, one must first understand where they stand in the roles GDPR gives to those dealing with the data. Here are the main roles covered within this document, and within our setup:

Data Controller

This role is taken by the person who deals directly with the data, collecting it, and choosing how it is used – Within PracticePal, the data controller is seen as the clinic.

Data Processor

The data processor takes care of the processing of the data, under the instructions of the data controller. In this case, the data is processed via our software, and we serve the role of the main data processor, though in some cases we also serve as data controller, but this is only ever done so ad-hoc, and on the instruction of yourself, the primary data controller.

Data Subject

The data subject is the individual who the data refers to – your patient/s.

Personal Identifiable Information (PII)

This is the data about, and belonging to the data subject (your patient) that can be used to identify them. GDPR increases the scope of PII to take into account newer ways to identify a customer with data gathered from a data breach i.e. a Patient’s ID would now be considered as PII.

Changes to Key Definitions

GDPR puts a huge emphasis on the ownership of the data, and confirms that data about a data subject legally belongs to the data subject and by confirming their consent, they are only giving a data controller consent to hold and use that data, until a time in which the data subject sees fit to remove that right, or at the point the data subject passes away, at which point they fall outside of the remit of GDPR.

Another thing to take into account when it comes to data roles, is the scope of a data processor. When a data subject (Your customer) agrees to giving you their data, and to you utilising that data, it is important that a clear understanding is put in place of who serves within each role, any exceptions to this, and that you ensure there are no breaches to this agreement.

A basic example of a breach would be if you (The data controller) were to show a friend, or family member a patient’s record, or a report. While you are not giving a physical copy of this data to them, you are still allowing them access to that data, and as such, they would then be considered an unauthorised data processor – this would be in breach of the data subject’s rights under GDPR, and you would be obligated to report this breach to the Information Commissioner’s Office within 72 hours of becoming aware.

When a data sub-processor is in place, it is imperative that the data controller make this clear to the data subject, at the point of gaining consent, and the role and/ or purpose they serve in dealing with the data subjects data.

Data Storage

Contrary to popular belief, GDPR is not solely based on data storage, and emphasises more in fact on data management, data collection, and the rights of data subjects. GDPR does, however, have an impact on your data storage, and has some specific guidance on web based data management systems, like ours.

One of the first restrictions put in place by GDPR is data storage location, and the restriction of keeping EU data within the EU. We already comply with this as we use dedicated (not cloud) based hosting, and all of our data, both live and backup, is stored in the London Based Rackspace server farm. You can find out more about Rackspace, and what they’re doing to combat GDPR here:

We also backup your database, every 24 hours, and this backup is held in a secure, off site backup – this data is destroyed after 24 hours when the next backup is taken, and never leaves the EU.

We use 256 bit SSL encryption for data sent to and from our servers. We use a dual server setup, whereby the server you access from the PracticePal interface is our ‘App server’, which serves up the PracticePal software, while all data is stored on a secondary contained dedicated server. The Database Server is not available online, and has a singular ring fenced connection, only accessible directly through the App server. In short, this means that even with direct logged in access to your PracticePal account, the physical database behind PracticePal could never be compromised via a script injection.

We are also implementing changes to the way the data is stored on our database servers, including changing our methods of storing any passwords to a hashed format, meaning should a data breach ever occur, passwords would be shown as an illegible encrypted string.

We are currently working closely with our server providers (Rackspace UK) to discuss our setup, and any further steps we can take to secure our environment with the view to going above and beyond what is required to keep your patient’s data secure.

While no data is stored physically on our company PC’s, we are also taking the relevant inhouse steps to ensure our internal systems cannot be compromised including Hardware level encryption of all of our company machines.

What WE are giving YOU

While the point still stands that ‘there is no one size fits all software for GDPR compliance’, we will do everything possible to help you along the way, and one of the biggest things we’re doing to help with the transition is adding a number of tools within the software.

Consent to marketing

One of the first areas of GDPR we focused on for our customers is consent. Under the previous Data Protection Act, the rules were much looser on direct marketing to your customers – unless they opted out, this is often referred to as ‘Assumed consent’. GDPR introduces an ‘opt in’ law, meaning you can no longer market to your customers under assumed consent – You first need to obtain that consent and, on request, confirm who gave that consent and when. Additionally, you need to be clear with your customers what they are consenting to, and ensure they are not doing so by default (GDPR legislation states opt ins must be ‘unambiguous’). Obviously, this is a huge change, and the administration alone terrifies many.

We’re going to roll out an update PRE GDPR, allowing you to easily record the details of formal consent. The feature will work backwards from the current ‘opt out’ feature found in the general tab of a patient record, and give the ability to record an ‘opt in’, along with the date of opt in.

While existing customers can be a bit tricky without assumed consent, new customers, and returning customers can give manual consent under the next changes.

As noted above, we’re adding a confirmation of consent box to the general tab, which can be ticked when a new patient registers, or an existing patient comes into the clinic, but this will also flow through to online booking meaning patients registering for online booking can opt in to marketing, which will flow automatically into PracticePal, meaning less manual input from you.

Data Policy and Transparency

The second area we focused on was ‘Transparency’. GDPR emphasises greater transparency of your companies terms and conditions, and the terms of how you will utilise the data of your subject (data policy). This means data policies, and the acceptance of them, become even more important than before.

To combat this, we will be adding a new feature within PracticePal, allowing you to host a document detailing your internal data policies, which you’ll then be able to link to your templates

  • you’ll also be able to attach it to your online booking system with a few simple clicks, along with mandatory consent from your patients.

We’ll also be providing a policy document from ourselves, as the data processors, which can be provided to all of your patients, and will automatically be added to the online booking system, along with your own.

Data Access Protection

Another area of GDPR is the protection of access to data – this one is for us and you. We’ve put in some key changes to help with this which you can read about in the ‘data storage’ section, but you’ll need to ensure you’re following strong security protocols in-house like updating your passwords regularly (We won’t enforce this just yet, but we do recommend a quarterly review) , ensuring all users have different passwords, using strong, hard to guess passwords that are at least 6 characters in length and contain a mix of letters, numbers, and special characters.

We’d also recommend reviewing your internal IT hardware protocols, perhaps look into the security of the computers you use to access the system, ensuring the systems are never left unattended whilst logged in, implementing password rules like those detailed above, or even looking into further policies like encryption for your devices instead of default software password walls, or keeping an audit of who can access the system.

There’s already a few features in the current software that can also help increase your security, like using security groups to restrict the access rights of certain users, should you feel they shouldn’t need to access certain areas, or the ‘access times’ feature in the user setup that lets you restrict the times your users can access the system.

We will be releasing an update to the software which will increase the scope of the current diary audit, which records any changes to the diary along with when they were made, and who by, and introducing a new audit of logins, including the user specific data – this will become useful, should you ever need to write a data access policy, or investigate a data breach.

There are a raft of misinterpretations when it comes to GDPR and data security. While it is more imperative than ever to maintain the utmost level of data security, both from a GDPR standpoint, and in terms of the future of online data security, the actual legislation on the data security that GDPR puts in place are not as strict, or even as specific as some are led to believe. The utmost important factor in GDPR compliance when it comes to data security, is showing that you’re doing whatever you can to maintain data security, as well as avoiding the more dangerous mistakes like allowing unauthorised access to third parties, or leaving room within your internal IT policies for intruders to take advantage of.

Data Subject Rights

The next area to look into was extending the ability of patient management to comply with the new rights of the data subjects. One such right was ‘the right of erasure’ or ‘The right to be forgotten’. This law gives a data subject the right to request you remove all of their data from your record. While obviously this is still open to interpretation as pre existing laws like the requirement to retain medical data would overrule this, there are many cases where this can not be looked past. We currently have two options for removing a patient’s data from the system:

⦁ Inactive: This is done via the ‘set to inactive’ tick box in a patient’s record, and is the most commonly used for deceased, or non returning customers. It removes them from simple searches and revokes their access to your online booking system, but it keeps their record dormant in case of later activation, or simply to stop errors or inconsistencies in accounts further down the line.
⦁ Delete: This option is available via the advanced search and is only available for patient records where the patient has no account history i.e. appointments or financial history.

The biggest issue with this new law is that, as detailed above, for many industries there are already laws in place that restrict you from deleting certain patient data, additionally, deleting a patient that has financial records would inadvertently corrupt your historical financial information.

We will be releasing an update to the system that will combat this by allowing you to anonymise the patient. This will remove all of their contact details, and delete any uploads or forms stored on their file, while maintaining their financial history. You will, however, need to look into what laws are in place in your given industry/ discipline on the length of time you’re mandated to hold onto patient data, and what data that is, before using this tool. Obviously, with a little work, this is already achievable on a manual basis, but the new tool should make this function easier for you, as well as providing a more auditable process.

Subject Data Access Requests

In addition to the right to erasure, subject access requests are predicted to increase as the previous £10 fee for a data access request will be abolished, along with an increased scope in what data should be provided, and the turnaround (Decreasing from 40 days to 30 days).

We will be putting together a useful guide on how to download each asset on a patient record, to put together a subject data pack, and will also be exploring ways to automate this process further, which we will update you on accordingly.

Useful Resources

Below are some free resources you can access that we highly recommend reading, as they will help you a lot in your journey to GDPR compliance.: ng-ready-for-the-gdpr/