Getting all NHS appointments into the App: where we got to

From January to September 2026 I was product lead for a small multidisciplinary create/change team at NHS England. Our mission: work out how people could see and manage all of their NHS appointments in the NHS App, not just the ones from their GP and hospital.

In September the programme decided to end our part of the work. I wanted to bring some closure to what we started and shared in the design history we published in March, and take stock of where we got to.

Where we left off in March

We'd previously set out the problem. GP appointments are broadly solved in the NHS App. The gap is everywhere else, including community services, mental health, pharmacy, screening, and physiotherapy and other therapies.

By then we had a problem statement, a logic model, 16 starting assumptions and a map of 116 services. Our next job was to find where things were ready to move, and to work out what a proof of concept should be.

Going local to see the whole

Going deep on one use case is a good way to learn and to ship. The risk is that you never get the chance to broaden out, and everything that follows has to fit around that first choice. Our national mapping had told us what exists, but not much about how it fits together for one person. So we picked one region and tried to see every appointment in it.

Going local only works if the region wants you there and can keep working with you. We looked at integrated care boards (ICBs) against three things:

• how stable they were as organisations
• whether the NHS App featured in their own digital strategies
• whether they had named digital leads with time to give

That helped us focus on relationships likely to last. Humber and North Yorkshire (HNY) stood out, and the relationship grew to the point where we were talking with the ICB about working together on a proof of concept.

We ran eleven sessions in HNY with people working across digital, clinical care, service planning and the voluntary and community sector. Each brought a different view of the problem. Between them we found 33 areas worth exploring, some well outside the NHS's own walls, including:

• council leisure services used for weight loss and social prescribing
• non emergency patient transport
• voluntary car schemes
• optometry, audiology, dentistry and pharmacy

The most useful thing we learned was about time. The different systems across a region won't line up for years, and waiting for that isn't a plan. So instead of asking how to connect each system, we started asking what the App needs to know about an appointment, whichever system holds it.

Mapping the systems behind the appointments

To answer that we needed a clear picture of what was actually in use. An appointment can only reach the App if the system holding it can share it. So we mapped the systems used by community, mental health and sexual health services across HNY against the providers using them, and checked each one against the routes into the App that exist today.

That showed us which providers:

• could connect through existing routes soon
• would need changes to their systems first
• had no route at all

It also showed where one supplier's rollout would help and where it wouldn't.

Defining the data, not the integration

With that many systems, building a connection for each one means the App will always be catching up. So rather than designing integrations, we described the appointment data itself:

1. what comes in from a local system
2. what happens to it on the way through
3. what the patient sees at the end
4. when each part can be shown, and when it can't

That gives suppliers and providers one thing to work to, whatever system they use. It also gave our technical architect the starting point for an early idea of a layer that could sit between local systems and the App.

Patterns, not appointment types

Working through the 33 areas, we noticed that while the number of appointment types kept growing, the ways people actually get booked kept repeating. We pulled these together into 12 booking patterns, including:

• self service booking
• treatment plans
• gated self service
• self referral with triage
• callbacks
• group sessions
• screening plans
• gated invitations
• ghost bookings, where the service holds an appointment but doesn't share it with the patient

We mapped these against what the App can do today. Most aren't yet supported, though other teams in the programme are looking at some of them.

That gives the programme a short list of things the App needs to be able to do, rather than a long list of services to connect one at a time.

Risk before integration

Patterns tell you how a booking works. They don't tell you whether it's safe to show in the App. A read only community nursing visit is a very different thing from a self referral into mental health services.

We listed 40 risks to patients and worked through five examples. They show how the risk of an appointment should shape how it gets into the App, not the other way round.

Showing what it could look like

Talk about appointment data gets abstract quickly. We built a toolkit of NHS App prototypes and a set of appointment journey types so people could see what an appointment from their own service might look like to a patient.

In sessions with providers and programme teams, this helped move conversations from systems to patients. It gave everyone a shared way to talk about journeys, and made it easier to spot where an appointment in the App could confuse someone.

Deciding what is worth doing

With 33 areas on the table, we needed a fair way to choose between them. So we compared each one against the same questions:

• does it fit local and national priorities?
• are the providers ready?
• are the data and consent in place?
• how does the booking work?
• can commissioners help make it happen?
• is it clinically safe?
• who might be left out?
• how many people would it help?

It meant we could explain our choices to partners and the programme. It's how we got from a long list to blood tests (phlebotomy) at community diagnostic centres, and anyone choosing the next priority can reuse it.

Making the case for each appointment

Our earlier logic model linked our work to benefits for patients and the wider system. We carried that through into benefit stories. For each priority they set out:

• the value we expected
• the evidence we held
• what was still unproven
• what to measure next

Being upfront about what we didn't know yet made the case easier to trust. For phlebotomy, our starting guess was fewer missed appointments and less admin for services. Testing it was how we'd find out.

A proof of concept with a purpose

In March we said we needed to work out what a proof of concept should be. Not necessarily working software, but something specific enough to show our approach could work in one real place. By the end of the summer we knew what we wanted to test. We thought the quickest way to learn more was to build something, and we wanted to get on with it.

We chose phlebotomy at community diagnostic centres in HNY as the first area. It's high volume, uses one of the simpler booking patterns and has likely benefits for patients and services. Read only community nursing appointments were a second option, depending on what existing supplier rollouts already cover.

The intention was a proof of concept using test data, then a private beta with a closed group of patients.

Getting providers and suppliers connected is slow, and it's often hard to see how it's going. So alongside the proof of concept we built an early dashboard showing where each provider and supplier is up to. It could be useful for NHS England integrations more widely.

What we learned

Going broad was how we found out where to narrow. The 33 areas came down to a handful of real opportunities, but it took the breadth to see that, and it came late in the time we had.

Plans elsewhere in the system can change the size of an opportunity quickly. As it became clear that existing supplier rollouts would cover a large part of community care in HNY, it changed what was left to do there.

We'd started with 16 assumptions. The work answered about half of them. The rest, mostly about whether patients want this and understand it, needed people using something real.

What we would do next

One option would be to start from what's already coming. One supplier's route for community services into the App is under way. The next step would be to work out which community appointments it won't reach, such as services on other systems and booking patterns the App doesn't yet support. That gap can be mapped and measured, and it's where a team looking across the whole system would add most value.

We'd previously described the pattern this work set out to avoid: solving for some appointments, in some settings, some of the time. Getting one appointment type working in one place is a good start. The harder question: how does a person see and manage all of their NHS appointments in one place? That still needs someone looking across the whole system.

My thanks to the great team of people I worked with, especially Aditi, Joni and Ian.