Development of AI for histological image analysis

Why histological image analysis hinges on manual annotation

Histological image analysis hinges not on scanner optics or compute resources, but on the fact that the final decision is made by a human.

A pathologist examines the specimen and formulates a conclusion based on their own experience: when the same slide is reviewed again, discrepancies for individual nosologies reach 10–20% of cases. This is not a consequence of low qualification — that is how the assessment itself is structured.

Uneven staining, different section thickness, embedding artifacts, and borderline patterns leave room for interpretation, and variation in pathologists' conclusions manifests even within a single laboratory.

Digitization of microspecimens does not remove this problem — it exacerbates it.

A scanner produces entire series of high-resolution images, but for a model to confidently separate tumor tissue from stroma and lymphoid elements, it needs contours annotated manually on thousands of slides.

The annotation is checked against WHO Classification of Tumours and laboratory protocols, yet the analysis itself remains manual: no automatic method yet provides ready-made annotation of acceptable quality across the full diversity of staining.

This is where the laboratory's bottleneck lies.

Manual slide annotation is the most time-expensive operation: a single complex specimen takes several hours of physician attention, and agreement between two annotators on fine structures drops so much that the model has to be retrained.

At the same time, the flow of studies grows faster than the pathologist staff: the queue of slides accumulates, report turnaround times stretch out, and rare observations are lost between batches.

The limitation is not in image quality or model architecture, but in the speed and stability of human annotation. Below we discuss how this is addressed: which techniques reduce the amount of manual labor and how reproducibility of conclusions is maintained at scale.

What automatic slide analysis delivers: measurable changes

A slide is digitized into a whole image and cut into fixed-size fragments.

A tissue-region classification model assigns each fragment to a class — tumor tissue, stroma, necrosis, lymphoid infiltrate — and highlighting of regions of interest aggregates the answers back into a map, over which the physician sees where to look first.

Reproducibility of conclusions is the first measurable axis.

Fixed preprocessing (reference-based color normalization, background trimming, unchanged scale) together with versioning of model weights yields over 99% annotation agreement between runs on the same slide, whereas repeat annotation by two specialists diverges noticeably more.

Laboratory throughput grows not because the physician works faster, but because they look only at the marked zones.

The key metric here is the proportion of missed significant regions on a hold-out set: we tune the sensitivity threshold so that the model highlights candidates with a margin, and a false positive costs a few seconds of review rather than a diagnosis.

Time to answer consists of the time to analyze a batch of slides and the verification queue. Analysis runs in a batch: an overnight run delivers ready maps by morning, rather than one slide at a time.

We manage annotation for training and acceptance in QuPath — several specialists annotate one slide, discrepancies are recorded separately, so it is visible where the model errs and where the annotation itself is disputed.

Control at each model update is based on three numbers: annotation reproducibility, the proportion of missed significant regions, and time to answer. They show that automatic slide analysis removes load from the physician rather than shifting it.

Modes of working with the image archive: three project options

The project mode is determined not by preferences, but by the state of the slide archive and what the laboratory is prepared to do on its own.

The three working configurations differ in the amount of annotation that must be created before launch and in the depth of access to data. We examine them by applicability conditions and limitations.

What we compare

The choice of project mode rests on three measurable things: the size of the archive, the share of already annotated slides, and the requirements for reproducibility of the result on identical material.

If there is a lot of data but little annotation, fine-tuning a ready model produces a working result noticeably sooner than full training, while additional annotation of the archive proceeds in parallel and gradually expands class coverage.

The mode is not fixed forever: a configuration started as embedding ready-made analysis can later be converted to fine-tuning on accumulated material without rebuilding the laboratory workflow.

Implementation stages: from archive audit to model handover

The work proceeds in iterations, and each subsequent one relies on the result of the previous one.

Until the composition of the archive and the quality of annotation are clear, any solution architecture remains a guess — therefore the order of stages is fixed: first data, then the scheme, then assembly and validation.

1. Slide archive audit. We count the volume of cases, distribution by staining and localization, check how images are stored and whether they are linked to conclusions. The output is a data map and a list of gaps that must be closed before launch.
2. Annotation quality control. We bring physicians' annotations together on an overlapping set and calculate discrepancies between annotators. Disputed classes receive written rules: without this, the model learns to reproduce someone's habits rather than morphology.
3. Solution scheme. We fix what exactly the model outputs — priority sorting, highlighting of suspicious areas, or a second look at a complex case — and what it never decides.
4. Pilot on retrospective slides. We build the model on data already in the archive and validate it on a sample not involved in training, with splits by admission period and source. We calculate sensitivity, specificity, and the share of cases going to manual review.
5. Model validation. We test robustness to scanning artifacts, different scanners, and restaining, and separately examine the classes where an error is most costly. We tune the trigger threshold so that misses are minimized.
6. Implementation plan. We determine how the solution is integrated into the current sample route, who resolves disputed conclusions, and by what metric we consider that quality has not declined.
7. Handover and team training. We hand over the annotation rules, validation protocol, instructions for the physician-user, and analysis of typical errors — the team must be able to support the model without us.

Each stage ends with an artifact that can be checked: a data map, annotation rules, validation protocol, regulation. This makes it possible to stop work at any step if the data do not withstand validation.

What remains with the client's team: model, annotation, regulations

A model that performs well on a test set but remains with the developer is a demonstration, not an implementation. We hand over everything needed for independent work: artifacts, rules for updating them, access, and instructions for those who use the system every day.

