The Problem

Not all GP consultations take the same amount of time.

Depending on the nature of a patient's health concern, a consultation might require 15 minutes or 20 minutes. That distinction sounds minor. At scale, across hundreds of appointments a day, it has a significant impact on how efficiently a GP's time can be used. D

octor Care Anywhere's scheduling system had been built around 20 minute slots only. Introducing 15 minute appointments alongside them, without creating gaps, disruption or an unmanageable rota, required solving a problem that was more complex than it appeared.

Getting it wrong would mean lost capacity, wasted GP time and a worse experience for patients.

The Challenge

Two appointment lengths, one constrained system

Microsoft Dynamics 365 with Universal Resource Scheduling was the backbone of Doctor Care Anywhere's appointment management. Every GP was modelled as a bookable resource within it, with working hours, roles and service groups all configured inside the platform.

The problem was that Dynamics was configured around a single Fulfillment Preference: 20 minute intervals starting on the hour. Introducing 15 minute slots alongside 20 minute ones was not straightforward. Dynamics could not easily mix slot lengths within a single service group, and the business had a firm constraint to maintain only one.

Performance limitations that ruled out simple fixes

Dynamics also had known performance constraints when queried at volume. The existing booking experience was already slower than ideal. Any solution that added further load to Dynamics queries would make that worse, not better.

A simple integration approach, querying Dynamics directly for every scheduling decision, was not viable. The solution needed to be smarter about where the scheduling logic lived.

Demand that was anything but even

Patient bookings skewed heavily toward early morning slots, with significant peaks at the start of the day. Any scheduling model that assumed even demand distribution would fail in practice. The solution needed to be stress-tested against real patterns, not theoretical averages.

A clear target to meet

The business defined success precisely: 90% appointment utilisation with no more than 5% wastage. Wastage meaning scheduling gaps too small to fill with either a 15 or 20 minute appointment. Hitting those numbers required rigorous modelling, not estimation.

The Solution

Solving a scheduling problem of this complexity required more than data analysis. The Curve worked closely with subject matter experts, business analysts and service owners within Doctor Care Anywhere to map out how the booking process needed to work end to end.

This meant understanding the operational realities of the business, the constraints of the existing infrastructure and the experience patients expected. That groundwork underpinned the foundation everything else was built on.

From there, The Curve analysed Doctor Care Anywhere’s historical booking data and designed a dynamic scheduling algorithm to handle mixed appointment lengths efficiently. 

The scheduling logic was engineered as a dedicated layer between the patient booking interface and Microsoft Dynamics, working with the existing system’s constraints rather than against them.

The approach was modelled against real data across multiple scenarios, giving the business clear evidence of what it would deliver before any production work began.

Our Approach

Working closely with subject matter experts and service owners, we analysed historical booking data and designed a dynamic scheduling algorithm that worked within the constraints of the existing Dynamics infrastructure rather than replacing it.

Understanding Dynamics before designing around it

The starting point was a thorough understanding of how Dynamics was configured and where its limits were. Each GP was a bookable resource with defined working hours. Service groups governed how patients were matched to doctors. Fulfillment Preferences controlled slot intervals.

The single service group constraint, combined with Dynamics' querying speed, shaped every subsequent design decision. Rather than treating Dynamics as a problem to solve later, The Curve treated it as a fixed constraint to design around from the outset.

Putting the scheduling logic where it belonged

The key architectural decision was to place the scheduling intelligence in a dedicated Booking API layer, sitting between the patient-facing booking form and Dynamics. Dynamics remained the source of truth for GP availability and confirmed bookings. But the logic determining which slot type to offer, and how to handle concurrent patient sessions, lived in the API layer where it could operate at speed.

This meant Dynamics was queried only for what it needed to provide, avoiding the performance degradation that a more direct approach would have caused.

Designing the algorithm

Three scheduling approaches were evaluated and simulated against real booking data:

  • Alternating hours, pre-assigning each hour to either 15 or 20 minute slots

  • Alternating by doctor, assigning individual GPs to one slot length

  • Dynamic designation, where the first booking against a GP for a given hour determines the slot length for that entire hour

The dynamic approach consistently outperformed the alternatives. Unlike fixed models, it did not depend on the 15/20 split being precisely right and did not create the hour-to-hour GP demand fluctuations that would have made rota management impractical.

Handling concurrency

A practical edge case needed to be solved: two patients browsing available slots at the same time, both being offered the same free hour. Without locking, both could attempt to book conflicting appointment types.

The solution incorporated slot designation locking at the API layer, temporarily assigning a slot type when it was offered to a browsing patient and releasing it if the session expired or the patient moved on. This kept the booking experience clean without placing any additional burden on Dynamics.

The Results

01.

Utilisation and wastage targets met in simulation: The dynamic scheduling model achieved 90% utilisation with less than 5% wastage in simulation across real booking data.

02.

A solution that respected the existing system: By designing around Dynamics rather than attempting to reconfigure it, the solution avoided the risk and cost of unpicking a system that was already managing thousands of bookings.

03.

Evidence to move forward with confidence: The proof of concept gave Doctor Care Anywhere a data-backed view of what the solution would deliver before any production work began.

Appointment scheduling at scale is one of those problems that looks straightforward until you look closely. By bringing data science and deep system knowledge to a complex operational challenge, The Curve gave Doctor Care Anywhere both a validated solution and the confidence to build on it. The right answer was not a bigger system or a costly overhaul. It was a smarter approach, built around the infrastructure already in place.

Their Thoughts

We had a genuinely complex scheduling problem and The Curve gave us a way through it.

They understood our systems deeply, designed something that worked within our constraints and gave us the data to move forward with confidence.

The analysis was thorough and the approach was pragmatic throughout.

Doctor Care Anywhere