On 26 October, I attended a scientific evening about artificial intelligence in medicine at the University of Tartu’s Delta Centre. The talk that stayed with me most was by Professor Lars Kaderali from Germany. His team has developed some fascinating tools, but getting them into hospital workflows comes with plenty of obstacles.
One of those obstacles is the speed of AI development itself. You get a system working, check its results, and then a new model arrives. As an everyday user, you want to try it and see whether it is better. In a hospital, another question comes first: what changes in our existing system when we replace the model, and how do we know we can still trust the results?
The scientific evening “AI at the Frontier of Medicine: Genomics, Imaging & Decision-Making” brought together Lars Kaderali, Professor of Bioinformatics at University Medicine Greifswald, and University of Tartu researchers Burak Yelmen and Ali Zeynalli. I was there as an attendee, interested in how data and experiments become tools that can help clinicians.
Lars Kaderali: there is an entire workflow around the model
Kaderali’s examples helped explain what building medical AI involves. At one end, there is information about a patient. At the other, there is a clinical decision. In between, a system might process documents, search scientific literature, combine different data sources and generate an explanation.
That sequence of steps is often called a pipeline. Replacing a model in the middle means checking how the change affects the overall result. A more fluent answer does not necessarily mean a more accurate one.
What struck me most in Lars’s talk was the work involved in checking the system again. When an important part of a tested system changes, the team needs fresh evidence about how it behaves. It helped me understand why a hospital cannot move at exactly the same pace as someone selecting the next model from an AI app’s menu.
There is a distinction between testing results again and formal conformity assessment. The extent of each depends on the particular system and the change. I would not take the talk as a rule that every update always requires the whole certification process to start from scratch. What did come through clearly was that results verified for one version do not automatically establish how the next version will perform.
ONCODE and OncoSage: help with scientific evidence
One concrete example was ONCODE, a locally hosted AI tool for finding scientific evidence and grading its strength. Kaderali presented it in an oncology context, where a patient’s disease and molecular findings need to be connected with a large body of research.
Another example was OncoSage, which brings together patient context and biomedical knowledge. In straightforward terms, the aim is to help a specialist find information relevant to a question and understand the evidence behind a possible conclusion.
I liked seeing the specific work these tools are being built for. The scientific literature keeps growing, more data becomes available, and someone has to connect it all. It is easy to see why AI could help with searching and comparing that information. A system-generated summary still does not amount to an approved treatment decision.
Kaderali also presented RareDex. Its slide showed a process starting with symptoms entered by a clinician, moving through standardising those descriptions and finding similar cases, then producing a reasoned comparison of possible diagnoses. The clinician remains responsible for the decision. It is an entire support system built around a carefully defined task.
In-house AI keeps data close, but brings work of its own
In the setup Kaderali showed, an open language model ran within the institution’s own environment. The slide made the arrangement clear: patient data, processing and the model stay within the same local infrastructure. Sensitive data does not leave that environment.
That provides more control, while also making the institution responsible for keeping the system running. Models, servers, access permissions and updates need to be managed. Listening to the talk, I had the impression that demand for these tools is substantial, but the route from a working experiment to a usable system is much longer than it first appears.
This does not mean that all commercial models are prohibited in medicine. Their example showed how they address their own sensitive data and need for control. An external service and a locally hosted model are different operational choices. Neither label alone establishes whether a system is suitable.
I also remember Lars discussing the need for stronger European AI capabilities and concerns about dependence on US providers. I took that mainly as a question about how much control a hospital has over the future of its own tools. Where is the data? Who decides when a model changes? What happens if a capability the hospital relies on disappears?
Model dependency also came up at the Tallinn Data Week seminar. The medical examples added another important dimension: understanding how a technical change affects work involving patients.
Burak Yelmen: using AI to study the human genome
Burak Yelmen, Associate Professor at the University of Tartu’s Institute of Genomics, spoke about deep learning and human genomic variation. This concerns how inherited differences relate to traits, disease risks and evolution, and how models can help researchers study those relationships.
For me, this broadened the picture. It is easy to think of medical AI as a chatbot or a program analysing a scan. Here, we were also hearing about research that helps explain the underlying biology of disease. It may contribute knowledge for precision medicine, although there are still several steps between a research finding and an individual patient’s treatment.
Ali Zeynalli: a kidney tumour AI example from Tartu
Ali Zeynalli from the University of Tartu’s Institute of Computer Science spoke about biomedical image analysis. His examples ranged from cells under a microscope to radiological scans. The laboratory he introduced is led by Dmytro Fishman, with work that combines computer science and medicine.
The most concrete example for me was BMVision Kidney. The slide showed its workflow: a computed tomography scan, tumour segmentation, measurements and a report. Developed by Better Medicine, it is a tool to assist radiologists. One important detail is that this kidney tumour example uses CT, not MRI.
Tartu University Hospital’s own account, published on 26 August 2026, adds useful context. BMVision Kidney ran alongside routine radiology for six months, analysing abdominal CT scans from 4,276 patients. In four cases, it flagged kidney lesions not described during the initial assessment. These were preliminary findings, with further analysis continuing.
The hospital also planned to repeat the test with an updated model. This connects directly with Lars’s discussion: a new version needs renewed evaluation. The hospital describes a tool authorised for clinical use whose impact and weaknesses are still being investigated.
I enjoyed seeing this work happening here in Tartu. It makes the subject feel much closer. We are talking about a tool already being tested alongside radiologists’ work, and people developing it locally.
Kaderali also showed an example of MRI image analysis that evening. That was a different imaging method and a separate example.
What I took away from the evening
Lars’s presentation was my favourite because he discussed the difficulties of using these systems as well as what they can do. The possibilities for AI in medicine are fascinating. It was equally interesting to hear how much work is required to fit them into everyday hospital practice.
In one evening, we saw scientific literature search, support for investigating rare diseases, genomic research and medical image analysis. These involve different tasks and different models. Yet the central question seemed shared: how do we establish that the assistance is useful in the particular job?
I went to hear what people are doing with AI in medicine. I left with a much clearer understanding of why building a good system and using it reliably are both substantial pieces of work. I would happily attend more talks like these.
Photos: Anti Soosaar, 26 October 2026. Slides belong to the respective speakers’ presentations. This article reflects my observations as an attendee; linked sources distinguish what was presented from background information checked afterwards.