RAD-SMART is an assistive operations layer for radiotherapy. It predicts machine-minutes, builds a plan in which hard rules cannot be broken, tests it in a digital twin, and explains and communicates it through Sarvam AI. People approve every change.

The department's own records show the pain. One patient in ten waits more than 109 minutes, and 22% are treated more than an hour late. The wait builds through the day: about 19 minutes in the morning, about 66 in the evening. A patient on a 25-session course who waits an extra hour a day loses about 25 hours, and so does the family member who comes along. Most Indian centres have one machine, so one bad day affects everyone.

This is not appointment booking; it is sharing out machine time. The department confirmed its rules on 21 September and 24 October: new starts finish before 17:00, complex cases between 10:00 and 17:00, the blood-irradiation slot at 13:30, hospice (MHRC) patients in the 16:00–17:00 slots to catch the 17:00 bus, public-transport patients home by 21:00, one breast board and one breath-hold unit shared with the CT room, and one standing slot for each course. Every rule is a setting the department can change, not code.

Four steps. Machine learning predicts each session's minutes, starting from the department's own estimate table; in the prototype it is off by 2.1 minutes on average, against 2.6 for plain averages. An optimiser gives each course a new-start slot and one standing slot, and it cannot break a hard rule; a separate checker re-verifies every plan. A digital twin, calibrated on the department's records, tests each plan before use. Sarvam AI translates each message into the patient's language, reads it aloud, and explains a proposed time in plain words; a technologist sends it on WhatsApp. It never sees names or phone numbers, and it never makes a scheduling decision.

We scored five designs on seven weighted criteria. Fixed templates are simple but cannot absorb variation or faults. An LLM alone cannot guarantee that no new start runs past 17:00. Optimisation alone guarantees rules but cannot learn or recover live. Deep reinforcement learning is opaque and needs huge data. The hybrid predicts, optimises, simulates and explains, and it can be built in layers: the optimiser with average tables works from week one.

RAD-SMART runs inside CARE, the Open Healthcare Network's open-source hospital information system, as a plugin. The doctor starts from the patient's visit page, fills in the prescription and treatment days, and ticks the priority checklist. RAD-SMART proposes a first-day slot before 17:00 and one standing slot, free on every treatment date, which the patient keeps until the course ends. The technologist records arrival, room in and out, and machine status. When the machine breaks down, RAD-SMART proposes the response under the department's rules, with messages drafted in each patient's language, and a technologist or doctor approves it. The same pattern works with the hospital's own EMR.

The patient's side is built. Each patient gets one private link, sent once on WhatsApp from the department's own number. The page needs no app and no login, shows the first name only, and is in the patient's language with a switch to English: today's time to come, the next treatment days, the department's messages with a voice note, and on treatment days a QR code and six letters for reception. Four buttons let the patient say they are on the way, late, cannot come, or would rather come in the morning, afternoon or evening; staff decide. After every approval RAD-SMART drafts each affected patient's message from fixed English templates. Sarvam Translate puts it into Kannada, Malayalam, Hindi or Konkani (Sarvam has no Tulu model, so Tulu speakers get Kannada, and staff can record a Tulu voice note), Sarvam Bulbul reads it aloud, and a technologist checks it and presses send in WhatsApp. A translation that drops or changes a time is never used: the patient gets the English text.

