Diabetic retinopathy (DR) is a strong use case for medical AI: retinal photographs are relatively easy to capture, early disease can be asymptomatic, and timely referral can prevent avoidable vision loss. But a model that performs well on a benchmark is not automatically ready for an Indian clinic.
Custom deep learning models for diabetic retinopathy must handle varied cameras, uneven lighting, incomplete metadata, multilingual workflows, limited connectivity, and the clinical cost of missed referable disease. The right goal is not simply a high accuracy score. It is a safe screening system that helps a health worker capture usable images, identifies patients who need review, and connects them to an ophthalmologist.
Define the clinical task before choosing a model
Start with the decision the system must support. Common tasks include:
- Imageability assessment: deciding whether a fundus image is adequate for grading.
- Binary screening: no referable DR versus referable DR.
- Severity grading: no DR, mild, moderate, severe NPDR, and proliferative DR.
- Lesion detection: locating microaneurysms, hemorrhages, exudates, or neovascularisation.
- Referral prioritisation: ranking cases for urgent specialist review.
A binary referable-DR model may be the safest first deployment for a screening camp. Full five-class grading is more demanding because neighbouring grades are difficult even for specialists to distinguish. Define the output, referral threshold, and escalation pathway with ophthalmologists before collecting training data.
For teams building their first computer-vision pipeline, this guide to building computer vision models on GitHub is useful for structuring repositories, experiments, documentation, and reproducible evaluation.
Build a representative Indian dataset
Data quality usually matters more than adding another layer to the network. A credible dataset should record, where permitted:
- Camera and lens model, resolution, field of view, and acquisition site
- Patient age range, diabetes duration, treatment status, and relevant comorbidities
- Eye laterality and whether images are macula-centred or disc-centred
- Imageability or quality grade
- DR and diabetic macular oedema labels
- Grader identity, grading protocol, adjudication process, and disagreement
- Referral outcome and, where available, specialist follow-up
Use patient-level and site-level splits. If images from the same patient or camera appear in both training and test sets, reported performance may be inflated. Keep an external test set from hospitals, districts, camera types, and patient groups not represented during training.
Public datasets such as EyePACS and Messidor can support prototyping, but they should not substitute for local validation. Indian deployment data may contain different image quality, pigmentation, disease prevalence, and referral patterns. De-identify images, minimise collected personal data, document consent and governance, and align handling with India’s Digital Personal Data Protection framework and institutional ethics requirements.
Choose an architecture that fits the workflow
EfficientNet, ResNet, ConvNeXt, and vision transformers can all be useful backbones. The practical choice depends on dataset size, image resolution, inference hardware, and whether the system must run offline. Begin with a strong pretrained baseline, then compare changes systematically rather than selecting an architecture by reputation.
Important design choices include:
- High-resolution or tiled inputs: tiny lesions can disappear after aggressive resizing.
- Multi-scale features: combine local lesion evidence with broader vascular and retinal structure.
- Attention mechanisms: help prioritise diagnostically relevant regions, but do not assume an attention map is proof of reasoning.
- Multi-task learning: jointly predict imageability, DR grade, and lesion presence when labels are reliable.
- Calibration: ensure a predicted probability corresponds reasonably to observed risk.
- Uncertainty estimation: flag borderline or unfamiliar cases for human review instead of forcing a confident label.
Preprocessing should be fixed and documented. It may include cropping the retinal field, illumination correction, colour normalisation, quality checks, and conservative augmentation. Avoid transformations that create clinically unrealistic lesions or erase subtle pathology.
Train for sensitivity, not just accuracy
DR datasets are commonly imbalanced, so overall accuracy can conceal dangerous failures. Report:
- Sensitivity and specificity at the intended referral threshold
- Area under the ROC and precision-recall curves
- Positive and negative predictive values at realistic prevalence
- Per-class recall and confusion matrices
- Quadratic weighted kappa for ordinal severity grading
- Calibration curves and performance by site, camera, and image quality
- Abstention or ungradable rates
A model with excellent sensitivity may still overwhelm a clinic with false referrals. Tune thresholds with clinicians and operations teams, based on specialist capacity and the harm of missed disease versus unnecessary review. Evaluate both eyes correctly and ensure one patient is not counted as two independent cases when estimating clinical impact.
Design explainability around clinician use
Grad-CAM, saliency maps, lesion boxes, and image-quality indicators can make review faster, but visual explanations are not a substitute for validation. Test whether clinicians can use them to detect model errors. A heatmap that highlights the wrong region may increase false confidence.
The interface should show the input image, quality status, predicted category, confidence or calibrated risk, highlighted regions, and a clear action such as repeat capture, routine review, or urgent referral. Keep the final clinical decision with an appropriately trained professional. The system should also preserve an audit trail of model version, threshold, image, output, override, and referral outcome.
Deploy for Indian healthcare conditions
Many screening programmes operate in primary health centres, mobile vans, diabetes clinics, and community camps. Design for the actual environment:
- Run a lightweight model locally when connectivity is unreliable.
- Use quantisation, pruning, or distillation only after confirming that sensitivity is preserved.
- Provide capture guidance for focus, field of view, glare, and alignment.
- Allow store-and-forward upload with encryption and role-based access.
- Support local languages and low-literacy workflows through clear icons and audio prompts.
- Integrate referral tracking, not just image classification.
Edge deployment is valuable, but it does not remove the need for updates, monitoring, cybersecurity, and human escalation. A model can drift when a clinic changes camera, firmware, lighting, or patient mix.
Validate prospectively and monitor after launch
Retrospective test performance is only one stage. Conduct silent prospective evaluation first, then a controlled rollout with predefined safety criteria. Compare AI-assisted screening with the existing pathway on referral completion, time to review, ungradable images, false negatives, and patient outcomes where feasible.
Monitor performance by site and subgroup. Investigate sudden changes in imageability, referral rate, confidence distribution, or disagreement with graders. Retraining should use a governed data pipeline, versioned labels, documented change control, and a fresh holdout set. Do not continuously learn from live data without review.
For teams developing the technical foundation, customizable neural network architectures for beginners offers a useful starting point for understanding model components; production healthcare work then requires substantially stricter validation and governance.
A practical build roadmap
1. Define the screening endpoint and referral action.
2. Establish ethics, consent, privacy, and data-access procedures.
3. Create a labelled, patient-level dataset with adjudicated reference standards.
4. Train a reproducible baseline and measure sensitivity, specificity, calibration, and abstention.
5. Test externally across cameras, sites, and image-quality bands.
6. Build capture guidance, clinician review, referral tracking, and audit logging.
7. Run a prospective pilot with ophthalmology oversight.
8. Monitor drift, errors, equity, cybersecurity, and clinical outcomes.
Teams should also document the intended use, exclusions, known failure modes, training data, evaluation population, and escalation policy. If you need a broader project structure for a portfolio or grant proposal, compare this workflow with machine learning portfolio projects for beginners in India, while recognising that a clinical product needs far stronger evidence than a demonstration project.
Frequently asked questions
Can AI replace an ophthalmologist?
No. It can support triage, image-quality checks, and prioritisation. Diagnosis, treatment, and difficult or uncertain cases require qualified clinical oversight.
Should a team begin with five-class grading?
Usually not. A validated referable-DR endpoint is often easier to deploy safely. Add severity grading after the data, labels, and workflow support it.
Are public datasets enough?
They are useful for prototyping, not for proving Indian clinical performance. External evaluation on local, diverse data is essential.
What makes a model production-ready?
Reliable image capture, calibrated outputs, prospective validation, clear escalation, privacy controls, monitoring, versioning, and evidence that the workflow improves care—not merely a high benchmark score.
Researchers and founders building this kind of system can explore support through AI Grants India. A strong proposal should state the clinical problem, local data strategy, validation plan, deployment setting, safeguards, and measurable patient or workflow outcomes.