Photo by Bernard Hermant on Unsplash

Driving GDPR compliance in small, SaaS, health tech products.

On the 25th of May 2018, the new General Data Protections Regulation (GDPR) will take effect. As a small company, working in a high governance field, with limited resources, we’ve been challenged to make smart choices to drive compliance. This post, documents our process and insights to date.

Disclaimer: I’m not a lawyer and this article does not constitute legal advice. This article details what we’ve learnt at Nudjed whilst becoming GDPR compliant, it’s meant to help you with the process but you should definitely seek legal advice for help interpreting and implementing the GDPR.

Our Steps to GDPR

This article takes you through several broad steps that we have found useful when reviewing our GDPR compliance against one of our products — WellSaid.health. Here are our steps:

• Understand the legislation
• Audit the system
• Roadmap improvements
• Work through with partners
• Update & Set Reviews

If you’re looking for a quick action, then we’d recommend planning meetings around each of these points. You could use each of the specific sections in this post as a primer for that meeting.

Understand the Legislation

There are several key areas of intent for GDPR that are worth knowing of the top of your head. GDPR is specifically designed to:

• Harmonise data privacy laws across Europe
• Protect EU citizens personal data (anything that can identify them)
• Clearly set out the rights of EU citizens, regarding their data
• Clarify the roles of stakeholders in data transactions — controllers, who decide WHY the data is processed; and processors who store/transact on behalf of a user/controller
• Reshape the way organisations approach data privacy and protection
• Set out rules relating to breaches/misuse of data including the penalties for doing so
• Apply to anyone dealing with EU citizen data, no matter where they are

Understanding the intent of the policy is important, as it’s unlikely that every aspect of it’s implementation will be entirely clear at the start. The intent of GDPR is improvement of citizen protection, not to cripple businesses. That doesn’t mean you should delay implementation until it’s clear, but it does mean the lawmakers are likely to be forgiving for companies that are taking steps to implement sensible changes and reduce risk of breach.

Audit the System

The product we’re assessing, WellSaid is a relatively simple tool. It enables transactional messaging (think short surveys) via SMS, so that outpatient services can gather patient feedback and outcomes data automatically, for about 5p per message.

As such our mapping exercise focused on where data was transacted between different parties (systems/users), as a simple way to explore the risk.

From the diagram and our understanding of the legislation, we can identify the data Controller and the data Processors. In WellSaid’s case, the health services are the data controllers because they determine the purposes and means of processing the patients data (the “WHY”). WellSaid is a processor and Nexmo, Linode are our sub-processors because they all process personal data on behalf of the health service (the controller).

From the audit a few areas of risk also became clear in the transactions and storage. We sorted these based on an urgent/important model. What were the simplest, fastest things to do, that would improve our compliance? Our list included:

• Review patient consent forms
• Audit external suppliers (Linode/Nexmo)
• Limit use of SMS to send personal data
• Encrypt data at rest
• Better audit trails and access control for Devs and Customers
• Support contracts should become more aligned
• General User Interface

For each of these areas we assigned tasks to the team to explore how we could improve our approach. The idea was not to absolutely solve every issue, but rather identify the risk/cost of implementing and roadmap them into our product development. We tried to keep improvement in mind at every stage.

Roadmap Improvements

Current System

One of the things we learnt through the auditing process is… we are actually already pretty compliant. We don’t do spammy marketing campaigns, we’ve always tried to keep data gathering minimal, working in health we have to comply with information governance and the Caldicott Principles. The insight from this relates back to the intention of GDPR. Treat personal data with care.

We minimise the number of locations we store personal information and who has access to it. For example, our developers only work with dummy data that has been anonymised first and access to production data is heavily restricted.

Our Logging and Access Control could be better, we do the standard stuff like log errors, user activity and events. As we are only small team this is manageable but we plan to a move to a more robust solution soon.

Improvements

For each area of improvement we set a task and reviewed as part of our normal agile process. In total we’ve completed quite a few pieces of work already including:

1. Updated Privacy Policy now written in clear and understandable terms
2. Sign up process now requires explicit consent (detailed later)
3. New processes put in place to respond to Data Subject Rights
4. Implemented a much clearer data retention schedule
5. Removed Personal Information from our web server logs / application urls
6. Appointed a Data Protection Officer (DPO)
7. Created an Inventory of Processing Activities
8. Logged product GDPR improvements (detailed later)

Patient Consent

The most major change for us as a business was in our approach to consent. Currently our consent process is dictated by customers, as they usually seek to integrate it into existing, paper based processes carried out as part of service administration. We become a simple set of boxes at the end of a very, long form.

However, recognising the potential risk that placed on us (and them) we drew up a template that focused on:

• Clearly communicated the purpose of the service and the reason the data is being collected
• Setting time limits on data storage and the purpose of this
• Made consent more explicit and granular
• Informed the patients of their rights and how to enact them
• Encourage the patient to ask questions about the service and their rights
• Translated into a short, plain english document that would work with low-literacy, low technology groups

The consent form is bespoke to WellSaid, but tries to ensure that the user is educated around their rights in a broader sense. You can view a PDF of the form here.

Currently the form is paper only, due the way our customers tend to work. However, we’re exploring various ways to use digital at distance, digital in person, SMS or combinations thereof to ensure the audit trail/UX is clearer.

