Waiting Lists: The Problem Isn't Capacity, It's the Pipeline

On 21 July 2026 the first Agenas Bulletin (Italy’s national agency for regional healthcare services) on waiting-list monitoring compared the first half of 2026 with the same period in 2025, province by province. The picture for Trentino-Alto Adige remains broadly positive, but it splits in two: on first specialist consultations, the Autonomous Province of Trento worsens, from 63.1% to 54.7% of services delivered within the maximum time limits — alongside Abruzzo, Sicily and Sardinia — while Bolzano rises from 72.7% to 78.5%, though still below the 80% threshold that national monitoring uses as its benchmark. On diagnostic tests Trento improves, from 76.7% to 77.0%, but it too remains below that threshold (l’Adige, 21 July 2026). The figure measures an outcome; it does not explain its causes — it says nothing about how the organisations involved actually work, or which factors weigh on each territory. But it raises the general question that holds this article together — one that applies to any booking system, not to any single organisation: what if part of the problem were not how much capacity there is, but how much of it gets lost along the way?

The typical pipeline: four links, three leaks

A necessary premise: we do not know from the inside the pipeline of any of the organisations named in the monitoring — every structure has its own integrations, its own remedies and its own strengths. What follows is the recurring model of a booking pathway organised around separate systems, and it is on this general model — not on any real organisation — that the rest of this article reasons. In this model, the chain that assigns an appointment has four links.

The doctor assigns the priority class on the referral: U (urgent, within 72 hours), B (short, within 10 days), D (deferred, within 30 days for consultations and 60 for tests) or P (planned, within 120 days) — the classes with which the National Waiting List Governance Plan (PNGLA) 2019-2021 measures the monitored basket of 14 first specialist consultations and 22 diagnostic tests. CUP (the Italian single booking centre), or the call centre standing in for it, assigns the first free slot on schedules drawn up weeks or months earlier. Where systems remain separate, every department and every site sees only its own schedule: CUP, the clinical record and staff rostering do not talk to one another. The patient, if they turn up, is seen.

In a chain built this way, capacity is lost at three points — and it is capacity already paid for: the room is open, the doctor is on shift.

• Unforeseen demand. Spikes — seasonal, epidemic, triggered by an event — are spotted only once they are already in the corridor: schedules open up in an emergency, not before the spike arrives.
• Slots not reassigned. A cancellation 48 hours before an appointment is rarely reallocated: most facilities have no active reserve list that can be checked in real time.
• Recurring no-shows. The literature shows widely varying rates, from a few percentage points to over 20-30% depending on specialty and area. For the simulation in this article we assume, and state openly, a 10% loss of slots between missed appointments and cancellations never reallocated.

None of these three points is a matter of goodwill. CUP and staff work well with the information they have: the limit is that this information only captures their own slice of the process, never the whole. The cost of this separation is not visible in any single local indicator: it shows up downstream, in the monthly aggregate that ends up in bulletins like the Agenas one — the same metric by which public healthcare is measured from the outside, month after month.

Why “more software” hasn’t solved it

Healthcare organisations are not short of tools. They have management systems, advanced CUP platforms, reporting dashboards — and these often work well, each within its own perimeter. The problem has never been any single tool: it is the architecture. Every vertical system captures its own slice — bookings, staff rostering, delivered-care history — and does so better than it did yesterday. But it remains a slice.

Adding yet another application, however sophisticated, adds a new silo: one more snapshot, not the overall view that would allow a spike to be foreseen before it turns into a full corridor. One more dashboard shows the problem more clearly; it doesn’t solve it, because the problem lives between the systems, not inside any one of them. The problem is not solved with more data or more dashboards. What’s needed is a layer that sits above the existing systems — that reads all of them together — not one more application bolted on alongside them, competing for the same attention from staff.

Five layers, not one more application

CSIDIA tackles the same chain — referral, booking, schedule, delivery — with a different architecture, not with one more application: the same data → ontology → AI agents → human operator → action pipeline described in general terms on Operational AI, applied here to waiting lists.

