Wróć do projektów

6000 stron dokumentacji dentystycznej w CRM w 38 dni

Historie leczenia 800 pacjentów uwięzione na papierze. W 11 dni zbudowałem aplikację do skanowania i dyktowania notatek. Trzy osoby z zespołu asysty stomatologicznej przeniosły dokumentację do CRM w kolejne 27 dni, sprawdzając każdy wpis przed importem.

4 min czytania
  • React
  • Google Cloud
  • OCR
  • Zamiana mowy na tekst
  • Migracja danych
UdostępnijXEmailFacebookWhatsApp

Był mniej więcej marzec 2025 roku. Hiszpański program Kit Digital oferował dotacje z funduszy unijnych na wdrażanie narzędzi cyfrowych w małych firmach, również jednoosobowych. Klinika miała już nowy CRM. Historie leczenia pacjentów z wielu lat nadal leżały na papierze.

Pracowało tam na pełen etat trzech dentystów, każdy z osobą do asysty. CRM obsługiwał wizyty, dokumentację pacjentów, kontakt w sprawie ofert i dalszą komunikację. Klinika chciała mieć w nim również dotychczasowe historie leczenia.

Archiwum obejmowało około 800 pacjentów i mniej więcej 3000 kartek, często zapisanych z obu stron. Część dało się odczytać bez problemu. Reszta wyglądała tak, jak można się spodziewać po latach notatek robionych przez dentystów.

Kiedy się do mnie odezwali, zespół asysty już przepisywał dokumentację do CRM. Odczytać odręczne notatki, przepisać, sprawdzić. Następna kartka. A wszystko to obok normalnej pracy przy pacjentach.

Skoro już wiadomo, gdzie boli...

...pora znaleźć rozwiązanie.

Wystarczyło jedno spotkanie. Właściciel opowiedział mi o problemie i o tym, co miał do dyspozycji. Trzy osoby znały dokumentację, potrafiły przypisać ją do pacjentów i mogły zająć się archiwum między wizytami albo w przeznaczonym na to czasie.

Na tej podstawie ustaliłem, co rozwiązanie musi zapewnić:

  • Dać się pogodzić z codzienną pracą zespołu w klinice.
  • Ograniczyć przepisywanie, również wtedy, gdy pismo okaże się zbyt nieczytelne dla OCR.
  • Pozwolić sprawdzić i poprawić każdy wpis, zanim trafi do dokumentacji pacjenta.
  • Przygotować dane w formacie, który przyjmie istniejący CRM.
  • Dać się szybko zbudować i być proste w obsłudze dla tych trzech osób. Mieliśmy do przerobienia jedno archiwum.

Wróciłem z trzema strategiami i rekomendacją.

  1. Sam zajmę się transkrypcją i przygotuję pliki do importu. Odciążyłoby to zespół, ale klinika i tak musiałaby pomagać przy nieczytelnych notatkach i przypisywaniu ich do pacjentów. Miała już ludzi, którzy znali archiwum, i czas, żeby się nim zająć.
  2. Zespół dalej przepisuje wszystko ręcznie. Niczego nie trzeba budować, ale każdą kartkę nadal trzeba przepisać. Ktoś już raz zapisał te notatki. Kazanie komuś robić to drugi raz wydawało mi się kiepskim wykorzystaniem czasu.
  3. Zbuduję małe narzędzie do fotografowania lub dyktowania notatek i sprawdzania tekstu przed importem. Najpierw trzeba byłoby poświęcić trochę czasu na aplikację. Potem klinika mogłaby wykorzystać ludzi i czas, które już miała, bez mozolnego wklepywania większości tekstu.

Poleciłem trzecią opcję. Zespół znał dokumentację, więc mógł skupić się na sprawdzaniu treści i przypisywaniu jej do pacjentów. Aplikacja zajmowałaby się transkrypcją. Dyktowanie pozwalało przejść przez notatki, z którymi OCR sobie nie radził.

Właściciel dostał opcje i moje uzasadnienie, żeby podjąć decyzję. Nie musiał sam wymyślać, jak ma działać aplikacja. Ustaliłem wymagania, rozpisałem specyfikację, zaprojektowałem kolejne kroki pracy zespołu i zbudowałem narzędzie.

Skoro to czytasz, pewnie już wiesz, którą opcję wybrał.

Zrobiłem aplikację w React, działającą w przeglądarce na telefonie. Trzy konta pracownicze, bez publicznej rejestracji. Te trzy osoby to byli wszyscy jej użytkownicy.

Dokument można było wprowadzić na dwa sposoby.

Zrób zdjęcie

Osoba z zespołu fotografowała kartkę i przesyłała zdjęcie. Google OCR odczytywał odręczne notatki po hiszpańsku i zwracał tekst wraz z oceną pewności odczytu.

Ustaliliśmy próg pewności na 88%. Poniżej niego aplikacja proponowała dyktowanie. Od 88% tekst trafiał do sprawdzenia. Wynik OCR nigdy nie zastępował kontroli treści medycznej przez człowieka.

Przeczytaj na głos

Gdy OCR sobie nie radził, wystarczyło przeczytać notatki na głos. Google Speech-to-Text V2 zamieniał nagranie na tekst. Jeśli człowiek potrafił odczytać pismo, mógł podyktować treść zamiast ją przepisywać.

Obie ścieżki kończyły się sprawdzeniem i poprawkami. Aplikacja przygotowywała JSON lub CSV do importu, a zespół przypisywał każdy wpis do właściwego pacjenta w CRM.

Kartka po kartce

Zbudowanie aplikacji zajęło mi 11 dni roboczych. Zespół przerobił archiwum w kolejnych 27 dniach roboczych. Razem 38 dni roboczych na aplikację i digitalizację.

Z 3000 kartek:

  • 1920 przeszło przez OCR, czyli 64%.
  • 750 podyktowano, czyli 25%.
  • 330 nie trafiło do importu do CRM, czyli 11%.

Biorąc pod uwagę niektóre próbki pisma, 64% przez OCR to więcej, niż się spodziewałem.

Ostatecznie istniejący zespół kliniki przepisał z pomocą aplikacji, sprawdził i zaimportował treść 2670 kartek, łącząc to ze swoimi obowiązkami. Nie mam wiarygodnej liczby zaoszczędzonych godzin. Mogę za to podać liczbę kartek i czas realizacji. Decyzje o dalszych losach papierowego archiwum były poza zakresem mojej pracy.

Aplikacja nie jest już używana. Zrobiła swoje i przeszła na emeryturę. Szczerze? Należało jej się :)

Właśnie dlatego tak lubię ten projekt. Trzy osoby, stos papieru i konkretny problem, który mogłem rozwiązać. Wiedziałem, dla kogo buduję, co ma do dyspozycji i po czym poznamy, że skończyliśmy.

Nie musiałem wyobrażać sobie miliona przyszłych użytkowników. Wszyscy moi użytkownicy zmieściliby się przy jednym stole. Mogłem zająć się tym, co naprawdę im pomoże, jak odczytanie bazgrołów i sprawdzenie tekstu przed importem.

A potem doszli do końca archiwum. I tyle. Skończył się papier do karmienia aplikacji. Jest coś pięknego w tworzeniu oprogramowania, które sprawia, że samo przestaje być potrzebne. Chętnie zrobiłbym więcej takich projektów.