OCR potrafi zamienić zdjęcie lub skan dokumentu na tekst. W dokumentacji medycznej to jednak dopiero pierwszy krok.
Problem zaczyna się później: system musi rozpoznać strukturę dokumentu, znaleźć właściwe wartości, powiązać je z nazwami parametrów, jednostkami i datą, a następnie przekazać je do kolejnych elementów systemu. W dodatku dane medyczne wymagają zupełnie innego podejścia do prywatności, infrastruktury i przetwarzania niż zwykłe dokumenty biznesowe.
- W testach na rzeczywistym dokumencie medycznym uzyskano współczynnik błędów znaków (CER) na poziomie 0,48%, co odpowiada 99,52% dokładności rozpoznawania znaków – jednak autorzy projektu podkreślają, że wynik ten nie oznacza 99,52% poprawności klinicznej, ponieważ błędnie odczytana pojedyncza cyfra w wyniku medycznym może mieć poważniejsze konsekwencje niż sugeruje ogólna statystyka.
- Sam OCR zwraca jedynie tekst, natomiast system przetwarzania dokumentacji medycznej musi dodatkowo rekonstruować strukturę dokumentu, identyfikować parametry medyczne ze słowników w języku polskim i angielskim, rozpoznawać i normalizować jednostki (np. przeliczać glukozę z mg/dl na mmol/l) oraz przypisywać wartości do konkretnych parametrów z uwzględnieniem ich położenia na stronie.
- W projekcie zastosowano centralny ledger stanów przetwarzania, który śledzi każdy dokument przez stany takie jak „available → processing → completed" lub „available → processing → failed", co umożliwia kontrolę nad asynchronicznym przetwarzaniem i obsługę błędów w warunkach produkcyjnych.
W opisywanym projekcie punktem wyjścia była aplikacja medyczna, która miała umożliwiać digitalizację papierowej dokumentacji. Prace objęły lokalny OCR na urządzeniu mobilnym, OCR serwerowy, heurystyki rekonstrukcji struktury dokumentu, normalizację danych, przetwarzanie wartości medycznych oraz pipeline uruchamiany w kontenerach.
Najważniejszy wniosek był prosty:
OCR nie jest systemem do rozumienia dokumentów. Jest jednym z elementów systemu, który dopiero musi zbudować z dokumentu użyteczne dane.
Problem: dokument medyczny nie jest zwykłym tekstem
Na pierwszy rzut oka zadanie wygląda banalnie. Użytkownik robi zdjęcie wyniku badania. Aplikacja wykonuje OCR. Otrzymujemy tekst. Gotowe. Tyle że wynik OCR może wyglądać mniej więcej tak:
Hemoglobina 13,8 g/dl
> Erytrocyty 4,72 T/l
> Cholesterol całkowity 184 mg/dl
Dla człowieka znaczenie jest oczywiste. Dla systemu już niekoniecznie.
Trzeba odpowiedzieć na pytania:
- która liczba jest wartością parametru?
- która liczba jest zakresem referencyjnym?
- do czego należy jednostka?
- czy „u” oznacza literę u, czy błędnie odczytany znak „μ”?
- czy „H” jest literą w nazwie, czy błędem OCR?
- czy przecinek i kropka oznaczają to samo?
- gdzie zaczyna się kolejny parametr?
- czy dokument jest obrócony?
- czy dana wartość pochodzi z tabeli, nagłówka czy opisu?
To jest różnica między rozpoznaniem tekstu a wydobyciem danych. Właśnie na tym etapie większość prostych demonstracji OCR przestaje być imponująca.
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Cel projektu
Celem nie było stworzenie kolejnego narzędzia, które po prostu zwraca tekst ze zdjęcia. Potrzebny był przepływ, w którym dokument może zostać:
wczytany → rozpoznany → uporządkowany → zinterpretowany na poziomie danych → zapisany → wykorzystany dalej.
Architektura musiała obsłużyć zarówno dokumenty przetwarzane na urządzeniu mobilnym, jak i cięższe modele uruchamiane po stronie serwera. W projekcie rozdzielono więc kilka problemów:
- pozyskanie dokumentu,
- OCR,
- rekonstrukcję struktury,
- identyfikację parametrów medycznych,
- normalizację wartości i jednostek,
- zapis danych,
- dalsze przetwarzanie i prezentację.
To rozdzielenie okazało się bardzo ważne. Dzięki niemu można było wymieniać model OCR bez przebudowywania całego systemu.
Dlaczego lokalny OCR?
W przypadku dokumentacji medycznej pierwsze pytanie techniczne nie powinno brzmieć:
„Jaki model ma najwyższą dokładność?”
Powinno brzmieć:
„Gdzie te dane będą przetwarzane?”
W projekcie rozważano zarówno przetwarzanie lokalne na urządzeniu, jak i cięższe przetwarzanie po stronie serwera. Lokalne przetwarzanie ma kilka oczywistych zalet. Dane nie muszą być wysyłane do zewnętrznej usługi tylko po to, żeby odczytać tekst. Można też ograniczyć zależność od połączenia sieciowego.
Z drugiej strony urządzenie mobilne ma ograniczone zasoby. Model, który działa dobrze na serwerze z GPU, niekoniecznie będzie dobrym rozwiązaniem na telefonie. Dlatego architektura nie zakładała jednego „magicznego” modelu. OCR traktowano jako wymienny komponent całego pipeline’u.
Pierwszy problem: orientacja dokumentu
Jednym z prostych, ale bardzo praktycznych problemów była orientacja dokumentu.
Dokument może zostać sfotografowany pionowo, poziomo albo pod innym kątem. Sam OCR nie zawsze radzi sobie z tym idealnie. W aplikacji zastosowano więc logikę pozwalającą obsługiwać różne orientacje dokumentu i odpowiednio przygotować obraz przed rozpoznaniem. To dobry przykład problemu, którego nie widać podczas prezentacji modelu.
Na demo mamy idealny skan. W rzeczywistości użytkownik robi zdjęcie telefonu, dokument jest lekko przekrzywiony, światło jest nierówne, a tekst może znajdować się w kilku blokach. Dlatego jakość całego rozwiązania zależy nie tylko od modelu AI, ale również od tego, co dzieje się przed i po nim.
Drugi problem: OCR nie rozumie tabeli
To był jeden z ważniejszych momentów projektu. OCR może poprawnie rozpoznać poszczególne słowa i liczby, ale nadal nie wiedzieć, jakie relacje między nimi występują na stronie.
Przykład:
Parametr | Wynik | Jednostka | Zakres referencyjny
Dla człowieka tabela jest strukturą.
Dla OCR może być zbiorem elementów rozmieszczonych w określonych miejscach. Dlatego sama lista rozpoznanych słów nie wystarczała. Położenie elementów na stronie musiało zostać wykorzystane do odtworzenia relacji między nimi. W praktyce oznaczało to rekonstrukcję linii i bloków tekstu na podstawie współrzędnych oraz kolejności elementów zwracanych przez OCR.
To ważna lekcja:
Jeżeli aplikacja ma pracować z dokumentami, nie można zakładać, że tekst zwrócony przez OCR zachowuje strukturę dokumentu.
Często trzeba ją zbudować ponownie.
Jak system rozpoznawał parametry medyczne?
Kolejny etap zaczynał się wtedy, gdy tekst był już dostępny. System korzystał z przygotowanego słownika parametrów medycznych w języku polskim i angielskim oraz słownika jednostek. To pozwalało powiązać znalezioną wartość z konkretnym parametrem. Przykładowo system nie powinien traktować:
Glucose 96 mg/dl
jako trzech niezależnych fragmentów tekstu.
Chodzi o utworzenie struktury:
parametr: glukoza
wartość: 96
jednostka: mg/dl
Dopiero taka struktura może być wykorzystana przez kolejne elementy aplikacji.
Najtrudniejsze pytanie: która liczba jest wynikiem?
To brzmi banalnie, dopóki nie zobaczy się prawdziwego dokumentu. Wynik badania może zawierać jednocześnie:
- wartość pacjenta,
- minimum zakresu referencyjnego,
- maksimum zakresu referencyjnego,
- numer próbki,
- datę,
- godzinę,
- numer strony,
- wartości z innych kolumn.
Jeżeli algorytm znajdzie wszystkie liczby, nie oznacza to jeszcze, że znalazł właściwą liczbę. Dlatego zastosowano heurystyki wykorzystujące między innymi nazwę parametru, jednostkę, położenie wartości oraz kontekst sąsiednich elementów. To nie jest efekt „magicznego AI”. To klasyczny przykład tego, że w systemach dokumentowych model AI i logika aplikacyjna muszą współpracować.
Model dostarcza materiał. Logika biznesowa próbuje ustalić, co ten materiał oznacza.
Problem jednostek
Ten sam parametr może występować w różnych jednostkach. Dla systemu oznacza to, że:
glukoza 96 mg/dl
i
glukoza 5,3 mmol/l
nie są dwoma różnymi parametrami.
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 oraz obsługę synonimów parametrów. To otwiera drogę do kolejnego etapu: budowania danych historycznych zamiast przechowywania kolejnych, niezależnych dokumentów.
PDF również nie rozwiązuje problemu
Można pomyśleć:
„Skoro użytkownik ma PDF, problem OCR znika”.
Nie zawsze. PDF może zawierać tekst, ale może też być po prostu kontenerem na zeskanowany obraz dokumentu. W tym drugim przypadku nadal potrzebujemy OCR. Co więcej, nawet jeżeli PDF zawiera tekst, nadal pozostaje problem jego struktury i znaczenia. Czyli ponownie wracamy do tego samego:
odczyt tekstu to nie to samo co wydobycie danych.
Od OCR do danych czasowych
Jednym z ciekawszych elementów projektu było odejście od traktowania dokumentu jako końcowego produktu. Jeżeli z dokumentów można wyciągnąć:
- parametr,
- wartość,
- jednostkę,
- datę,
- źródło,
to kolejnym krokiem może być zapis tych informacji jako danych uporządkowanych w czasie. Przykładowo można wtedy obserwować historię:
hemoglobina → kolejne pomiary → kolejne daty
zamiast otwierać pięć różnych plików PDF i ręcznie porównywać wyniki. Właśnie tutaj OCR zaczyna mieć realną wartość biznesową. Nie dlatego, że „rozpoznaje tekst”. Dlatego, że zamienia nieustrukturyzowany dokument w dane, które można wykorzystać dalej.
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.
Jak mierzyliśmy jakość?
W projekcie wykonano test na rzeczywistym dokumencie medycznym. Dla tego konkretnego dokumentu uzyskano:
CER: 0,48%
co odpowiadało około:
99,52% dokładności rozpoznawania znaków.
Wszystkie dane liczbowe w tym teście zostały odczytane poprawnie. Pojawiły się natomiast błędy dotyczące części jednostek, polskich znaków oraz zamiany kropki i przecinka. I tutaj pojawia się bardzo ważne zastrzeżenie.
99,52% nie oznacza, że system jest w 99,52% poprawny klinicznie.
To wynik dla konkretnego pomiaru jakości OCR na konkretnym dokumencie. To ogromna różnica.
Czy 99,52% oznacza, że system działa dobrze?
Nie automatycznie. Wyobraźmy sobie, że dokument ma 1000 znaków i jeden z nich zostanie źle rozpoznany. Statystycznie wynik może nadal wyglądać świetnie. Ale jeśli tym jednym znakiem będzie cyfra w wyniku medycznym, konsekwencje mogą być dużo większe niż sugeruje ogólny procent. Dlatego w systemach medycznych nie wystarczy mierzyć jednego wskaźnika.
Trzeba osobno sprawdzać między innymi:
- dokładność tekstu,
- dokładność wartości liczbowych,
- poprawność jednostek,
- poprawność przypisania wartości do parametru,
- kompletność danych,
- zachowanie na różnych typach dokumentów.
Najważniejsze pytanie nie brzmi więc „jaka jest accuracy?”. Brzmi: „Co dokładnie system może pomylić i jak wykryjemy tę pomyłkę?”
Od aplikacji mobilnej do serwera
Wraz z rozwojem projektu stało się jasne, że jeden model nie rozwiąże wszystkich przypadków. Lżejsze rozwiązania dobrze sprawdzają się na urządzeniach mobilnych, ale cięższe modele mogą oferować lepszą jakość rozpoznawania dokumentów, zwłaszcza bardziej złożonych. Dlatego powstał podział na:
warstwę mobilną
odpowiedzialną za pozyskanie dokumentu i lokalne przetwarzanie,
oraz
warstwę serwerową
przeznaczoną do bardziej wymagających operacji.
Po stronie serwera pipeline obejmował kolejne etapy:
upload → walidacja → OCR → strukturyzacja → normalizacja → tłumaczenie/eksport
Poszczególne elementy były rozdzielane na niezależne komponenty uruchamiane w kontenerach. Takie podejście pozwala rozwijać jeden element bez konieczności przebudowy całego systemu.
Dlaczego potrzebny był ledger?
Przetwarzanie dokumentu nie jest operacją, którą zawsze można wykonać synchronicznie. OCR może potrwać kilka sekund albo znacznie dłużej, szczególnie przy cięższych modelach. Potrzebny był więc mechanizm, który wie:
- który dokument czeka,
- który jest aktualnie przetwarzany,
- który zakończył się poprawnie,
- który zakończył się błędem,
- czy operację można bezpiecznie powtórzyć.
Dlatego zastosowano centralny ledger stanów przetwarzania. Dokument przechodził przez stany takie jak:
available → processing → completed
albo:
available → processing → failed
To rozwiązanie może wydawać się mało efektowne w porównaniu z samym modelem AI. W praktyce jest jednak kluczowe. Bo produkcyjny system musi wiedzieć nie tylko jak przetworzyć dokument, ale także co się z nim dzieje, kiedy coś pójdzie nie tak.
Dane medyczne zmieniają architekturę
W zwykłym projekcie można często zacząć od pytania:
„Jaki cloud service będzie najprostszy?”
Przy dokumentacji medycznej dochodzą kolejne pytania:
- gdzie znajdują się dane?
- kto ma do nich dostęp?
- jak są przesyłane?
- jak są przechowywane?
- jak wygląda logowanie operacji?
- co dzieje się z kopią zapasową?
- co stanie się po awarii jednego komponentu?
- które elementy systemu rzeczywiście muszą mieć dostęp do danych wrażliwych?
Dlatego architektura projektu uwzględniała separację środowisk, konteneryzację, kontrolę dostępu, monitoring, backupy oraz mechanizmy bezpieczeństwa infrastruktury. Ważna była również koncepcja ograniczania ekspozycji danych. Jeżeli dany komponent nie potrzebuje pełnej dokumentacji, nie powinien automatycznie otrzymywać dostępu do wszystkiego. To jest praktyczna realizacja zasady: minimalizuj ilość danych i zakres dostępu tam, gdzie jest to możliwe.
Co było największym wyzwaniem?
Paradoksalnie nie był nim sam OCR. Najwięcej pracy wymagało połączenie kilku pozornie prostych elementów:
mobilnego skanowania + OCR + rekonstrukcji struktury + heurystyk + normalizacji + infrastruktury + obsługi błędów.
Każdy z tych elementów osobno jest stosunkowo łatwy do opisania. Problem pojawia się na granicach między nimi. OCR zwróci tekst, ale aplikacja potrzebuje struktury. Model znajdzie liczbę, ale system potrzebuje wiedzieć, czego ta liczba dotyczy. Dokument zostanie poprawnie przetworzony, ale system musi jeszcze wiedzieć, gdzie zapisać wynik. Serwer wykona zadanie, ale aplikacja musi wiedzieć, czy zadanie zakończyło się sukcesem. To właśnie te połączenia tworzą produkt.
Co zostało osiągnięte?
W ramach prac powstał działający przepływ przetwarzania dokumentów obejmujący między innymi:
- OCR lokalny i serwerowy,
- obsługę różnych orientacji dokumentu,
- rekonstrukcję struktury tekstu,
- identyfikację parametrów medycznych,
- rozpoznawanie jednostek,
- normalizację danych,
- przetwarzanie dokumentów w pipeline,
- panel do kontroli wyników,
- pomiar jakości OCR,
- ręczną korektę wyników,
- zapis danych w warstwie trwałej,
- konteneryzację poszczególnych elementów systemu.
Jednocześnie projekt pokazał, że dalsze zwiększanie jakości wymaga pracy nie tylko nad samym modelem, ale również nad logiką interpretacji dokumentu i jakością danych wejściowych.
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.
Czego ten system nie rozwiązuje?
To równie ważne jak lista funkcji. OCR nie zastępuje lekarza. Nie gwarantuje poprawności klinicznej. Nie rozwiązuje automatycznie problemu słabej jakości zdjęcia. Nie gwarantuje poprawnego przypisania każdej wartości do parametru. Nie sprawia też, że każdy dokument medyczny staje się od razu ustrukturyzowaną bazą danych.
Dlatego systemy tego typu powinny mieć jasno określone granice odpowiedzialności oraz mechanizmy wykrywania niepewnych wyników. W medycynie lepiej wiedzieć, że system czegoś nie jest pewien, niż udawać stuprocentową pewność.
7 rzeczy, które warto sprawdzić przed wdrożeniem OCR w dokumentacji medycznej
- Nie testuj tylko idealnych skanów
Sprawdź zdjęcia wykonane telefonem, różne oświetlenie, przekrzywione dokumenty i różne formaty.
- Mierz nie tylko tekst
Osobno sprawdzaj wartości liczbowe, jednostki, parametry i kompletność danych.
- Nie zakładaj, że OCR zachowa strukturę dokumentu
Tabela i tekst liniowy to dwa różne problemy.
- Zaprojektuj obsługę błędów od początku
Dokument może utknąć, model może zwrócić niepełny wynik, a infrastruktura może przestać działać.
- Zdecyduj, gdzie mają być przetwarzane dane
Lokalne przetwarzanie i serwer mają różne zalety, ograniczenia i konsekwencje architektoniczne.
- Oddziel OCR od logiki biznesowej
Model powinien być wymienialnym komponentem. Nie buduj całego systemu tak, jakby jeden model miał być rozwiązaniem na zawsze.
- Zdefiniuj, co oznacza „sukces”
99% znaków poprawnie rozpoznanych może być świetnym wynikiem technicznym, ale niewystarczającym wynikiem biznesowym lub klinicznym.
Podsumowanie
Największa zmiana w myśleniu o OCR pojawia się wtedy, kiedy przestajemy traktować go jako funkcję „odczytaj tekst”. W dokumentacji medycznej prawdziwym celem nie jest tekst. Celem są wiarygodne, uporządkowane i możliwe do dalszego wykorzystania dane.
Dlatego cały problem można sprowadzić do prostego łańcucha:
dokument → OCR → struktura → dane → walidacja → dalsze wykorzystanie
Każdy z tych etapów może być źródłem błędu. I właśnie dlatego dobry system OCR nie kończy się na wyborze najlepszego modelu. Najtrudniejsza część zaczyna się dopiero po tym, jak model zwróci tekst.
