Data security for the MESH API

As the Connecting Party of a service or product, your staff (and contractors) might come into contact with patient data, for example when processing data or supporting your end users.

To ensure you have controls in place to keep patient data private and secure, you must complete the Data and Security Protection Toolkit (DSPT).

You will need an ODS code to complete the DSPT.

Help and tips for completing this section

When you complete the DSPT, you need to state your organisation profile. You should use:

  • NHS Business Partner – if your system directly processes patient data on a regular basis (for example, a GP system)
  • Company – if your software has technical access to patient data (for example, a middleware system)
Q.1

Has your organisation completed the Data Security Protection Toolkit (DSPT) assessment for this current year?

The DSPT allows organisations to measure performance against the National Data Guardians data security standards. It is a prerequisite for Live deployment.
You can enter up to 2000 characters
Q.2

Are you compliant with the annual DSPT assessment?

Your organisation must reach a 'standards met' or 'standards exceeded' status.
Supporting information

See Connection Agreement

  • Clause 3.5 of the CONNECTION CRITERIA & REQUIREMENTS
You can enter up to 2000 characters
Q.2.1
Q.2.2

Provide the date your organisation's DSPT status was published
For example, 06 09 2024
Q.3

Do you have a process in place to ensure all End User Organisations (EUOs) connected to your product have completed the DSPT assessment for the current year within the deadline before onboarding?

Supporting information

The Connecting Party shall incorporate or otherwise alert the EUOs to the EUO acceptable use policy as updated from time to time.

You can enter up to 2000 characters
Q.4

Do you have a formal and documented Information Security Management System (ISMS) in place which covers the scope of the Consumer System?

An ISMS is defined as that part of the overall management system, based on a business risk approach, to establish, implement, operate, monitor, review, maintain and improve information security.

This should be in line with ISO/IEC 27001 ISMS but does not require certification against this standard. Some guidance on appropriate controls to have within your ISMS is available here.
You can enter up to 2000 characters

Insufficient information

Not providing the relevant information will increase the time of approval and may result in application rejection.

Q.5

Has appropriate penetration testing been undertaken for your product in a suitable environment?

Supporting information

If your product is new:

  • penetration testing to CHECK / CREST standards must be completed before go live
  • an action plan must be in place to mitigate any vulnerabilities identified in an appropriate timeframe
  • all critical or high vulnerabilities found must be fixed or mitigated before onboarding. Medium risk vulnerabilities will be assessed and you may be required to provide a dated plan for resolving these

If your product is an existing product:

  • penetration testing must have been completed within the last 12 months to CHECK / CREST standards
  • there must be no major change to your product (for example, new interface or third party access) as a result of the changes
  • penetration testing must be performed within 12 months of go live and every 12 months thereafter
  • all critical or high vulnerabilities found must be fixed or mitigated. Medium risk vulnerabilities will be assessed and you may be required to provide a dated plan for resolving these

See Connection Agreement:

  • Clause 3.5 of the CONNECTION CRITERIA & REQUIREMENTS

Provide the date the penetration testing was conducted
For example, 06 09 2024
You can upload one file that is smaller than 250MB. If you need to provide multiple files you should zip them up and upload them as a single .zip file.

Do you have penetration testing already scheduled?

Provide the date the penetration testing is scheduled
For example, 06 09 2026

Data security for the MESH API

Q.1

Does your MESH Client Application display basic security context information to the user?

This includes:

  • computer misuse warning on start-up
  • confirmation of the logged on user's current role and organisation
You can enter up to 2000 characters
Q.2

Does your MESH Client Application provide authentication control over access to its administration and other features?

Authentication must be based on a user identity which is then authenticated at least through the use of a separate password.
Supporting information
  • The use of two-factor authentication mechanisms (e.g. Smartcard) is encouraged but not mandated
  • Where passwords are used, password management processes and policy enforcement are essential. The guidance documentation referenced in the Trust Operating Model (“Password Policy for Non-Spine Connected Applications”) therefore applies
You can enter up to 2000 characters
Q.3

Is your MESH Client Application hosted in a managed and secure environment?

This includes protective labelling of prescription data on-screen and in printed output.
You can enter up to 2000 characters
Q.4

Does your MESH Client Application utilise a Stratum 3 time source as a minimum?

The MESH Client Application must utilise a Stratum 3 time source as a minimum.

The MESH Client Application must utilise a Stratum 3 time source as a minimum but implementers should consider the use of Stratum 2 or above.

This enables meaningful comparison and sorting of messages based on timestamps. It is particularly important to enable an end-to-end trace of events to be established all the way from the MESH Client Application, through the MESH service.
You can enter up to 2000 characters
Q.5

Do your Audit timestamps generated by the MESH Client Application comply with issued guidance on time zones?

For full compliance details must be complied with, see HSCN network time protocol guidance.
You can enter up to 2000 characters
Back to MESH OCT 24