Data. Existing sources connect in read-only mode, from day one: CUP bookings, the schedule register, staff rostering, delivered-care history, cancellations and no-shows, Accident & Emergency (A&E) attendances — useful for reading induced demand. No big bang, no replacement of the systems the organisation already uses: the management systems stay exactly where they are, CUP included — the layer that sees them all together is added on top.

Ontology. This is the layer that makes the difference, and it’s worth explaining properly. A database describes an event as disconnected rows in different tables: a cancellation is a row that changes status in a bookings table. The ontology describes it as an operational object: a cardiology slot tomorrow at 3pm in Rovereto, compatible with class B, with 41 patients on the list who could take it. Service, Slot, Schedule, Site, Doctor, Priority class, Booking become objects related to one another, not disconnected tables — and it is this representation that makes the data actionable by an agent, rather than merely viewable by a person. Personal data enters minimised and pseudonymised: the ontology reasons about slots and queues, not clinical records.

AI agents. These are not chatbots. They are processes that observe the ontology, calculate and propose actions. On waiting lists there are four: no-show recall (who is at risk of not turning up, contacted in advance), cancellation backfilling (who on the list can take the slot that has just freed up), demand forecasting (which schedules risk becoming saturated in three weeks’ time) and cross-site rebalancing (where to move a session to absorb a spike already forecast) — the detail, with figures, in the next section.

Human operator. Autonomy thresholds are explicit, not implicit. A low-impact action — a reminder, a reallocation already accepted by the patient — runs on its own. A critical action — opening an extraordinary schedule, moving a session between sites — arrives as a proposal and is approved by whoever holds organisational responsibility. Clinical choices are never delegated to the AI: agents propose, clinicians decide, and every critical action passes through an operator.

Action. The approved decision goes back onto the real schedule — write-back — and the outcome feeds the model again: the system learns from its own operations, not from a static archive updated once a year.

This is, broadly speaking, the ontology-plus-agents paradigm made famous at enterprise scale by platforms such as Palantir Foundry — a paradigm analogy, not a product comparison or an affiliation — brought down to the scale of an Italian healthcare organisation, with data that stays in Europe and the same caution, described above, over what an agent can do on its own and what it cannot.

The four levers, in the order they switch on

The four levers don’t switch on all at once: they follow the timeline of ignition, not that of a traditional IT project — where the first results usually arrive after months of preliminary analysis, not within the first few weeks. It’s the same pattern we describe, with other use cases, on the page dedicated to healthcare.

Week 1 — ignition. Connectors are linked to the sources, the base ontology is built on the schedules already in use — not a separate test environment — and the first use case goes live. This is not a vague claim: operational on your own data within 7 days, first use case live from week one.

Months 1-2 — quick win. The first two levers switch on. No-show recall sends reminders and requests confirmation across multiple channels; if the patient does not confirm or cancels, the agent frees the slot in advance instead of finding it empty in the waiting room — channels, tone and contact rules remain a choice made by staff. Cancellation backfilling checks, within seconds of a slot freeing up, the reserve list compatible by priority, site and stated availability; ambiguous cases stay with staff. The point worth remembering: these first percentage points require no new staff and no new budget. They are slots already paid for that stop going to waste.

Months 3-6 — forecasting. With consolidated history, a third agent estimates attendances and requests days or weeks ahead, based on seasonality and events, and proposes rebalancing sessions between sites and clinics — always as a proposal a manager approves, never as an automatic move. This is the lever that takes longest, because it needs the most history: before three months there isn’t enough data to tell a real spike from statistical noise. Schedules open before the spike, not during it.

Months 7-12 — steady state. Continuous optimisation of pathways and priorities, always with human validation. From this point on, all four levers stay active together: they don’t switch each other off, they add up. In the simulated scenario — the word matters, it is a simulation — the 80% Agenas threshold is crossed around month eight.

The numbers behind a declared simulation

