Building a Compliance Culture in Healthtech Organisations

Every healthtech innovator in the UK has heard of DTAC (or should have heard of by now).

The Digital Technology Assessment Criteria (DTAC) is the national baseline criteria for digital health technologies wishing to enter the NHS. It brings together legislation and good practice on meeting clinical safety, data protection, technical security, usability and accessibility standards. All new technologies should be assessed against DTAC criteria as part of each new procurement process or contract renewal with the NHS.

So, if you’re a healthtech innovator and wish to sell your product to the NHS, you first need to make sure it is DTAC compliant. Let’s assume you’ve done the work and passed the assessment. You are now DTAC compliant. You take a deep breath and feel relieved. You may be tempted to forget about compliance for a while. Here’s why you should not.

Compliance does not stop once DTAC is completed. Compliance is a way of working, a way of doing product development. To maintain your DTAC certification, compliance needs to be deeply embedded into your organisation and considered in everything that you do.

How do you do this? 

If we look at typical product maturity stages, here’s how compliance can be embedded at every step to support the DTAC.

In the early stages of your product development, when you’re considering which features might appear in the first build of your healthtech innovation, you absolutely must consider patient safety.

A central part of the DCB0129 Clinical Safety standard (part of the DTAC) asks that you create a hazard log for your product. Our advice is to build this from your ideation phase, where you should openly discuss how a patient may come to harm should your product be used incorrectly, its features used out of sequence or an action executed more than once.

Note all of this down somewhere, e.g. in the NHS DCB0129 hazard log template, store the outputs somewhere your team has access and record any meetings you have. Those early conversations where patient safety is given a lead role will be a valuable resource and a time saver for you as your product matures.

For technical security there are some simple steps you can take that are recommended by the National Cyber Security Centre. These steps are part of the Cyber Essentials certification (also part of the DTAC).

We’d recommend that you:

• Ensure all of your data is stored in an encrypted format
• Turn on Multi Factor Authentication (MFA) everywhere you can, e.g. on MS Teams, Google Workspace, etc.
• Install anti-malware and anti-virus software on your business computers
• Turn on software firewalls on your computers
• Change default password on your router
• Establish a password policy and get your whole team to implement it

The above steps are simple, but offer a good early base of protection for the IP your team are creating, and for your reputation.

From an organisational standpoint, we’d recommend that you at least:

• Register with NHS Digital for an ODS (organisation) code that will identify your organisation with NHS Digital and allow you access to a crucial part of the DTAC, the Data Security and Protection Toolkit (DSPT). Again the earlier you begin with DSPT the better as it is for your benefit to implement its requirements and essential to sell to the NHS
• With regards to Data Protection you should also be impacting each feature you are developing to understand whether it presents a risk to personal data and any sensitive data. If so, implement measures within your product and its related processes that mitigate this. Again by noting down these risks at an early stage this will save you time and money as your product nears pre-production / pilot phase

As your healthtech product matures and is in a final internal testing phase, sometimes known as pre-production, you will need to level up your compliance with the DTAC.

For Clinical Safety you will need to formalise your hazard log and this is where you’ll realise the benefit of noting potential hazards early! As you finalise the features for your initial product release you should also begin to create the Clinical Safety Case Report as required under DCB0129. This is of course underpinned by your Clinical Risk Management System which also needs documenting.

Working to agile methodology is also part of the DTAC and it offers great opportunity to begin embedding a structured way of managing compliance activity. For instance, you could include in a Definition of Ready, the need for every feature on your product backlog to have been assessed for patient harm under DCB0129, for privacy challenges under GDPR and so on.

Embedding a structured way of impacting features against the DTAC domains is, in our experience, highly effective and can build in an extra quality gateway that will also serve you well as your product matures, particularly if your product is, or is becoming, a medical device. If you already know your product is a medical device then there is much more work to do to ensure it can safely enter the market.

You should also consider at this stage of development the interoperability aspects of the DTAC. Ensure you have Open APIs that allow authentication to current good practices and consider how your product can add value, increase safety and lower costs for the NHS by embracing interoperability, e.g. does your product need to link with GP records or Acute Electronic Patient Records? If so, then you need to be thinking and documenting and interoperability strategy and preparing your product for such integration.

This will help you move towards the product release stage and sale to the NHS. At this stage, you should have ample coverage of the key areas of the DTAC and you will need to fill in any gaps, which could include:

• Finalising your clinical safety documentation and ensuring any mitigations you have implemented within your innovation are repeatably testable, release to release
• Completing the DSPT
• Documenting your interoperability strategy
• Ensuring you are Cyber Essentials certified
• Executing a Penetration Test against your application, infrastructure and any connected devices
• Completing an accessibility audit against the WCAG 2.1 AA standard
• Having an external code security review executed

Once you’ve closed those gaps, and you have a full DTAC evidence file you will be in a position to sell to the NHS. And through impacting each feature against each DTAC domain as your product evolves, you’ll have the seeds of a robust process for ensuring you remain aligned to DTAC release to release.

Because compliance never stops. It’s a journey to bring increasingly safer and more effective care to patients who really need it.

If you want to know more about how to build a culture of compliance within your organisation, review our DTAC learning resources.