Centrum Komunikacji - aplikacja z tłumaczem języka migowego i platforma usług dla Polskiego Związku Głuchych

Najważniejsze informacje

• Order Group zbudował Centrum Komunikacji dla Polskiego Związku Głuchych w projekcie finansowanym z programu Fundusze Europejskie dla Rozwoju Społecznego 2021-2027 (FERS, EFS+).
• Prace zaczęły się od warsztatów w lipcu 2025. Aplikacja działa produkcyjnie od 20 kwietnia 2026 i jest dostępna jako "Centrum Komunikacji CK" w App Store i Google Play.
• Rozmowy wideo są szyfrowane end-to-end. Telefon działa w osobnym pokoju, więc nigdy tego szyfrowania nie osłabia.
• Przy transkrypcji na żywo pierwszy szkic przygotowuje rozpoznawanie mowy w przeglądarce, a specjalista poprawia każdy fragment, zanim zobaczy go użytkownik.
• PZG jest właścicielem kodu i ma do niego prawa autorskie. Rdzeń systemu działa na komponentach open source hostowanych w UE.

Projekt „Centrum Komunikacji dla Osób z Niepełnosprawnościami” trwa od 1 stycznia 2025. Order Group wygrał postępowanie na aplikację, ogłoszone w maju 2025, i przejął tworzenie oprogramowania na zamówienie. Poza aplikacją projekt prowadzi 16 regionalnych centrów komunikacji (RCK) i centralę w Warszawie, a aplikacja ewidencjonuje także usługi realizowane stacjonarnie. Zapytanie ofertowe określiło założenia planistyczne: co najmniej 13 000 usług i 2000 użytkowników w pierwszych 24 miesiącach, 24 miesiące utrzymania z SLA i hosting przez co najmniej siedem lat od startu. Aplikację znajdziesz w App Store i Google Play, a projekt na stronie centrumkomunikacji.org.pl.

Centrum Komunikacji obsługuje całe centrum usług. Ewidencjonuje każdą usługę, zdalną i w punkcie RCK, liczy godziny przysługujące każdemu użytkownikowi, zbiera formularz zrealizowanej usługi i przygotowuje raporty, które musi składać projekt finansowany z UE.

Z aplikacji korzystają osoby głuche, słabosłyszące i późno ogłuchłe, głuchoniewidome oraz niewidome i słabowidzące. Jedni migają w PJM, inni czytają tekst, jeszcze inni używają alfabetu Lorma, linijki brajlowskiej albo czytnika ekranu. Po drugiej stronie pracują tłumacze PJM, specjaliści transkrypcji, tłumacze-przewodnicy osób głuchoniewidomych, specjaliści od dokumentów, dyspozytorzy, koordynatorzy, kierownicy, koordynatorzy RCK i administratorzy. Użytkownik ma te same usługi na telefonie i w przeglądarce, a narzędzia pracowników działają w przeglądarce.

• Usługi zdalne: tłumaczenie PJM na żądanie, umawiane sesje do dwóch godzin, SOS i transkrypcja rozmowy telefonicznej na żywo.
• Usługi stacjonarne w punktach RCK: tłumacz PJM albo tłumacz-przewodnik osoby głuchoniewidomej do czterech godzin, zamawiany w aplikacji albo przez tłumacza w trakcie rozmowy.
• Dokumenty: tłumaczenie tekstu na PJM jako wideo i z PJM na tekst, brajl oraz dokumenty przygotowane dla czytników ekranu w formacie .docx lub .pdf. Pracę wykonują specjaliści PZG, a aplikacja prowadzi zamówienie, termin i odbiór.
• Reguły usług PZG zapisane w systemie: dokument w trzy dni robocze, brajl w dziesięć i zwrot godzin przy anulowaniu rezerwacji co najmniej 12 godzin wcześniej.

Każda usługa kończy się formularzem, a raporty obejmują działalność RCK i aktywnych beneficjentów, bez połączeń testowych. PJM jest częścią samego interfejsu: ekrany rejestracji, wymagania hasła, regulaminy i powiadomienia mają filmy w PJM. Gdy wniosek zostanie odrzucony, użytkownik dostaje powód jako film w PJM i na piśmie.

Zapytanie ofertowe wymagało rozmów wideo szyfrowanych end-to-end i jednocześnie nagrań na potrzeby reklamacji i kontroli jakości. Przy szyfrowaniu end-to-end serwer nie widzi rozmowy, więc nie może jej nagrać.

