Information security

Data flows

For a Concentric deployment where demographic and document integrations are in place, the diagram shows the key data flows between users (clinicians and patients) and systems.

Concentric data flows

Who can access the data

Healthcare organisation staff

Healthcare organisation staff can access patient and consent episode data, restricted to their healthcare organisation, if a Concentric account has been created for them. Access can be with ‘clinician’ or ‘read-only’ permissions. Clinician users can view, create and edit consent episodes whilst read-only users can only view but not edit consent episodes.

Authentication and authorisation of all users is via either a organisation managed authentication (SSO) service (e.g. Entra or NHSmail) or by managing organisation specific Concentric user accounts.

Patients

Patients can be sent an email and/or SMS message which allows them to securely view their consent information, and optionally to give consent remotely. Messages are sent using GDPR compliant email/SMS services, with messages containing no special category data.

Patient authentication is described within the technical details.

Concentric Health staff

We take protecting patient data extremely seriously.

We have applied the following principles while designing Concentric:

  • Access to patient data, by both humans and systems, should be minimised.
  • Technical solutions which prevent access to data are preferred to policies.
  • All access to patient data should be auditable, with strong guarantees that prevent these controls being circumvented.

By minimising the systems responsible for the storage and access to patient details, we reduce the scope for any bugs, reduce the attack surface area, reduce the number of employees with access, and can increase the scrutiny applied to changes to these systems.

We encapsulate the storage of patient details within a service dedicated to this purpose. It ensures that at an application level only clinicians logged in to the appropriate tenant (i.e. healthcare organisation) can access a patient record, or the patient themselves, and that all access to patient records is audit logged to an append only structure.

These security critical services are only accessible to a subset of the engineering team. Again this access is protected by cryptographic controls.

In order to allow us to diagnose issues with a specific tenant (e.g. a healthcare organisation), the Concentric authorization service allows specific individuals (GMC-registered clinicians with license to practice) to authorise themselves to the system as if they were clinical staff logged in to a specific tenant, using dedicated login details designed for this purpose. Their access to patient details is auditable via exactly the same mechanism as for any other users. At a policy level this is considered an exceptional use case.

Audit logs

Concentric stores audit trail information within the primary application database for the following concerns, linking all activity to the currently logged in user session.

  • Access to and editing of patient demographic details
  • Access to and editing of consent episodes (with edits stored as an immutable sequence of changes)
  • Creation and editing of clinician user accounts

In addition, application logs are stored for 90 days, allowing more detailed investigation.

Hosting

Concentric is an internet accessible application, hosted on Google Cloud Platform (GCP), with the appropriate data centre location used for each healthcare organisation (e.g. UK NHS Trust data is held within a UK data centre).

The cloud deployment at each data centre is multi-tenant, so each healthcare organisation uses the same physical deployment. Within the multi-tenant system, care is taken to ensure that users logged in to one tenant can only access data linked to that tenant. This is done, for example, by including the tenant detail in a cryptographically signed auth_token, and operating internal services under zero-trust principles.

Data security at rest

Personal and episode data is stored in a relational database (PostgreSQL), which stores its data at rest on an encrypted (using AES-256) distributed block storage device. The database operates in master-slave configuration for redundancy, and additionally backup snapshots (also AES-256 encrypted) are taken periodically for disaster recovery. All database block data is logically protected by access control lists (ACLs) which limit access to the appropriate database servers.

Consent summary PDFs are stored in a distributed block storage device which encrypts data using AES-256 before it is written to disk.

Data security in transit

Web and API servers only allow requests made using TLS version 1.2 or above, which provides protection against snooping and man in the middle attacks on data.

Non-HTTPS requests are denied by API servers.

Certifications

Data Security Protection Toolkit

The system, and business processes, have been assessed to exceed the standards required by the NHS Digital Data Security Protection Toolkit (DSPT). The assessment is available to view here.

Cyber Essentials Plus

The company is certified to meet Cyber Essentials Plus standards for cyber security. Active Cyber Essentials certificates can be viewed on the BlockMark Registry.

Electronic signature

As per the UK eIDAS Regulation, the UK’s electronic signature regulation, a digital signature can be obtained, by method of an on-screen signature, and is court-admissible.

The digital signature captured by the Concentric Health digital consent platforms conforms to the requirements of an Advanced Electronic Signature (AES), meeting the requirements that it is uniquely linked to the signatory, is capable of identifying the signatory, creation is under the control of the signatory, and the completed signature is stored in a way that subsequent change to the data, either signature data or information viewed by the signatory, is detectable.

Further reading

Data processing

Details regarding what data is processed by Concentric, the legal basis for processing, third party processors, and how user rights are met.

Read

Technical details

An outline of our technical approach, including development practices, hosting diagram and server security, and resilience to failures.

Read