Prajval Mohan on Building Reliable AI Systems for Digital Pathology and Advancing Deep Learning Through Slideflow
Artificial intelligence is creating new possibilities in digital pathology, but applying deep learning to medical images presents challenges that extend well beyond model development. From processing enormous whole-slide images to ensuring reliable predictions across different datasets, researchers need systems that are scalable, reproducible, and capable of handling the complexities of real-world healthcare data.
Prajval Mohan, a software engineer and researcher specializing in artificial intelligence, machine learning, computer vision, and scalable software systems, has contributed to addressing these challenges through his work on Slideflow, an open-source deep-learning framework for digital pathology. His contributions include developing the framework’s first integrated model-ensembling system, introducing methods for uncertainty estimation, and integrating pathology-specific feature extraction capabilities.
With a Master of Science in Computer Science from the University of Chicago and research experience spanning reinforcement learning, computer vision, and AI infrastructure, Mohan brings both academic and applied engineering perspectives to his work.
In this interview with Intelligent HQ, Mohan discusses his contributions to Slideflow, the technical challenges of building reliable AI systems for digital pathology, and the importance of making advanced machine-learning methods accessible and reproducible for the broader research community.
How did your experience in AI, machine learning, and software engineering prepare you for your work on Slideflow, particularly in addressing the challenges of digital pathology?
Before working on Slideflow, I had already conducted research in machine learning, neural networks, and reinforcement learning. My master’s program at the University of Chicago, together with my internships and capstone work, helped me build the engineering skills needed to turn research ideas into usable software. Slideflow was where those two parts of my background came together.
That combination was important because digital pathology is not only a machine-learning problem. Whole-slide images are extremely large, experiments can take a long time to complete, and the resulting tools need to be usable by researchers who may not be software engineers. My research background helped me understand how model ensembles could improve predictive reliability and provide another way to evaluate uncertainty. My engineering experience helped me build that functionality into Slideflow itself rather than leaving it as code developed for a single experiment. I designed it to fit the framework’s existing workflow so other researchers could train ensembles, combine their predictions, and reproduce the results without rebuilding the process themselves.
For readers who may not be familiar with Slideflow, what problems is the framework designed to solve, and what specific areas of the project did you contribute to?
Slideflow is an open-source deep-learning framework built for digital pathology. It brings the major stages of working with whole-slide images into one system, from slide processing and tile extraction to model training, evaluation, and patient-level analysis.
My main contribution was building Slideflow’s model-ensembling capability from the ground up. Before my work, Slideflow lacked a framework-level architecture for model ensembling. I designed and implemented its first integrated ensemble system, covering model training, output organization, and the alignment and merging of predictions at the tile, slide, and patient levels. I later expanded it to support hyper-deep ensembles, where members can use different hyperparameter configurations. Through this work, I introduced ensemble-based uncertainty estimation and out-of-distribution analysis into Slideflow, giving researchers a way to evaluate not only what a model predicted, but also how consistently several independently trained models reached that conclusion.
I also brought RetCCL into the Slideflow ecosystem. I built the integration that connected the pathology-specific model to Slideflow’s feature-extraction interface, preprocessing pipeline, model registry, pretrained weights, and whole-slide workflow.
Digital pathology involves extremely large and complex medical images. What technical challenges arise when building deep learning systems for whole-slide imaging, and how did your work on Slideflow help address those challenges?
The challenge with whole-slide imaging is that the model never sees the slide the way a pathologist does. A whole-slide image is too large to process at once, so it has to be broken into thousands of smaller tiles. The model makes predictions on those tiles, but the researcher ultimately needs an answer for the slide or patient. That creates a difficult engineering problem: predictions from a large number of tiles and multiple models have to be organized and combined without losing their connection to the original slide.
There is also no guarantee that future slides will resemble the training data. Differences in staining, scanners, and tissue preparation can affect how a slide appears, even when the sample itself is the same. My ensemble work gave Slideflow a structured way to run several independently trained models on the same data and combine their predictions at the tile, slide, and patient levels. Just as importantly, differences between the models’ predictions provided a practical indication of uncertainty, allowing researchers to identify cases that may require closer examination rather than relying on a single model’s output.
What engineering or machine learning methods did you apply in your contributions to Slideflow, and how did you approach balancing model performance, scalability, and usability for researchers working with pathology data?
I worked mainly with deep ensembles and hyper-deep ensembles. The idea behind deep ensembles was to improve performance without relying too heavily on one model. With hyper-deep ensembles, the goal was to use different hyperparameters to add more variety between the models, providing a more informative picture of both the final prediction and its uncertainty.
I designed the ensemble members to run independently, so they could be executed in parallel when enough computing power was available. This kept the extra time manageable and meant that a problem with one run didn’t waste the work completed by the others.
I also wanted the system to remain easy for researchers to use. Managing several models and matching all their prediction files manually could quickly become complicated. I built those steps into Slideflow’s existing interface, so the framework kept track of the ensemble members and combined their results across tiles, slides, and patients. Researchers could use the new methods without changing the workflow they were already familiar with.
Computer vision methods that work well on conventional image datasets do not always translate directly to pathology. What makes pathology data technically different, and how did those differences influence the way you designed or evaluated your work?
Pathology images are very different from conventional image datasets. In a dataset like ImageNet, one image usually contains a recognizable object with a clear label. A pathology slide may contain thousands of tiles, while the label often belongs to the entire slide or patient. Many of those tiles may not even contain the feature connected to that label.
The visual patterns are different too. The important information may be in cell structure, tissue arrangement, or texture rather than a familiar object shape. Slides can also look different because of staining or scanning methods, even when the underlying biology is similar.
These differences influenced my work in two ways. I designed the ensemble system to combine results at the tile, slide, and patient levels instead of focusing only on individual images. I also integrated RetCCL because its features were learned from pathology images rather than ordinary photographs, making it a more relevant starting point for researchers working with tissue data.
Slideflow is an open-source framework intended to support both research and practical experimentation. How do you think about building AI infrastructure that is technically sophisticated while still being reproducible and accessible to other researchers and developers?
To me, reproducibility means that another researcher should be able to revisit an experiment and understand exactly how it was run. While building the ensemble system, I kept the models and outputs for each member organized and preserved the slide manifest and experiment settings with them. I also made sure that the combined results could be regenerated from saved predictions. If the final merging step was interrupted, the completed model runs did not have to be repeated.
I also wanted these capabilities to fit naturally into Slideflow. The ensemble methods used the framework’s regular training workflow, and their options were documented in the public interface. RetCCL worked through the existing feature-extraction system as well. Researchers could therefore use these methods without creating and maintaining an entirely separate workflow.
Looking across your work in digital pathology, reinforcement learning, computer vision, and software engineering, what broader lessons have you learned about turning advanced AI research into systems that can reliably handle complex real-world data?
The broader lesson for me is that solving a complex AI problem usually requires more than expertise in one area. In digital pathology, understanding machine learning mattered, but so did understanding how pathology data is structured and how researchers would actually use the framework. My reinforcement-learning work taught me something similar. Improving one objective, such as speed, can create problems elsewhere if you don’t consider safety and efficiency together.
Software engineering is what helps turn those ideas into something usable. A strong model is only one part of the system. The data pipeline, interfaces, failure handling, and ability for others to reproduce the work matter as well. Across these projects, I have learned to look at the complete problem rather than treating the algorithm as the entire solution.