W Centrum Komunikacji pokój rozmowy, z użytkownikiem i pracownikami, jest szyfrowany end-to-end na urządzeniach uczestników. Serwer mediów przekazuje wyłącznie zaszyfrowane klatki. Nagranie powstaje w przeglądarce tłumacza, bo tłumacz jest uprawnionym uczestnikiem i widzi rozmowę w postaci jawnej.

• Klatki szyfruje LiveKit end-to-end: w przeglądarce w osobnym wątku roboczym (web worker), w aplikacji mobilnej przez natywny menedżer szyfrowania. Backend wydaje klucz pokoju razem z tokenem dostępu, tylko uczestnikom tego pokoju.
• Przeglądarka tłumacza składa obraz wszystkich uczestników w jeden kadr, miksuje dźwięk wszystkich stron, a w usłudze transkrypcji na żywo wypala zatwierdzony tekst w nagranie.
• Fragmenty nagrania zapisują się na bieżąco w IndexedDB, więc odświeżenie albo zamknięcie karty nie kasuje nagrania. Wysyłka do magazynu S3 idzie kolejką multipart z ponawianiem, a każda część ma sumę kontrolną SHA-256 liczoną w wątku roboczym i porównywaną przez magazyn.
• Zasady dotyczące danych: każde spotkanie online i każda rozmowa przez bramkę telefoniczną są nagrywane, wiadomości z czatu i załączniki są usuwane po 30 dniach, metadane zostają dłużej na potrzeby sprawozdawczości UE, a nagranie może otworzyć tylko administrator albo koordynator rozpatrujący reklamację.

Sieć telefoniczna nie obsługuje szyfrowania end-to-end, więc rozmowa telefoniczna nigdy nie wchodzi do szyfrowanego pokoju.

Osoba głucha chce zadzwonić do przychodni. Tłumacz musi być jednocześnie na wideo z nią i na telefonie z rejestracją. Typowe rozwiązanie to osobna centrala i program telefoniczny na komputerze tłumacza, czego PZG nie dopuścił.

Zbudowaliśmy mostek między dwoma pokojami. Rozmowa z osobą głuchą zostaje w pokoju szyfrowanym end-to-end. Telefon trafia do osobnego pokoju VoIP jako uczestnik SIP (LiveKit SIP). Tłumacz jest w obu pokojach naraz i dzwoni z tej samej aplikacji w przeglądarce, więc szyfrowana rozmowa nigdy nie styka się z linią telefoniczną, a obie strony słyszą się przez tłumacza.

• Mikrofon tłumacza nadaje do obu pokoi, przeglądarka miesza dźwięk z obu, a eliminacja echa zapobiega sprzężeniom.
• Gdy pokój telefoniczny się rozłączy, aplikacja wraca do niego z tym samym tokenem i nie przerywa rozmowy telefonicznej.
• Bramka SIP działa na tym samym, samodzielnie hostowanym stosie LiveKit, na własnych serwerach.
• Operatora telefonii zmienia się konfiguracją trunku SIP, bez przebudowy, zgodnie z wymaganiem zapytania ofertowego.
• Linia telefoniczna obsługuje też transkrypcję na żywo: osoba słabosłysząca dzwoni, a specjalista transkrybuje rozmówcę.
• Użytkownik może zadzwonić na 112 i inne numery alarmowe, a wybieranie tonowe (DTMF) działa w menu infolinii.

System zaprojektowano na 24 jednoczesne linie zewnętrzne i jeden numer wychodzący.

Osoba słabosłysząca w trakcie rozmowy telefonicznej potrzebuje słów rozmówcy jako tekstu na żywo. Automatyczne napisy przekręcają nazwiska, adresy i nazwy leków, a tu pomyłka ma konsekwencje. PZG nie dopuścił pokazywania nieobrobionego wyniku rozpoznawania mowy: tekst trzeba poprawić, zanim zobaczy go użytkownik, i to w trakcie rozmowy.

Specjalista pracuje w panelu, w którym rozpoznawanie mowy szkicuje tekst osobno dla każdego mówcy. Specjalista poprawia szkic i wysyła go fragmentami, a użytkownik widzi tylko zatwierdzony tekst.

