How NHS Wales Is Using AI to Match 100,000 Patients to Dental Practices

NHS dental access in Wales is not a simple problem. There are not enough dental practices, the geography ranges from dense inner-city populations to deeply rural communities, and the patients on waiting lists have needs that vary enormously — from routine check-ups to complex specialist requirements that only a handful of practices in a region can accommodate. Sitting behind all of this is a waiting list of over 100,000 patients.

For years, the process of matching patients to practices was done by coordinators working across disconnected systems, relying heavily on local knowledge, manual cross-referencing, and institutional memory. It was slow, inconsistent across health board boundaries, and impossible to scale. A coordinator in one board might weight a patient's travel distance as the primary factor. In another board, clinical urgency might dominate every decision. Neither approach was wrong — but they were not reconcilable, and the waiting list kept growing.

The Welsh Government needed a different approach. What emerged from that need was one of the most technically and ethically complex AI systems we have built.

Before writing a line of code, we spent time inside the actual workflow. What became clear immediately was that this was not a simple matching exercise. A patient is not just a name on a list — they are a family unit with a shared address, a clinical history, a level of need that may have changed since they first registered, and practical constraints around travel and access that matter enormously in a rural health board but may be irrelevant in Cardiff.

A practice, equally, is not just a slot count. It has a clinical capacity profile — what specialist treatments it can deliver, how many patients it can take on across different NHS contract types, whether it has accessible facilities, and what its current patient mix looks like. Sending a patient with complex periodontal needs to a practice that cannot treat them is not a successful allocation. It is a failure that wastes everyone's time and delays the patient further.

And then there are the health boards. Wales has seven. Each has its own operational priorities, its own interpretation of the national waiting list guidance, and its own definition of what a “good” allocation looks like. A board covering the Brecon Beacons weights geography very differently from one covering Swansea. A board with significant deprivation in its catchment may prioritise clinical urgency above all else. These are not inconsistencies to be flattened out — they are legitimate local judgements that the system needed to respect and encode, not override.

The allocation engine at the heart of the system works through a weighted scoring model. For every patient-practice pairing, the system calculates a composite score across a set of factors that the health boards themselves helped define. The weighting of those factors is configurable per health board — meaning that what matters most in Powys is not hardcoded to be identical to what matters most in Aneurin Bevan.

The factors the model considers include:

• Clinical urgency — assessed from the patient's dental health record and time on the waiting list, with higher urgency patients surfaced to the top of the allocation queue
• Family unit cohesion — the system actively tries to allocate family members to the same practice, reducing the coordination burden on patients and improving retention
• Travel distance and access — calculated using actual road travel time, not straight-line distance, and weighted more heavily in rural health boards where a ten-mile journey may take forty minutes
• Practice capacity and specialisms — the engine only surfaces practices that can genuinely accommodate the patient's needs, filtering out practices that lack the clinical capability or contractual headroom
• Deprivation and vulnerability indicators — patients with indicators of social vulnerability receive additional weighting to ensure they are not systematically disadvantaged by a model that would otherwise favour easier-to-serve patients
• Patient stability — where possible, the system maintains existing patient-practice relationships rather than disrupting continuity of care without clinical justification

Every allocation decision the engine produces can be explained. A coordinator can see precisely why a patient was matched to a practice, which factors drove the score, and how the decision would change if a single variable were adjusted. There is no algorithmic opacity. The system is a tool that augments clinical and operational judgement — not one that replaces it.

Safety was the first conversation we had, not the last. Working in a regulated clinical environment, with patient health data, across a government programme, the question of how the system could fail — and what would happen when it did — had to be answered before anything was built.

The ethical framework we developed with the Welsh Government covered three things. First, bias monitoring: the system is continuously evaluated to ensure that no patient group — defined by geography, age, deprivation or clinical complexity — is systematically disadvantaged by the allocation model. Second, auditability: every decision the system makes is logged with its full scoring breakdown, creating a complete audit trail that satisfies both clinical governance and data protection requirements. Third, human primacy: the system is explicitly designed so that removing it returns coordinators to exactly the workflow they had before, with no dependency created that would leave patients unallocated if the system went offline.

The data architecture reflects these principles. Patient data is processed within the Welsh Government's secure Azure tenancy. There is no external data transfer, no third-party model training on patient records, and no persistent storage of data outside the environments it was collected in. The system was built to meet the requirements of the Data Protection Act 2018 and the NHS Wales Informatics Service's information governance standards from day one — not retrofitted to comply after the fact.