Since Round 1 on 19 September we built the department's two sets of written answers into the engine: one standing daily time per course, free on every treatment date; new patients start and finish before 17:00, with 150 minutes kept free for future new starts; their breakdown rule (up to 60 minutes everyone is treated the same day, longer and patients still at home are told not to travel); and roles (only a doctor enters or approves a course). On 24 October the engine became a working application inside CARE, and on 25 October we added the Sarvam AI layer, the patient phone page, QR check-in and plain-language explanations, with automated safety tests. On 26 October it went live on Microsoft Azure: one Docker image built on CARE's production image, with a managed PostgreSQL database and HTTPS, deployed by one script, and open for anyone to try with synthetic patients. On 27 October, from clinical feedback, patients choose a part of the day (morning, afternoon or evening) and RAD-SMART offers a better time as slots free up, which staff agree with the patient; and the day board keeps the plan as an order, showing whom to call next and letting a technologist take a ready patient in when another is late, with the reason recorded. 45 automated tests now pass. Testing found and fixed four problems: Kannada suffixes on times that the first time check missed, Konkani turning "the next working day" into "next week" (messages now name the date), an explanation using the proposed rather than the current time, and one ambiguous patient button. Not yet built: automatic WhatsApp sending through the Business API, spoken replies, Excel and prescription import, plain-language rule editing, and an oncology information system feed.

Two datasets, kept apart. On the department's own 55 recorded days, the wait that one patient in ten exceeds falls from 108.6 to 70.4 minutes when the same day sizes are re-planned by RAD-SMART in the digital twin, and the share treated more than an hour late from 22% to 6%. The busiest days gain the most: 130 to 70 minutes. On 12 synthetic weeks where each course keeps one standing slot, it falls from 82 to 49 minutes. This is a replay in the twin, not a live trial; the pilot measures it on real days. The price is real: the evening runs about two hours later, still inside the department's hours, and one new patient in five starts a little later, by less than half a day on average.

The department's breakdown rules of 24 October are built in. A breakdown lasts 15 minutes to 48 hours. Up to 60 minutes, nobody is sent home and everyone is treated with overtime. Longer than that, RAD-SMART sends back only as many patients as the downtime needs, those who have not left home first, and the missed session is added at the end of the course. New starts wait for the machine, and patients at home are told to postpone travel. In the 150-minute test, one patient who had not left home was sent back, two new starts moved to the next day, and everyone else was treated the same day. Compared with keeping the plan unchanged, the typical wait falls from 104 to 39 minutes. After a 45-minute breakdown it falls from 53 to 37 minutes and nobody is sent home.

We tested the language step with the app's own settings, on synthetic text. Seven message templates with four sets of times each, in Kannada, Malayalam, Hindi and Konkani: all 112 translations kept every clock time, so none would have fallen back to English. Translating back into English and comparing with the source gave a median chrF of 76 to 80 by language; this is a rough check of meaning, so native speakers at the department will rate every template before the pilot. For 20 synthetic plans, Sarvam-105B's plain-words explanation passed the time check every time, with no invented time. Session-length prediction is off by 2.15 minutes on average on held-out synthetic sessions. Safety: a person approves every course and every change; hard rules are constraints in the optimiser and are re-checked by an independent checker; the language models never schedule, a translation that changes a time is discarded and an explanation that invents one is rejected; no names, hospital numbers or phone numbers are sent to Sarvam; and if Sarvam is unreachable, messages go in English and staff see the engine's own reasons. The pilot follows the DPDP Act with patient consent for messaging and goes to the ethics committee.

The pilot target, at least 25% lower than the 109 minutes in the records, is set below the prototype's results (35% on the department's own days replayed, 40% over 12 synthetic weeks), because the twin is not perfect and the real gain depends on how much of today's waiting comes from scheduling. We also track lateness over an hour (22% today, aim 10% or less), punctuality, overtime and throughput. Stopping rule: if a hard rule is broken in practice, or balancing measures worsen for two weeks, the department reverts to manual mode. Budget about ₹2–3 lakh: a server, three tablets, a QR printer and messaging. The application already runs live on Microsoft Azure as one Docker image; the pilot runs the same image with demonstration mode off, on the hospital's server or in an Indian Azure region, so moving from the demonstration to the pilot is configuration, not new code. Team: Dr Akshay Dinesan (team leader, doctor partner), Abhinand T M (technical lead), P S Raghotham Rao (lead engineer), Dr Shirley Lewis Salins and Dr Umesh Velu (doctor partners).