The supplier does not have an appointed Data Protection Officer. Not all organisations need to officially appoint a Data Protection Officer.

The supplier needs to appoint a Data Protection Officer if:

• They are a public authority or body (except for courts acting in their judicial capacity)
• Their core activities require large scale, regular and systematic monitoring of individuals (for example, online behaviour tracking)
• Their core activities consist of large scale processing of special categories of data or data relating to criminal convictions and offences.

‍

Most organisations that process some form of health or medical data as a core element of their product will need to appoint a DPO. The most common reason for organisations providing digital health technologies to have a DPO is due to the core activities involving processing health data (being a special category).

Please consult this ICO checklist (https://ico.org.uk/for-organisations/data-protection-fee/does-my-organisation-need-a-data-protection-officer-dpo/) to review whether you need a DPO.

The product exposes APIs or integration channels for other consumers, but does not follow the Open API Best Practice from Government Digital Services. Any APIs exposed by the product must follow the best practices set out by the UK Government.

You can find these best practices here.

The Government Digital Services (GDS) Open API Best Practices are a set of guidelines for designing, building and operating APIs for use in government and public services, including the NHS. They aim to provide consistency, quality and usability for APIs across different platforms and services.

The key requirements of the GDS Open API Best Practices are:

• Use a design-first approach:
  Plan what the API will do and how it will work before coding, based on user and business needs. Test and iterate the design based on feedback. Check for existing APIs that could be reused or adapted;
  ‍
• Follow the API technical and data standards:
  Use the standards that describe how to design, build and operate APIs in a consistent way. They cover aspects such as security, versioning, naming, data formats, error handling, and documentation;
  ‍
• Use GraphQL for your API:
  Use GraphQL, which is a query language and a set of tools for building APIs with a flexible data schema. It allows users to request only the data they need, and supports multiple formats and protocols;
  ‍
• Define an API management strategy:
  Define a strategy that covers aspects such as security, monitoring, testing, and governance. Manage your APIs to meet user needs by following the service lifecycle stages: discovery, alpha, beta, and live;
  ‍
• Document your APIs:
  Document your APIs using clear and concise language, and provide reference documentation for developers. Use tools and frameworks that can generate documentation from the API specification or code.

The supplier must make sure that the APIs or integration channels their product exposes follows the GDS Open API Best Practice.

The supplier's APIs are not documented and freely available. Part of the DTAC requirements is that suppliers provide clear documentation for any APIs the product exposes and make their APIs freely available.

To address this issue, the supplier should follow these steps:

• Document APIs:
  Documenting APIs means providing clear and concise information about how to use and integrate with the supplier's APIs. This documentation should include details such as the available endpoints, methods, parameters, headers, data formats, error codes, and examples of requests and responses. The supplier should also provide reference documentation for developers, such as API specifications, user guides, or training materials.
  ‍
• Make APIs freely available:
  Making APIs freely available means allowing potential users to access and experiment with APIs without any barriers or restrictions. Suppliers should provide a sandbox or a test environment where users can try out their APIs and see how they work. They should also provide a way for users to register and obtain API keys or tokens, and manage their usage and permissions.

Third parties do not have reasonable access to connect to the supplier's APIs. DTAC requires the supplier to ensure that third parties can connect to their APIs without needing to implement unreasonable methods.

To address this issue, the supplier needs to follow these steps:

• Document their APIs:
  Provide clear and concise information about how to use and integrate with the supplier's APIs, such as the available endpoints, methods, parameters, headers, data formats, error codes, and examples of requests and responses.
  ‍
• Publish APIs:
  Make API documentation publicly available and discoverable, so that third parties can easily find and access it.- Support APIs: Provide ways for third parties to get help and support when using APIs, such as FAQs, forums, tutorials, or contact details. Suppliers can also collect feedback and suggestions from their API users, and use them to improve their API quality and usability.

The supplier needs to create a detailed product description and architecture that aligns with the NHS architecture principles. Without this, it will be difficult for the purchasing organisation to understand the supplier's product.

The description and architecture should be aligned to the following NHS principles:

• Deliver sustainable services:
  Consider the environmental, social and economic impact of the service life cycle.
  ‍
• Put NHS tools in modern browsers:
  Use browser based and open web standards, avoid proprietary or legacy technologies.
  ‍
• Internet first:
  Use internet standards and protocols, make services available over the public internet by default.
  ‍
• Public cloud first:
  Move to the public cloud unless there is a clear reason not to, benefit from scalability, security and cost savings.-
  ‍
• Build a data layer with registers and APIs:
  Store data once and share via open APIs, avoid data duplication and inconsistency.
  ‍
• Adopt appropriate cyber security standards:
  Follow the cyber security standards and guidance, keep software, networks and systems up to date.
  ‍
• Use platforms:
  Build upon existing platforms and common capabilities, avoid reinventing the wheel.
  ‍
• Put user needs first:
  Design services around user needs, use user research, feedback and testing.
  ‍
• Interoperability with open data and technology:
  ‍Use open data and technology standards, enable interoperability and data sharing across the system.
  ‍
• Reuse before buy/build:
  Reuse existing solutions before delivering new ones, make new solutions reusable by others.

The supplier's product has the capability for read/write operations with Electronic Health Records (EHRs) but does not use industry standards for secure interoperability.

In principle, suppliers should use industry standards for secure interoperability. When interfacing with EHRs without using industry standards (such as OAuth 2.0 or TLS 1.2) the supplier must ensure their product is implementing controls commensurate with these industry standards.

They must ensure they are implementing the following controls when connecting to EHRs:

• Mutual authentication:
  Both parties must verify their identity using non-repudiable methods. For example, OAuth 2.0 allows clients to authenticate with the authorization server using mutual TLS, which is a method of verifying the identity of both parties using X.509 certificates. This prevents unauthorized clients from obtaining access tokens or impersonating legitimate clients. TLS 1.2 also enables the use of TLS extensions, such as Server Name Indication (SNI) or Application-Layer Protocol Negotiation (ALPN), that allow for better performance, compatibility, and flexibility of the protocol.
  ‍
• Authorization:
  Clients must obtain delegated access to protected resources using secure methods such as tokens. OAuth 2.0 also allows authorization servers to bind access tokens to the client’s mutual TLS certificate, which means that only the client that obtained the token can use it to access the protected resource1. This prevents token theft or replay attacks by malicious actors.
  ‍
• Encryption:
  Sensitive data must be encrypted using strong algorithms to prevent eavesdropping. TLS 1.2 provides a secure channel for the transmission of sensitive data, such as authorization codes, access tokens, user credentials, or API requests and responses. TLS 1.2 also supports stronger encryption algorithms, such as AES, and improved hashing and signing algorithms, such as SHA-256, that are resistant to brute-force attacks or collisions.- Integrity: Data should be hashed and signed to prevent tampering or modification. OAuth 2.0 and TLS 1.2 both use cryptographic techniques to ensure the integrity of the data and the parties involved. OAuth 2.0 uses digital signatures to verify the authenticity and validity of the access tokens and the authorization server. TLS 1.2 uses message authentication codes (MACs) to verify the authenticity and integrity of the messages exchanged between the client and the server.

The product is a wearable or device, or integrates with them, and thus must comply with ISO/IEEE 11073 Personal Health Data (PHD) standards. The supplier's product is not yet compliant with ISO/IEEE 11073 Personal Health Data (PHD) standards.

The ISO/IEEE 11073 standards set out the requirements for communication between medical, health care and wellness devices and external computer systems. They require developers to take certain measures to ensure that medical, healthcare and wellness devices are interoperable and can exchange data between them efficiently and securely.

Some of the overarching principles of the standards are:

• Interoperability:
  ‍Devices must use defined protocols for communication, enabling them to exchange data seamlessly regardless of manufacturer or technology.
  ‍
• ‍Data Security and Privacy:
  ‍Mechanisms are employed to ensure only authorized devices and users can access and manage data and data is encrypted.
  ‍
• ‍Data Integrity and Quality:
  ‍Mechanisms are implemented to identify and handle potential errors in data transmission and storage. The supplier will need to understand your product in depth to then be able to decide which ISO/IEEE 11073 standard is applicable to the product. For instance:
  
  1. Nomenclature (ISO/IEEE 11073-10101):
     ‍If the device uses standardized medical terminology for data elements, this sub-standard is relevant.
     ‍‍
  2. Domain information model (ISO/IEEE 11073-102xx):
     ‍This sub-standard defines data structures for specific medical domains (e.g., cardiology, respiratory). Choose the sub-standard that aligns with the device’s data type.
     ‍‍
  3. Application profiles (ISO/IEEE 11073-104xx):
     ‍These define communication protocols for specific device types or applications. Identify the profile that matches the device’s functionality (e.g., vital signs monitoring, continuous glucose monitoring)
     ‍
  4. ‍Device descriptions (ISO/IEEE 11073-105xx):
     ‍If the device requires a specific description for interoperability, this sub-standard might be relevant.

Further guidance can be found here.

The useability requirements from the DTAC are aimed at ensuring that a supplier's product is appropriate for users and that their product is adequate in solving the problem that it sets out to solve.

To aid the useability of suppliers' products, the NHS requires suppliers to:

• Define their ideal user profile in detail;
• Survey people within the NHS who fit this profile;
• Define the user benefits of their product;
• Validate these assumed benefits with the NHS;
• Develop and document user journeys;
• Engage users in the development of the product;
• Consider user needs and verify with the ideal users throughout the development process
• Map all key user journeys to ensure that the whole problem is solved or it is clear to users how it fits into their own pathway or user journey.

‍

The supplier has not carried out, or is still working towards, some or all of these requirements. In order to pass the useability assessment section of DTAC, all of these requirements must be fulfilled.

The product is not Web Content Accessibility Guidelines Level AA compliant. The DTAC requires suppliers to make sure that people with different physical, mental health, social, cultural or learning needs can use their product, whether it's for the public or staff.

Accessibility is about making digital services work for everyone, including people who face barriers related to:

• Hearing, like people who are deaf or have hearing loss;
• Mobility, like people who find it difficult to use a mouse;
• Thinking or understanding in a different way, like autistic people or people with dyslexia or learning difficulties;
• Vision, like people who are blind, partially sighted or colour blind.

The DTAC requires suppliers to use common components and patterns in the development of their product. The supplier does not use common components and patterns in their product.

Examples of these components and patterns are:

• Content design patterns:
  Templates for structuring different types of content (e.g., forms, guides) for clarity and accessibility.
  ‍
• Interaction patterns:
  Defined ways users interact with elements like buttons, menus, and search bars, creating consistent user experience.
  ‍
• API (Application Programming Interface) patterns:
  Standardized ways for different systems to communicate, enabling smooth data exchange.

The DTAC requires suppliers to ensure their team contains multidisciplinary skills, as a team with diversity of expertise and perspectives is more likely to come up with the best solution.

As part of the DTAC submission, the supplier should be able to show that their team:

• Is a multidisciplinary team that will help them achieve what they need to in each phase of development;Is co-located as far as possible;
• Includes people with expertise in how services are delivered across all the relevant channels, and the back end systems the service will need to integrate with;
• Has access to the specialist expertise it needs (for example clinical, legal or policy expertise, from inside or outside the organisation);
• Will help the supplier deal with what they believe are their riskiest assumptions.

‍

The supplier does not have a multidisciplinary team.

The supplier does not use agile ways of working in the development of their product. In order to fulfil the DTAC requirements, the supplier should use agile ways of working.

The most common form of agile working is using scrum:

• A product owner makes a prioritised features list known as a product backlog.
• The scrum team takes one small piece of the top of the features list, called a sprint backlog, and plans to implement it.
• The team completes their sprint backlog task in a sprint (a 2-4 week period).
• They assess progress in a meeting called a daily scrum.
• At the sprint’s end, the team closes the sprint with a review and demo, then starts a new sprint.

‍

The NHS provides more guidance on agile ways of working here.

The supplier's product does not meet the NHS Cloud First Strategy.

The NHS Cloud First Strategy means digital services should prioritise public cloud solutions unless specific reasons prevent it.

The strategy highlights the potential benefits of cloud computing, including:

• Flexibility and scalability:
  Cloud enables easy adaptation to changing demands and service growth.
  ‍
• Cost-effectiveness:
  Public cloud solutions can be more cost-efficient compared to traditional on-premise infrastructure.
  ‍
• Sustainability:
  Cloud can potentially offer lower environmental impact through efficient resource utilisation.
  ‍
• Faster innovation:
  Cloud facilitates rapid development and deployment of new digital services.Use a public cloud provider to host your infrastructure and data to ensure you meet this DTAC requirement.

‍

‍You can find details of the Cloud First Strategy here.

The supplier's product does not meet the NHS Internet First Policy.

The Internet First policy states that all new health and social care digital services should be internet facing and existing services should be changed to be made available over the internet as soon as possible.

The benefits of publishing digital services on the internet include:

• Easier access to digital health and social care services, including remote working;
• It makes it easier for different digital services to work together;
• Increased innovation by improving accessibility to other digital service providers;
• Simpler connections for health and care organisations;
• New NHS and social care centres, such as field hospitals, can be set up more quickly.

You can find details of the Internet First Policy here.