Test na prawdziwym wyniku badania dał współczynnik błędu znaków na poziomie 0,48%, czyli 99,52% poprawnie rozpoznanych znaków. I to wciąż za mało, żeby powiedzieć, że system jest gotowy.
Bo OCR zwraca tekst, a aplikacja medyczna potrzebuje danych. To dwie zupełnie różne rzeczy, choć na slajdzie z prezentacji wyglądają identycznie. Między jednym a drugim leży cała robota, o której nikt nie opowiada na demo: odbudowa struktury dokumentu, znalezienie właściwej liczby wśród siedmiu innych, rozpoznanie jednostki, przypisanie wartości do parametru, obsługa błędów i infrastruktura, która nie wyciecze danych wrażliwych.
- W teście na rzeczywistym dokumencie medycznym system OCR osiągnął współczynnik błędu znaków (CER) na poziomie 0,48% (99,52% poprawnie rozpoznanych znaków), jednak błędy pojawiły się nie w cyfrach, lecz w polskich znakach diakrytycznych, częściowo w jednostkach oraz w zamianie przecinka z kropką jako separatora dziesiętnego – co może skutkować np. odczytem wartości 4,72 jako 472.
- Badanie opublikowane w BMC Medical Informatics and Decision Making przez zespół z Peking University First Hospital wykazało, że na 153 papierowych raportach laboratoryjnych moduł OCR osiągnął dokładność 0,93, natomiast moduł wydobywania informacji (przypisujący wartości do parametrów, jednostek i zakresów referencyjnych) uzyskał wynik F1 jedynie 0,86 – co potwierdza, że rozpoznawanie znaków jest łatwiejsze niż ich poprawne przypisanie do właściwych pól.
- Rozporządzenie o Europejskiej Przestrzeni Danych Zdrowotnych weszło w życie 26 marca 2025 roku, a przepisy o wtórnym wykorzystaniu danych zdrowotnych zaczną obowiązywać od 26 marca 2029 roku; równolegle AI Act od 2 grudnia 2027 roku obejmie systemy wysokiego ryzyka, co oznacza, że projekt OCR w medycynie może wymagać pełnej oceny zgodności z udziałem jednostki notyfikowanej, jeśli zostanie zakwalifikowany jako wyrób medyczny – a kary za naruszenia mogą sięgnąć 20 milionów euro lub 4% rocznego światowego obrotu.
Opisuję tu projekt, w którym punktem wyjścia była aplikacja medyczna mająca digitalizować papierową dokumentację pacjenta. Prace objęły OCR lokalny na telefonie, OCR serwerowy, heurystyki rekonstrukcji układu strony, normalizację jednostek, przetwarzanie wartości medycznych oraz potok uruchamiany w kontenerach. Case study trafiło do mnie od zespołu, który to zbudował, a ja wyciągnąłem z niego to, co najbardziej przyda się każdemu, kto planuje podobne wdrożenia AI dla firm w obszarze dokumentów.
Co znajdziesz w tym tekście:
- wynik pomiaru jakości OCR na rzeczywistym dokumencie medycznym i wyjaśnienie, dlaczego ten procent bywa mylący,
- listę problemów, które pojawiają się dopiero po tym, jak model zwróci tekst,
- porównanie przetwarzania lokalnego i serwerowego wraz z konsekwencjami dla prywatności,
- opis rejestru stanów dokumentu, bez którego produkcyjny system się rozsypuje,
- otoczenie prawne, które w 2026 roku zmienia architekturę takich projektów,
- siedem rzeczy do sprawdzenia, zanim podpiszesz umowę z wykonawcą.
Dlaczego skan wyniku badania to nie jest zwykły tekst?
Na pierwszy rzut oka zadanie wygląda banalnie. Pacjent robi zdjęcie wyniku morfologii. Aplikacja odpala OCR. Wychodzi tekst. Koniec. Tyle że tekst wychodzi mniej więcej taki:
Hemoglobina 13,8 g/dl Erytrocyty 4,72 T/l Cholesterol całkowity 184 mg/dl
Człowiek rozumie to w sekundę. System nie rozumie tego wcale. Ma ciąg znaków i musi z niego wyprowadzić sens.
Zestaw pytań, na które trzeba odpowiedzieć, żeby ten ciąg stał się danymi:
- która liczba jest wartością parametru, a która minimum zakresu referencyjnego?
- do czego należy jednostka stojąca obok?
- czy „u” to litera, czy źle odczytany znak „μ”?
- czy „H” jest częścią nazwy, czy artefaktem rozpoznawania?
- czy przecinek i kropka znaczą to samo w tym dokumencie?
- gdzie kończy się jeden parametr, a zaczyna następny?
- czy dokument jest obrócony, przekrzywiony, sfotografowany pod światło?
- czy ta wartość pochodzi z tabeli, z nagłówka, czy z opisu w stopce?
To jest różnica między rozpoznaniem tekstu a wydobyciem danych. Właśnie w tym miejscu większość efektownych demonstracji przestaje być efektowna. Model radzi sobie ze znakami. Nie radzi sobie z tym, co te znaki znaczą w kontekście dokumentu laboratoryjnego.
Najważniejszy wniosek z całego projektu zapisałbym jednym zdaniem, które warto powiesić nad biurkiem każdego zespołu produktowego:
OCR nie jest systemem do rozumienia dokumentów. Jest jednym z elementów systemu, który dopiero musi zbudować z dokumentu użyteczne dane. Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Co dokładnie musi zrobić system, żeby z dokumentu powstały dane?
Celem nie było zbudowanie kolejnego narzędzia zwracającego tekst ze zdjęcia. Potrzebny był przepływ, w którym dokument zostaje wczytany, rozpoznany, uporządkowany, zinterpretowany na poziomie danych, zapisany i przekazany dalej. Zespół rozdzielił więc siedem osobnych problemów: pozyskanie dokumentu, OCR, rekonstrukcję struktury, identyfikację parametrów medycznych, normalizację wartości i jednostek, zapis danych oraz dalsze przetwarzanie i prezentację.
To rozdzielenie okazało się jedną z lepszych decyzji projektowych. Dzięki niemu model OCR można wymienić bez przebudowy całej aplikacji. Kto pracował przy projektach AI w praktyce, ten wie, jak szybko starzeją się modele. Rok temu standardem było jedno rozwiązanie, dziś inne, za pół roku pewnie kolejne. Jeżeli wpleciesz konkretny model w logikę biznesową, przy pierwszej podmianie przepisujesz połowę systemu.
Poniżej to, co zwraca sam OCR, i to, czego naprawdę potrzebuje aplikacja medyczna.
| Etap | Co system dostaje | Czego jeszcze brakuje |
|---|---|---|
| Zdjęcie lub skan | Piksele, często krzywe i nierówno oświetlone | Wykrycie krawędzi, korekta orientacji, przygotowanie obrazu |
| OCR | Ciąg rozpoznanych znaków i współrzędne bloków | Relacje między elementami, kolejność logiczna, podział na wiersze |
| Rekonstrukcja układu | Odtworzone linie i kolumny | Wiedza, który blok jest nazwą parametru, a który wynikiem |
| Identyfikacja parametrów | Dopasowanie do słownika nazw | Rozstrzygnięcie synonimów, skrótów i wersji dwujęzycznych |
| Normalizacja | Ujednolicona jednostka i format liczby | Przeliczenie między jednostkami, obsługa separatora dziesiętnego |
| Zapis | Rekord w bazie | Data, źródło, poziom pewności, możliwość korekty przez człowieka |
Zauważ, że model AI odpowiada dokładnie za jeden wiersz tej tabeli. Reszta to inżynieria.
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Gdzie mają być przetwarzane dane, czyli pytanie ważniejsze od wyboru modelu
Przy dokumentacji medycznej pierwsze pytanie techniczne nie brzmi „który model ma najwyższą dokładność”. Brzmi „gdzie te dane wylądują”. Widziałem wystarczająco dużo projektów, w których zespół najpierw wybrał najlepszy model dostępny przez zewnętrzne API, a potem dowiedział się od prawnika, że właśnie zaplanował wysyłanie wyników badań pacjentów do usługi poza kontrolą administratora danych.
W opisywanym projekcie rozważono oba warianty i oba zostały użyte, ale do różnych zadań. Przetwarzanie lokalne na urządzeniu ma zalety, których nie da się kupić za lepszą jakość rozpoznawania. Dane nie opuszczają telefonu tylko po to, żeby odczytać z nich tekst. Aplikacja działa też wtedy, gdy sieć nie działa. Z drugiej strony telefon ma ograniczoną pamięć i moc obliczeniową, a model świetnie sprawdzający się na serwerze z kartą graficzną potrafi zabić baterię w kilka minut.
| Kryterium | OCR lokalny na urządzeniu | OCR po stronie serwera |
|---|---|---|
| Ekspozycja danych | Dokument nie opuszcza telefonu | Dokument trafia do infrastruktury, wymaga zabezpieczeń i rejestrowania operacji |
| Jakość na trudnych dokumentach | Niższa, ograniczona rozmiarem modelu | Wyższa, można użyć cięższych modeli |
| Zależność od sieci | Brak | Pełna |
| Koszt jednostkowy | Praktycznie zerowy po stronie operatora | Rośnie liniowo z liczbą dokumentów |
| Możliwość podmiany modelu | Wymaga aktualizacji aplikacji | Natychmiastowa, po stronie zaplecza |
| Typowe zastosowanie | Szybki podgląd, wstępna walidacja, proste wyniki | Wielostronicowe wypisy, skany złej jakości, dokumenty tabelaryczne |
Wniosek z projektu jest praktyczny: nie ma jednego magicznego modelu, jest podział zadań. Telefon robi to, co tanie i bezpieczne. Serwer robi to, co trudne.
Krzywa kartka i nierówne światło, czyli problemy niewidoczne na demo
Orientacja dokumentu wygląda na drobiazg, dopóki nie zobaczysz, co ludzie wysyłają do aplikacji. Zdjęcie zrobione pod kątem, kartka na kolanie w poczekalni, cień od własnej ręki, odblask lampy na papierze śliskim jak lustro. Sam OCR nie zawsze sobie z tym radzi, więc w aplikacji trzeba było dołożyć logikę obsługującą różne orientacje i przygotowującą obraz przed rozpoznaniem.
Sprawdziłem to na własnych wynikach badań i zajęło mi to jedną próbę: zdjęcie zrobione telefonem z odblaskiem daje kompletnie inny wynik niż ten sam dokument zeskanowany porządnym skanerem. Różnica bywa większa niż różnica między dwoma modelami OCR.
Rzeczy, które psują rozpoznawanie zanim model w ogóle się uruchomi:
- przekrzywienie kartki o kilka stopni, wystarczy, żeby wiersze zaczęły się zlewać,
- odblask i cień, które wybielają lub zaciemniają fragment tabeli,
- zagięcia i zszywki, szczególnie w wypisach szpitalnych,
- druk igłowy i wyblakły toner w starszych wynikach,
- pieczątki i odręczne dopiski nachodzące na wartości,
- zdjęcie zrobione zbyt blisko, gdzie brakuje kontekstu nagłówka strony.
Dlatego jakość całego rozwiązania zależy nie tylko od modelu, ale przede wszystkim od tego, co dzieje się przed nim i po nim. Przygotowanie obrazu jest nudne. Bez niego reszta nie ma sensu.
Dlaczego OCR nie rozumie tabeli i trzeba mu ją odbudować?
To był jeden z ważniejszych momentów projektu. Model może poprawnie rozpoznać każde słowo i każdą liczbę, a mimo to nie mieć pojęcia, jakie relacje łączą je na stronie.
Dla człowieka układ „Parametr | Wynik | Jednostka | Zakres referencyjny” jest strukturą. Dla OCR to zbiór elementów rozmieszczonych w określonych miejscach. Sama lista rozpoznanych słów nie wystarczy, bo gubi informację o tym, który wynik należy do którego wiersza. Trzeba wykorzystać współrzędne elementów i kolejność ich zwracania, żeby odtworzyć linie i bloki tekstu.
Skala problemu jest dobrze udokumentowana w literaturze. W badaniu opublikowanym w Journal of Biomedical Informatics zespół budował osobny potok do wykrywania i rozpoznawania tabel w skanowanych raportach laboratoryjnych, ponieważ wydobywanie danych tabelarycznych ze skanowanych raportów laboratoryjnych wymaga dwóch osobnych etapów: wykrycia tabeli i rozpoznania jej struktury. Ich dostrojony model osiągnął wynik TEDS na poziomie 0,699, a wynik dla samej struktury tabeli 0,764. To znaczy mniej więcej tyle: nawet wyspecjalizowane rozwiązanie do tabel medycznych myli się w co czwartym przypadku strukturalnym.
Lekcja jest prosta i kosztowna, jeśli się jej nie odrobi:
- nie zakładaj, że tekst zwrócony przez OCR zachowuje układ dokumentu,
- traktuj współrzędne bloków jako dane pierwszej klasy, nie jako metadane,
- testuj osobno na dokumentach jednokolumnowych i wielokolumnowych,
- sprawdź, co się dzieje, gdy tabela przechodzi na kolejną stronę.
Która liczba jest wynikiem? Najtrudniejsze pytanie całego projektu
Brzmi banalnie, dopóki nie otworzysz prawdziwego wyniku badania. Na jednej stronie potrafi być kilkadziesiąt liczb, a tylko część z nich to wyniki pacjenta.
W jednym wierszu znajdziesz jednocześnie:
- wartość zmierzoną u pacjenta,
- dolną granicę zakresu referencyjnego,
- górną granicę zakresu referencyjnego,
- numer próbki i numer zlecenia,
- datę pobrania i datę wykonania,
- godzinę,
- numer strony,
- wartości z sąsiednich kolumn, na przykład wyniku poprzedniego.
Jeżeli algorytm znajdzie wszystkie liczby, nie znaczy to jeszcze, że znalazł właściwą. Zespół zastosował heurystyki wykorzystujące nazwę parametru, rozpoznaną jednostkę, położenie wartości względem nazwy oraz kontekst sąsiednich elementów. Do tego doszedł słownik parametrów medycznych w języku polskim i angielskim oraz osobny słownik jednostek, bo w polskich laboratoriach spotkasz oba języki, czasem w jednym dokumencie.
Chodzi o to, żeby zamiast trzech niezależnych fragmentów tekstu powstała struktura:
- parametr: glukoza
- wartość: 96
- jednostka: mg/dl
Dopiero taki rekord da się zapisać, porównać i pokazać na wykresie. I żeby było jasne: to nie jest efekt magicznego AI. To klasyczny przykład sytuacji, w której model i logika aplikacyjna muszą pracować razem. Model dostarcza materiał. Logika ustala, co ten materiał znaczy.
Podobnie podszedł do tematu zespół z Peking University First Hospital, którego wyniki opisano w BMC Medical Informatics and Decision Making. Zbudowali kompletny potok oparty na przetwarzaniu języka naturalnego, w którym moduł wydobywania informacji wyciąga cztery encje: nazwę badania, wynik, jednostkę i zakres referencyjny. Na 153 papierowych raportach laboratoryjnych moduł OCR osiągnął średnią dokładność 0,93, a moduł wydobywania informacji wynik F1 na poziomie 0,86, przy średnim czasie przetwarzania jednego raportu wynoszącym 0,78 sekundy na pojedynczym procesorze. Zwróć uwagę na rozjazd między tymi dwiema liczbami. Rozpoznawanie znaków idzie lepiej niż przypisywanie ich do właściwych pól. Zawsze.
Jednostki, przecinki i polskie znaki, czyli miejsce, w którym sypie się historia pacjenta
Ten sam parametr występuje w różnych jednostkach. Glukoza 96 mg/dl i glukoza 5,3 mmol/l to nie są dwa różne badania, tylko ta sama wartość zapisana inaczej. Jeżeli dane mają być później porównywane w czasie, jednostki muszą zostać rozpoznane i w razie potrzeby przeliczone. W projekcie uwzględniono więc normalizację jednostek i obsługę synonimów nazw parametrów.
W teście na rzeczywistym dokumencie wszystkie dane liczbowe zostały odczytane poprawnie. Błędy pojawiły się gdzie indziej i to jest ciekawsze niż sam wynik:
- w części jednostek,
- w polskich znakach diakrytycznych,
- w zamianie kropki i przecinka jako separatora dziesiętnego.
Trzeci punkt potrafi zaboleć najbardziej. Jeżeli system przeczyta 4,72 jako 472, wykres poszybuje w kosmos, a pacjent dostanie zawału przy własnym telefonie. Dlatego walidacja zakresów fizjologicznych powinna siedzieć w systemie od pierwszego dnia, a nie zostać dołożona po pierwszym zgłoszeniu.
Nie ratuje też sytuacji PDF. Można pomyśleć, że skoro pacjent ma plik, problem znika. Nie znika. PDF bywa zwykłym pojemnikiem na obraz ze skanera i wtedy nadal potrzebujesz OCR. A nawet jeśli zawiera warstwę tekstową, wciąż zostaje pytanie o strukturę i znaczenie. Znowu to samo: odczyt tekstu to nie to samo co wydobycie danych.
Dopiero po tym etapie zaczyna się rzecz, dla której cały projekt ma sens. Kiedy z dokumentów da się wyciągnąć parametr, wartość, jednostkę, datę i źródło, przestajesz przechowywać kolejne pliki, a zaczynasz budować szereg czasowy. Hemoglobina, kolejne pomiary, kolejne daty, jeden wykres. Zamiast otwierania pięciu PDF-ów i ręcznego przepisywania do arkusza. Tam siedzi wartość biznesowa, nie w samym rozpoznaniu tekstu.
Jak mierzyć jakość OCR w medycynie, żeby liczba coś znaczyła?
W projekcie wykonano pomiar na rzeczywistym dokumencie medycznym. Wynik: CER 0,48%, co odpowiada około 99,52% poprawnie rozpoznanych znaków. Ładna liczba. I bardzo łatwa do nadużycia w materiałach sprzedażowych.
Zacznijmy od tego, czym te wskaźniki w ogóle są. Współczynnik błędu znaków (CER) to odsetek wszystkich znaków rozpoznanych błędnie, a współczynnik błędu słów (WER) to odsetek słów zawierających co najmniej jeden błędny znak. Warto mieć skalę porównawczą: dokładność na poziomie słów w typowych silnikach OCR dla pisma łacińskiego mieści się między 80% a 95%, a w dokumentach farmaceutycznych i regulacyjnych nawet czołowe silniki osiągają niemal stuprocentową dokładność na idealnym tekście, podczas gdy realne formularze i raporty dają zwykle 80 do 95 procent.
Na tym tle 99,52% wygląda świetnie. Tylko że to wynik dla jednego konkretnego pomiaru na jednym konkretnym dokumencie. Wyobraź sobie stronę z tysiącem znaków, na której jeden znak zostanie odczytany źle. Statystyka nadal wygląda pięknie. Jeżeli tym jednym znakiem jest cyfra w wyniku badania, konsekwencje nie mają nic wspólnego z tym procentem. Nie ma czegoś takiego jak 99,52% poprawności klinicznej.
Sama literatura metryczna zresztą ostrzega przed nadmiernym zaufaniem do jednej liczby. CER potrafi przekroczyć 100%, gdy system halucynuje znaki i wstawia więcej błędów, niż jest znaków w tekście odniesienia, a dokumenty medyczne i prawne wymagają niższych progów błędu ze względu na wymogi zgodności. W obszarze medycznym rozjazd między warunkami testowymi a rzeczywistością bywa dramatyczny. Przegląd badań klinicznych wykazał współczynniki błędu słów od 0,087 w kontrolowanym dyktowaniu do ponad 50% w rozmowach wieloosobowych, a autorzy uznali, że taki rozkład błędów czyni użycie bez nadzoru niebezpiecznym w warunkach klinicznych.
Dlatego w systemach medycznych mierzy się kilka rzeczy naraz.
| Wskaźnik | Co mierzy | Czego nie wykryje |
|---|---|---|
| CER | Odsetek błędnych znaków | Błędu w przypisaniu poprawnie odczytanej liczby do złego parametru |
| WER | Odsetek błędnych słów | Pominięcia całego wiersza tabeli |
| Dokładność wartości liczbowych | Poprawność samych wyników | Błędnej jednostki przy poprawnej liczbie |
| Poprawność jednostek | Rozpoznanie i normalizację jednostki | Braku danych, które w ogóle nie zostały znalezione |
| Trafność przypisania parametru | Powiązanie wartości z nazwą | Błędu w dacie badania |
| Kompletność | Ile pozycji z dokumentu trafiło do bazy | Jakości tego, co trafiło |
| Zachowanie na typach dokumentów | Odporność na różne układy stron | Regresji po podmianie modelu, jeśli nie ma zestawu kontrolnego |
Pytanie, które naprawdę trzeba zadać wykonawcy, nie brzmi „jaka jest dokładność”. Brzmi: co dokładnie ten system może pomylić i po czym poznamy, że właśnie się pomylił?
Opisz krótko, czego potrzebujesz. Jesteśmy największym HUB-em AI w Polsce — w naszej bazie znajdziesz blisko 500 zweryfikowanych firm specjalizujących się w AI. W Twoim imieniu poprosimy 3-5 dopasowanych wykonawców o kontakt w ciągu 48 godzin.
Od telefonu do serwera, czyli po co komu rejestr stanów dokumentu
Wraz z rozwojem projektu stało się jasne, że jeden model nie obsłuży wszystkich przypadków. Lżejsze rozwiązania dobrze pracują na urządzeniu, cięższe dają lepszą jakość przy złożonych dokumentach. Powstał więc podział na warstwę mobilną, odpowiedzialną za pozyskanie dokumentu i przetwarzanie lokalne, oraz warstwę serwerową do operacji wymagających mocy.
Po stronie serwera potok obejmował kolejne etapy: wysłanie pliku, walidację, OCR, strukturyzację, normalizację oraz tłumaczenie i eksport. Poszczególne elementy rozdzielono na niezależne komponenty uruchamiane w kontenerach, dzięki czemu można rozwijać jeden fragment bez ruszania reszty.
Tu pojawia się rzecz, która na slajdzie wygląda najmniej efektownie, a w produkcji ratuje projekt. OCR nie zawsze da się wykonać synchronicznie. Czasem trwa dwie sekundy, czasem dwie minuty, a czasem nie kończy się wcale, bo model zwrócił błąd albo kontener padł. Potrzebny był centralny rejestr stanów przetwarzania, po angielsku nazywany ledger, który w każdej chwili wie, co się dzieje z każdym dokumentem.
| Stan | Co oznacza | Co system musi umieć zrobić |
|---|---|---|
| available | Dokument czeka na przetworzenie | Pobrać go do kolejki bez ryzyka podwójnego przetworzenia |
| processing | Trwa rozpoznawanie | Wykryć zawieszenie i zwolnić blokadę po czasie |
| completed | Zakończono poprawnie | Zapisać wynik i udostępnić go aplikacji |
| failed | Zakończono błędem | Zapisać przyczynę, pozwolić na bezpieczne powtórzenie |
Rejestr odpowiada na pytania, których nie zada się modelowi: który dokument czeka, który jest właśnie przetwarzany, który skończył się błędem i czy operację można powtórzyć bez tworzenia duplikatu w bazie. Produkcyjny system musi wiedzieć nie tylko, jak przetworzyć dokument, ale przede wszystkim, co się z nim dzieje, kiedy coś pójdzie nie tak.
Dane medyczne zmieniają architekturę, a w 2026 roku zmieniają ją bardziej niż kiedykolwiek
W zwykłym projekcie pierwsze pytanie brzmi zwykle: która usługa chmurowa będzie najprostsza. Przy dokumentacji medycznej lista pytań robi się dłuższa i mniej przyjemna:
- gdzie fizycznie leżą dane i kto jest ich administratorem?
- kto ma do nich dostęp i jak ten dostęp jest rejestrowany?
- jak dane są przesyłane między komponentami?
- jak wygląda kopia zapasowa i kto ma do niej klucze?
- co się stanie po awarii jednego elementu potoku?
- które komponenty naprawdę muszą widzieć dane wrażliwe, a które radzą sobie na identyfikatorach?
Architektura projektu uwzględniała separację środowisk, konteneryzację, kontrolę dostępu, monitoring, kopie zapasowe oraz ograniczanie ekspozycji danych. Zasada jest prosta: jeżeli komponent nie potrzebuje pełnej dokumentacji, nie powinien jej automatycznie dostawać.
Do tego dochodzi otoczenie prawne, które w tym roku wygląda inaczej niż dwa lata temu. Rozporządzenie o Europejskiej Przestrzeni Danych Zdrowotnych już działa i będzie się rozwijać etapami. Weszło w życie 26 marca 2025 roku, stosuje się je od 26 marca 2027 roku, przepisy o wtórnym wykorzystaniu danych zdrowotnych zaczną obowiązywać od 26 marca 2029 roku, a obowiązki udostępniania niektórych danych, w tym badań obrazowych i wyników badań, dopiero od 26 marca 2031 roku. Kary za naruszenia mogą sięgnąć 20 milionów euro lub 4% rocznego światowego obrotu.
Równolegle działa AI Act, którego przepisy ogólne obowiązują od 2 sierpnia 2026 roku, a terminy dla systemów wysokiego ryzyka zostały przesunięte na 2 grudnia 2027 roku rozporządzeniem zmieniającym z pakietu Digital Omnibus. Dla projektu OCR w medycynie ma to konkretne znaczenie: jeżeli oprogramowanie zostanie zakwalifikowane jako wyrób medyczny podlegający ocenie zgodności z udziałem jednostki notyfikowanej, wchodzi w reżim wysokiego ryzyka razem z całą dokumentacją techniczną, zarządzaniem ryzykiem i nadzorem człowieka. Jeżeli natomiast jest narzędziem porządkującym dokumenty pacjenta bez funkcji diagnostycznej, sytuacja wygląda inaczej. Granica bywa cienka i przechodzi się ją przypadkiem, dopisując jedną funkcję „system podpowie, czy wynik jest w normie”.
Polski kontekst też się liczy. Z badania omawianego przez serwis Prawo.pl wynika, że dostęp do własnej elektronicznej dokumentacji medycznej oferuje pacjentom 28,3% podmiotów, a wśród tych, które planują wdrożenie e-usług, tylko 2,8% ma w planach e-rejestrację. Papier nie zniknął. Dlatego narzędzia zamieniające skan w dane wciąż mają w Polsce realny rynek, i to na lata.
Czego ten system nie rozwiązuje?
Ta sekcja jest równie ważna jak lista funkcji, a w materiałach wykonawców pojawia się mniej więcej nigdy.
Czego OCR w dokumentacji medycznej nie załatwia:
- nie zastępuje lekarza i nie interpretuje wyniku,
- nie gwarantuje poprawności klinicznej, tylko poprawność odczytu,
- nie naprawi zdjęcia zrobionego w ciemności pod kątem czterdziestu pięciu stopni,
- nie zagwarantuje trafnego przypisania każdej wartości do parametru,
- nie zamieni automatycznie każdego dokumentu w uporządkowaną bazę,
- nie rozwiąże problemu dokumentów odręcznych, które wciąż są najtrudniejszym przypadkiem.
Dlatego systemy tego typu powinny mieć jasno wyznaczone granice odpowiedzialności i mechanizmy sygnalizowania niepewności. W medycynie znacznie lepiej wypada system, który mówi „nie jestem pewien tej wartości, sprawdź ją”, niż taki, który udaje stuprocentową pewność. Interfejs z ręczną korektą to nie jest przyznanie się do porażki modelu. To element bezpieczeństwa produktu.
Siedem rzeczy do sprawdzenia przed wdrożeniem OCR w dokumentacji medycznej
Jeżeli masz przed sobą rozmowę z wykonawcą, przejdź przez tę listę punkt po punkcie. Każdy z nich wyszedł z realnych problemów w tym projekcie.
- Nie testuj na idealnych skanach. Poproś o test na zdjęciach z telefonu, przy różnym świetle, na przekrzywionych kartkach i na dokumentach z pieczątką nachodzącą na tabelę.
- Mierz więcej niż tekst. Osobno sprawdzaj wartości liczbowe, jednostki, trafność przypisania parametru i kompletność. Jeden procent nie opisuje systemu.
- Nie zakładaj, że OCR zachowa strukturę. Tabela i tekst ciągły to dwa różne problemy i wymagają osobnych testów.
- Zaprojektuj obsługę błędów od pierwszego dnia. Dokument utknie, model zwróci połowę wyniku, kontener padnie. To nie są wyjątki, to codzienność.
- Zdecyduj, gdzie przetwarzasz dane, zanim wybierzesz model. Kolejność odwrotna kończy się przepisywaniem architektury po rozmowie z inspektorem ochrony danych.
- Oddziel model od logiki biznesowej. OCR ma być wymienialnym elementem, nie fundamentem, na którym stoi cała aplikacja.
- Zdefiniuj, co znaczy sukces. Dziewięćdziesiąt dziewięć procent poprawnych znaków bywa świetnym wynikiem technicznym i całkowicie niewystarczającym wynikiem klinicznym.
FAQ, czyli pytania i odpowiedzi o OCR w dokumentacji medycznej
Czym różni się OCR od wydobycia danych z dokumentu?
OCR zamienia obraz na tekst i na tym kończy swoją rolę. Wydobycie danych to proces, w którym z tego tekstu powstaje struktura: nazwa parametru, wartość, jednostka, data i źródło. Między jednym a drugim jest rekonstrukcja układu strony, dopasowanie do słownika parametrów, normalizacja jednostek i heurystyki rozstrzygające, która z kilkunastu liczb w wierszu jest wynikiem pacjenta. W praktyce ta druga część pochłania znacznie więcej pracy niż wybór i uruchomienie modelu.
Czy 99% dokładności OCR wystarczy w medycynie?
To zależy od tego, co ten procent obejmuje. Dokładność na poziomie znaków mówi tylko o tym, ile znaków zostało odczytanych poprawnie, i nie mówi nic o tym, czy poprawnie odczytana liczba trafiła do właściwego parametru. W dokumencie o tysiącu znaków jeden błąd daje 99,9% dokładności i jednocześnie może oznaczać błędny wynik badania. Dlatego przy dokumentacji medycznej mierzy się osobno poprawność wartości liczbowych, jednostek i przypisań, a system powinien sygnalizować przypadki niepewne zamiast je wygładzać.
Czy lepiej przetwarzać dokumenty medyczne lokalnie, czy na serwerze?
Lokalnie, jeśli zależy ci na tym, żeby dane nie opuszczały urządzenia, i jeśli dokumenty są proste. Na serwerze, jeśli potrzebujesz wyższej jakości przy złożonych, wielostronicowych dokumentach albo chcesz podmieniać model bez aktualizowania aplikacji. W opisywanym projekcie użyto obu wariantów, przydzielając im różne zadania. To rozsądny domyślny wybór, bo pozwala ograniczyć ruch danych wrażliwych do przypadków, w których naprawdę jest potrzebny.
Czy plik PDF rozwiązuje problem OCR?
Nie zawsze. PDF bywa wyłącznie pojemnikiem na obraz ze skanera i wtedy potrzebujesz OCR dokładnie tak samo jak przy zdjęciu. Nawet gdy plik zawiera warstwę tekstową, kolejność znaków w niej zapisana nie musi odpowiadać układowi wizualnemu, a struktura tabeli często ginie całkowicie. Sprawdzenie jest banalne: spróbuj zaznaczyć i skopiować fragment tabeli z takiego pliku i zobacz, co wkleiło się do notatnika.
Ile trwa przetworzenie jednego dokumentu?
Zależy od modelu i miejsca uruchomienia, ale rząd wielkości warto znać. W badaniu opisanym w BMC Medical Informatics and Decision Making lekki potok przetwarzał jeden raport laboratoryjny średnio w 0,78 sekundy na pojedynczym procesorze. Cięższe modele serwerowe potrafią potrzebować kilku lub kilkunastu sekund na stronę, szczególnie przy skanach złej jakości. Właśnie dlatego przetwarzanie projektuje się jako operację asynchroniczną, z rejestrem stanów, a nie jako zwykłe wywołanie z interfejsu.
Czy taki system to wyrób medyczny podlegający AI Act?
To zależy od funkcji, nie od technologii. Narzędzie, które porządkuje dokumenty pacjenta i pokazuje historię pomiarów, zwykle nie pełni funkcji diagnostycznej. Jeżeli jednak dołożysz interpretację wyniku, sugestię rozpoznania albo ocenę ryzyka, kwalifikacja może się zmienić, a wtedy w grę wchodzą wymagania dla systemów wysokiego ryzyka. Tę kwestię przesądza się z prawnikiem przed rozpoczęciem prac, a nie po pierwszej wersji produktu, bo od kwalifikacji zależy dokumentacja, procesy i harmonogram.
Jak sprawdzić jakość OCR przed podpisaniem umowy?
Przygotuj własny zestaw kontrolny z dwudziestu do pięćdziesięciu dokumentów, które faktycznie krążą w twojej organizacji, razem z tymi brzydkimi. Ustal ręcznie poprawne wartości i traktuj je jako punkt odniesienia. Poproś wykonawcę o wynik nie tylko dla znaków, ale osobno dla wartości liczbowych, jednostek i przypisania parametrów. Zapisz w umowie, że ten sam zestaw będzie używany po każdej podmianie modelu, bo bez tego nie wykryjesz regresji.
Czy duży model językowy zastąpi cały ten potok przetwarzania?
Częściowo już zastępuje, zwłaszcza na etapie porządkowania i poprawiania wyniku OCR, i robi to lepiej niż heurystyki pisane ręcznie. Ale wprowadza własne ryzyko, którego klasyczny OCR nie miał: potrafi dopisać wartość, której w dokumencie nie było, i zrobi to w sposób wyglądający całkowicie wiarygodnie. W dokumentacji medycznej to gorszy rodzaj błędu niż zwykłe przekręcenie znaku, bo nie zostawia śladu. Dlatego nawet przy modelu językowym potrzebujesz walidacji zakresów, porównania z tekstem źródłowym i mechanizmu oznaczania niepewnych pozycji.
Za każdą polską firmą AI stoi konkretny człowiek z imieniem i nazwiskiem, często ten sam w kilku miejscach naraz, i to właśnie ludzie, nie tabelki finansowania, są prawdziwym bohaterem tego artykułu.
Podsumowanie, czyli co naprawdę zostaje po wdrożeniu OCR
Największa zmiana w myśleniu o OCR następuje wtedy, gdy przestajesz go traktować jako funkcję „odczytaj tekst”. W dokumentacji medycznej celem nie jest tekst. Celem są wiarygodne, uporządkowane dane, z których da się zbudować historię pacjenta. Cały problem sprowadza się do łańcucha: dokument, OCR, struktura, dane, walidacja, dalsze wykorzystanie. Każde z tych ogniw jest osobnym źródłem błędu, a najsłabsze wcale nie leży tam, gdzie wszyscy patrzą. Model rozpoznał 99,52% znaków i to była najłatwiejsza część projektu. Trudne okazało się to, co dzieje się na granicach: OCR zwraca tekst, ale aplikacja potrzebuje struktury; model znajduje liczbę, ale system musi wiedzieć, czego ona dotyczy; serwer kończy zadanie, ale telefon musi się dowiedzieć, czy zakończył je sukcesem. Te połączenia tworzą produkt i one pochłaniają większość budżetu, choć w ofercie zajmują jedną linijkę. Jeżeli wychodzisz z tego tekstu z jedną rzeczą, niech będzie to pytanie do zadania każdemu wykonawcy: nie „jaką macie dokładność”, tylko „co wasz system może pomylić i skąd się o tym dowiem”. Odpowiedź na to pytanie mówi więcej o dojrzałości zespołu niż każdy procent w prezentacji. A jeśli ktoś odpowie, że jego system się nie myli, wiesz już, że rozmowę można kończyć.
Powiedz w komentarzu, jak wygląda to u ciebie: masz w firmie albo w placówce dokumenty, które ktoś do dziś przepisuje ręcznie do systemu? Ile czasu to zjada w skali miesiąca? A jeśli znasz kogoś, kto właśnie wybiera wykonawcę takiego wdrożenia, podeślij mu ten tekst przed spotkaniem. Siódmy punkt z listy kontrolnej potrafi oszczędzić kilkadziesiąt tysięcy złotych.
Źródła i metodologia
Artykuł powstał na podstawie materiału przekazanego redakcji AIPORT.pl przez zespół realizujący opisywany projekt oraz analizy redakcyjnej, uzupełnionej o zewnętrzne źródła naukowe i regulacyjne, w tym BMC Medical Informatics and Decision Making (Ma i in., 2023, potok wydobywania danych z papierowych raportów laboratoryjnych) oraz Journal of Biomedical Informatics (wykrywanie i rozpoznawanie tabel w skanowanych raportach laboratoryjnych). Kontekst regulacyjny opracowano na podstawie rozporządzenia (UE) 2025/327 o Europejskiej Przestrzeni Danych Zdrowotnych, rozporządzenia o sztucznej inteligencji (AI Act) wraz ze zmianami z pakietu Digital Omnibus oraz rozporządzenia o wyrobach medycznych (MDR). Definicje metryk jakości rozpoznawania (CER, WER, TEDS) zweryfikowano z anglojęzyczną literaturą przedmiotu. Polski kontekst rynkowy opracowano na podstawie danych o poziomie cyfryzacji placówek publikowanych między innymi przez Prawo.pl, a także materiałów Centrum e-Zdrowia i raportu OSOZ „Atlas cyfryzacji”. Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl. Artykuł będzie aktualizowany w miarę pojawiania się nowych informacji na temat automatycznego przetwarzania dokumentacji medycznej.
Autorem case study jest: Sebastian Magnes – Fractional CTO specjalizujący się w projektach IT, AI, MedTech oraz przejmowaniu i porządkowaniu złożonych projektów technologicznych. Zajmuje się architekturą systemów, infrastrukturą, wdrażaniem rozwiązań AI/OCR oraz prowadzeniem projektów od strony technologicznej i produktowej. O firmie: Magnes Cloud – usługi Fractional CTO i wsparcie technologiczne dla firm oraz projektów IT. Obszary specjalizacji: IT, cloud, AI, MedTech, architektura systemów, DevOps oraz zarządzanie i ratowanie projektów technologicznych. Strona: https://www.magnes.
