This resource describes our approach to information governance, the technical details, and how Concentric integrates with other systems.
On this page you will find the following information:
- Data processing
- Information security
- Technical details
- Integration options
- Technical approaches to integration
- Types of data processed
- Legal basis for data processing
- Use of third parties
- Transparency and user rights
- National data opt-out
Types of data processed
The healthcare organisation is the data controller, and Concentric Health is the data processor.
Patient personal data used:
- Patient title, given name, and family name
- Patient date of birth
- Patient gender
- Patient hospital number and/or NHS number
- Patient contact details
- Contact details may be provided by the healthcare organisation or directly by the patient if this information is not previously held by the healthcare organisation
Justification: For clinical safety reasons this data must be displayed on-screen during all clinician interactions with a patient’s records, and also appears on the patient’s consent form. Since this information forms part of a consent record, it must be stored according to the same retention schedule as those records. Best practice states that patients are given a copy of their consent form, and therefore contact details are stored to allow communication of the consent interaction and outcome data collection.
For all consent episodes discussed (which may or may not have resulted in surgical consent being given), the following special category data (all relating to the patient’s health) is used:
- The surgical procedure (A)
- Details of the operation, specifically the side (if applicable) (A)
- The clinician responsible (A)
- The names of other clinicians who have viewed or modified the consent episode (B)
- Other treatment options discussed (B)
- The medical diagnosis which led to this procedure (A)
- The intended purpose of the procedure (A)
- The risks which the patient has been informed of (A)
Justification: Data marked (A) is a requirement for the consent form as per Department of Health guidelines, and thus must be maintained. In order to fully understand the context in which consent was discussed and taken, data marked (B) is also stored. In combination data (A) and (B) are cryptographically linked to the state of a consent episode at all points in time.
Clinician personal data used:
- Clinician name
- Clinician role
- Clinician email address, unless using shared identity and access management (IDAM)
Justification: As part of the audit trail of the application, all activity is tied to the identity of the logged in user, and in some cases is shown to other users of the system (for example the name of the clinician taking confirmation of consent). The clinician’s email address, where applicable, is used for login, and to support use cases such as password reset.
The legal basis for processing is that of ‘direct care’. The healthcare organisation has a requirement to take and store procedural consent as part of providing direct care to an individual. The contract between the healthcare organisation and Concentric Health to deliver a digital consent platform will provide Concentric Health’s ‘direct care’ legal basis for processing.
We use Google Cloud Platform (GCP) for all hosting and data processing requirements, and consider GCP to be a ‘Commercial Third Party’. GCP are fully compliant with NHS (England) information governance requirements (see https://cloud.google.com/security/compliance/uk-healthcare/ and the linked whitepaper). Data processing and security terms are agreed between GCP and Concentric Health.
Transparency and user rights
The platform has been designed to meet the GDPR individual rights requirements by design, as requested by the data controller.
A data processing notice can be provided as part of the consent interaction with the patient. Service access requests, rectification requests, processing freeze requests, and data portability requests can be met by design.
National data opt-out
The use or disclosure of data is considered out of scope of the National data opt-out for the following reasons:
- The national data opt-out policy does not apply to uses of information for individual patient care. For example; creation of a consent episode; sharing of interaction information to the patient; sharing completed documentation into the medical record.
- The opt-out for research and planning purposes only applies to confidential patient information - data that includes both:
- information that identifies or could be used to identify the patient, and
- information about their health, care or treatment
No other use of data by Concentric Health, that falls outside use for individual patient care, meets both these conditions.
Further details regarding the National data opt-out can be found here: https://digital.nhs.uk/services/national-data-opt-out/understanding-the-national-data-opt-out
- Data flows
- Who can access the data
- Audit logs
- Data security at rest
- Data security in transit
- Data archival, retention, and disposal
- Testing considerations
- Electronic signature
This is an example data flow, using a scenario where user authentication, patient demographics and document storing integrations are in place.
1 = Authentication details entered
2 = Authentication passed to Concentric
3 = Lookup patient by patient identification number
4 = Lookup patient demographic details
5 = View patient data. View and edit episode data
6 = Patient consent given in consultation view
7 = Store consent record
8 = View episode details and consent
9 = Patient completed outcome data
10 = Store anonymised data
Who can access the data
All clinician users are provided access to the patient data used, contained within their healthcare organisation, and use this access to create and edit consent records. Nurses and theatre staff are provided with equivalent access to the patient data used, and will typically use the platform to check that consent has been given.
Authorisation and authentication of all users is via either a healthcare organisation managed authentication service or by managing healthcare organisation specific Concentric Health user accounts on behalf of the healthcare organisation. This is detailed within the technical description document.
Functional limitations are not enforced for different healthcare professional users within the healthcare organisation, with each subject to professional guidelines regarding professionalism and scope of practice.
Patients are sent an email and/or SMS message containing an unguessable link which allows them to securely view their consent record, including if appropriate, the ability to give consent remotely. This message is shared at the completion of each interaction with a clinician. Messages are sent using GDPR compliant external email/SMS services, and contain no special category data. Full patient authentication and security details are within the technical description document.
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 (cryptographic) 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 for any attacker, can 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 (cryptographically) 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.
Consent episodes are stored as an immutable sequence of changes, with each change linked to a logged in user, allowing application level auditing of changes. All access to patient data is logged against the authenticated user id. Application logs are also written, which identify the authenticated user.
The Concentric Health digital consent platform is hosted within the public cloud, via the Google Cloud Platform (GCP) in a European data centre. As described above, GCP are fully compliant with NHS (England) information governance requirements. The cloud deployment is multi-tenant, so each healthcare organisation uses the same physical deployment of the Concentric Health digital consent platform. GCP, as a sub-processor enters the linked agreement with Concentric Health with regards to appropriate and contracted sub-processing of data.
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 patient’s tenant in a cryptographically signed auth_token, and using per-tenant encryption keys for all application-level encryption (non including database encryption at rest).
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.
Legal consent PDFs are stored in a distributed block storage device which encrypts data using AES-256 before it is written to disk.
Data collected for research purposes is stripped of personally identifiable information at the point of collection, and stored using a write-only API to a separate database. This data is not accessible to clinician or patient facing services at runtime, providing an extra layer of security, but rather used for offline data analysis purposes.
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.
Data archival, retention, and disposal
All data relating to consent episodes is stored for a specified number of years as dictated by the individual healthcare organisation as the data controller. Concentric Health recommends that this time period is at least 8 years, as per best practice for electronic health record data. After the agreed number of years of full data retention, the data is reduced to a stub record containing patient details, procedure name, date, and responsible clinician.
Backups are designed for data recovery, and are stored for 7 days. Data is not removed from backups when removing patient or consent data, but will naturally expire.
All data used during application development and testing is synthetic.
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.
- Process logging and audit logs
- Data storage and tampering
- Secure application development practices
- Hosting and network diagram
- Server security
- Data deletion
- Resilience to failures
- Internal identity and access management
- Incident response process
Process logging and audit logs
All API calls are logged, including user ID, whether successful or otherwise. Logs do not contain personal data and are for the purpose of debugging.
Audit logging of user behaviour is a separate application concern and is covered here.
During deployment of Concentric either an integrated Single Sign-On (SSO) approach will be taken, or Concentric accounts may be used.
Web-based approaches to single sign-on such as OpenID Connect are preferred and quicker to integrate, however other SSO systems can be supported.
Where Concentric accounts are used for authentication, users log in using an email and password. The approach to password authentication was designed using industry best practice and NSCS guidance. In particular:
- A defined joiners/movers/leavers process should be defined as part of deploying Concentric.
- Admins can create, edit, and disable users using the admin interface. All editing activity is audit logged.
- Users can edit their password within Concentric, and reset a forgotten password via a link sent to their email address.
- Passwords must be at least 8 characters in length. There is no maximum length requirement.
- Password resets are not required.
- Protection against brute-force password guessing is provided by limiting authentication attempts to 10 in any 5 minute period, and exceeding this rate limit will trigger logging allowing further investigation.
- Passwords are stored in the database using a salted hash, and never stored or logged in plain text.
- 2 factor authentication (2FA) via OTP codes is enforced for admin level access.
Patients are provided with view-only access to their consent episode in order that they may review the information discussed in their consent consultation, to allow them to access linked additional information (e.g. patient information videos), and to provide the patient with a record of their legal consent.
Patients enter or confirm their email address and/or phone number as part of their consent consultation. Patients are provided with an option not to share contact details, at which point an option to print the episode details is presented.
Patients will receive an email and/or SMS containing an unguessable unique URL (generated using a secure random generator with in excess of 1018 possible combinations). When patients access this link, they are required to enter their date of birth as second factor authentication before their consent record may be viewed.
In order to ensure that the URL and consent details are kept secure: the URL is locked if a date of birth is entered incorrectly too many times, only TLS connections are accepted, browsers and intermediaries are requested not to cache, and outbound links do not reveal the full referrer URL.
Emails and SMS messages are sent using external services (Postmark for email, Twilio for SMS), and contain no special category data.
Data storage and tampering
Append only data-structures are used for data storage which allows full audit tracking of changes. Protection against data tampering is provided by computing a cryptographic hash which encodes the current and past state of a consent episode at each mutation as a hash chain. This hash is included on screen after consent is given, and in the exported consent form PDF.
Secure application development practices
Git is used across the company for source control. Given a git SHA, cryptographic guarantee is ensured on the entire history of the codebase.
Software development takes place in feature branches and pull requests are required before this code may be merged (and considered for deployment). Our pull request process requires that code changes to each component are reviewed by a defined code owner, that the code compiles, that all unit tests pass, and is subject to clinical safety approval by the Clinical Safety Officer (CSO) where appropriate.
Appropriate testing is embedded in the software development process, and not by a separate software testing function.
Deployments are linked to a Git SHA allowing full audit tracking of code changes, may only be initiated by defined individuals, and the process for deploying new code is integrated with the clinical safety process, overseen by the CSO.
The deployment system and data storage approach allow bad deployments to be quickly rolled back to a known working version.
Software library vulnerabilities
We subscribe to automatic security vulnerability alerts for all our code dependencies, which are sent to designated individuals.
Our policy is to deploy updated dependency versions within 2 weeks, or sooner if deemed necessary by our CTO.
Hosting and network diagram
Concentric’s cloud environment is hosted on Google Cloud Platform (GCP).
GCP’s Cloud load balancer provides HTTPS termination for end-user requests, and load balances these requests to backend instances. Traffic to backend instances is encrypted at the network level (see https://cloud.google.com/load-balancing/docs/ssl-certificates#backend-encryption for details). Any HTTP (port 80) requests received are redirected to port 443.
VM instances run multiple application processes and backend services which implement Concentric’s consent platform. There is an internal reverse proxy which handles routing. Backend servers are implemented according to zero-trust principles, which in practice means that all sensitive operations are authenticated using the logged in user token, logged, and used to write audit logs where appropriate.
Various components require read and write database access. GCP’s Cloud SQL service is used which provides high availability via automatic failover, regular backups, and encryption of data at rest. Separate database credentials are used for all services, and the communication to the database server is secured and encrypted using a Cloud SQL Proxy process (see https://cloud.google.com/sql/docs/postgres/sql-proxy for details).
GCP Cloud Storage is used for various purposes, including for long term retention of consent forms. Buckets are configured with retention policies which ensure that data cannot be deleted maliciously or accidentally.
Best practice, as per NHS digital guidance, are followed with regard to access control management, log management and patch management.
The following managed Google Cloud Platform (GCP) services are used, for which server security and encryption of data at rest is handled by GCP:
Concentric makes use of 2 technologies provided by GCP to store customer data at rest – Cloud SQL and Cloud Storage – which are ultimately responsible for the secure erasure of data. Google has published a whitepaper which describes their approach.
At a high level, the approach taken is that all data is stored encrypted at rest and that on deletion encryption keys are first deleted ensuring that data is unreadable (cryptographic erasure), with the physical data later deleted and over time expired from backup systems. Additionally at end of life drives are securely sanitised.
Resilience to failures
With regards to fault tolerance, redundancy and availability guarantees:
- Service Level Objective (SLO): 99.95% (less than 4.38 hours per year of unavailability)
- Automatic failover configured to handle all server failure, which is designed to cause less than 5 minutes of unavailability
- System is designed to not need any scheduled maintenance
- Zero downtime deployments of new application code
- Designed to be resilient to a single datacenter failure within a region
Data recovery processes are in place, in the unlikely event of total system failure:
- Database backups can be used in the case of total system failure. This scenario is not anticipated and would be a manual operation taken as a last resort.
- Configuration management system is used to configure all cloud services and hosts, allowing rapid total replacement of cloud infrastructure in the case of total failure.
Database backups are taken daily and stored for 7 days.
Internal identity and access management
All access to infrastructure is authenticated via two factor authentication and limited using GCP IAM policies, under the principle of least privilege. There is a defined joiners and leavers process.
Incident response process
Periodic monitoring of the system results in automatic notification to a human in the case of over 5 minutes of system unavailability.
Tenants are provided a company operational and technical contact for use in an emergency, with emergency support available 24⁄7.
Root cause analysis investigations are undertaken in response to failure.
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.
Cyber Essentials Plus
The company is certified to meet Cyber Essentials Plus standards for cyber security.
Concentric delivers the best user experience in the presence of the following integrations:
Patient demographic lookup (recommended)
- Allows clinical staff to search for a patient (by your preferred record identifier) and access the patient’s latest details. See more details below.
- Where this integration is not in place patient details need to be entered manually by a member of the healthcare organisation prior to a consent episode being created.
Store consent PDF (optional)
- Allows consent form PDFs and associated metadata to be sent to your document store. See more details below.
- Concentric always stores a copy of the consent PDF and provides access to patients and clinicians within the app.
- Where this integration is not in place the consent form can be reviewed in Concentric, or manually imported into a document store/EHR.
Clinician user account integration and single sign on (optional)
Patient demographic lookup
When using Concentric, clinicians use the search bar to find a patient by identification number. In cases where patients have multiple identification numbers (e.g. an internal medical record number and an NHS number) clinicians should ideally be able to search by either field, although this is configurable.
Searching for a patient triggers the demographic lookup API, and if successful the patient’s details are shown:
If a patient is not found an error is shown:
To keep the interface fast and to avoid unnecessary load on the lookup API, patient details are cached within Concentric’s cloud environment, and refreshed if at least 10 minutes have elapsed since the last successful retrieval.
If an error occurs on refresh a message is shown to the clinician informing them that the demographic information may be outdated. This allows clinicians to continue using concentric with existing patients in the case of a temporary integration failure.
Called with a single parameter:
|IdentificationNumber||String||123456||Patient national and/or local identifier, as entered by the clinician, downcased, and stripped of whitespace.|
Lookup should return 0 or 1 patient records, with the following fields:
|Title||String (nullable)||Miss||Defaults to “Mx” if null|
|Middle name(s)||String (nullable)||Edith|
|Date of birth||Date String||1924-03-21|
|Gender||String||Female||Valid values: male, female, other, unknown. As defined by http://hl7.org/fhir/administrative-gender|
|Local identifier||String||123456||e.g. hospital number|
|National identifier||String (nullable)||1234567890||e.g. NHS number. Alternatively the national identifier can be required, or Concentric can be required to only use a single identifier.|
|String (nullable)||firstname.lastname@example.org||Used to prefill fields when sharing episode information with a patient. Fields can be edited before sharing, but edits are not pushed back to integration.|
|Mobile||String (nullable)||07700 900077 / +44 7700 900077||as above|
|Test patient (optional)||Boolean||True||Recommended in cases where an EHR contains both real and test patient records.|
Note r.e. name casing: Patient names should be returned in Title Case if stored as such, and will then be used unchanged in the interface. If names are stored in UPPERCASE they can be converted to Title Case by Concentric for display on a best-effort basis.
Performance requirements: Users will directly experience the response time of demographic lookup queries so efficient querying is critical. A good target is < 100ms, while anything above 1s becomes increasingly unacceptable.
Email and Mobile fields: if available and provided they will be pre-filled during consent interactions, saving clinician time, but allowing editing if necessary. If not available the patient will be asked for these details if they wish to receive a copy of the information discussed.
Store consent PDF
The consent PDF returned by Store consent form contains the patient details above, and additionally:
- Name of proposed procedure
- Side (if applicable)
- Anaesthetic options discussed
- Risks discussed
- Name of the responsible clinician
- Name and job title of clinician who took the patient’s consent
- Name and job title of the clinician who confirmed consent
- The patient’s signature
- Time of consent and confirmation of consent
This mirrors the content of a completed consent form as per the Department of Health template.
Technical approaches to integration
Concentric has been designed to be cloud-hosted rather than deployed on a private network, and therefore this may present integration challenges depending on the infrastructure currently in place.
Internally our integration approach allows significant flexibility depending on your specific requirements, however a standards based approach is preferred since this is likely to result in significant time / cost savings on both sides, and simpler long-term maintenance.
The following outlines 2 ‘standard’ integration approaches which we have previously taken:
FHIR API approach
Our preferred integration option is via an internet accessible FHIR API, which offers a modern and standardised approach, and limits (or eliminates completely) custom development work. It also supports the option of adding staff authentication via SMART on FHIR.
Patient demographic lookup – FHIR
- Via an identifier search against the FHIR Patient resource, e.g.
- Via an identifier search against the FHIR Patient resource, e.g.
Store consent form – FHIR
- By creating a new FHIR DocumentReference resource with a binary (PDF) attachment
- By creating a new FHIR DocumentReference resource with a binary (PDF) attachment
It is also possible to share structured data via the FHIR Consent resource.
When it is not possible to integrate via a public-cloud accessible API (FHIR or otherwise), we support running a (bespoke) connector process within the internal network. We have used this approach successfully multiple times and it offers flexibility at the expense of custom development effort and the need to host and maintain an additional software component within the network.
Running within the internal network, the Connector can provide secure access to internal systems that are not otherwise available from the public internet, for example database servers, internal APIs, or network filesystems.
It works by opening an outgoing WebSocket connection to Concentric’s public cloud environment. This connection is secure, authenticated, long-lived, and bidirectional. The connector registers RPC handlers on connect, and will receive and respond to RPC requests over this connection. If the connection drops the connector will automatically reconnect after a short delay.
The Go programming language is used which provides: simple compilation to Windows & Linux targets, zero-dependency static binaries, minimal resource consumption, type safety, and readable, auditable code.
The connector source code is forked for each Concentric deployment to implement the specific RPC methods required. The source code can be shared.
Authentication to Concentric
The connector initiates a TLS (version 1.2) WebSocket connection to Concentric’s GCP server. The server’s SSL certificate is validated; thereby authenticating the Concentric server.
The connector immediately sends an auth token over this connection. The server computes the SHA256 hash of this token and validates it, thereby authenticating the Connector. On authentication failure the connection is closed immediately by the server.
If the connection closes for any reason the Connector will periodically attempt to reconnect and re-authenticate over the new connection.
The connector runs as a Windows service or Linux process.
Resource requirements are minimal: ~ 30MB RAM, minimal CPU load, and some disk space to store log output.
Concentric runs separate demo and production environments. The demo environment is designed for testing purposes and must not be given access to real patient data. Separate auth tokens are used for each environment.
A separate connector process should run for each environment, but they can co-exist on the same host VM if desired with different configuration.
Maintenance and monitoring
Concentric’s cloud environment monitors the status of each Connector process and will alert the team in the case that there is no active Connector available to handle requests.
Scaling and redundancy
Each connector process can handle multiple concurrent RPC calls which are multiplexed over a single connection. As a result it is not necessary or recommended to run multiple Connector processes for the same Concentric environment on the same host to achieve concurrency. A single Connector process will easily support the anticipated request volume for a large trust.
Redundancy can be achieved by running separate Connector processes on different VMs. The server will load balance requests to available Connector processes.
The Connector establishes a long lived connection over which very little data is transmitted when there is no activity (lightweight WebSocket ping-pong messages are used to monitor latency and detect potential issues).
The bandwidth requirement is primarily a function of the integrations in place and the volume of episodes. Bandwidth estimates are based on:
- Patient demographic lookup: 1KB
- Consent PDF: 200KB (a typical consent form PDF is 100KB, which is encoded as base64 for transmission, packed in JSON, and encrypted via TLS)
Episode volumes for calculation purposes:
- Concentric episodes per year: 100,000
- Demographic lookups per episode: 10
- Consent PDFs generated per episode: 2
To calculate a conservative peak bandwidth requirements we assume that all traffic occurs during weekdays during a 1 hour period (i.e. during 250 days * 60 min * 60 sec = 900,000s ≈ 106 seconds per year).
Peak mean bandwidth during busiest hour:
(10 * 1KB) + (2 * 200KB) * 100,000 episodes ≈ 40 GB
40GB / 10^6s = 40 KB/s