We also spent considerable time on the question of equity. A weighted scoring model applied at scale will, if poorly designed, optimise for the patients who are easiest to allocate — those who live close to practices, have straightforward needs, and do not require specialist care. Left unchecked, this produces a system that systematically disadvantages the patients who most need help. The vulnerability weighting in our model was specifically designed to counteract this tendency, and its impact is monitored on an ongoing basis.

The system went into production processing real waiting list data within 30 days of kickoff. That timeline was possible because we scoped aggressively, built only what was necessary to be live, and treated the first production deployment as the beginning of the work rather than the end of it. It is the same methodology behind our AI Deployment Sprint — identify the highest-value problem, build the minimum viable production system, and ship it before the scope creeps.

What we shipped in month one was a working, safe, auditable allocation engine that materially reduced the time coordinators spent on manual triage. What we shipped in months two and three was a more refined model, informed by the actual allocation decisions coordinators were accepting, modifying and overriding in production — data that is uniquely valuable for understanding where the model's judgements aligned with clinical expertise and where they did not.

This iterative approach is not a workaround for uncertainty. It is the correct engineering model for AI systems in complex operational environments. No model built in a workshop, however carefully designed, will perform identically to one that has processed real decisions with real consequences. The gap between a well-reasoned design and a production-calibrated system is where the actual work happens — and it can only happen once the system is live.

The infrastructure was built for this from the start. This kind of architecture — configurable without code deployments, continuously evaluated, integrated with existing identity and data infrastructure — is what we mean when we describe an AI Platform Build. The weighting configurations are adjustable without a code deployment. The evaluation pipeline runs continuously, flagging statistical drift in allocation patterns before it becomes a clinical governance issue. New practice capacity data flows into the system automatically from the NHS Wales data feeds, so the model is always working with current information. And the health board configuration interfaces are owned by the operational teams, not by us — because a system that requires its builders to make every adjustment is not a production system, it is a perpetual dependency.

This project succeeded where similar initiatives have stalled for one reason above all others: we were embedded inside the problem before we started building the solution. The clinical coordinators who use the system every day were not consulted once during a requirements workshop — they were involved continuously throughout the build, their feedback shaped every significant design decision, and their trust in the system was earned incrementally by demonstrating that it produced allocations that made sense.

The Welsh Government's commitment to genuine cross-health-board collaboration was equally important. Getting seven health boards to agree on a shared platform, while respecting the legitimate operational differences between them, required sustained organisational effort that sat well outside our scope — but without it, the technical work would have had nowhere to land. A technically excellent system deployed into an organisation that is not ready to use it is not a production system. It is an expensive proof of concept.

Finally, the decision to treat safety and ethics as engineering constraints rather than compliance checkboxes made the system more useful, not less. A model that coordinators trust enough to act on without second-guessing every output is a model that actually reduces waiting times. A model that produces opaque decisions, however accurate, gets overridden constantly — at which point you have built something expensive that nobody relies on.

The waiting list has not been solved. NHS dental access in Wales remains genuinely difficult. But the coordinators working on it now have a tool that surfaces the right patients to the right practices faster and more consistently than was previously possible — and the health boards have a system they can configure, audit, and trust. That is what production looks like.

How does an AI allocation engine for NHS dental waiting lists work?

The system scores every possible patient-practice pairing against a set of weighted factors — clinical urgency, travel time, family cohesion, practice capacity and specialism, and deprivation indicators. The health board controls the weighting. The engine surfaces the highest-scoring matches for coordinator review; no decision is automated without human sign-off.

Is patient data safe when processed by an AI system?

In this deployment, all patient data stays within the Welsh Government's secure Azure tenancy. There is no external data transfer and no third-party model training on patient records. The architecture was designed to meet Data Protection Act 2018 requirements and NHS Wales information governance standards from day one.

Can different health boards have different allocation priorities?

Yes, and in this system they do. Each of the seven Welsh health boards has its own weighting configuration. A rural board in Powys weights travel distance more heavily than one covering Swansea. These configurations are owned and adjustable by the operational teams, without requiring any code change from the builders.

What happens if the system goes offline?

The system was designed from the start so that removing it returns coordinators to exactly their prior workflow. No operational dependency is created. The AI accelerates an existing process; it does not become the process.