Fundus Image Analysis: Where Accuracy Is Lost
Fundus image analysis hinges not on recognition quality but on reading consistency.
The same image gets a different description depending on who reads it and how far into their shift they are: by the fortieth study in a row, microaneurysms at the edge of the visual field are noticed less often, and isolated hemorrhages slip into “observe.” The spread of physicians’ conclusions is the diagnostic bottleneck, and it remains invisible until you consolidate reports across the entire flow.
The cause goes deeper than fatigue. A grading scale implies a reference image and calibration against it, but in practice everyone reads by their own internal norm: one counts microaneurysms by quadrants, another estimates the area affected.
Errors in manual retinal description accumulate not in isolated cases but in statistics—at borderline stages, discrepancies between readers measure in tens of percent.
Then follow-up studies come into play. A patient returns six months later, the previous conclusion turns out to be incomparable with the new one, dynamics across history are lost, and the decision is made based on the latest text.
The losses look like a few lines in the chart, but that is exactly where progression tracking falls apart.
Open datasets such as EyePACS show the same nature of error: discrepancies between readers were recorded separately and resolved by arbitration rather than by searching for a single correct answer.
We break down how this is addressed: where grading by stages is sufficient, where pixel-level segmentation is needed, and how to combine them into a comparable conclusion for a series of images.
What a Unified Retinal Assessment Standard Delivers
The point of a unified standard is not automated retinal assessment itself but a common reference point for all studies. Below are four effects measured across the flow: review time, repeat capture rate, agreement of conclusions, and physician workload.
Unified Description Protocol
The model reduces an image to a fixed set of features: lesion localization, their area, severity, and edema zone.
The wording relies on the International Clinical Diabetic Retinopathy Severity Scale, so two specialists describe the same image identically—discrepancies remain in clinical interpretation, not terminology.
Study Review Speed
The physician receives an annotated map and a draft conclusion, not a bare image. Review and editing take minutes instead of tens of minutes, a series of studies is closed within one shift—office throughput grows without expanding staff.
Fewer Repeat Captures
Quality control rejects unsuitable frames for blur, artifacts, and incomplete capture right during acquisition. The share of studies sent for a repeat visit drops severalfold, and the patient does not return to the clinic because of technical defects.
Result Reproducibility
Re-running the same image yields the same feature set and the same stage assessment: model versions and the run log record this. Patient dynamics are visible through comparable measurements, not through wording from different shifts.
Implementation Formats for Image Review: Cloud, Local Environment, Hybrid
The choice of deployment scheme is determined not by team convenience but by the regulations for handling medical images: where an image is allowed to reside and who has access to it.
Cloud image analysis removes concerns about in-house capacity but requires a secure channel and pre-agreed retention periods.
A local processing environment, conversely, keeps data within the organization and removes part of the approvals, but shifts performance and model update concerns to the customer.
Between the extremes, a hybrid scheme works: images remain in the environment, and only anonymized results or a model request go outside.
Below is a comparison along three axes: where data physically resides, what is required on the customer side, and what limitations emerge in operation.
Comparison of Deployment Schemes
| Option | When It Fits | Limitations |
|---|---|---|
| Cloud analysis | No requirements for image localization, need a fast start and peak load on demand | Image transfer only over a secure channel; retention and deletion policy is fixed before the first image |
| Local environment | By regulation or customer requirement, images do not leave the organization | Requires in-house compute capacity, a separate update environment, and model version control |
| Hybrid scheme | Data must remain inside, but the model is more convenient to keep centrally | More expensive to maintain: two environments, version synchronization, and a regulation for exchanging anonymized data |
Data storage requirements differ in each scheme, so we fix them at the start and build them into the architecture rather than adding them later.
How We Run a Project: From Data Audit to Handover
AI retinal analysis breaks not on the model but on the data: the archive contains images from different cameras, different capture protocols, and text conclusions that are not suitable for training directly.
Therefore, the work follows a fixed sequence—each stage is closed with an artifact that can be verified before moving to the next.
-
Audit of the study archive. We consolidate images into a single storage, calculate the distribution by stages and pathologies, and assess whether there are enough examples for each target finding. The result is a data map with a list of gaps that need to be closed before work begins.
-
Labeling setup. We describe the class dictionary, tie it to the clinical scale, and write instructions for the annotator with borderline examples.
Each image is labeled independently by two people, discrepancies go to ophthalmologist arbitration—the reference stops depending on a single expert.
-
Model training. We split the archive by studies, not by individual frames: images from one patient must not appear in both training and validation, otherwise the quality assessment will be inflated. We separately test robustness to different cameras, lighting, and capture artifacts.
-
Validation on an independent sample. We calculate metrics on data that participated in neither training nor labeling, and break them down by subgroups—camera, pathology, image quality.
The average figure across the sample hides failure on a rare class, and that is exactly what determines clinical value.
-
Implementation and handover. We connect the model to the physician’s workstation without changing the usual route: processing runs in the background, disputed cases are flagged for manual validation, and decisions are written to a log.
We hand over the code, labeling configurations, a model passport with applicability boundaries, and a retraining regulation.
Delivery Package: Model, Labeling, Regulations
After implementation, the customer retains not a demo prototype but a working environment with a full set of artifacts. Below is the delivery package: each item can be handed over to an internal team or another contractor without reconstructing the logic from correspondence.
- A configured model and a reproducible launch environment: the same result on the same image on a repeat run, and the environment is brought up on your side without us.
- Model documentation: finding classes, input image quality requirements, confidence thresholds, and system behavior when it refrains from output.
- Labeling description: class dictionary, rules for disputed cases, dataset passport, and labeling of the control sample on which the model was validated.
- Quality report for each class: where the model errs, in which direction, and what share of studies goes to a specialist for confirmation.
- Data access rules: user roles, anonymization at input, image access log, retention periods, and export procedure.
- Instructions for physicians: how the result fits into an appointment, what the numerical assessment means, and in which cases the decision remains with a human.
- Model update procedure: signs of divergence from real data, retraining regulation, acceptance of a new version on a closed set, and rollback to the previous one.
Case Study: How Study Review Changed After Implementation
Starting Point: Weeks-Long Queue and Spread in Assessments
Before implementation, reviewing one fundus series took 10–14 minutes: examination, manual annotation of zones, and formulation of the conclusion.
At peak flow, the diagnostic queue stretched to three weeks, and the share of discrepancies between specialists on the same images reached 9–11%—most often at the boundary between adjacent stages on the ETDRS scale. The discrepancy had to be resolved by a repeat review, and that also consumed appointment time.
What Was Changed
The model was installed as a second reader, not as a replacement for the physician: it annotates zones and suggests a stage, and the specialist confirms or edits the conclusion.
Disputed series go to a senior reviewer—instead of “trust in the conclusion,” there is now a measurable criterion.
Quality control was configured separately: the share of edits and repeat reviews is calculated per specialist and per stage, so model degradation is visible before it reaches the queue.
Result After Three Months of Operation
Study time decreased to 4–6 minutes, most of which is confirmation of the annotation. The share of discrepancies between specialists fell to 3–4%, and the share of series requiring repeat review fell from 18% to 5%.
The appointment queue decreased from three weeks to 4–6 days without expanding staff or purchasing equipment: throughput came from removing routine annotation, not from speeding up the examination itself.
More important than the numbers is predictability: workload no longer depends on how many complex series fall into a shift. The physician focuses on disputed cases and conversation with the patient, not mechanical tracing of zones.
How Does Segmentation Differ from Grading?
Retinal segmentation answers the question “where”: it is the delineation of regions in an image where the model labels every pixel—optic disc boundaries, the macular zone, the vascular network, exudates, and hemorrhages.
The output is masks and measurable numbers: the area of each region, its share of the frame area, and displacement relative to the macular center. Grading answers the question “how pronounced” and assigns a severity degree—from normal to severe stage on the accepted scale.
The difference lies in the nature of the answer, not in model “power.” Segmentation is dense prediction per pixel, and its quality is measured by the intersection of predicted and reference masks; grading is a class decision where error is asymmetric: missing a severe stage is worse than overestimating a mild one.
Therefore, quality control also differs—the share of exact grades and the share of one-step shifts versus review of borderline annotation zones.
The choice of approach is dictated by the task of the stage. For mass image triage, grading is more necessary: it gives a quick answer “normal or refer to a physician” and fits into the appointment flow.
For dynamic follow-up, planning laser coagulation, and assessing neoplasm growth, segmentation is needed—here area and boundary displacement matter, not a label. In practice, both approaches more often work together.
Grading trained on segmentation labels is more robust: severity relies on measurable features, and the physician can see what exactly influenced the decision.
Our engineers build labeling so that one set of images covers both task types—then the choice of approach remains with the clinic, not with the data format.
Concerns About Data, Accuracy, and Responsibility
Objections to fundus image analysis are usually technical: whether the archive is sufficient, how to handle varying capture quality, whether the solution will coexist with the current environment, and who is responsible for an error.
Will our images be enough for training?
We clean the clinic’s archive of duplicates and split it so that one patient does not appear in both training and validation. Common classes need several thousand studies, and we source rare pathologies separately.
What should be done about varying capture quality?
Different cameras and operators produce glare, overexposure, and blurred frames. We filter out unreadable ones and bring the rest to a unified form; on a weak frame, the model gives low confidence rather than a random answer.
Physicians disagree in their conclusions—what then?
Discrepancies are part of labeling, not an obstacle. We review disputed cases before the start and measure annotator agreement; the metric is calculated against the agreed reference, not a single conclusion.
How will the solution integrate into our environment?
The image is taken from the study archive, and the conclusion is returned to the physician’s workstation. Physician edits become feedback for the model instead of being lost in correspondence.
Who is responsible for the result?
The final conclusion remains with the physician; the solution supports their decision. We are responsible for reproducibility: model versions, trigger thresholds, and metrics on a holdout group. If quality degrades, we roll back to the previous version.
Let’s Discuss Your Task: We’ll Return with an Estimate and Plan
The first conversation is not a presentation but a review of your data and what counts as a result.
Therefore, we start with questions whose answers determine the project estimate and work plan: where images come from, whether historical labeling exists, and which model errors are critical for the physician.
What we clarify before naming implementation timelines:
- which fundus images we process—export format, cameras, and whether the capture protocol is unified across offices;
- which tasks are prioritized: grading by stages, highlighting lesion zones, or a screening conclusion “normal / refer to a physician”;
- what exists for labeling: who labeled, by which scale, and how many studies are suitable for training and validation;
- where the solution lives in the process: the physician’s workstation with prompts, batch processing of a study flow, or export of ready conclusions;
- which metrics we consider target and which class of misses is unacceptable—the trigger threshold depends on this;
- how access, anonymization, and image storage are arranged in your environment;
- whether a model quality report on your dataset is needed before launch into clinical work.
Describe your task—we will return with a project estimate, a stage-by-stage work plan, and realistic implementation timelines: from data preparation and labeling to pilot operation and handover to your team.
If there are gaps in the data, we will say directly what needs to be closed before the start, not after.