• Szkic i tekst zatwierdzony mają różne kolory. Przepływ: szkic, korekta, wysyłka.
• Każdy mówca ma osobny strumień: klient, specjalista i rozmówca telefoniczny.
• Silnik to open source Vosk z polskim modelem mowy, uruchamiany w przeglądarce specjalisty przez WebAssembly. Rozpoznawanie mowy nie wysyła dźwięku do zewnętrznego API ani chmury AI.

Dla osoby niewidomej i głuchoniewidomej liczy się to, jak czytnik ekranu odczytuje każdy ekran, a tego lista kontrolna WCAG nie pokaże. Testowaliśmy z użytkownikami i na prawdziwych technologiach asystujących, w kilku rundach.

• Już w pierwszym miesiącu sprawdziliśmy, czy komponenty wideo spełniają WCAG.
• Audyt WCAG był częścią odbioru etapu, a jego zalecenia wdrożyliśmy przed startem.
• Testy z VoiceOver i TalkBack objęły każdy ekran, także to, jak odczytywane są numery telefonów, komunikaty typu toast i nazwy plików.
• Okna dialogowe zatrzymują czytnik ekranu w swoim obrębie, więc użytkownik VoiceOver porusza się tylko po kontrolkach samego okna.
• Klawiatura brajlowska w iOS działa w polach formularzy.
• Pasek aplikacji ma przełączniki rozmiaru tekstu i trybu wysokiego kontrastu.
• Linijki brajlowskie działają przez mechanizmy samego systemu operacyjnego, bez własnych modułów, tak jak zakładało zapytanie ofertowe.

Powiązane hasła w naszym słowniku: audyt dostępności, testy z czytnikami ekranu i zarządzanie fokusem.

Zmiana tłumacza bez przerywania rozmowy

Tłumaczenie PJM jest wyczerpujące i dobra praktyka to zmiana tłumacza co 20-30 minut. Gdy połączenie się przerwie, osoba głucha traci kontekst i musi opowiadać sprawę od nowa. Przy dłuższych sesjach w pokoju jest dwóch tłumaczy, a zmiana polega na przełączeniu aktywnego obrazu, więc rozmowa toczy się dalej. Aktywny tłumacz jest wyświetlany na pierwszym planie, a wyjście jednego tłumacza nie kończy rozmowy. Każdy typ usługi ma własne limity czasu: sesja na żądanie trwa 30 minut i tylko tłumacz może dodać kolejne 30, a SOS nie ma limitu dla dzwoniącego, tylko bezpiecznik techniczny. Dyspozytor może zmienić tłumacza w umówionej sesji. Jakość wideo dopasowuje się do łącza użytkownika.

Kolejki, SOS i nocne dyżury

Tłumaczy jest mniej niż osób, które ich potrzebują, a zgłoszenie SOS nie może czekać za pytaniem o czynsz. Każda usługa (SOS, PJM na żądanie, transkrypcja na żywo) ma własną kolejkę w czasie rzeczywistym, zbudowaną na WebSocket i Redis i sterowaną grafikiem dyżurów. Pracownik nasłuchuje kolejki tylko w godzinach swojej zmiany i tylko dla usług ze swojego grafiku. Dyżur może przechodzić przez północ. Użytkownik widzi swoje miejsce w kolejce, a tłumacz widzi, ile osób czeka. SOS ma najwyższy priorytet, każde użycie jest rejestrowane, a funkcję można zablokować przy nadużyciach. Razem z PZG zdecydowaliśmy, że zgłoszenia SOS trafiają do priorytetowej kolejki, bez automatycznego przekierowania przez dyspozytora. SOS nie zastępuje 112: tłumacz sam kontaktuje się ze służbami. Nocne dyżury SOS już działają. Dyspozytorzy śledzą na żywo w swoim panelu statusy pracowników, przerwy i liczniki dla każdej usługi, ręcznie przydzielają i przekazują zadania oraz pobierają raporty.

Tożsamość i zgody, online i w punktach RCK

Projekt unijny wymaga potwierdzonej tożsamości każdego uczestnika, a nie każdy może skorzystać z rządowego logowania. Tożsamość można potwierdzić na dwa sposoby. Online użytkownik robi to sam przez login.gov.pl, czyli Węzeł Krajowy (Profil Zaufany albo aplikacja mObywatel), i z tej ścieżki beneficjenci już korzystają. W punkcie RCK koordynator sprawdza dokument ze zdjęciem i generuje jednorazowy kod, który potwierdza konto. Orzeczenie o niepełnosprawności użytkownik może wgrać prosto z aparatu, zgody zbiera się przy rejestracji, a dane są usuwane na żądanie, zgodnie z RODO.

