The DCB0129 standard applies to organisations that are responsible for the development and maintenance of health IT systems. A health IT system is defined as ‘“product used to provide electronic information for health and social care purposes”.

You can access the DCB 0129 standard here.

DCB 0129 requires developers to have a Clinical Risk Management System in place and to provide evidence that your Clinical Risk Management System is compliant with DCB 0129.

Your Clinical Risk Management System should include:

You don't yet have a defined clinical safety case.

As part of your DTAC submission, you must provide a comprehensive Clinical Safety Case Report that should include:

You don't maintain an up-to-date clinical hazard log.

A clinical hazard log is a formal document used in healthcare settings to identify, track, and manage potential risks associated with medical devices, procedures, or systems. It serves as a vital tool for ensuring patient safety by proactively addressing and mitigating hazards before they can cause harm.

Starting with your hazard log in an early stage of product development is a good idea, as the process is iterative. As your product changes, so will your thinking about the hazards that might arise. Therefore, maintaining an up-to-date clinical hazard log is essential, as new risks (hazards) will rear their heads during your product lifetime, and you may not have considered those from the very beginning.

The NHS provides guidance on the requirements for a hazard log (which you can download here).  

Follow the guidance from the NHS (which you can download here ), making sure the headings in your hazard log are the same. The hazard log is arguably the most important part of your DCB 0129 and subsequently your DTAC submission. You should give a summary to the of the hazards that you could not reduce (or 'mitigate') far enough. You should also clearly point out the hazards that may need user or customer input in order to reduce the hazard to an acceptable level. You can download an example hazard log here (https://digital.nhs.uk/services/clinical-safety/documentation#clinical-risk-management).Your customer may ask to see the hazard log whenever there is any change to your product or the way the product is used.

You have not appointed a defined Clinical Safety Officer (CSO).

You have to appoint a Clinical Safety Officer to sign off your Clinical Safety Case and attest that you have taken the necessary steps to reduce the clinical risks identified in your hazard log to an acceptable level.

The Clinical Safety Officer can be an employee or a third-party contractor. They must have a number of skills and qualifications.

‍Below are the requirements that a CSO must fulfil:

Your product has not been registered with the MHRA but it does have a medical purpose.

Since your product has a medical purpose, it is likely that you need to register your product with the MHRA and demonstrate MDR compliance before it can be sold in the UK.

The MHRA has detailed guidance, with an interactive decision tree, here.

You can contact the MHRA directly to determine if your product requires UK MDR compliance, and if it does, at what level here.

Your product has not been registered at the MHRA, does not have a medical purpose, does not work in combination with one or more medical devices, but enables the function of a medical device.

Since your product does not have a medical purpose on its own, but enables the function of another medical device, it is likely that you need to register your product with the MHDA and demonstrate MDR compliance before it can be sold in the UK.

The MHRA has detailed guidance, with an interactive decision tree, here.

You can contact the MHRA directly to determine if your product requires UK MDR compliance, and if it does, at what level here.

Your product connects to or uses third party products, but you have not gone through a risk management process to ensure this third party complies with NHS and GDPR requirements.

In order to be compliant with DTAC yourself, you must ensure that any third party products meet the NHS requirements as well and conform to the UK GDPR.

In your Clinical Risk Management Documentation, you must include third party connection and thus, they must demonstrably meet the NHS and GDPR requirements as well.

A way to find out whether the third parties that you connect to or use in your product are in fact compliant is through questionnaires, requesting them to provide you with evidence, or requesting to receive their third-party certifications and attestations.

All organisations in the UK that "process" "data" should be registered with the ICO. Processing means carrying out any action related to data, including collecting, storing, amending, consulting, sharing, transferring, etc.. Data in the meaning of the UK GDPR is related to "personally identifiable data", which means information that can be directly or indirectly linked to an individual person.

Registering with the ICO can be done here, and will require the payment of a fee ranging from £40 to £2900 annually, depending on the size and turnover of your organisation‍

A Data Protection Officer may be a staff member or may be contracted externally on the basis of a service contact. A DPO can be an individual or an organisation.

Not all organisations need to officially appoint a Data Protection Officer. You need to appoint a Data Protection Officer if:

Your product has access to personally identifiable or NHS-held patient data. That means you must carry out a Data Protection Impact Assessment (DPIA) for your product.

A DPIA is a process to go through whenever a new way of processing personal data is being employed or considered by your organisation. You can carry out a DPIA for a certain product, process, supplier, or even for the third-party apps that you are thinking about using.

DPIA's must be carried out prior to the start of the particular processing activity you're going to carry out a DPIA for. DPIA's only have to be carried out if it is likely that the processing will result in a high risk for the people (data subjects) involved. The determination whether a certain type of processing is likely to result in a high risk for the people involved is up to your organisation, but it is good practise to carry out a DPIA for any project that involves processing medical or health data. As part of DTAC, the NHS requires you to submit your DPIA for review.

The DPIA must have the following elements:

One of the elements of the DTAC is that the organisation must have met or exceeded the DSPT requirements. The DSPT is an online self-assessment tool employed by the NHS to assess their suppliers on their information security and privacy posture. The DSPT must be submitted each year.

If you have not completed the current year's assessment and the deadline has not yet passed, The NHS asks you to confirm (as part of your DTAC submission) that you intend to complete this ahead of the deadline and that there are no material changes from your previous years submission that would affect your compliance. The deadline for the Data Security and Protection Toolkit is 30th June 2024.

In order to find out more about the requirements of the DSPT, please consult Naq's blog here.

In order to view the NHS' assessment criteria for the DSPT, please download the NHS guidance here.

Here is also a useful guidance document on the roles and responsibilities that are necessary to assign as part of the DSPT requirements.

Your answer to the question whether your organisation has a nominated DPO may have been no, or may have been "we don't need one". If you fall within the latter category, another responsible individual may be appointed instead of a DPO.

Your DPO or another responsible individual is responsible for signing off on your risk assessments, access controls and system-level security policies.

An information security risk assessment must be carried out by your organisation, considering the risks that may lead to a cyber incident or data breach. This is similar to your hazard log, where you consider hazards (and accidents) that might have an impact on patient safety or health, whereas an information security risk assessment only considers those risks that impact the confidentiality, integrity or availability of data.

Access controls are the measures implemented on your product and other systems in use in your organisation to ensure that unauthorised users do not get access to your systems and the data contained thereon. Examples include role based access, multifactor authentication and logging and reviewing access attempts.

System-level security policies are policies which describe how the security and confidentiality of specific systems are maintained within your organisation. For instance, if you use a third party (cloud) hosting provider, you will need to create a system-level security policy specific for that hosting provider, detailing how you are ensuring that this system remains security and the confidentiality of data is protected.

Make sure that your DPO reviews these risk assessments, controls and policies at least annually.

You store data outside of the UK but these countries do not ensure adequate protection for British citizens or residents, or you are not sure if they do.

Best practise when supplying your product to the NHS is that all data remains within the UK. In the edge cases that data does leave the UK, you are responsible for ensuring that this data is transferred to areas covered by similar data protection legislation as in the UK, which will have been determined by the UK government through so called 'Adequacy Decisions'.

An Adequacy Decision is a decision by the UK government (or the European Union Commission and referred to by the UK government) that determines that a certain country or area provides 'adequate protection' for British citizens or residents from a data protection perspective.

You may only transfer data outside of the UK if you are transferring data to organisations located in a country or an area that is covered by an adequacy decision.

The list of countries for which an adequacy decision exists can be found here.

Make sure you consult this list and ensure that your suppliers or third party products are either covered by an adequacy decision, or that you choose an alternative supplier or third party app.

Also make sure that you are not unwittingly sending data to other countries by making use of third party products or suppliers that are headquartered outside of the UK and have a privacy policy clause stating that they may share data within their group, which may include sharing data outside of the UK. This is common practice with hosting providers such as AWS or Azure.

You do not have a valid Cyber Essentials Certificate.

All NHS suppliers must hold a valid Cyber Essentials certificate which was issued within the last 12 months.

Cyber Essentials is controlled by the National Cyber Security Centre (NCSC) and certificates are issued and managed by IASME. Cyber Essentials ensures your organisation (not just your product) meets the minimum requirements of information security against five areas:

You have not yet carried out a penetration test of your product.

Annual penetration testing of your product is part of the DTAC requirements. This penetration test must be carried out by a qualified penetration tester. It is not acceptable to submit the output of a vulnerability scan in lieu of a penetration test.

The penetration test must map all findings against the OWASP Top 10 as a minimum. You cannot have any vulnerabilities in the report that you submit to your NHS customer with a CVSS score of over 7.0. If a vulnerability is discovered with a CVSS score greater than 7.0, you must fix that vulnerability and you must carry out another penetration test. Ensure that all findings from the penetration test report are taken into consideration in your security risk assessment and hazard log.

When looking for a penetration tester, we recommend that you look for those that are approved by CREST.

A typical innovator going through the NIA can expect to pay around £5000 for a penetration test, but this can vary greatly depending on the complexity of your product. If your product contains a hardware component, you can expect to pay more.

You have not yet carried out a source code security review.

An internal or external custom code security review is part of the DTAC requirements.

This review should be aligned to the guidance from the NCSC and the OWASP Top 10.

Whilst an internal source code review is acceptable, it is preferred that your source code has been reviewed by a qualified third party. Most penetration testing companies can perform source code security reviews, and it is often a good idea to combine this with your annual penetration test. If your product is defined as introducing a high level of risk to the NHS, your customer may require you to provide evidence of an independent source code review.

Key things to look out for when reviewing your source code are hard-coded secrets (such as API keys), out of date open source packages and ensuring all user input is sanitised. You should however read the NCSC guidance for detailed requirements for your source code as referenced above.

Privileged accounts in your product and across the organisation do not have appropriate multi-factor authentication.

It is now a hard requirement by the NCSC through Cyber Essentials that all user accounts, not just accounts with privileged levels of access (i.e. admin accounts) must have Multi-Factor Authentication (MFA) enabled (this is sometimes referred to as Two-Factor Authentication or 2FA).

You can find more about MFA here.

You should ensure that all of the online products your organisation and product uses (e.g. Google Workspace, Office 365, Azure, AWS, GCP) have MFA enforced for all users, if available. There are many forms of MFA that are acceptable including numeric codes generated by a mobile phone app, a code sent to your email, an SMS sent to a mobile phone or a physical device such as a YubiKey.

It is imperative that you enforce MFA for all users, as this is the single most effective way to stop the majority of cyber incidents.

You have not defined and implemented logging and monitoring on your product. Part of the DTAC requirements is that you define a logging and monitoring plan and that you have implemented this on your product.

Monitoring data could come from event-driven logs, such as website connections, or device configurations details, such as the current operating system version running on a device. You must implement some form of logging and monitoring of your product. The NHS acknowledges that not all developers will have advanced audit capabilities, but a basic form of logging and monitoring is required to ensure you meet your quality, safety and information security obligations.

The level of monitoring you need must be based on the cyber, quality and clinical safety risk associated with your product.

You can find more information about how, and what, to log here.

If your product is hosted on popular cloud platforms, you can easily turn on sufficient levels of logging and monitoring with services such as:

Your product has not yet been load tested. To verify that your product can meet its security, availability and performance requirements, the DTAC requires you to ensure it is regularly load tested. It is also recommended that you perform stress testing to take your product past its designed tolerance and capacity.

In your DTAC submission, you must provide evidence that your product has been load tested. What you are testing during a load test is whether your product can meet the expected peak load conditions, for example, the number of concurrently logged-in users or database operations. You must ensure that the results of the load testing satisfy your product requirements.

It is also recommended that you test your product past its designed tolerances by performing stress testing. Examples of stress testing include adding significantly more users than you expect during normal operations or performing database operations at a rate that far exceeds the designed limits. That way, you can see where the boundaries of your product are, which enables you to plan appropriately.

There are several cloud based solutions available such as AWS Distributed Load Testing or Azure Load Testing.

Your product exposes APIs or integration channels for other consumers, but do not follow the Open API Best Practice from Government Digital Services.

Any APIs exposed by your 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:‍

Your APIs are not documented and freely available. Part of the DTAC requirements is that you provide clear documentation for any APIs you expose and make your APIs freely available.

‍To address this issue, you need to follow these steps:‍

Your Product exposes Application Programme Interfaces or integration channels for other consumers but the APIs do not set out the healthcare standards of data interoperability.

As part of the DTAC requirements, developers must set out the healthcare standards of data interoperability e.g., Health Level Seven International (HL7) / Fast Healthcare Interoperability Resources (FHIR) and demonstrate their compliance with these standards to your customer in your DTAC submission.

‍To address this issue, you need to follow these steps:

Third parties do not have reasonable access to connect to your APIs.

DTAC requires you to ensure that third parties can connect to your APIs without needing to implement unreasonable methods.

‍To address this issue, you need to follow these steps:

You need to create a detailed product description and architecture that aligns with the NHS architecture principles. Without this, it will be difficult for your customer to understand your product. Your description and architecture should be aligned to the following NHS principles:

You must ensure your product has implemented security controls commensurate with the protection offered by the NHS login.

You can find more information about NHS Login here.

You will need to demonstrate these measures clearly in your DTAC file with a justification as to why you have decided not to use the NHS login.

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

In principle, you should use industry standards for secure interoperability. You will be asked to provide more information on which standards you have employed during your DTAC submission. If you do not use any industry standards, you will be asked to provide the rationale, mitigations, methodology and security measures behind the lack of use of interoperability standards.

It is advisable to ensure that your product aligns with the industry standards for secure interoperability as this does not only fulfil the DTAC requirements, but ultimately helps to protect patients as well.

When interfacing with EHRs without using industry standards (such as OAuth 2.0 or TLS 1.2) you must ensure your product is implementing controls commensurate with these industry standards. You must ensure you are implementing the following controls when connecting to EHRs:

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

Your 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:

"Lots of products and services are not useful for users. You need to understand your users and their needs - from their point of view - to build something that helps them. Understanding as much of the context as possible will give you the best chance of meeting users' needs in a simple, cost effective way. The most obvious problem is not always the one that really needs solving. Test your assumptions early and often to reduce the risk of building the wrong thing."

- NHS Guidance on usability

The usability requirements from the DTAC are aimed at ensuring that your product is appropriate for your users and that your product is adequate in solving the problem that it sets out to solve.

‍To aid the usability of your product, the NHS requires you to:‍

You have not carried out, or are still working towards, some or all of these requirements. In order to pass the usability assessment section of DTAC, all of these requirements must be fulfilled. Make sure that you carry out these steps as appropriate to the stage of your product development lifecycle.

Once you have carried out these steps, it is important to remember: As you go through product iteration, you might change certain elements of the user journey or product features. Make sure you go back to the drawing board when it comes to usability, and do not assume that you have taken user needs into account appropriately when you change an element of your product. Validation should be iterative and you might need a few attempts before getting the full picture.

Guidance on usability is provided by the NHS here:

User Acceptance Testing (UAT) is a crucial part of demonstrating compliance with usability and accessibility requirements. Usability testing helps in ensuring that the product is simple to use, which is especially important when thinking about patient pathways and how products should help patients or other users solve important problems.

The NHS DTAC asks product developers to carry out user acceptance testing. You have not yet carried out user acceptance testing or you're working towards it. Make sure to follow the following principles of user acceptance testing:

The public, patients and staff need to access NHS services throughout the day and night. If a service is unavailable or slow, it can mean people do not get the help they need. This is why one of the requirements of the DTAC is for developers to provide a Service Level Agreement (SLA) to all customers purchasing the product.

A Service Level Agreement should clearly define your product, set realistic and measurable objectives, and take any customer requirements into account.

‍Through your SLA, you should show that you aim to:

Your customers may require you to report on your performance regarding support, system performance and availability.

Reporting on these topics to your customers is not a hard requirement on the DTAC (half points may be awarded during the assessment for a "no" answer), but it is desirable.

These performance indicators depend on what you have promised your customers in your Service Level Agreement.

You have not mainained an average uptime (availability) of 99% or higher over the past 12 months. In order to obtain points in the DTAC assessment for this section, 99% uptime is the minimum threshold.

Your product is not Web Content Accessiblity Guidelines Level AA compliant.

The DTAC requires you to make sure that people with different physical, mental health, social, cultural or learning needs can use your 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:‍

The DTAC requires you to use common components and patterns in the development of your product.

You do not use common components and patterns in your product.

Using common components and patterns means you do not have to solve problems that have already been solved. By using a component or pattern that’s already been extensively tested, you can provide users with a good experience in a cost effective way.

Examples of these components and patterns are:‍

The DTAC requires you to ensure your team contains multidisciplinary skills, as a team with diversity of expertise and perspectives is more likely to come up with the best solution. The size and roles you'll need will change as you build the service.

You do not have a multidisciplinary team.

‍As part of your DTAC submission, you should be able to show that your team:

You do not use agile ways of working in the development of your product.

In order to fulfil the DTAC requirements, you should use agile ways of working.

Using agile, iterative, user-centred ways of working will help you get your service in front of real users as soon as possible. Then observing and analysing data on how they use it, and iterating the service based on what you've learned.

Continuous development of your product means more than doing basic maintenance, like fixing bugs in code or deploying security patches. It means responding to feedback and changes in user needs and behaviour, clinical evidence and practice, technology and policy. You do not continuously develop your product.

In order to fulfil the DTAC requirements, you must ensure that you iterate and improve the product throughout its lifetime. That means you should continuously collect user feedback, carry out user validation, and keep track of changes in clinical practice, technology and policy. That way, you can continuously improve your product.

You don't yet have a benefits case that includes your objectives and the benefits you will be measuring, or the metrics that you will be tracking. In order to fulfil the DTAC requirements, you should define what success looks like and be open about how your service is performing.

A benefits case is a document which considers not just the cost but also use, usability and clinical benefit of your product. In this document, you should identify not only the benefits but also potential negative impact, inappropriate use or unintended consequences.

This will help you work out how your product helps improve health and well being, people's experience of health and care, and the efficiency of the health product and how you will know that you're succeeding.

The UK government provides guidance on measuring the benefits of your product, please find that guidance here.

Your 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:

Your 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: