Clinic triage is a risk-ranking problem, not a diagnosis problem. A useful system helps a nurse, doctor, or trained frontline worker decide who needs immediate attention, who can wait safely, and what information must be collected next. In India, that system must work across crowded outpatient departments, multilingual conversations, uneven connectivity, varied clinical protocols, and devices with limited compute.
Quantization can make an approved model smaller, faster, and cheaper to run on a clinic laptop, tablet, or edge device. It does not make a clinically weak model safe. Build the clinical workflow and evaluation plan first; optimise the model only after its baseline behaviour is understood.
Define the triage task before choosing a model
Start with a narrow, operational output. For example, the model might assign one of four dispositions:
- Emergency: immediate clinician review or referral.
- Urgent: assessment within a defined time window.
- Routine: safe queueing with escalation instructions.
- Insufficient information: collect specific missing details rather than guessing.
Avoid presenting a probability as a medical conclusion. The interface should show the recommended priority, key supporting inputs, missing information, and an explicit escalation path. A clinician must be able to override the recommendation and record why.
Write a clinical safety specification with doctors, nurses, administrators, and patient representatives. Define red-flag symptoms, age-specific rules, exclusions, referral destinations, maximum waiting times, and what happens when the model is unavailable. A triage model should be a decision-support component, not an autonomous gatekeeper.
Build an Indian, consented dataset
The highest-risk failure is often not model architecture but data that reflects one hospital, one language, or one patient population. Assemble de-identified records from the facilities where the system will operate, with documented consent and approved access controls. Useful fields may include:
- Age band, sex, pregnancy status where clinically relevant, and location.
- Presenting complaint, symptom duration, vital signs, observed signs, and comorbidities.
- Language, input channel, timestamp, facility type, and referral availability.
- Clinician-assigned triage category, subsequent diagnosis or disposition, and time to care.
Do not use downstream outcomes as a simplistic label. A patient who waited longer may have done so because the clinic was understaffed, not because the triage decision was correct. Establish a label policy, adjudicate disagreements, and preserve uncertainty where experts cannot agree.
Partition data by patient, facility, and time. Random row-level splits can leak repeated visits and produce inflated results. Hold out entire clinics or districts for external testing. Report performance by language, age, sex, pregnancy status, urban or rural setting, and facility type. If an input is unavailable in a target clinic, do not quietly impute it using information that would not exist at deployment.
For multilingual intake, define a controlled symptom vocabulary and test spelling variation, code-switching, transliteration, and local expressions. A low-resource Indic NLP workflow can help with annotation and language evaluation, but clinical terms still require review by local healthcare professionals.
Establish a transparent baseline
Before using a neural network, create a rules-based baseline and a simple statistical model. Logistic regression, a small decision tree, or gradient-boosted trees may perform well on structured vitals and symptoms while remaining easier to audit. Compare every later model with these baselines on both clinical and operational measures.
For text or voice intake, separate the pipeline into components: speech recognition or text normalisation, symptom extraction, triage scoring, and explanation. This makes errors easier to locate. Voice can improve access, but noisy clinics, accents, hearing impairment, and code-switching need dedicated testing; see this voice-agent architecture guide for relevant deployment patterns.
Use metrics that reflect harm, not just average accuracy:
- Sensitivity for emergency cases and the false-negative rate.
- Specificity and positive predictive value to measure avoidable escalation.
- Calibration, checking whether predicted risks match observed frequencies.
- Queue and referral impact, including waiting time and clinician workload.
- Subgroup performance, with confidence intervals and minimum sample sizes.
Choose thresholds with clinicians. In triage, a small loss in overall accuracy may be acceptable if it substantially reduces dangerous under-triage.
Quantize only after baseline validation
Quantization converts weights, activations, or both from floating-point values to lower-precision representations such as int8. The main options are:
- Dynamic post-training quantization: simple and useful for some CPU-based models, especially where activations are measured at runtime.
- Static post-training quantization: uses a representative calibration set to quantize activations and can improve predictable edge performance.
- Quantization-aware training (QAT): simulates quantization during training and is often the safer choice when accuracy is sensitive.
Your calibration set must resemble real deployment data: languages, symptom patterns, device conditions, and facilities. Never calibrate only on clean, English-language examples. Keep the calibration set separate from the final test set, and record the framework, operator support, tensor shapes, and rounding configuration.
Export a baseline model and a quantized candidate using the runtime intended for production, such as ONNX Runtime, TensorFlow Lite, or an approved mobile inference stack. Check more than file size:
- Accuracy and subgroup metrics before and after conversion.
- Emergency sensitivity at the selected operating threshold.
- Calibration error and confidence distributions.
- Cold-start time, median and tail latency, RAM use, battery impact, and offline behaviour.
- Reproducibility across supported CPUs, Android devices, and clinic hardware.
If quantization causes clinically meaningful regression, try QAT, per-channel weight quantization, a better calibration set, or a smaller but more suitable architecture. Do not solve the problem by silently changing labels or lowering the safety threshold.
Design the deployment and safety layer
Keep patient-identifiable data out of logs wherever possible. Encrypt data in transit and at rest, use role-based access, define retention periods, and maintain an audit trail for model version, input availability, recommendation, override, and final clinical action. Follow applicable Indian health-data, privacy, medical-device, and institutional review requirements; obtain legal and clinical review before live use.
A production system should support offline-first operation with safe synchronisation when connectivity returns. Package model and rules versions together, sign releases, and provide rollback. Add hard-coded red-flag overrides where clinically justified, but document how these rules interact with the model.
Run a silent pilot first: generate recommendations without displaying them to clinicians, then compare them with expert decisions. Follow with a supervised pilot in a small number of facilities. Train staff on limitations, escalation, and override procedures. Measure workflow effects, not just model scores.
Monitor drift and govern updates
After launch, monitor missing-input rates, language mix, referral patterns, subgroup errors, override frequency, latency, and model confidence. Investigate changes caused by seasonal disease, new protocols, altered staffing, or expansion to a different region. Set thresholds that trigger review rather than automatically retraining.
Every update should have a versioned dataset, evaluation report, clinical sign-off, security review, and rollback plan. Keep a model card describing intended use, excluded cases, known limitations, quantization method, and tested hardware. For broader deployments, principles from building AI apps for the next billion users in India are useful: minimise bandwidth, design for shared devices, and treat accessibility as a core requirement.
A practical build sequence
1. Define triage categories, red flags, exclusions, and escalation ownership.
2. Obtain approvals and build a de-identified, representative dataset.
3. Create rules-based and interpretable baselines.
4. Validate on facility- and time-held-out data with subgroup reporting.
5. Train a compact model and compare dynamic, static, and QAT options.
6. Benchmark the quantized model on actual target hardware.
7. Run silent and supervised pilots with clinician override.
8. Launch with monitoring, audit logs, incident response, and scheduled review.
The best quantized triage model is not the smallest one. It is the smallest model that preserves clinically acceptable safety, remains understandable to its users, and performs reliably in the clinics where it will actually be used.