• Model weights and its model card. We record which specimens and stainings the model was trained on, how it behaves for each class of findings, and where the boundaries of applicability are.
• Update procedure. We describe how to fine-tune the model on new slides, who confirms a version release, and how to roll back to the previous one if metrics on the control set decline.
• Annotation workflow regulation. Rules for annotating disputed areas, the procedure for resolving discrepancies between physicians, versioning of datasets, and the share of cases with cross-checking.
• Integration scheme. How the result enters the laboratory system, in what form the physician sees the annotation, and what happens when the service is unavailable — patient intake does not stop.
• Patient data access policies. Roles and permissions within the system, de-identification before processing, audit log of image access, retention periods and conditions.
• Instructions for laboratory technicians. Requirements for slide preparation and scanning: artifacts, bubbles, section quality, and signs indicating that an image should be rescanned rather than sent for processing.
• Instructions for physicians. How to read the model output, what is confirmed manually, and in which cases the conclusion is formed without its participation.

We store documents alongside the system and update them together with it: a new version is not released until the model card, regulations, and instructions have been brought into alignment.

After a month of support, the client's team manages updates independently, and we join in for analysis of complex cases.

Case study: how the share of discrepancies between experts was reduced

The laboratory received several hundred slides per week, and borderline cases went to a consensus panel: two or three physicians examined one specimen and did not always agree on the conclusion.

Variation in decisions held at roughly every fifth case, and some specimens were reviewed again — not because of a lack of data, but because of the absence of a single reference point.

What measurements showed before implementation

What was changed and why it worked

Annotation was managed in QuPath according to a single protocol: all experts independently marked disputed fields of the specimen, and discrepancies were not smoothed over but kept as a separate class.

The model learned not from a single “correct” conclusion, but from the distribution of opinions, so it outputs confidence for each class rather than a hard label.

The confidence threshold was tuned so that doubtful cases did not enter the ready report but immediately entered the queue for repeat review.

Metrics were taken not as a one-time export but in the flow: discrepancy was calculated for cases where the conclusion changed after review, and analysis time was calculated from slide open and close timestamps in the system.

The outcome is not a “report instead of a physician,” but a predictable analysis: disputed specimens are filtered out before signing, and the review regulation is the same for the entire shift.

How does fine-tuning a ready model differ from training from scratch?

Fine-tuning is transfer learning: a network that has already seen a large array of images is adjusted on your archive for a specific task — “normal/pathology,” detection of metastases in a lymph node, nucleus segmentation.

A small set of a few hundred annotated specimens is usually enough, because the basic features — contours, chromatin texture, nucleus shape — are already in the model.

Training from scratch is used when the data differ noticeably from typical data: different staining, rare nosology, a proprietary imaging channel.

The second case is when the decision is made for the whole specimen rather than an individual fragment: then both the processing scheme and the network output are rebuilt.

The amount of annotation that saved the day in fine-tuning does not work here — an order of magnitude more specimens is needed.

The main risk of both paths is annotation and validation. If fragments from the same slide end up in both training and validation, the metrics are inflated: the model memorizes the specimen, not the feature.

Therefore, the sample is split by patients and scans, not by individual fragments, and a separate set is kept that was not involved in either fine-tuning or threshold selection.

The practical criterion is simple. If there are at least a few hundred annotated specimens and the task resembles a typical one, we start with fine-tuning; it delivers the first working version in weeks.

If there is little annotation, the classes are rare, or whole-slide analysis is needed, we estimate building from scratch, and then we immediately include an annotation cycle in the plan: the model suggests disputed fields to the pathologist, who confirms or corrects them, and accuracy grows from iteration to iteration.

Integrations, slide quality, and data protection: common concerns

Before launch, the same concerns come up: how the model will fit into the laboratory workflow, what to do with a heterogeneous archive, and where the boundary lies in patient data. Below are brief answers.

Is patient data sent outside?

No. Identifiers are de-identified before being submitted to the model, processing takes place in your environment, and the reverse mapping is stored only by you.

What should be done about a heterogeneous archive and slide quality?

Weak scans are filtered out at preview, and the model is fine-tuned on your batches — accuracy does not decline on old and unevenly stained slides.

Are there many false positives?

The sensitivity threshold is tuned to your flow: disputed cases go to the physician for confirmation rather than to an automatic answer. Annotated errors are returned to fine-tuning.

What happens after launch?

Quality monitoring, fine-tuning on new batches, handling of requests, and scheduled model updates — without stopping the laboratory process.

Let's discuss the task: what to send for assessment and plan

To come back with an estimate of the scope of work, a solution scheme, and timelines, we need not general words about the task but concrete inputs.

The more complete the source data, the fewer assumptions in the labor estimate and the fewer discrepancies at acceptance — disputed situations almost always grow out of details that were missing at the input.

• A set of histological images: several dozen scans of different stainings, machines, and laboratories — using them we check how homogeneous the data are and what will need to be normalized.
• Formulation of the target task: what exactly we determine in the image, which classes interest us, and how they relate to each other.
• Annotation: annotated examples or at least partially verified ones — to estimate the amount of manual work and the quality control scheme.
• Current process: who currently reviews images, in what time, where the bottleneck is, and what share of disputed cases goes to repeat review.
• Requirements for the result: acceptable miss rate, whether confidence estimation is needed, and how the solution integrates into the physician's existing workflow.
• Data and environment constraints: where images are stored, whether there is an isolated environment, who the owner is, and what access mode our engineers need.
• Acceptance criteria: on which sample we validate, who on the customer side confirms the result, and by which document we record the stages.

Send what you already have, even if it is scattered folders with scans and free-form notes — we will organize them into a structure ourselves.

Describe the task, and we will come back with an estimate of the scope of work, a solution scheme, and a stage-by-stage implementation plan.