GP Patient Access and AI Reception Insights | QuantumLoopAI

AI reception at ICB scale: choosing the right evidence

Written by Evan Burgess | November 11, 2026

An ICB digital patient access decision needs evidence that connects a proposed service to the work of the practices involved. A feature list, an encouraging demonstration and a single customer story can each help, but they do not answer the same question. Organise the evidence around the decision the integrated care board needs to make.

For a GP reception proposal, that might be whether to explore a defined workflow, proceed with a bounded pilot or expand an arrangement already in use. State that decision first. It determines what evidence is necessary and prevents a large document from hiding an unresolved practical question.

Start with the local problem and its limits

Describe the affected practices, patient-access routes and administrative work. Record how the problem was identified: operational data, staff observation, patient feedback or an untested hypothesis. Keep those evidence types visible.

A network average can conceal different starting points. One practice may need help understanding unfinished requests; another may have a content problem that creates repeated enquiries. Preserve practice-level context before proposing the same intervention everywhere.

The PCN rollout guide offers a way to map those differences. Use it as a conversation aid, not as a mandatory barrier to an initial supplier discussion.

Why scaling AI reception across an ICB needs local evidence

The challenge is agreeing what a successful patient request looks like across practices with different starting points. Reception staffing, appointment rules, language needs and follow-up arrangements can vary. A headline answer rate does not explain whether the requested administrative task was completed or what the reception team still needed to do.

Choose a common set of definitions, then keep each practice’s context alongside its results. Agree who checks unfinished work, how staff report problems and what would justify expanding the agreed service. This gives the ICB a useful comparison while preserving the local responsibilities that make the service work.

Give the evidence pack a decision structure

  1. Problem and baseline: who is affected, what is measured and which gaps remain.
  2. Proposed service: operating hours, settings, actions and configuration boundaries.
  3. Observed workflow: what a demonstration or pilot actually showed, including remaining staff work.
  4. Implementation responsibilities: local ownership, human support, relevant assurance and dependencies.
  5. Commercial and buying route: a scoped quote and the process confirmed by the responsible procurement team.
  6. Evaluation and decision: the evidence that would support continuing, revising or stopping the proposal.

Keep a short source record beside each material claim: owner, date, setting, measure and limit. This makes it possible to update one fact without rewriting the entire argument.

NHS England’s AI buyer’s guide, last edited 16 June 2025, asks buyers to consider local delivery requirements and how they will monitor benefits in practice. Use that question to organise the pack: which benefit are we testing here, and what evidence would show it? This is a practical use of the guidance, not an endorsement of a supplier.

Make measures comparable before aggregating them

Define calls, requests and completed administrative actions separately. A conversation can contain more than one request, and a captured request can still require staff action. Combining unlike measures under a label such as “resolution” creates a misleading comparison.

For each practice, record the observation window and relevant configuration. Note missing data and changes in staffing or access arrangements. Report an unknown outcome as unknown. A positive result at one site is useful evidence to examine, not proof of the same result throughout the system.

Include qualitative evidence alongside counts. A reception colleague may identify a handover problem that a summary dashboard does not show. Explain how that observation was collected and what decision it changes.

A worked example: one request, two different results

Consider this fictional example. Two practices each review 100 routine appointment requests. Practice A records 70 appointments booked and 30 requests passed to reception. Practice B records 90 requests captured, but has not checked how many became appointments. Those figures do not show that Practice B completed more bookings. They describe different outcomes.

The next step is to record appointment outcomes for Practice B and the follow-up needed at both sites. Keep the observation period, agreed booking rules and unreviewed requests visible. The point is to improve the decision, not to manufacture a single impressive percentage. These numbers illustrate a measurement problem; they are not EMMA or customer results.

Keep ambition separate from the service being evaluated

EMMA is QuantumLoopAI’s AI receptionist for NHS GP surgeries in England. It supports patient requests and routine appointment booking and cancellation during surgery hours. The options available depend on the service agreed with each practice. EMMA supports 19 languages clinically signed off through QuantumLoopAI’s Clinical Safety Officer process. Outbound calling remains beta. EMMA does not provide medical advice or clinical triage.

The current product FAQs provide the starting scope. GP evidence should retain that setting when an ICB considers wider pathway questions; it does not establish hospital, urgent-care or system-wide deployment capability.

End with an explicit next decision

Name the evidence still needed and who can supply it. A useful pack can recommend a limited next step without pretending every uncertainty has disappeared. Request an EMMA demonstration to explore the GP administrative workflow and configuration relevant to that decision.