Healthcare & Life Sciences
Appointment No-Show Prediction API
An empty slot costs the same as a used one. The question is not who deserves an appointment — it is which slots are likely to go unused, and what you can do about it in advance.
- Practice management software
- Scheduling platforms
- Hospital operations teams
- Telehealth providers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Outpatient no-show rates sit in the double digits across most specialties, and the cost is twofold: clinician time that cannot be recovered, and a waiting list that moves more slowly than the capacity on paper suggests. Scheduling software usually treats every booking as equally likely to be kept, which means the only lever available is a blanket reminder sent to everyone.
The predictive signal is real and mostly mundane. Lead time between booking and appointment is the single strongest factor in most datasets. Prior attendance history, time of day, whether the appointment was rescheduled, weather on the day, and whether a reminder was acknowledged all contribute. None of this is exotic modelling; it is a well-specified tabular problem on data the practice already holds.
The part that requires care is what the prediction is used for. A no-show model trained on historical attendance will correlate with deprivation, with distance from the site, with shift work and with transport access — because those things genuinely cause missed appointments. Used to add capacity, that is useful. Used to decide who gets seen, it quietly penalises the patients who struggle most, and we will not build that.
Who buys this
Practice management software, Scheduling platforms, Hospital operations teams, Telehealth providers
What the API returns
What comes back
- Per-appointment no-show and late-cancellation probability
- Contributing factors for each prediction, with direction and magnitude
- Slot-level and clinic-level expected attendance for a session
- Recommended overbooking level per session, with the double-booking risk stated
- Reminder targeting: which patients a reminder is likely to change the behaviour of
- Support-need flags — transport, interpreter, out-of-hours — as offers of help, not risk scores
- Waiting-list fill candidates ranked by how quickly they can realistically attend
- Fairness reporting: predicted and realised no-show rates by cohort, published as a standing output
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/appointments/score | No-show probability for one or many appointments |
| GET | /v1/sessions/{id}/expected-attendance | Expected attendance for a clinic session |
| GET | /v1/sessions/{id}/overbooking | Recommended overbooking with risk bounds |
| POST | /v1/reminders/target | Which appointments a reminder is likely to affect |
| POST | /v1/waiting-list/fill | Ranked candidates to fill a released slot |
| GET | /v1/fairness/report | Predicted versus realised rates by cohort |
Request and response
illustrativeRequest
{
"appointments": [
{
"appointment_id": "apt_55120",
"specialty": "ophthalmology",
"booked_at": "2026-08-14T09:12:00Z",
"scheduled_for": "2026-11-03T08:30:00Z",
"modality": "in_person",
"rescheduled_count": 1,
"prior_attendance": { "kept": 6, "missed": 2 }
}
],
"include_factors": true
}Response
{
"scored_at": "2026-10-22T07:40:00Z",
"model_version": "noshow-2026.09",
"appointments": [
{
"appointment_id": "apt_55120",
"no_show_probability": 0.31,
"late_cancellation_probability": 0.12,
"band": "elevated",
"factors": [
{ "factor": "lead_time_81_days", "direction": "increases", "weight": 0.42 },
{ "factor": "prior_missed_2_of_8", "direction": "increases", "weight": 0.21 },
{ "factor": "first_slot_of_day", "direction": "increases", "weight": 0.11 },
{ "factor": "reminder_acknowledged_previously", "direction": "decreases", "weight": 0.09 }
],
"suggested_actions": [
{ "action": "send_confirmation_request", "expected_effect": 0.07 },
{ "action": "offer_transport_information", "expected_effect": 0.03 }
],
"permitted_uses": ["capacity_planning", "reminder_targeting", "support_offer"],
"prohibited_uses": ["appointment_denial", "deprioritisation"]
}
]
}Where the data comes from
| Your appointment history | Booked, attended, cancelled and missed appointments — the core training set, and it must be your own, because no-show behaviour does not transfer between sites |
| Scheduling metadata | Booking channel, lead time, reschedule history, clinic and clinician, slot position in the session |
| Reminder and communication logs | Which reminders were sent, through which channel, and whether they were acknowledged — this is what makes intervention targeting possible rather than guesswork |
| Weather and public transport disruption | Published feeds; both measurably affect same-day attendance for in-person appointments |
| Local calendars | School holidays, public holidays and major local events shift attendance patterns in ways a generic model misses |
| Deliberately excluded fields | We do not use ethnicity, religion, immigration status or payer status as model inputs. Some are unlawful to use this way, and the rest invite exactly the harm this design is meant to avoid |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Gradient-boosted trees on tabular features, because this problem rewards clean feature engineering far more than model novelty
- Lead time modelled as a continuous curve rather than buckets — the relationship is strong and distinctly non-linear
- Separate models for no-show and late cancellation, since the operational response to each is different
- Calibration checked per specialty and per clinic; a probability that is well calibrated overall can be badly wrong for one department
- Uplift modelling for reminders, so targeting identifies patients whose behaviour changes rather than those simply most likely to miss
- Standing fairness evaluation across available cohorts, including geography and deprivation proxies, with results reported to you whether or not they are flattering
- A documented permitted-use field on every response, and contractual scope limits in the build agreement
- Monitoring for calibration drift after any change to your booking flow, which reliably breaks these models
What it changes for the business
Recovered capacity
Session-level attendance forecasts let overbooking be set deliberately, with the double-booking risk quantified rather than guessed.
Reminders that are worth sending
Targeting by expected effect reduces message volume while concentrating it where behaviour actually changes.
Faster waiting lists
Released slots get filled from candidates who can realistically attend at short notice.
Equity visible rather than assumed
Cohort reporting is a standing output, so a drift toward penalising disadvantaged patients is detectable instead of invisible.
How it fits into your product
How it embeds
- Deployed inside your own environment; appointment and attendance records do not need to leave it
- Batch scoring overnight for the coming weeks, plus a synchronous endpoint for same-day rescheduling decisions
- Webhooks into your reminder and messaging system for targeted outreach
- Session-level outputs for the operational dashboards your schedulers already use
- The fairness report as a scheduled artefact your governance or clinical audit group receives directly
- Role-scoped access, so individual probabilities are visible to the teams arranging care and not as a label on the patient record
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can this be used to deprioritise patients who are likely to miss appointments?
No, and we would decline that engagement. No-show models encode socioeconomic reality — shift work, transport cost, caring responsibilities, distance from the site — so using one to allocate access means withdrawing care from the people least able to absorb it. We build this to add capacity: overbooking, better reminders, transport and interpreter support, faster waiting-list fill. If the intended deployment is denial, downgrading or discharge, that is not a build we will take on, and we would rather say so at the first conversation than at handover.
Does the model use protected characteristics?
No. Ethnicity, religion, immigration status and payer status are excluded as inputs. That does not make the model neutral — geography and lead time carry some of the same information — which is precisely why cohort fairness reporting is a built-in output rather than an optional extra.
How accurate is it in practice?
Accuracy depends almost entirely on how much attendance history you hold and how consistently it is recorded. Twelve to twenty-four months of clean history on a reasonable volume gives something useful. We measure on a held-out period from your own data during the prototype and report what it actually achieved, including where calibration is weak. We will not quote a figure before seeing your data.
Does it decide anything clinically?
No. It says nothing about urgency, acuity or clinical need, and it must not be mixed into triage. A patient with a high no-show probability and an urgent clinical need is an urgent patient who needs help attending.
What if the model turns out not to beat a simple rule?
Then we tell you. For some clinics a lead-time threshold plus prior attendance captures most of the available signal, and in that case the honest recommendation is the simple rule, built cheaply and monitored. That outcome is a legitimate result of the prototype phase.
Related blueprints
Hospital Capacity Forecasting API
Forecasts of bed occupancy, staffing requirement and service demand by unit, with prediction intervals rather than point numbers.
Provider Directory Intelligence API
Clinician and facility directory data with specialties, locations, accepted coverage and a measured accuracy score per record.
Medical Document Extraction API
Structured fields pulled from clinical notes, lab reports and referral letters, returned with per-field confidence for review.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.