
We build the software around digital pathology. That includes the whole slide image viewer, integration with the models used for biomarker scoring, automation for scoring and validation, and the testing needed to run the system in production. The pathologist makes the diagnosis. The software handles the measurement and the work around it.
Whole slide images are stored as pyramids. The full resolution image sits alongside smaller versions, each divided into tiles.
The viewer requests only the tiles needed for the area and zoom on screen. Tile serving, caching and prefetching are what let a user move around a very large slide without waiting for the image to load.
Pathology has traditionally meant working with a glass slide under a microscope. Once the slide is scanned into a high resolution whole slide image, it can be reviewed from anywhere, shared with another reader, stored digitally and analysed by software.
A diagnostic slide can be several gigabytes. Manual scoring takes time, and two readers can score the same slide differently. The differences can matter when a result is close to a treatment threshold.
Software can apply the same measurement consistently and handle more slides than a team could process manually. The viewer, models and processing pipeline all need to work reliably enough for pathologists to use them as part of the normal workflow.
A model does not replace the pathologist’s judgement. It gives them a consistent measurement to work from.
On many pathology platforms, the scoring models come from a specialist AI vendor and are exposed through an API. We integrate those models into the product, send the right slide and region, handle the response, display the score with the tissue it came from, and record the model version used. On the platform we built, this included HER2, Trop2 and CD8 scoring alongside H&E.
We built the viewer on our case study platform from scratch and worked with DICOM whole slide images. Performance at high magnification had to be right from the start. A viewer that slows down while someone is reviewing a slide is not useful in practice.
Freehand outlines, polygons, points and region boxes are organised into layers. The annotations can be used later as training data, as input to a pipeline or as part of the case record. The score stays with the region it came from, and the platform records who confirmed or overrode it and when.
Slide scoring and validation can run without someone sitting in front of the application. Python handles the analysis and Playwright drives the browser interface. A full scoring run can run overnight across a batch, and the same scripts are used as the regression suite.
Two experts can score the same HER2 slide differently, especially when the result is close to a treatment threshold. Fatigue, slide quality and staining differences can all affect the score.
Each marker has its own scoring method. Some measure the proportion of positive cells, some measure staining intensity, and some use both. The methods make results easier to compare between pathologists, but only when the scoring is applied consistently.

For clinical or research use, a model should be tested against ground truth that was not part of training. The measures depend on the task. That can mean sensitivity and specificity for detection, or agreement with expert scoring for quantification.
A model needs annotated examples, which means a pathologist or biologist has to mark up images by hand. That takes time and can become one of the main constraints on a project.
Slides differ by lab, scanner and staining batch. A model trained on one source may not perform the same way on another. Stain normalisation and testing on slides from other sources help identify that before deployment.
A score is easier to review when there is some indication of what contributed to it. Heatmaps and region level information can show which parts of the slide affected the result.
A team has already selected its scoring models, either its own or a vendor’s, and needs the viewer, annotation tools, processing pipeline, model API integration and connection to the laboratory information system. We build that layer.
We add the scoring automation, test design and release checks, then build a regression suite around known slides so changes can be checked before release.
We can build the viewer and pipeline, integrate the models, and cover QA from requirements through release. That is how the platform in our case study was delivered.
Our work includes pathology and tissue analysis companies, cancer diagnostics companies, and healthcare organisations using slide analysis in oncology workflows. The platform on our case studies page was built for a global healthcare organisation to support tissue slide analysis in oncology, reducing pathologist time per case and production defects. We do not name clients on this site.
Quantified scoring that does not drift between readers or across days.
Automation of key pipeline steps including slide scoring and validation.
Reduced human error in routine assessment, with expert attention freed for the cases that need it.
What is being measured on a slide, why it matters for treatment, and how software measures it consistently.
The interface a pathologist actually works in, and the engineering that makes a multi gigabyte image feel instant.
Computer vision for biological imaging is also covered under AI for Life Sciences.
Biomarker scoring models, an interactive slide viewer, Python and Playwright automation and end to end QA on a digital pathology platform for oncology.
Read the case study →HER2, Trop2, and CD8 on immunohistochemistry slides, alongside H&E for morphology. Other markers can be added as the workflow requires them.
Both are possible. On the platform in our case study, we built the viewer from scratch because high magnification performance and the annotation and scoring workflow needed to fit the pathologist's work. If a client already has a viewer they trust, we build around it.
Not usually. Pathology scoring models often come from specialist AI vendors, and we integrate them through their APIs. We own the software around the model: the viewer, pipeline, record of which model version scored each slide, and tests that catch changes in the result.
Against expert scoring on held out slides from more than one source, rather than the data used to train the model. That applies whether the model belongs to the client or a vendor. The validation runs are automated and repeated after changes, including changes to the vendor model, so a change in score can be caught before release.
Yes, provided the interface is stable and the scripts are maintained as product code. On the platform we built, the same Playwright scripts used for release testing also run the overnight batch. They need to be maintained like any other production software.
Usually. A viewer that is disconnected from the laboratory information system creates extra work for every case. Connecting the case, slides, metadata, and signed score is what makes the viewer part of the actual workflow.
We work with pathology and diagnostics teams on viewers, model integration, automation and QA for slide analysis.
Start a conversation