A supplier may arrive with a completed DTAC form, a reassuring procurement presentation and a claim that its software is safe for NHS use. That still doesn't answer the question a practice manager or Clinical Safety Officer has to answer: is this product safe, secure and workable in our specific deployment?
For GP practice software, DTAC compliance is best treated as an ongoing local governance file, not a permanent vendor badge. NHS guidance says every separate NHS organisation using a technology must undertake its own DTAC assessment, so the practice, PCN or ICB remains responsible for checking how the product will operate within its own pathways, information governance arrangements and technical environment.
That distinction matters particularly for autonomous AI triage and booking. A supplier may provide strong national evidence, but local reviewers still need to understand the product's clinical safety documentation, data flows, integration behaviour, accessibility and change-control arrangements before go-live.
The Reality of Local Digital Assurance
The common mistake is to treat DTAC as something the supplier completes once and the buyer accepts. NHS England describes DTAC as the baseline framework for digital health and social care technologies seeking access to NHS markets or systems, but the assessment still has to be considered by each organisation using the technology. A vendor's evidence is therefore a starting point for local assurance, not a substitute for it.
The local question is practical. What happens when a patient submits information through this particular pathway? Where does the resulting summary go? Who reviews exceptions? How are risks escalated? What happens if an integration fails, a workflow changes or a product version is updated?
A vendor pack is evidence, not approval
A sensible local review should identify:
Deployment setting: Which practice, PCN or ICB pathway will use the software, and does the supplier's evidence cover that configuration?
Accountability: Which local information governance, clinical safety and IT leads will review and sign off the deployment?
Version control: Does the evidence relate to the exact product version being procured?
Operational ownership: Who manages incidents, changes, user feedback and post-go-live assurance?
This is why DTAC compliance for GP practice software has more in common with controlled clinical governance than with a one-off procurement form. The file should be updated when the product, integration or intended use changes.
Mapping the Five Baseline Domains
A complete supplier assurance pack should map the product clearly to DTAC's five baseline domains: clinical safety, data protection, technical assurance, interoperability, and usability/accessibility. The pack should make it easy for local reviewers to identify the evidence, its owner, its date and the product version to which it applies.
What to request from the supplier
Clinical safety should include the relevant DCB0129 documentation, a named Clinical Safety Officer, a hazard log and a clinical safety case. Ask how the supplier's safety evidence supports the practice's own deployment assessment under DCB0160.
Data protection needs more than a privacy statement. Request data-flow information, processing responsibilities, retention arrangements, access controls and DPIA-level evidence. The local information governance reviewer should be able to see what information is collected, where it travels and how it's protected.
Technical assurance should be supported by current cyber security policies, security testing evidence, access-control information, incident processes and relevant assurance records. The supplier should explain how evidence is maintained rather than attaching an undated certificate.
Interoperability requires technical detail. Ask for integration architecture, data-flow diagrams, record schemas, write-back behaviour, audit information and error-handling arrangements for each route into the practice's clinical system.
Usability and accessibility should be evidenced through user research, workflow testing, accessibility review and remediation records. Patient-facing software must be assessed in the context in which patients and practice staff will use it.
Practical rule: If a supplier can answer a DTAC question but can't produce the underlying evidence, record the response as an assurance gap rather than treating it as closed.
Route the pack through the practice's information governance, clinical safety and IT review functions. Procurement can coordinate the process, but it shouldn't be the only control point.
Navigating Clinical Safety Standards
Clinical safety is where a generic assurance statement becomes inadequate. Under the NHS clinical risk management standards, compliance with the relevant standards is mandatory under the Health and Social Care Act 2012. The manufacturer and the deploying organisation have different responsibilities, and both need to be visible in the evidence trail.
DCB0129 applies to manufacturers of health IT systems. It requires proportionate clinical risk management, clinical safety documentation and a Clinical Safety Officer throughout development. DCB0160 applies to the organisation deploying and using the system, which must assess risks in its own operational setting.
| Standard | Applies To | Core Requirement |
|---|---|---|
| DCB0129 | Manufacturer or supplier | Maintain clinical risk management during development, with a named Clinical Safety Officer, hazard log and safety case |
| DCB0160 | Deploying practice, PCN or other NHS organisation | Assess and manage risks created by implementing and using the system in the local care setting |
What the practice should verify
The supplier's DCB0129 pack should be specific enough to support local review. Check that it identifies the responsible Clinical Safety Officer, describes the product's intended use, records hazards attributable to the product and explains the controls applied.
A hazard log isn't just an administrative attachment. NHS England's digital clinical safety assurance guidance describes it as a formal document covering hazards considered attributable to the product. For triage and booking software, the local review should examine how the product behaves when information is incomplete, urgency is unclear, a booking route is unavailable or an escalation requires human attention.
The practice then needs its own DCB0160 activity. That means assessing the actual pathway, staff roles, local configuration, escalation arrangements and fallback process. A supplier's safety case can't describe every practice's operational reality.
GP Triage presents its product assurance around Infermedica, a Class 2B medical device, with UKCA and MHRA positioning and DCB0129 and DCB0160 documentation. Its stated safety record is “to date, zero recorded clinical safety incidents across approximately two million triages” and “around 97% concordance with GP decision-making”. Those statements should still be reviewed as evidence within the local governance process, not treated as a guarantee that removes the practice's own obligations.
Evaluating Interoperability and Usability Claims
Interoperability and usability are often the domains where a supplier's broad wording creates the most work for the buyer. “Integration” doesn't tell a practice what data is transferred, when it's transferred, what staff see, or what happens when the transfer fails.
NHS England's guidance on medical devices and digital tools states that interoperability should support information being transferred quickly, safely and securely. For GP practice software, that makes structured write-back and auditability central requirements. They're not optional conveniences.
Ask the supplier to demonstrate each integration path using the actual deployment workflow:
Input behaviour: What information does the product receive, and from which channel?
Output behaviour: What triage summary or booking information is transferred into the practice's clinical system?
Schema evidence: Which fields are created, and how are missing or ambiguous values handled?
Failure handling: What happens if the connection is interrupted or the write-back doesn't complete?
Audit trail: Can the practice identify what was submitted, processed, booked, escalated or rejected?
User testing: Have NHS practice users tested the workflow, including exception cases?
A product can be technically interoperable but operationally awkward. Usability testing should therefore include reception staff, clinicians and patients where relevant. The aim isn't to collect favourable feedback. It's to identify where the workflow creates confusion, duplication or unsafe workarounds.
GP Triage states that it integrates with the major UK clinical systems and pushes a triage summary into the booking record. A local reviewer should still confirm the exact data flow, configuration and failure process for the intended practice.
Understanding the 2026 Form Update
DTAC is actively maintained. NHS England says the original DTAC form must be retired and version 2.0 used from 6 April 2026. A supplier claiming to be DTAC compliant should therefore identify which form version it has completed, when it was last updated and which product version the evidence covers.
The refreshed form contains approximately 25% fewer questions, partly because duplicated checks, including parts of the Data Security and Protection Toolkit, were removed. The shorter questionnaire may reduce repetition, but it doesn't automatically reduce the underlying assurance burden.
Why fewer questions can mean more scrutiny
The risk is that buyers interpret a shorter form as a simpler decision. In practice, the buyer may need to verify more carefully whether the remaining answers are supported by current evidence and whether removed questions are covered elsewhere in the governance pack.
Ask for:
Form version: Is the supplier using DTAC 2.0 rather than the retired form?
Product version: Does the assessment match the software being procured?
Supporting evidence: Are policies, tests, safety documents and data-flow records current?
Scope: Does the assessment describe the intended NHS use and deployment model?
Change control: How will the supplier notify the practice about material product, integration or processing changes?
NHS guidance also says developers must keep an up-to-date DTAC form and supporting documentation for each product version. The phrase “DTAC compliant” is therefore incomplete unless it's accompanied by version-specific evidence and a clear maintenance process.
The practical trade-off is straightforward. A shorter form can make review less repetitive, but it can't replace professional judgement. Local organisations still need to establish whether the product is safe and suitable in their own setting.
Building Your Local Governance File
A workable governance file should let a reviewer answer three questions quickly: what was assessed, what evidence supports it, and what remains outstanding? Start by creating a product record that names the supplier, product version, intended use, deployment sites and local accountable leads.
A practical review sequence
Map the product to the five DTAC domains. Record which requirements apply and identify the evidence expected for each one.
Collect the supplier pack. Store the DTAC form, supporting documents, version information and named owners together.
Review clinical safety separately. Verify DCB0129 documentation, the named Clinical Safety Officer, hazard log and safety case.
Complete local deployment checks. Use DCB0160 to assess the practice's pathway, configuration, staffing, escalation and fallback arrangements.
Test the integration. Confirm data flows, write-back, auditability and error handling using realistic NHS workflows.
Record gaps and actions. Give each gap an owner, a required document or test, and a decision point before go-live.
Set review triggers. Reopen the file when the product, integration, data processing or clinical workflow changes.
Pause procurement when the supplier provides only a completed questionnaire without supporting evidence, relies on an obsolete form, refuses to identify its Clinical Safety Officer, or can't explain how local deployment risks will be assessed. The same applies when interoperability claims aren't backed by data-flow and error-handling evidence.
For practices assessing autonomous AI triage and booking, GP Triage provides an assurance pack built around the DTAC domains, clinical safety documentation and local deployment review. Visit GP Triage to arrange a demonstration focused on your practice's evidence requirements, integration pathway and governance process.
