Why we built our own approach
A healthcare helpline has a simple goal: help the caller get the right next step. That might be an appointment, an answer about a service, or a handover to a person.
The conversation is rarely simple. Someone may book for their mother, change the date, ask about fees, and switch languages in the same call. The AI needs to keep up without mixing up the details.
At Iksha Labs, general language models helped us get started. But we needed more control over how the system understood a request and acted on it. We began adapting smaller models for these repeated healthcare tasks.
It took us three months to get our first usable model, and six months to reach a point where we could use it in production. The work included collecting suitable examples, improving the model, testing difficult cases, and connecting it to checks around the booking workflow.
That experience shaped the way we now approach custom models for healthcare. Customer and project names are masked throughout this article; conversation examples are illustrative.
What healthcare teams can gain
The value of a custom model goes beyond a better test score. Designed properly, it can give healthcare teams more control over safety, patient information, response time, and operating cost.
Safer actions
The model identifies what the caller wants. The workflow checks whether the action is allowed. It can require clarification, verify a booking before confirming it, and hand over requests outside its scope. Clinical advice remains outside an appointment model’s job.
More privacy control
A task-specific model can receive only the details needed for that task. Hosting in an organisation’s chosen environment can reduce external data sharing. Recordings, training data, and logs still need access limits and retention rules.
Stronger security boundaries
The model can work with a limited set of tools. A booking request should not open access to unrelated patient records. Permissions and checks stay in application code, so the model cannot simply talk its way around them.
Faster responses
A smaller model can focus on a short, repeated task. In one booking experiment, the interpretation step took a median of 362 milliseconds. The full conversation also depends on speech recognition, network delay, and voice playback.
Lower operating costs
A smaller model can handle routine requests while larger models or people handle exceptions. At suitable volume, this can lower processing costs. The useful measure is cost per correctly completed booking, including hosting, speech services, maintenance, and human review.
Better multilingual access
Training on relevant language examples can help the system preserve names, relationships, and preferences when callers switch languages. Each supported language still needs its own tests and listening review.
These benefits come from the model and the system around it. A small model alone does not guarantee safety, privacy, or savings.
Three months to usable. Six months to production-ready.
Month 3: our first usable model
We had a model we could work with and evaluate on the target task. That gave us something concrete to improve: we could look at its answers, identify mistakes, and build better examples around them.
“Usable” was an early milestone. It did not mean every difficult conversation was solved or that the model was ready to act on its own.
Month 6: a model we could use in production
It took six months in total to reach this point. The journey included work on data coverage, consistent labels, model behaviour, evaluation, and workflow checks.
Being able to use a model in production means defining the tasks it may handle, how its output is checked, and when another model or a person takes over. A model prepared for appointment interpretation has not thereby been validated for clinical decisions.
The time mattered because healthcare conversations contain exceptions. Training a model is one step. Making its output useful inside a real workflow takes additional work.
The problems were ordinary conversations
Three recurring problems explain why we took this approach.
| What a caller says | What the system needs to understand |
|---|---|
| “Call me on Friday.” | This is a follow-up request, not an appointment booking. |
| “I’m booking for my mother.” | The caller and patient are different people. |
| “Actually, make it next week.” | Update the earlier preference instead of keeping two conflicting dates. |
Other difficulties included missed details, uncertain names, and language switches. We also found inconsistencies in our own test labels: similar examples sometimes expected different answers.
We addressed these problems in a few clear steps:
- Define the job. Decide which details the model should capture and when it should ask for clarification.
- Collect varied examples. Include ordinary requests, corrections, family-member bookings, and language changes.
- Adapt an existing model. Teach it the recurring decisions in the workflow.
- Test unfamiliar examples. Check both improvements and new mistakes.
- Check actions in the application. Verify details and tool results before confirming success.
The model understands the request. The booking system remains responsible for the actual booking. Doctor availability, fees, and opening hours come from current sources rather than the model’s memory.
The hardest part was the data
Our research combined examples drawn from conversations, controlled internal test calls, and generated training examples.
Conversation-derived examples showed how people phrase requests. Internal calls let us test specific situations. Generated examples helped us add variations once we knew what behaviour we wanted to teach.
But more examples did not automatically mean better coverage.
If most examples show people booking for themselves, the model may struggle when someone calls for a relative. If all examples are in one language, they say little about mixed-language calls. If every request is clear, the model gets little practice with uncertainty.
This is what we mean by data distribution: the mix of situations the model sees.
We need enough common examples to reflect everyday calls, and enough difficult examples to teach the important boundaries. Rare requests needing human attention deserve dedicated tests, even when they make up a small share of traffic.
Cleaning the dataset helps remove duplicates and fix inconsistent labels. It cannot add a missing type of conversation. Getting the right data—and the right mix—was therefore central to the work.
Healthcare data also needs careful handling. Permission to access a recording does not automatically mean permission to train on it. A project needs appropriate authority for data use, limited access, removal of unnecessary identifying details, and a retention plan.
Testing must stay independent of training. Closely related examples from the same conversation should not appear on both sides. Otherwise, a good score can hide a model that has only learned familiar patterns.
Where model-building platforms fit
A category of companies now helps teams prepare data, generate examples, train smaller models, and run evaluations. distil labs is one example of this approach.
These platforms can reduce the engineering effort involved in a training pipeline. They can be useful tools in a custom-model project.
The domain questions still need answers: which conversations matter, which data may be used, and what should count as a correct response? Expanding a seed dataset is helpful only if it covers the situations the healthcare workflow needs to handle.
Our experience with voice and healthcare workflows helps us work on those questions alongside model development. See production voice workflows like Krisper for how those conversations run in care settings. The challenge is obtaining suitable examples, covering the important cases, and testing the system against meaningful outcomes.
What our research showed
Our experiments demonstrated that a smaller, specialised model could perform well on a defined conversation task.
| Recorded result | What it tells us |
|---|---|
| 93.2% on a 161-turn task evaluation, compared with 90.7% for a strong general-model comparator | The custom model recorded four more correct turns on this bounded comparison. |
| 88.3% field-value accuracy on 546 internal-test turns in a separate booking experiment | The model usually captured the details expected by the test labels. |
| 13.4 percentage-point improvement over a simple workflow lookup baseline | The model added useful understanding beyond the current question alone. |
| 362 ms median processing time in the booking experiment | The interpretation step was fast in the recorded serving setup. |
These are earlier research results, not a scorecard for the final production configuration. The comparison model was evaluated separately under the corrected scoring policy. The booking dataset came from 74 internal test calls, not a patient-outcome study.
Those experiments also exposed failures. One candidate became worse at handling several details together. The booking experiment missed two escalation examples and failed a test of how well its confidence matched its accuracy. Finding these weaknesses gave us specific work to address before broader use.
The achievement was building a model, a way to measure it, and a workflow around it. The three-month and six-month milestones describe the wider development journey; the individual experiment reports capture steps along that journey.
Design your healthcare custom-model journey with Iksha Labs
A custom-model project starts with a workflow. Which decisions repeat? Where do callers get stuck? What data is available? Which requests need a human?
Iksha Labs can help turn those questions into a practical plan: suitable data, a clear model task, tests that reflect real conversations, and checks around every action. That work sits on our full healthcare agent platform stack. A controlled pilot can then measure verified bookings, correct routing, response time, human review effort, and total cost.
The approach can support appointment booking, rescheduling, service enquiries, lead qualification, and multilingual follow-up. Each use case needs its own scope and evaluation.
With our experience in voice systems, healthcare workflows, and custom-model research, we are happy to help you design your custom-model journey for healthcare solutions and workflows.
Evidence and further reading
The development timeline is Iksha Labs’ account of the wider programme. The figures summarise July–August 2026 engineering experiments. The 161-turn evaluation was consulted during development, rather than kept as an untouched final blind test. The booking set used one annotator and included three disclosed post-training additions. No audited customer-outcome or measured cost-saving claim is made.
Further reading: distil labs’ model-building approach, NIST AI Risk Management Framework, and OWASP guidance on prompt injection. Reviewed on 6 October 2026.