System przetwarza dane o zdrowiu i niepełnosprawności, jest finansowany ze środków publicznych, a zapytanie ofertowe wykluczyło wszystko, co po okresie wsparcia generowałoby opłaty: abonamenty, opłaty za minuty i SaaS bez wersji on-premise. Ma działać co najmniej siedem lat.

Główne komponenty (LiveKit, PostgreSQL, Redis, Vosk) są open source, więc nie ma opłat licencyjnych za minuty ani za użytkownika. Część infrastruktury działa na AWS, a hosting i dane zostają w UE.

• Wideo i telefonia działają na samodzielnie hostowanym LiveKit, serwerze mediów open source, bez API wideo płatnego za minuty. Instancje skalują się automatycznie pod obciążeniem, a warstwę wideo zaprojektowano na ponad 30 jednoczesnych sesji.
• Wysoką dostępność zapewniają klaster PostgreSQL z failoverem i Redis Sentinel.
• Dane są szyfrowane w bazie i w magazynie plików S3. Dozwolony jest tylko TLS 1.3, a ruch między load balancerem a serwerami idzie przez wzajemne uwierzytelnianie TLS (mTLS).
• Dostęp jest możliwy tylko przez VPN, wdrożenia idą wyłącznie przez tunel, SSH jest zamknięte z zewnątrz, panel administratora wymaga uwierzytelniania dwuskładnikowego, a działania administratorów są logowane.
• Monitoring obejmuje metryki infrastruktury i wideo w Grafanie, Sentry oraz SIEM Wazuh z ELK do wykrywania naruszeń.
• Testy bezpieczeństwa zakończyliśmy przed startem.
• Infrastruktura jest opisana jako kod.

• Dostępność jako inżynieria: testy z osobami głuchymi, niewidomymi i głuchoniewidomymi oraz na prawdziwych czytnikach ekranu, a PJM wbudowany w interfejs.
• Jeden samodzielnie hostowany stos mediów: wideo, telefon i nagrania na LiveKit, z mostkiem dwóch pokoi, który trzyma linię telefoniczną z dala od szyfrowanej rozmowy.
• Nagrania, które przetrwają zamknięcie karty: zapisywane na bieżąco i wysyłane z sumami kontrolnymi.
• Człowiek w pętli przy AI: rozpoznawanie mowy przyspiesza pracę specjalisty i nigdy nie decyduje, co zobaczy użytkownik.
• Reguły z praktyki zapisane w kodzie: system sam pilnuje zmian tłumaczy i standardów usług PZG.
• Własność: kod i prawa autorskie należą do klienta, a główne komponenty są open source, bez opłat licencyjnych za minuty czy za użytkownika.
• Od zapytania ofertowego do produkcji: specyfikacja rozpisana na moduły, odbiory etapów, szkolenia i utrzymanie z SLA.

• Lipiec 2025: warsztaty planistyczne i wymagania zapytania ofertowego rozpisane na moduły, każdy z odniesieniem do punktu specyfikacji.
• Lipiec-sierpień 2025: monorepo React i React Native (Expo) ze wspólnym kodem dla przeglądarki i aplikacji mobilnych oraz CI/CD od pierwszych tygodni.
• Wrzesień-październik 2025: czat, SOS, wideo, bramka telefoniczna i rejestracja. Etap 1 trafił do PZG do testów.
• Wrzesień 2025-styczeń 2026: warsztaty i testy z użytkownikami głuchymi i niewidomymi. Na ich podstawie wprowadziliśmy około 30 zmian UX i UI, m.in. paletę wysokiego kontrastu i obramowania przycisków, wyraźniej zaznaczone wybrane opcje, wąską kolumnę treści z przyciskami na dole, sekcję pomocy i powody odrzucenia w PJM.
• Luty-kwiecień 2026: infrastruktura produkcyjna, testy bezpieczeństwa i wydajności, audyt WCAG, odbiór etapu 2, szkolenia dla pracowników PZG i publikacja w App Store i Google Play. Po szkoleniach tłumacze poprosili o lustrzane odbicie własnego obrazu i je dodaliśmy.
• 20 kwietnia 2026: start produkcyjny.
• Od kwietnia 2026: utrzymanie. QA sprawdza każdą zmianę zgłoszoną przez pracowników PZG, zanim ją zamknie.

Te same osoby, które zbudowały system, wdrożyły go i dalej go utrzymują.