The compliance question is the question that decides most AI voice procurement decisions in NHS primary care. It is also the question that gets answered badly by most vendors, and the gap between a confident demo and a defensible IG sign-off is where most evaluations stall. The standards themselves are not the difficulty. The difficulty is knowing which evidence a clinical safety committee or an ICB procurement lead actually needs to see before they can sign anything.
This post is a working guide to the four frameworks that govern AI voice deployment in an NHS GP practice: DCB0129, DTAC, GDPR, and the DSP Toolkit. It covers what each one requires, what compliance evidence looks like in practice, and the specific questions an IG lead can put to a vendor that will produce useful answers rather than reassurance. It is written for practice managers, GP partners, IG leads, and ICB procurement professionals, in plain language.
Why These Standards Exist and Why They Are Right
Software that sits in the path of patient care can cause clinical harm. A system that misroutes an urgent symptom, misidentifies a patient, fails during peak demand, or applies the wrong clinical protocol is not an operational issue. It is a patient safety event. The standards that govern healthcare software in England exist to ensure that any technology touching the patient pathway has been systematically assessed for risk, that risks have been mitigated, and that the organisation deploying the technology has a clear framework for monitoring and responding to safety events that do occur.
This is the right framework. It is appropriate to hold AI voice technology to it, and the standards are not the barrier. The barrier is the evidence quality vendors are willing to produce when asked.
Before getting to the frameworks individually, it is worth understanding the relative weight of each, because they do different jobs in a procurement evaluation.
The Four Frameworks and What Each One Actually Does
DCB0129 is the clinical safety standard. It is the framework that tells you whether the vendor has identified and managed the clinical risks the product creates. It is the gatekeeper.
DTAC is the assessment framework. It is the NHS-defined process for evaluating a digital health product against clinical safety, data protection, technical security, interoperability, and usability criteria. A completed DTAC assessment is the single most useful procurement document a vendor can produce, because it consolidates evidence from the other three frameworks into one independent reference.
GDPR and the DSP Toolkit cover data protection and data security. GDPR is the legal framework that governs how patient data is processed. The DSP Toolkit is the NHS-specific framework for assessing whether the vendor’s data security practices meet the standard required to handle NHS patient data.
The order matters. A vendor with a clean DCB0129 file and a current DTAC assessment is operating inside a recognised compliance envelope. A vendor without DCB0129 evidence is not ready for NHS deployment, regardless of how their product performs in a demo.
DCB0129: Clinical Risk Management
DCB0129 is an NHS Digital standard that applies to manufacturers of health IT systems. It requires the vendor to implement and maintain a clinical risk management system, which is a documented process for identifying, assessing, and mitigating clinical risks associated with the product.
The output of that process is a Clinical Risk Management File. The file identifies every clinical risk the product could create, assesses the likelihood and severity of each risk, and records what mitigations have been put in place to reduce that risk to an acceptable level. The file is a living document and must be updated when the product changes.
For an AI voice receptionist specifically, the clinical risks that should appear in the file include: a call where an urgent symptom is not correctly identified and escalated, a call where patient identity is not correctly verified and information from the wrong patient record is accessed or disclosed, a system failure during a period of high patient demand, and incorrect protocol application resulting in a missed or delayed clinical action.
DCB0129 compliance does not mean these risks are impossible. It means they have been identified, documented, and addressed with specific technical and procedural controls, and that there is a systematic process for monitoring whether those controls remain effective.
The questions to put to a vendor on DCB0129 are specific. Can you share the summary of your Clinical Risk Management File. Who is your named Clinical Safety Officer. Has the CSO reviewed the current version of the product. What is your process for updating the risk file when the product changes. A vendor who cannot answer these in writing is not DCB0129 compliant in any meaningful sense.
DTAC: The Procurement Shortcut
DTAC is the NHS framework for assessing digital health products before deployment. It covers clinical safety, data protection, technical security, interoperability, and usability, and the assessment is performed against criteria defined by NHS England.
A completed DTAC assessment does not mean a product has been approved by the NHS. It means it has been evaluated against the NHS’s own standards by a qualified assessor, and the result is a document that an IG lead or procurement professional can reference directly.
The reason DTAC matters disproportionately in a procurement context is that it consolidates evidence. Inside a DTAC assessment you find DCB0129 status, DPIA status, penetration testing results, interoperability evidence, and usability validation. For an IG lead writing a sign-off recommendation to a partners’ meeting, a current DTAC assessment is the single document that does most of the work.
A vendor who has completed DTAC assessment has gone through external scrutiny. That does not guarantee the product is right for any specific practice, which remains a judgement the practice makes, but it substantially reduces the due diligence burden on the practice team and produces a defensible audit trail.
Before looking at the specific GDPR and DSP Toolkit questions, it is worth flagging the one piece of evidence that does most of the work in an information governance review.
The Data Processing Agreement Is Not Optional
The Data Processing Agreement, the DPA, is the legal document that defines the relationship between the practice as data controller and the AI vendor as data processor. It specifies what data the vendor can access, how they can use it, how it must be stored and secured, and what happens to the data when the contract ends.
Any AI vendor operating in an NHS setting must provide a DPA before any patient data is processed. If a vendor cannot produce a DPA, or asks you to sign a generic terms-of-service document that does not specifically address NHS data handling, the procurement evaluation stops at that point. There is no path forward without a DPA in place.
This is the single most reliable filter in an AI voice procurement evaluation. Vendors who are ready for NHS deployment have a DPA template ready to send before the first call ends. Vendors who are not ready will delay, send a non-NHS-specific document, or ask the practice to draft one.
GDPR and the Specific Questions That Matter
GDPR governs how personal data, including patient data, is collected, stored, and processed. For an AI voice receptionist specifically, three GDPR questions carry the most weight.
The first is the data controller question. In any NHS GP setting, the practice is the data controller. This is true regardless of what technology the practice uses. If the practice deploys an AI voice receptionist, the practice remains responsible for the patient data the system processes. The vendor is a data processor, acting on the practice’s instructions under the terms of the DPA. Any vendor framing suggesting otherwise is wrong, and that framing should be challenged in writing.
The second is patient identity verification. An AI voice receptionist that handles patient calls must verify identity reliably before any patient-specific information is accessed or disclosed. The verification standard for a well-built system is two-factor: phone number and date of birth, validated against NHS Patient Demographics Service. If identification fails, the call is flagged for human review and not completed. Calls where identification fails should not be billable to the practice.
The third is data minimisation and retention. GDPR requires that only the minimum necessary data is collected for the stated purpose. An AI voice receptionist that collects clinical information should collect only what is needed to complete the triage or administrative task, and the retention period for call recordings, transcripts, and structured outputs should be defined and aligned with NHS records management guidelines.
The DSP Toolkit: The Data Security Floor
The Data Security and Protection Toolkit is the NHS’s self-assessment framework for organisations that handle NHS patient data. GP practices complete their own DSP Toolkit submission annually. AI vendors operating in NHS settings should also be assessed against DSP Toolkit standards, either through their own submission or through the DTAC process.
The DSP Toolkit covers cyber security, staff training, incident management, and data flow mapping. For a vendor sitting in the patient access pathway, DSP Toolkit evidence is the floor for data security, not a stretch standard. A vendor without either an independent DSP Toolkit submission or DSP Toolkit assessment evidence inside their DTAC document cannot demonstrate that they meet NHS data security standards.
Live Deployment Is Evidence Too
Compliance documentation is the necessary base. Live deployment performance is the validating evidence on top of it.
The Park Street Surgery deployment in Liverpool has been operating since November 2025. Across the first eight weeks, the live performance numbers were 1,200 calls handled, 81% inbound demand absorbed, 91.1% completion rate, and zero missed safety indicators. The Greensand Surgery deployment is showing the same operational pattern in its early weeks, with 816 calls handled and almost 26 hours of reception time recovered.
The zero missed safety indicators metric is the one that connects directly to DCB0129. It is the empirical observation against the clinical risk that the framework is designed to manage. Documentation tells you what mitigations are in place. Live deployment tells you whether those mitigations are working in the operational environment.
For an IG lead or procurement professional evaluating a vendor, the combination is the answer to the underlying question: is this safe for NHS use. The documentation tells you the framework is in place. The deployment data tells you the framework is producing the intended outcomes.
The Procurement Question Set
A vendor that is genuinely ready for NHS deployment will answer all of the following in writing without hesitation. These are the questions an IG lead or ICB procurement professional should expect to put on the table.
Is the product DCB0129 compliant. Who is the named Clinical Safety Officer. Can you provide a summary of the Clinical Risk Management File.
Has the product been through a DTAC assessment. Can you provide the assessment summary document.
Can you provide a Data Processing Agreement before any patient data is processed. Where is patient data stored. Is it stored within the UK or EEA.
What is the retention period for call recordings, transcripts, and structured outputs.
Has the product been penetration tested. When was the last test. Can you share the outcomes summary.
What is your process for notifying the practice of a data security incident. What is your maximum notification timeframe.
What happens to patient data when the contract ends. What is the data return and deletion process.
Who has access to patient data on the vendor side. How is that access logged and audited.
A vendor that can answer these in writing within one working day is operating inside the compliance envelope NHS deployment requires. A vendor that delays, deflects, or offers reassurance in place of documentation is not ready, regardless of how the product performs in a demo.
What Compliance Confidence Actually Looks Like
A vendor ready for NHS deployment has these documents prepared and ready to share before they are asked for them. They have a named Clinical Safety Officer who can be contacted directly. They have a current DPA template. They have a DTAC assessment summary, or a clear timeline for completion of one. They know where patient data is stored, how long it is retained, and what the incident response process is.
They are also able to articulate, in plain language, what the residual clinical risks of the product are. Not because the risks are problems, but because a responsible vendor acknowledges that no software is risk-free and demonstrates that the residual risks have been identified and managed. A vendor who says their product is risk-free is not telling the truth, and that statement alone is a procurement red flag.
The Auxilis team works through the compliance question set with every practice during the demo and the four-week pilot setup. The pilot itself runs on existing telephony with no setup fee, and produces live deployment data from the practice’s own patient list as part of the IG and clinical safety evidence base.
Book a 20-minute demo at auxilis.ai
Frequently Asked Questions
What is DCB0129 and does it apply to AI voice receptionists?
DCB0129 is an NHS Digital clinical risk management standard that applies to manufacturers of health IT systems. Any software that sits in the patient care pathway, including an AI voice receptionist that handles clinical triage information, falls within its scope. A DCB0129 compliant vendor has a documented Clinical Risk Management File, a named Clinical Safety Officer, and a systematic process for monitoring whether the risk mitigations remain effective as the product evolves.
Does our practice need to complete a DPIA before deploying an AI receptionist?
A Data Protection Impact Assessment is required under GDPR when processing is likely to result in high risk to individuals. Handling patient health data using a new technology is typically high-risk processing, so a DPIA is required in most cases. A vendor with current DTAC, DCB0129, and DPA documentation reduces the practice’s DPIA workload significantly, because most of the underlying evidence is already produced.
Who is responsible for patient data processed by an AI voice receptionist?
The GP practice is the data controller and is responsible for patient data throughout. The AI vendor is a data processor, acting on the practice’s instructions under the terms of the Data Processing Agreement. This relationship is non-negotiable in any NHS setting and must be documented in writing before any patient data is processed.
Can an AI voice receptionist be CE marked or UKCA marked as a medical device?
Some AI health tools are classified as medical devices depending on their intended purpose. An AI system that provides clinical decision support, recommending diagnoses or treatments, is more likely to require device marking than one that handles administrative triage and routing. Most current AI voice receptionists in primary care are positioned as administrative tools rather than clinical decision support systems, which affects their regulatory classification. The right question to put to a vendor is how they have assessed and documented their regulatory classification, and what the basis for that classification is.
What is the DSP Toolkit and why does it matter for an AI vendor?
The Data Security and Protection Toolkit is the NHS framework for assessing data security practices among organisations that handle NHS patient data. AI vendors operating in NHS settings should be assessed against DSP Toolkit standards, either through their own submission or through their DTAC assessment. A vendor without either cannot demonstrate they meet NHS data security standards.
What evidence should a vendor provide that their compliance controls are working in practice?
Live deployment data. Documentation tells an IG lead what mitigations are in place. Live deployment tells them whether those mitigations are producing the intended outcomes. Metrics like zero missed safety indicators across thousands of calls, alongside the underlying documentation, are the combination that supports a defensible sign-off recommendation.
What is the single fastest filter in an AI vendor evaluation?
The Data Processing Agreement. Vendors ready for NHS deployment have a DPA template prepared and can send it before the first call ends. Vendors who are not ready will delay, send a generic non-NHS-specific document, or ask the practice to draft the DPA. The presence or absence of a ready DPA is the single most reliable indicator of whether a vendor is operating inside the NHS compliance envelope.