Specification for a digital consent application

This page outlines our opinion regarding the required characteristics and features of a digital consent solution, to inform decisions around approach and supplier when introducing digital consent.

The presented specification is not an exhaustive list of Concentric features with the intent of promoting Concentric as the sole possible option – many Concentric features are not present – instead, it represents our honest opinion of the technical, clinical, and organisational requirements to support a successful digital consent implementation.

Minor modifications are often reasonable in the local context, for example regarding integration requirements.

For simplicity, the following description primarily focuses on UK requirements, but we are happy to discuss equivalent relevant international requirements directly via our contact page.

Technical requirements

Conformance with relevant technical requirements:

  • Published NHS Digital Technology Assessment Criteria (DTAC) self-assessment
  • NHS Data Security Protection Toolkit (DSPT) - standards met / exceeded
  • Cyber Essentials Plus (CE+) certification within the last 12 months
  • Clinical safety case report demonstrating compliance with DCB0129
  • External penetration test conducted within the last 12 months, with a published summary of findings

Data encryption:

  • AES-256 encryption for data at rest
  • TLS v1.2 (or above) encryption for data in transit

Alignment with the organisation’s security policy:

  • Inactivity timeout that is, or can be configured to be, in line with the organisation’s security policy

Consent process assurances:

  • Audit trail of each consent episode is available, including selections made and by whom, and when consent events occurred
  • Appropriate authentication mechanisms used to link clinical and patient users to actions, such as organisational login for clinicians, and electronic freehand (not typed or requiring mouse entry) signature or national ID (e.g. NHS login) authentication for patient users
  • Remote patient access to digital information

Ease-of-use:

  • Accessible and fully functional via any modern web browser on the public internet, and across mobile, tablet, and desktop devices (to support flexible working as well as access from other sites e.g. private hospitals used for additional NHS lists)
  • Consent information can be shared digitally with patients (for example via email/SMS/patient portal), with special category data not exposed without appropriate patient authentication

Support:

  • At least working-hours support function with an application service level objective for availability of 99.95% or above

Integration requirements

  • Local and/or national patient demographic integration including email/phone number (in many cases this requires linking to systems within the healthcare organisation’s infrastructure that are not themselves exposed to the public internet)
  • Utilise the single sign-on mechanism that is used within the healthcare organisation (for example Microsoft Azure AD/Entra ID, NHSmail, or ADFS)
  • Launch in patient context from or within the EHR

Clinical requirements

Clinical standards and guidance:

  • PIF Tick accreditation (the UK-wide quality mark for trusted health information)
  • Evidence of effectiveness as per Tier B of the NICE Evidence Standards Framework for Digital Health Technologies

Consent process functionality:

  • Coverage of requirements of each of the standard consent forms – adult with capacity (consent form 1), child without capacity (consent form 2), adult without capacity/best interest decision (consent form 4)
  • Support for multi-stage consent across several clinicians, with confirmation of consent (and re-confirmation if required), and revocation of consent
  • Evidence-based template information for common treatments across all specialties (our experience is that this means a resource with 1500+ templates)
  • Personalisation of consent information to the individual patient (for example adding or editing risk profile, and adding patient notes)
  • Easy access to required templates (for example live search and/or an individual’s commonly used or favourite templates)
  • Combination of treatments together to be included on the same consent documentation
  • Generation of consent information in the absence of a pre-defined treatment template
  • Customisation of template information at local level, including the addition of local documents/web links
  • Additional consents such as registry consents (e.g. NJR) and tissue for research/biobank consents alongside treatment consent
  • Consent can be given in person with a clinician or remotely alongside or following a consent consultation
  • Translation of consent information into commonly spoken non-English languages

Operational requirements

  • Administrator management of user accounts
  • Administrator access to usage data including use by individual and specialty, over time
  • Read-only access for non-clinician users (for example administrative and theatre staff)
  • Training/getting started support for all users

Clarification/Tender questions

In many cases it is appropriate to contact several suppliers to clarify full/partial/non-compliance with the specification prepared. Depending on the procurement approach this may be through the process of post-shortlisting clarification questions (e.g. UK Gov Digital Marketplace - AKA G Cloud framework - process) or via a tender process.

The following are examples of questions that can be used to gather information regarding conformance with the above specification, and a suppliers approach given the organisations local context:

  • Provide evidence of conformance with the relevant technical requirements (NHS Digital Technology Assessment Criteria, NHS Data Security Protection Toolkit, Cyber Essentials Plus, DCB0129, External penetration testing)

  • Describe how the solution can support the organisation’s assurance processes around the consent process.

  • Describe how the solution mitigates the risk of digital exclusion for clinical staff and patients, including accessibility considerations.

  • Describe the proposed support structure provided to the organisation during deployment and following transition to Business as Usual (BAU). Include description of project management structure and duration, resources available, approach to training, and technical monitoring/alerting.

  • Describe how the solution supports the organisation’s consent process functionality requirements:

    • Coverage of requirements of each of the standard consent forms – adult with capacity, child without capacity, adult without capacity/best interest decision
    • Support for multi-stage consent across several clinicians, with confirmation of consent (and re-confirmation if required), and revocation of consent
    • Evidence-based template information for common treatments across all specialties
    • Personalisation of consent information to the individual patient
    • Easy access to required templates
    • Combination of treatments together to be included on the same consent documentation
    • Generation of consent information in the absence of a pre-defined treatment template
    • Customisation of template information at local level, including the addition of local documents/web links
    • Additional consents such as registry consents alongside treatment consent
    • Consent can be given in person with a clinician or remotely alongside or following a consent consultation
    • Translation of consent information into commonly spoken non-English languages

  • The relevant technical, infrastructure and integration context for the organisation includes: [relevant context]. In that context please summarise the relevant experience of the solution provider in delivering an effective and timely technical implementation, and a proposed technical approach.

  • Provide a demonstration video (no longer than 30 minutes) or demo credential access to the solution to enable clinicians within the organisation to understand process flows and usability.

  • Describe the reporting capabilities provided as part of the application, and any further data that is possible to obtain on request.

  • Describe what elements of the solution are configurable at the organisation level, and the process for undertaking and managing this configuration.

  • The organisation is an [XX] bedded organisation, undertaking [XX],000 elective procedures annually across [XX] sites. Summarise the experience of the solution provider in supporting similar organisations.