W lipcowym artykule z cyklu „12-go o 12-tej” przyglądamy się rozwiązaniu, które odpowiada na jeden z realnych problemów cyfrowej ochrony zdrowia. Miliony Polaków co roku odbierają wyniki badań laboratoryjnych w postaci pliku PDF. Porównanie ich z wynikami sprzed roku, z innego laboratorium albo w innych jednostkach to zadanie, które pochłania czas lekarzy i rodzi błędy. Duże modele językowe mogą to zmienić, ale tylko wtedy, gdy od pierwszej linii kodu projektuje się je w granicach, których prawo i etyka kliniczna nie pozwalają przekroczyć. Maciej Białostocki, absolwent studiów podyplomowych Innowacje w Medycynie i Ochronie Zdrowia na Warszawskim Uniwersytecie Medycznym, sprawdził, jak powinno wyglądać takie narzędzie. Efektem jest prototyp i coś cenniejszego: model projektowania, który może zmienić podejście całego sektora MedTech.
Problem, który każdy lekarz i pacjent znał już wcześniej
Porównywanie wyników badań krwi z różnych terminów albo różnych laboratoriów to zadanie, które brzmi prosto, a w praktyce bywa męczące. Inne jednostki, inne zakresy referencyjne, kolejny PDF do przeszukania wzrokiem w poszukiwaniu zmiany, która umknęła przy poprzednim spojrzeniu. Duże modele językowe wydają się naturalnym kandydatem do pomocy: wystarczy wkleić dane i poprosić o podsumowanie trendu.
Tyle że „wystarczy wkleić” to dokładnie ten moment, w którym większość takich pomysłów się rozsypuje. Dane z wyników badań to dane dotyczące zdrowia w rozumieniu RODO. Wklejenie ich do ogólnodostępnego narzędzia AI nie rozwiązuje problemu – tworzy nowy.
Od techniki do granic: co właściwie sprawdzał ten projekt
Praca Macieja Białostockiego nie była próbą zbudowania kolejnego „AI do diagnozowania”. Postawił sobie inne pytanie: czy taki system da się zaprojektować jako narzędzie wspierające, bezpieczne i zgodne z przepisami od pierwszej linii kodu, a nie jako produkt, do którego zgodność dokleja się na końcu.
– System przetwarzający dane dotyczące zdrowia trzeba budować zgodnie z regulacjami i w jasno określonych granicach od pierwszej wersji. W przeciwnym razie późniejsze „dodanie zgodności” może oznaczać konieczność przebudowania całego rozwiązania – pisze autor w podsumowaniu pracy.
Powstał demonstrator: aplikacja webowa, która przyjmuje dwa pliki PDF z wynikami badań, anonimizuje dane, porównuje wartości i generuje raport edukacyjny, bez stawiania diagnoz i bez sugerowania leczenia. Granica między „wsparciem” a „diagnozą” miała być utrzymana na każdym poziomie: w treści raportu, w regulaminie, w interfejsie i w samej instrukcji systemowej modelu.
Cztery hipotezy, cztery odpowiedzi bez naciągania wyniku
To, co wyróżnia tę pracę, to brak entuzjastycznego „wszystko się udało”. Z czterech postawionych hipotez tylko jedna została potwierdzona bez zastrzeżeń.
Model językowy faktycznie poradził sobie z opisem kierunku i skali zmian między dwoma zestawami wyników, pod warunkiem czytelnych danych wejściowych i precyzyjnie ograniczonej instrukcji. Da się też zbudować narzędzie wspierające, które nie wchodzi w rolę diagnostyczną, ale tylko wtedy, gdy ta granica jest pilnowana konsekwentnie, bo jedno nieostrożne sformułowanie w raporcie przesuwa system w stronę wyrobu medycznego i zupełnie innych wymogów regulacyjnych.
Najciekawszy wynik dotyczy jednak czwartej hipotezy – anonimizacji. Reguły zastosowane w prototypie istotnie ograniczyły ryzyko ujawnienia danych identyfikujących, ale autor uczciwie zaznacza: to nie jest gwarancja pełnej nieidentyfikowalności w każdym przypadku. System pozwalał zachować pewne dane kontekstowe (np. wiek, płeć), jeśli poprawiały użyteczność raportu, pokazując realny kompromis między minimalizacją danych a sensownością analizy. Zasada, która nie podlegała negocjacji: anonimizacja zawsze przed wysłaniem danych do modelu, nigdy po.
cMVP – pojęcie, które może się przydać każdemu, kto projektuje AI w zdrowiu
Głównym wynikiem pracy nie jest sama aplikacja, a koncepcja, którą autor nazywa cMVP – Compliance Minimum Viable Product. Krótko: w ochronie zdrowia MVP nie oznacza „najmniejszego działającego produktu”, lecz minimalny zakres produktu potrzebny do sprawdzenia hipotezy. Nie może więc oznaczać samej funkcji. Musi od razu obejmować zgody użytkownika, klauzulę informacyjną RODO, regulamin, ostrzeżenie medyczne, zasady retencji danych i metadane audytowe, nie jako dodatek, ale jako część konstrukcji.
To przekłada się na konkretną architekturę: frontend w Vue 3, backend w FastAPI, warstwa AI oparta na Google Gemini / Vertex AI w regionie UE, a użytkownik przechodzi przez kontrolowaną sesję: od zgód, przez wgranie plików i anonimizację, aż do raportu i skasowania danych operacyjnych po zakończeniu.
Demonstrator przeszedł dziesięć sesji testowych zakończonych sukcesem technicznym, system konsekwentnie trzymał się przyjętych granic, nie generując sugestii diagnostycznych ani zaleceń terapeutycznych. To potwierdza wykonalność architektury, nie przydatność kliniczną i autor sam to podkreśla, traktując projekt jako sprawdzenie modelu działania, a nie gotowe narzędzie do wdrożenia.
Dlaczego to ważne nie tylko dla jednej pracy dyplomowej
Wniosek z tego projektu wybiega daleko poza laboratorium akademickie. Pokazuje logikę, która powinna obowiązywać każdy zespół budujący AI w obszarze zdrowia: najpierw określamy granice dopuszczalnego działania, ochronę danych, zakaz diagnozowania, nadzór człowieka, a dopiero w tych granicach projektujemy technologię. Odwrócenie tej kolejności kończy się tym, że „poprawienie interfejsu” zamienia się w przebudowę całego systemu od zera.
W czasach, gdy o wdrażaniu AI w szpitalach mówi się głównie w kategoriach możliwości, praca Macieja Białostockiego przypomina o czymś równie istotnym: o dyscyplinie projektowania. To dobra lekcja nie tylko dla studentów, ale i dla startupów MedTech, które stają przed podobnym wyzwaniem na znacznie większą skalę.
O autorze:
Maciej Białostocki – lider IT i praktyk odpowiedzialnego wdrażania technologii w ochronie zdrowia. Od ponad 20 lat łączy doświadczenie w zarządzaniu zespołami, architekturze systemów, integracjach, chmurze i cyberbezpieczeństwie z wiedzą o regulacjach takich jak MDR, RODO, AI Act czy IEC 62304. Specjalizuje się w projektach z obszaru Digital Health, MedTech i systemów regulowanych, gdzie software musi być nie tylko skuteczny, ale także bezpieczny, audytowalny i możliwy do utrzymania. Absolwent programu Innowacje w Medycynie i Ochronie Zdrowia WUM; w pracy dyplomowej zbudował demonstrator aplikacji LLM do analizy trendów wyników laboratoryjnych w podejściu compliance-by-design.