Technical Improvements

Two of the bigger technical tasks were:

1. Move infrastructure over to Amazon Web Services
2. Switch to a “Bring your own infrastructure” Model

During the writing of this article, Nexmo have announced two new API’s we’ll be exploring. The new Redact API and Audit Event API will give us the ability to redact the phone number and message body through a API calls and give us to user events related to customer accounts.

Moving infrastructure over to Amazon Web Services

Whilst our system is pretty compliant already, we quickly identified that Linode, though brilliantly flexible, is not the right platform for us to build upon. Linode provide high performance SSD Linux servers but they don’t provide any tools to help with GDPR.

Amazon Web Services (AWS) on the other hand, has much more resource to help with GDPR. They have a full GDPR Centre full of great documentation on GDPR.

The introduction of ‘Data protection by design and by default’ in Article 25 of the GDPR played a big part in the decision to move our infrastructure over to AWS. Privacy and security can no longer be an afterthought and we plan on utilising a number of AWS solutions for data encryption, access control, monitoring and logging, which aligned with some of our other tasks.

By encrypting data at rest, GDPR allows a lot more leeway relating to any data breaches. It was a no-brainer for us to roadmap the change in and AWS facilitating it also made it a quick win, once we transfer.

GDPR also stipulates that there should be an audit trail for data access. Currently database access is restricted to a small number of individuals within the company and developers only have access to dummy data. This works in the short term but as the system grows, we’ll need a more robust solution and moving to AWS with allow us to make use of AWS Identity and Access Management (IAM).

Switching to a “Bring your own infrastructure” Model

Information Governance (IG) has always been a headache for us, not in concept, but in operations. Health data has to be treated carefully and we are regularly quizzed by customers on our IG processes and ethics.

Though Nexmo/AWS proved relatively good in terms of our GDPR audit, longer-term it made sense for us to only own what we needed to. The onlybit we really want to own is the conversations and analytics.

Exposing this functionality through an API would allow our customers to bring their own infrastructure and make use of our API. We would “plug in” to our customers existing infrastructure (or at least managing it on their behalf).

Handing over control of the data storage, web servers and SMS gateway simplifies our business model, reduces our risk and provides the customer with a higher degree of control over patient data. Be that changing to another supplier, plugging us into existing services, or sharing data across their organisation.

Work through with Partners

Throughout our process we have communicated, informed, prodded and challenged our customers and partners. By no means do we pretend to know the exact path to compliance. But, we are definitely not planning on getting caught out by not asking a silly question or two.

To ensure we are on top of the work we took several steps:

• Offered our time to talk through the changes to how our system works
• Created templates and guides to take the patient facing staff through the process
• Engaged with Information Governance/Procurement teams with refreshed agreements to ensure that we are compliant and they can see we are being compliant
• Pushed for feedback around our process

One of the interesting outputs from that has been the confidence it gave us as a team. We anticipated being off the pace, well behind and under resourced to make this change. We thought it would be a pain. But so far, if anything, it’s proven to us that we are on the right path.

Reviews & Audits

One the key actions to take away from this work is it’s ongoing nature. You can’t leave it behind you. From now on, every decision has to be thought of through the lens of GDPR. We’ve also planned regular meetings/audits to ensure that we don’t drop the ball. In terms of planning we are looking at:

• Introducing more user stories based on how our systems transfers to the long term vision
• Recognising IG/Data privacy teams as a stakeholder in our system
• Going through our IG checklist on a quarterly basis
• Regularly reviewing the platforms/documentation of services in our industry to see how best practice is emerging​

Conclusions

The General Data Protection Regulation brings a lot of changes to the way organisations collect, store or process the data of individuals within the EU. It can be complex topic, depending on your company and you need to take some time to make yourself familiar.

Benefits

One of our reflections from this process has been that GDPR was not just a pain. In lots of areas it makes our operation better. For example:

• We no longer need to seek advice from local lawyers to ensure compliance in each European country in which they operate.
• Shared learning around security practices — this drives our ability to standardise work
• Greater transparency and security for customers, leading to more informed customers and more intelligent conversations
• Forced us to think in terms of “minimal data collection”, which is a new level of Minimum Viable Product we’d not considered
• Levels the playing field, giving recourse against “bad actors” and ensuring we can be benchmarked against other companies
• Competitive advantage for fast moving and clear communicating companies that put compliance first, (hence this blog)

Summary & Resources

In case you’re looking for resources we would recommend:

• ICO’s guide to GDPR — https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/
• GDPR Checklist — https://gdprchecklist.io/
• GDPR Form — https://www.gdprform.io/
• Amazon’s General Data Protection Regulation (GDPR) Cente — https://aws.amazon.com/compliance/gdpr-center/
• GDPR Tracker — https://gdprtracker.io/
• GDPR for Web Developers — https://www.smashingmagazine.com/2018/02/gdpr-for-web-developers/
• Preparing for GDPR, 12 steps to take now — https://ico.org.uk/media/1624219/preparing-for-the-gdpr-12-steps.pdf
• Nexmo GDPR — https://www.nexmo.com/gdpr

Feel free to question, criticise or compliment in the comments!