Lesson 9: Data Security, Consent & GDPR

Objective

Architect UK-compliant consent models and implement consent recording in openEHR.
Apply pseudonymisation and de-identification techniques to protect patient privacy.
Configure encryption and comprehensive audit logging to satisfy GDPR, UK Data Protection Act, and NHS Digital requirements.

Overview

Health data carries the highest sensitivity classification in UK Information Governance.

Under GDPR and the UK Data Protection Act 2018, personal data must be:

Processed lawfully, transparently, and for a specified purpose.
Limited to the minimum required (data minimisation).
Stored securely with safeguards against unauthorised or accidental access.

openEHR’s flexible model supports robust consent capture, role-based access control, pseudonymisation, and immutable audit trails. This lesson shows you how to weave these features into a GDPR-ready deployment.

Tutorial Breakdown

1. Legal Framework & NHS Requirements

GDPR & UK Data Protection Act 2018

Lawful bases for processing: consent, vital interests, public task, legal obligation, etc.
Data subject rights: access, rectification, erasure (“right to be forgotten”), restriction of processing.

NHS Digital Data Security and Protection Toolkit (DSPT)

Annual self-assessment covering 10 data security standards.
Requires encryption at rest/in transit, audit logging, staff training, and DPIA evidence.

Information Governance (IG) Policies

Local IG policies specify retention periods (e.g., 8 years for adult records).
Data Sharing Agreements govern cross-organisation flows (e.g., HIE, ICS).

2. Capturing and Managing Consent in openEHR

Consent in openEHR can be modelled explicitly as part of the EHR context or via dedicated templates:

Consent in Composition Context

Use context/other_context[at0001] to record consent type, date/time, and scope.
Template elements could map to ISO 13606 Consent archetypes (e.g., openEHR-EHR-EVALUATION.consent-v1).

Dedicated Consent Archetype

Define openEHR-EHR-EVALUATION.consent.v1 capturing:

Consent ID, patient signature, consent granularity (primary care, research use, date range).
Withdrawal flags.

Access Control & Affinity Domains

Configure an affinity domain (trusted network boundary) to enforce consent across multiple systems.
Integrate with an IAM or XACML policy engine to grant/revoke access at attribute or role level.

Example: capturing explicit consent for research


archetype (adl_version=2.0.5)
openEHR-EHR-EVALUATION.consent_research.v1
description
  details
    name = <"Research Consent">
definition
  EVALUATION[consent] matches {
    items[
      ELEMENT[at0001] occurrences matches {1..1}
        name = <"Consent Given">
        value matches DV_BOOLEAN,
      ELEMENT[at0002] occurrences matches {0..1}
        name = <"Scope Details">
        value matches DV_TEXT,
      ELEMENT[at0003] occurrences matches {1..1}
        name = <"Consent DateTime">
        value matches DV_DATE_TIME
    ]
  }
}

3. Pseudonymisation & De-Identification

Minimising identifiers reduces re-identification risk:

Proxy Identifiers

Replace NHS numbers with a surrogate key stored in a secure vault.
Only the vault can map back to the true identity.

Template-Driven De-Identification

Create a de-id Composition template that omits direct identifiers (Patient.name, Patient.address) and replaces them with hashed or coded values.

Techniques

Hashing (e.g., SHA-256 with salt): irreversible, for common linkage keys.
Tokenisation: secure vault issues tokens that map to real values.
Data Masking: partial redaction of dates, postcode truncation.

Example pseudonymisation pipeline in Node.js


const crypto = require('crypto');

// Hash NHS number with secret salt
function pseudonymise(nhsNumber, salt) {
  return crypto
    .createHmac('sha256', salt)
    .update(nhsNumber)
    .digest('hex');
}

// Usage
const salt = process.env.PSEUDO_SALT;
const pseudoId = pseudonymise('9876543210', salt);

4. Encryption at Rest and in Transit

Protecting data both when stored and moving between systems:

Transport-Level Security

Enforce TLS 1.2+ for HTTP endpoints (openEHR REST, Terminology server, FHIR connectors).
Disable insecure ciphers and apply HSTS.

Encryption at Rest

PostgreSQL Transparent Data Encryption (TDE) or file-system encryption (LUKS).
Elasticsearch encryption via xpack.security.enabled=true and encrypted disk volumes.
Cloud provider managed keys (AWS KMS, Azure Key Vault).

Key Management

Rotate keys annually or per breach policy.
Store keys in an HSM or hardware vault.
Audit key usage for compliance.

5. Audit Logging and Monitoring

An immutable record of who did what, when:

openEHR Audit Service

Every Composition, EHR, and Versioned Resource carries an audit node:

system_id, committer, time_committed, change_type.
Configure EHRbase to write audit events to a separate database or log stream (e.g., Kafka, CloudWatch).

Centralised SIEM & Log Retention

Ship logs via Filebeat or Fluentd to Splunk, ELK, or Azure Sentinel.
Retain audit logs for at least 8 years per NHS guidelines.

Alerting

Define alerts for unauthorized access attempts, high-volume deletions (archive requests), or failed pseudonymisation jobs.
Integrate with PagerDuty or Opsgenie for on-call escalation.

Example Elasticsearch ingest pipeline for audit events


# filebeat.yml
filebeat.inputs:
- type: log
  paths:
    - /var/log/ehrbase/audit.log
output.elasticsearch:
  hosts: ["https://es-host:9200"]
  ssl.enabled: true

Real-World Examples

Example 1: Mental Health Trust Consent Dashboard

South London and Maudsley NHS Foundation Trust implemented a patient portal for consent management:

Granular Consent: Patients choose which data (therapy notes, medication history) can be shared with third-party research.
openEHR Templates: Used a consent_research.v1 EVALUATION archetype in every Composition context.
Audit & Reporting: Built a dashboard in Grafana to show active consents, withdrawals, and audit trails per patient.

Impact: Transparent consent process increased patient trust and improved ethics board approval times by 30%.

Example 2: Research Registry with Pseudonymisation

The University Hospitals Birmingham diabetes registry required de-identified data for audit and academic research:

Proxy Identifier Service: A separate Node.js microservice generated salted hashes of NHS numbers.
De-ID Compositions: Researchers accessed only the pseudonymised ID and key clinical observations via a custom Composition template.
Secure Storage: All raw EHR data encrypted with AWS KMS; pseudonymised research data stored in a separate S3 bucket with restricted IAM roles.

Outcome: Zero data breaches, maintained full research utility, and satisfied both NHS DSPT and university ethics requirements.

Hands-On Exercise

Define a Consent Template
Build an adL or XML template for capturing three consent types: care, audit, research.
Implement Pseudonymisation
Write a small service that replaces ehr_status/subject/external_ref/id with a hashed surrogate.
Verify that the real NHS number is never stored in the research Composition.
Configure Encryption
Enable TLS on your local EHRbase instance using a self-signed certificate.
Set up file-system encryption for your Docker volume.
Set Up Audit Logging
Configure EHRbase to write audit logs to a file.
Deploy Filebeat to ship logs into an Elasticsearch index.
Create a simple Kibana dashboard showing the last 24 hours of write events.

Further Reading

UK GDPR and Data Protection Act 2018: https://ico.org.uk/for-organisations/guide-to-data-protection
NHS Digital Data Security & Protection Toolkit: https://www.dsptoolkit.nhs.uk/
openEHR Access Control and Audit Service Specification: https://specifications.openehr.org
ICO Guidance on Pseudonymisation: https://ico.org.uk/for-organisations/guide-to-data-protection/
ISO 13606 Consent Archetypes and Templates for Health Information Exchange