Every year, millions of people in Poland receive their lab results as PDF files. Comparing results across time, across labs, or across institutions is time-consuming for doctors and prone to error. Large language models could help – but only if they’re designed from the very first line of code within limits that law and clinical ethics don’t allow you to cross. Maciej Białostocki, a graduate of the “Innovations in Medicine and Healthcare” postgraduate program at Warsaw Medical University (WUM), explored what such a tool should look like. The result is both a prototype and something more valuable: a design model that could shift how the whole MedTech sector approaches this problem.
A familiar problem
Comparing blood test results from different dates or labs sounds simple but is tedious in practice – different reference ranges, another PDF to scan visually for a change that might have been missed before. LLMs seem like a natural fit: paste in the data, ask for a trend summary. But “just paste it in” is exactly where most such ideas fall apart — lab results count as health data under GDPR, and feeding them into a generic AI tool doesn’t solve the problem, it creates a new one.
What the project actually tested
Białostocki wasn’t trying to build another “AI diagnostic tool.” His question was different: can such a system be designed as a supportive, safe, legally compliant tool from day one, rather than one where compliance gets bolted on afterward? He argues that systems processing health data must be built within clearly defined regulatory boundaries from the first version — otherwise, “adding compliance” later can mean rebuilding the whole solution.
The demonstrator he built is a web app that accepts two PDF lab reports, anonymizes the data, compares values, and generates an educational report — without diagnosing or recommending treatment. The line between “support” and “diagnosis” was meant to hold at every level: in the report content, the terms of use, the interface, and the model’s own system instructions.
Four hypotheses, four honest answers
What sets this thesis apart is that it doesn’t claim total success. Of four hypotheses, only one was confirmed without reservation: that an LLM can describe the direction and scale of changes between two result sets, given clean input data and a tightly scoped prompt. It’s also possible to build a support tool that doesn’t slide into a diagnostic role — but only if that boundary is enforced consistently, since one careless phrase in a report can push the system toward being classified as a medical device, triggering a completely different regulatory regime.
The most interesting finding concerns anonymization. The rules applied in the prototype meaningfully reduced the risk of exposing identifying data, but the author is upfront that this isn’t a guarantee of full non-identifiability in every case. The system could retain some contextual data (like age or sex) when it improved the report’s usefulness — a real trade-off between data minimization and analytical value. One rule wasn’t up for negotiation: anonymization always happens before data reaches the model, never after.
cMVP — a concept worth knowing if you design AI in healthcare
The thesis’s main contribution isn’t the app itself but a concept the author calls cMVP — Compliance Minimum Viable Product. In healthcare, he argues, “MVP” can’t just mean the smallest working feature — it has to include user consent, GDPR privacy notices, terms of service, medical disclaimers, data retention rules, and audit metadata as part of the core build, not as an add-on.
Architecturally, that meant: a Vue 3 frontend, a FastAPI backend, and an AI layer built on Google Gemini / Vertex AI hosted in the EU region. Users move through a controlled session — from consent, to file upload and anonymization, to the final report and deletion of operational data afterward.
The demonstrator ran through ten successful technical test sessions, consistently staying within its defined limits without generating diagnostic suggestions or treatment recommendations. That confirms the architecture is workable — not that it’s clinically useful yet, a distinction the author himself is careful to make, framing the project as a proof of concept rather than a deployment-ready tool.
Why it matters beyond one thesis
The takeaway extends well past academia: any team building health AI should first define the boundaries — data protection, no diagnosing, human oversight — and only then design the technology within them. Doing it the other way around means a simple interface fix can turn into a full system rebuild. At a time when hospital AI adoption is discussed mostly in terms of possibilities, this thesis is a reminder about something just as important: design discipline. A good lesson not just for students, but for MedTech startups facing the same challenge at much larger scale.
About the author: Maciej Białostocki is an IT leader and practitioner of responsible technology deployment in healthcare, with over 20 years combining team management, systems architecture, integrations, cloud, and cybersecurity with expertise in regulations like MDR, GDPR, the AI Act, and IEC 62304. He specializes in Digital Health, MedTech, and regulated systems projects where software must be effective as well as safe, auditable, and maintainable. He’s a graduate of WUM’s “Innovations in Medicine and Healthcare” program, and for his thesis built a demonstrator of an LLM app for lab trend analysis using a compliance-by-design approach.