In this connected world, users’ personal data are at risk at every corner. There are myriad online services, and new are coming every day that deal with data that should be kept secret and safe. Our personal data is scattered across the web, and once just one service is hijacked, our privacy is brittle. More and more conservative industries are opening their boundaries to the Wild Wild West, and yes, Healthcare is one of those.
The threats and risks to our users are no longer fictional or theoretical. They are real, they are every day, and they are frightening. As system designers, developers and decision-makers must defend users’ personal privacy by adopting the Privacy by Design (PbD) Framework. As the creators of applications and the data flow they create, we can play a critical and positive role in protecting our users from attacks on their privacy, their dignity, and even their safety. PbD is not something new, but these common-sense principles will soon become mandatory under the EU’s imminent General Data Protection Regulation. So, if you are present in Europe as a business, privacy by design is now your responsibility.
It is clear that IT systems supporting Healthcare services are managing personal and personal sensitive data. So it must be protected adequately. This article is about how we do it.
What is Privacy by Design
As I said in the summary PbD is not something new (1), it has existed as a best-practice framework since the 1990s, but few developers are aware of it, let alone use it. As described by the PbD author: “The Privacy by Design framework prevents privacy-invasive events before they happen. Privacy by Design does not wait for privacy risks to materialise, nor does it offer remedies for resolving privacy infractions once they have occurred; it aims to prevent them from occurring. In short, Privacy by Design comes before-the-fact, not after.” The PbD Framework relies on seven simple, yet powerful principles (2). Please read the full description of these principles in the referenced paper.
Principles of the PbD Framework:
1) Proactive not Reactive; Preventative not Remedial: Privacy must be proactive, not reactive, and must anticipate privacy issues before they reach the user. Privacy must also be preventative, not remedial.
2) Privacy as the Default: Privacy must be the default setting. The user should not have to take any action to secure their privacy, and consent for data sharing should not be assumed.
3) Privacy Embedded into Design: Privacy must be embedded into the design. It must be a core function of the product or service, not an add-on.
4) Full Functionality – Positive-Sum, not Zero-Sum: Privacy must be the positive sum and should avoid dichotomies. For example, PbD sees an achievable balance between privacy and security, not a zero-sum game of privacy or security.
5) End-to-End Security – Lifecycle Protection: Privacy must offer end-to-end lifecycle protection of user data. This means engaging in proper data minimization, retention and deletion processes.
6) Visibility and Transparency: Privacy standards must be visible, transparent, open, documented and independently verifiable. Your processes, in other words, must stand up to external scrutiny.
7) Respect for User Privacy: Privacy must be user-centric. This means giving users granular privacy options, maximized privacy defaults, detailed privacy information notices, user-friendly options and clear notification of changes.
But PbD does not have just a technical aspect. As a company, you have to change your thinking and attitude as well. PbD must not be perceived as a set of checklists of boxes to be tickled because “the law says it must be done this way”. Don’t let your employee think of it as something you have to implement “or else”. Introduce PbD as an opportunity to creatively rethink more of how your user’s data can be misused, stolen, aggregated and accessed. Consider where data flow, even if you might not be aware of it. Think of what risk you might expose yourself by collecting, retaining and processing data you don’t even really need, or you do not have a lawful use.
Why PbD is a dealbreaker
In Europe, privacy is considered a fundamental human right. Our presence online nowadays is like being in the Wild West. In the past years, it has almost become normal to launch applications that required social media registration, that request unnecessary permissions, shared data with 3rd parties without consent, embedding user traceability and other practices that are in clear contrast with PbD. This is about to change.
In Europe, the personal data regulation has been rewritten. Now regardless of the use, sector or situation collection and processing of personal data has become very strictly regulated. This new set of rules, known as the General Data Protection Regulation (GDPR), is already approved but becomes legally enforceable on 25 May 2018. We all should already be working towards wider GDPR compliance obligations ahead of this deadline, which will come up fast.
It’s a deal breaker! GDPR makes PbD and privacy by default legal requirements within the EU (be aware it is extraterritorial; which means that it applies to users within EU whom data is collected about, regardless of where the service provider is provided from). Not only will you have to design, develop and maintain according to PbD, but you will have to document your PbD processes. That documentation must be made available to a European regulatory authority in the event of a data breach or a consumer complaint.
What is personal and sensitive personal data
The European data protection law defines (3) personal data as any information about an individual who could be identified from that data, either on its own or when combined with other information. There is an even more restricted personal data classification, which must be protected even with a higher level of security. It’s called sensitive personal data.
Sensitive personal data relates to all information concerning individual:
- health data,
- religious or philosophical beliefs,
- Racial or ethnic origin
- political opinions,
- genetic data,
- biometric data,
- sex life or sexual orientation,
- past or spent criminal convictions.
- trade union membership.
How we use the PbD framework
We are a software company. We provide eBusiness solutions in Health, Insurance and telco domains for more than a decade, therefore, is clear that PbD compliance for us means factoring in data privacy by default.
On every step we make toward delivering a working solution we consider the seven principles of PbD that are behind GDPR:
- when gathering requirements we use Risk Management based approach and performing the Privacy Impact Assessment. QA Plan and Test Plan assure security and privacy concerns won’t be left aside during design, implementation and validation.
- when we prepared the initial system design we implement industry standards that safeguard data privacy and protection; We implement best practices and strictly follow industry standards (e.g. IHE HL7, FHIR,…), guidelines and legislative constraints
- when implementing the design using various tools, policies, standards, checklists and after all the most powerful one; code reviews; Nothing is left out to randomness. As said we plan in advance and we enforce that plan.
- when validating we use the predefined test plan, our QC team expertise, external security scrutiny, specialized tools; again the QA Plan and Test plan are followed and executed.
- we deploy in secured environments and we maintain a high level of security protection on them; part of the design is the deployment specification. We embed security into our target deployment environments. We use all applicable IT solutions to lock down the environment from unauthorized access. Using the guidelines set by industry standards we apply all the security-driven requirements.
- we train users and system administrators; the weakest link is usually the human, therefore, we train our users and system maintenance personnel how to deal with privacy and security.
Why is Healthcare domain special
Obviously, it controls and processes far more a lot of personal and personal sensitive data than an average solution. Privacy and security are always the top most important concerns expressed by end-users and customers. They are the main show stopper when considering using such systems. There were data breaches in the past (5) that threw a dark shadow over the industry. So it is on us the developers to reassure the community.
When delivering Healthcare IT solutions we put even more emphasis on privacy, security and data protection as we normally do.
Our main tactics for achieving compliance are:
- Keep in line with Healthcare IT standards (IHE)
- Privacy by Design (perform PIA, manage risks)
- Use a Risk Quality Management Approach
- Verify and Validate early and often
- Audit and Review
- User-Centric Design
Final remarks
Embedding PbD into your workflows will surely create new steps to follow and make new commitments. These steps are necessary in our rapidly expanding, changing and interconnected world. Please, view PbD as a cultural change. Use it as a driving force to improve your policies, practices, guidelines and products by integrating privacy into your culture. Your customers will be better protected, your reputation will boost, and you will be well on the way to legal compliance.
Make a difference by starting using the PbD Framework.
References
1) https://www.ipc.on.ca/wp-content/uploads/Resources/PbDReport.pdf, Dr Ann Cavoukian 1990
2) https://iab.org/wp-content/IAB-uploads/2011/03/fred_carter.pdf, Dr Ann Cavoukian
3) https://ico.org.uk/for-organisations/guide-to-data-protection/key-definitions/, Key definitions of the Data Protection Act, ICO.org.uk
4) https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf, Conducting privacy impact assessment: code of practice, DPA, ICO.org.uk
5) http://www.healthcareitnews.com/slideshow/biggest-healthcare-breaches-2017-so-far?page=1, 2017 Breaches, HealthCare IT News
Miloš Cigoj, Head of Quality and Compliance
Views are my own and do not necessarily reflect the official policy or position of any other agency, organization, employer or company.