By Sidney Ocanagil-Tunstall
The use of artificial intelligence (AI) in digital pathology has proposed faster workflows, more accurate diagnoses, and the opportunity to discover new insights that we can harness to improve patient care. Thousands of academic papers demonstrate new AI algorithms each year, yet only a handful of these ever make it into the world of clinical care.
During the European Congress of Pathology (ECP), Dr. Andrew Janowczyk took to the stage to provide insight into how the Service of Clinical Pathology at Geneva University Hospitals (HUG) has managed to develop a practical framework for the deployment, validation, and accreditation of AI tools in a clinical setting. Their team formalized this information in the recent release of their detailed guide, A Guide for the Deployment, Validation, and Accreditation of Clinical Digital Pathology Tools.1
Dr. Janowczyk’s guide is a great resource and while his presentation went into greater depth on the process of deploying AI, this article will highlight the barriers to the adoption of AI in the clinical setting, taking personal notes from Dr. Janowczyk’s presentation in Vienna at ECP, 7th September 2025.
The Infrastructure Mismatch
Throughout his talk, Dr. Janowczyk made it clear that the greatest barriers to the deployment of clinical AI are not scientific breakthroughs, but the practical realities of infrastructure, integration, people, and regulation.
Beginning with the impracticalities of infrastructure, Dr. Janowczyk noted:
“Universities tend to have large high-performance computing (HPC) clusters, while hospitals typically don’t. Instead, they have a smaller amount of compute specifically aligned with completing their routine clinical tasks.”
HPC clusters are interconnected computers capable of processing vast amounts of data at high speed, common in research institutes, where algorithms are typically trained (on potentially very large datasets) and tested. Hospitals, by contrast, rarely have access to this level of compute, nor require it in an “inference-only” setting.
The result is an infrastructure mismatch: algorithms built for research often demand more processing power than hospitals can provide. As an AI developer, you must therefore account for the limited compute available in clinical environments so you can ensure algorithms are able to keep up with daily slide volumes. Otherwise, instead of adding value, your AI is at risk of being operationally incompatible or becoming a burden on the lab.
A Successful Deployment Hinges on a Suitable IMS
Having developed an AI algorithm, the choice and openness of the local image management system (IMS) becomes your next hurdle. Many of these IMSs were developed, purchased, and integrated long before the arrival of AI, and thus were not designed with modern best practices in mind:
“In Geneva and Emory, we have Sectra, which has a digital pathology API… allowing us to programmatically chat with the server in a standardized way to get images to analyze, and push associated results. But many other IMSs don’t have this type of programmatic interface and thus are considered ‘closed’ systems. So, if I’m being honest with you, I don’t know how you can build and integrate 3rd party tools into them.”
Including Sectra there are wide range of IMS options available. While Sectra proves it can facilitate in the API department, can their software also facilitate the other needs of an AI algorithm in a clinical context?
“The current version of Sectra is relatively new and still under active development. One limitation is that it can’t yet support an unlimited amount of polygons. So, if I need to display a polygon for say each of the 1 million cells in a typical pathology image, I can’t do it. Now I need to rethink how I can reach a similar user experience in a different way which is currently supported.”
Polygons are digital outlines used to precisely mark areas within images. In pathology, we are dealing with tumor regions, glands, and nuclei, all of which have irregular contours. Using polygons, we can provide precise, closed-boundary outlines to map areas that rectangular bounding boxes cannot capture.
Clearly there is something to be said for understanding your algorithm’s needs and the capabilities of your IMS before embarking on your deployment project.
Clinically Realistic Datasets
Dr. Janowczyk argues that many datasets are “over curated”, via eliminating challenging or complex edge-cases, and thus “not realistic for direct translation into real-world clinical tools.” Leaning on his experience with the public dataset, CAMELYLON17, designed specifically to encourage and prototype the development of automated algorithms for the detection and classification of breast cancer metastases in lymph node whole-slide images (WSIs):
“Many datasets are not clinically realistic… I love CAMELYON17. I competed in this challenge. But when we applied models trained on CAMELYON to our routine clinical slides, the performance just collapsed… tons of false positives, because that training set is very different from the routine types of clinical data that we see, and now you experience this painful research versus clinical gap.”
For Dr. Janowczyk, this experience led to a shift in strategy for their projects destined for clinical translation:
“Now we start by collecting real-world data coming out of our clinical workflow, so that when we deploy our tool in the same clinical setting, we know the data will be very similar, thus hopefully easing the validation process.”
This experience highlights a core challenge: domain shift. When the data used for training differs from the data seen in practice, models can fail dramatically. The lesson here is simple – ask yourself: am I training my model on the same type of data I intend to apply the algorithm to?
The Human Contingent
Even with robust models, finding personnel who can work together cohesively is essential. Research code is often written by PhD students who don’t have access to hospital systems.
“I know a lot of folks engage PhD students to help build algorithms. I don’t know about your institutions, but ours, rightfully, won’t allow a PhD student to simply walk into the hospital and start integrating software into the clinical system. So, we need to find someone on the hospital side for that student to partner with.”
As an additional hurdle, you need to consider finding someone who can partner with your PhD student/algorithm integrator to
“transition information and knowledge, software and experience to someone who has access to the clinical system but perhaps doesn’t know anything about that clinical use case.”
Additionally, due to the nature of working with PhD students and their independent projects, you will likely end up with multiple algorithms:
“It’s a potential nightmare story. 10 PhD students develop 10 algorithms, each in complete isolation, dump it on the desk of the hospital engineer before leaving and now this hospital engineer has to maintain 10 different approaches implemented in 10 different ways.”
Over the years, this technological legacy burden compounds. Dr. Janowczyk’s workaround:
“We are starting to develop a software development kit (SDK) in collaboration with Sectra that organises how we can perform common tasks like downloading slides for analysis and uploading results.”
Now, rather than having multiple approaches from a range of algorithms, you can use a software development kit to engineer a single shared approach and “more sustainably maintain that singular kind of software product.”
Moving on Dr. Janowczyk reflected on human-AI relationships and the importance of considering automation bias. Automation bias, a product of humans interfacing with the algorithm, also provides a source for concern.
“We looked at medical students and how they used algorithms when the results are incorrect… it turns out the more experienced someone is, the less likely they are to trust that algorithm and are more confident to override its results.”
Their study also showed that if the algorithm happens to be wrong, the less experienced user tends to submit false answers more frequently with higher confidence.2 Those with more experience felt more confident with their own decisions and were less likely to submit false answers.
This leaves the community of healthcare professionals with legal questions that we don’t currently have answers for. As the pathologist in the driving seat, are you accountable and liable for a misdiagnosis backed by AI? Do we need to reconsider how we train pathologists and the prior experience a pathologist should have before they are certified to practice?
Considering Variables & Quality Control
Unobservable factors that influence the performance of your algorithm dubbed latent quality control variables must be a serious consideration.
“To quickly introduce two of our recent papers… we looked at how tissue thickness impacts computational features3… it shouldn’t be too surprising that as the slide becomes thicker or thinner, the features themselves change.”
This includes texture features that “model chromatin structure within nuclei.”
“We therefore need to ask ourselves; if we have an image-based biomarker that relies on this feature and we test it on 3-micron thick tissue and then start using it on 2 or 4-micron thick tissue, is it still going to work? Probably not.”
Currently, variables like this are not largely kept track of or reported despite having significant effects on algorithm performance. If you can first identify variables, and find methods to measure them, you can then develop quality control tools to screen training data, allowing you to deliver more robust algorithms.
Thinking ‘Clinic First’
Algorithms need to be built with the clinic in mind.
“As a researcher starting to work in a clinical space, you operate under different assumptions. You experience a pain gap. An example of this is Hover-Net, a popular approach for segmenting cell nuclei. It was designed to be maximally performant, obtaining the best scores and benchmarks. But in a clinical setting with modest GPUs, it can take more than ten hours per whole slide image. If I have over two thousand slides per day and I want to segment cells, is it feasible for me to do this? No.”
These lengthy image analysis times are impractical in a clinical setting, and due to the nature of the clinic’s resources, the solution does not lie in gearing up computational power as Dr. Janowczyk alluded to:
“Would hospital administration consider approving a request for 2,000 GPUs so I could run the segmentation? No.”
A modified approach is required.
“For this, we developed HoverFast.4 It’s essentially the same algorithm… but we rewrote it using computer science best practices, parallel processing, and heavy optimisations… we are now able to get highly comparable results in 3 minutes. Now that sounds like something I can clinically deploy.”
Matching technologies with available infrastructure to meet throughput demands has reshaped Dr. Janowczyk’s outlook on how we define ‘algorithm performance.’
“It’s probably okay to miss one mitosis if I can save 10 hours of compute time.”
On a case-by-case basis, Dr. Janowczyk makes it clear that a successful deployment is born out of working with the “pathologist and IT folks” to find the optimal balance between your algorithm’s ability and the capabilities of the deployment setting.
Control Slides
“I’ll be honest with you. I’d never seen control tissue in my entire career. And that’s because on the research side they’re [control slides] removed before they are given to the researchers. The clinical folks see them, but my algorithm never gets the opportunity.”
Researchers aren’t involved in the clinical process, so they don’t see these slides despite being the engineers for the clinical algorithm. How can you build a successful algorithm which takes them into account, if you’re not exposed to them? This is yet another example of why AI developers must think ‘Clinic First’.
The Road Ahead
Ultimately, Dr. Janowczyk believes we can
“improve patient care and deploy these algorithms tomorrow. I believe this because the existing technology we have is already proving sufficient to aid and improve the efficiency, confidence, and performance of pathologists.”
However, we are still presented with these clinical deployment and integration bottlenecks that are
“difficult to find funds for because they are not research [objectives].”
Where previously our momentum was suppressed by solely algorithm capability and compute power. It’s now a question of
“integration into IMSs, obtaining high quality realistic datasets, collaboration and effort from multiple teams, interoperability, figuring out reimbursement methods and accountability, and finding the expertise to put all this together.”
About Dr. Andrew Janowczyk
Assistant Professor, Department of Biomedical Engineering, Emory University and Georgia Institute of Technology and Department of Oncology, Division of Precision Oncology, Department of Diagnostics, Division of Clinical Pathology, Geneva University Hospitals, Switzerland.
References
- https://www.preprints.org/manuscript/202509.1090/v1
- https://pubmed.ncbi.nlm.nih.gov/40610733/
- https://pmc.ncbi.nlm.nih.gov/articles/PMC11978545/
- https://arxiv.org/abs/2405.14028
No audio available for this article yet.
No quiz available for this article yet.