The scenario that follows is an illustrative simulation, not measured data: the assumptions are stated openly, the model is available on request, and the label stays visible on every chart and table. The starting point is a typical facility with 100 bookable slots per week in the monitored basket, 10% lost to no-shows and cancellations never reallocated — so 90 visits delivered per week — an average wait of 60 days and 68% of bookings within the maximum time limits. These are hypothetical but realistic figures: they get recalibrated against the facility’s real data, once available.

In the 12-month scenario, visits delivered rise from 90 to 108 per week for every 100 slots (+20%), the average wait falls from 60 to 47 days, and compliance with maximum time limits rises from 68% to 81% — above the 80% Agenas threshold. The most concrete number for the reader: roughly 630 additional visits delivered in the first year, for every 100 weekly slots at the starting point.

The +20% is the steady-state scenario, not a promise: the real result depends on the facility’s no-show baseline, the share of cancellations that can be reallocated, and its capacity to open additional sessions during spikes. The claim that holds up is this: first results within a few weeks, a scenario of up to +20% after 12 months.

Governance: traceability, not promises

Every proposal from an agent is explainable and logged: who approved what, when, on which data. This is not a technical detail: it is the condition under which a medical director can sign off on a decision without having to trust a black box.

Data is processed in Europe and remains the property of the organisation, not of the platform provider — your data stays yours, always. Processing is GDPR by design, the platform meets NIS2 cybersecurity requirements, and — a point worth repeating because it is the most sensitive one — every clinical decision remains with whoever holds responsibility for it: the AI optimises logistics and capacity, it does not decide who has the right to jump the queue. Systems that touch access to essential services may fall within the categories governed by the AI Act: one more reason to build traceability in from day one, rather than chase it afterwards — the same logic with which we treat a corporate AI policy as a legal obligation, not an optional choice.

Architecturally, the platform runs in two modes, never in a generic public cloud: on-premise, installed in the client’s own environment, or in a dedicated CSIDIA cloud — an environment reserved for a single client, accessed via dedicated VPN, with a data centre in Italy, in guarded premises.

The first step

The first step is not a multi-year project: it is one real use case, on data the organisation already holds, live from the first week — usually no-show recall or cancellation backfilling, where the gain shows fastest. From there, it’s a decision whether and how to extend into demand forecasting and cross-site rebalancing, with the same caution with which the process began.

Want to see what these numbers would say about your own organisation’s data? In July, the first 30-minute session with one of our experts is free as part of a promotion: book it here.

The questions we always get asked

• Do you replace CUP? No: we sit on top of it, CUP remains the system staff use every day.
• Do you need a multi-year project? No: 7 days for the first use case to go live.
• What about privacy? Data minimised, pseudonymised, processed in Europe.
• Does the AI decide who jumps the queue? No: it optimises logistics, clinical priority stays with the doctor.
• What if the historical data is messy? The first use case also helps surface it and correct it.

Minimum glossary

• CUP — the Italian single booking centre: the system (and call centre) that assigns appointments.
• Priority classes U/B/D/P — PNGLA maximum times: urgent 72 hours, short 10 days, deferred 30 days for consultations/60 for tests, planned 120 days.
• No-show — a patient who does not turn up without cancelling: the slot is lost.
• Data fabric — an integration layer that connects existing data sources without replacing them.
• Ontology — a semantic model that represents the organisation as operational objects and relationships (slots, schedules, sites, priorities), making the data actionable.
• AI agent — a process that observes data through the ontology, calculates and proposes (or executes, within approved thresholds) operational actions.
• Decision intelligence — prediction and simulation supporting high-impact decisions.
• Human-in-the-loop — every critical action requires operator approval; clinical choices remain with clinicians.
• Agenas 80% threshold — the minimum share of bookings delivered within maximum time limits used in national monitoring.

Sources

• l’Adige — Healthcare in Trentino loses ground: waiting lists worsen (21 July 2026)
• Agenas — Waiting List Bulletin, Issue 0 (data as of 30 June 2026), with the related Agenas press release announcing the first Bulletin (21 July 2026)
• National Waiting List Governance Plan (PNGLA) 2019-2021 — basket of 14 first consultations and 22 diagnostic tests, U/B/D/P priority classes, referenced in the Agenas Bulletin cited above