Centrum Komunikacji - A Sign Language Interpreter App and Service Platform for the Polish Association of the Deaf

Key takeaways

• Order Group built Centrum Komunikacji for the Polish Association of the Deaf in a project funded by the European Funds for Social Development 2021-2027 (FERS, ESF+).
• Work started with workshops in July 2025. The app went into production on 20 April 2026 and is published as "Centrum Komunikacji CK" in the App Store and Google Play.
• Video calls are end-to-end encrypted. Phone calls run through a separate room, so they never weaken that encryption.
• Live transcription starts as in-browser speech recognition, and a specialist corrects every fragment before the user sees it.
• PZG owns the code and the copyright. The core of the system runs on open-source components hosted in the EU.

The project "Centrum Komunikacji dla Osób z Niepełnosprawnościami" (Communication Centre for People with Disabilities) has been running since 1 January 2025. Order Group won the tender for the app, published in May 2025, and took on the custom software development. Besides the app, the project runs 16 regional communication centres (RCK) and a head office in Warsaw, and the app records the services delivered there too. The tender set the planning assumptions: at least 13,000 services and 2,000 users in the first 24 months, 24 months of maintenance with an SLA, and hosting for at least seven years from launch. You can find the app in the App Store and Google Play, and the project at centrumkomunikacji.org.pl.

Centrum Komunikacji runs a whole service centre. It records every service, remote or delivered at an RCK point, tracks each user's hour allowance, collects a service completion form and produces the reports an EU-funded project has to submit.

Users include Deaf, hard-of-hearing and late-deafened people, deafblind people, and blind and partially sighted people. Some sign in PJM, some read text, and some use the Lorm alphabet, a braille display or a screen reader. On the other side work PJM interpreters, transcription specialists, deafblind guide-interpreters, document specialists, dispatchers, coordinators, managers, RCK coordinators and administrators. Users get the same services on a phone and in a browser, and staff tools run in the browser.

• Remote services: on-demand PJM interpreting, booked sessions of up to two hours, SOS, and live transcription of a phone call.
• On-site services at RCK points: a PJM interpreter or a deafblind guide-interpreter for up to four hours, booked in the app or by an interpreter during a call.
• Documents: translation between text and PJM video, braille, and documents prepared for screen readers in .docx or .pdf. PZG specialists do the work, and the app handles the order, the deadline and the delivery.
• PZG service rules in the system: documents within three working days and braille within ten, and hours returned when a booking is cancelled at least 12 hours ahead.

Every service ends with a completion form, and the reports cover RCK activity and active beneficiaries, without test calls. PJM is part of the interface itself: registration screens, password requirements, terms of service and notifications come with PJM videos. When an application is rejected, the user gets the reason as a PJM video as well as in writing.

The tender required end-to-end encrypted video calls and, at the same time, recordings for complaints and quality control. With end-to-end encryption the server cannot see the call, so it cannot record it.

In Centrum Komunikacji the call room, with the user and staff, is end-to-end encrypted on the participants' devices. The media server forwards encrypted frames only. The recording is made in the interpreter's browser, because the interpreter is an authorised participant who sees the call in plain form.

• Frames are encrypted with LiveKit end-to-end encryption: in the browser in a separate web worker, and in the mobile app through the native encryption manager. The backend issues each room key together with the access token, only to the participants of that room.
• The interpreter's browser composes all participants into one frame, mixes the audio of every side and, in the live transcription service, burns the approved text into the recording.
• Recording fragments are saved to IndexedDB as the call goes on, so refreshing or closing the tab does not lose the recording. Upload to S3 storage runs as a retrying multipart queue, and every part carries a SHA-256 checksum computed in a worker and compared by the storage.
• Data rules: every online meeting and every phone call through the gateway is recorded, chat messages and attachments are deleted after 30 days, metadata is kept longer for EU reporting, and only an administrator or coordinator handling a complaint can open a recording.

The phone network does not support end-to-end encryption, so a phone call never joins the encrypted room.

A Deaf person wants to call a clinic. The interpreter has to be on video with them and on the phone with the receptionist at the same time. The usual answer is a separate PBX and a softphone on the interpreter's computer, which PZG ruled out.

We built a bridge between two rooms. The conversation with the Deaf person stays in the end-to-end encrypted room. The phone call goes to a separate VoIP room as a SIP participant (LiveKit SIP). The interpreter sits in both rooms at once and dials from the same browser app, so the encrypted call is never exposed to the phone line and both sides hear each other through the interpreter.

• The interpreter's microphone feeds both rooms, the browser mixes sound from both, and echo cancellation prevents feedback.
• If the phone room drops, the app rejoins it with the same token and keeps the phone call alive.
• The SIP gateway runs on the same self-hosted LiveKit stack, on its own servers.
• The phone operator can be changed by configuring the SIP trunk, without rebuilding anything, as the tender required.
• The phone line also serves live transcription: a hard-of-hearing person makes the call and a specialist transcribes the other side.
• Users can call 112 and other emergency numbers, and tone dialling (DTMF) works for hotline menus.

The system was designed for 24 simultaneous outside lines and a single outgoing number.

A hard-of-hearing person on a phone call needs the other side as live text. Automatic captions get names, addresses and drug names wrong, and here a mistake has consequences. PZG ruled out raw speech recognition: the text has to be corrected before the user sees it, during the call.

The specialist works in a panel where speech recognition drafts the text separately for each speaker. The specialist corrects the draft and sends it in fragments, and the user sees approved text only.

• Draft text and approved text have different colours. The flow is draft, correction, send.
• Each speaker gets a separate stream: the client, the specialist and the person on the phone.
• The engine is open-source Vosk with a Polish speech model, running in the specialist's browser through WebAssembly. Speech recognition does not send audio to an outside API or an AI cloud.

Blind and deafblind users depend on how a screen reader reads each screen, which a WCAG checklist does not show. We tested with users and with real assistive technology in several rounds.

• In the first month we checked whether the video components met WCAG.
• A WCAG audit was part of milestone acceptance, and its recommendations were implemented before launch.
• Tests with VoiceOver and TalkBack went through every screen, including how phone numbers, toasts and file names are read out.
• Dialogs keep the screen reader inside them, so a VoiceOver user moves only through the dialog's own controls.
• The iOS braille keyboard works in form fields.
• The app bar has switches for text size and a high-contrast mode.
• Braille displays work through the operating system's own mechanisms, as the tender assumed, without custom modules.

Related terms in our glossary: accessibility audit, screen reader testing and focus management.

Interpreter changes that do not interrupt the call

PJM interpreting is exhausting, and good practice is to change interpreters every 20-30 minutes. If the call is cut, the Deaf person loses context and has to explain everything again. For longer sessions two interpreters sit in the room, and a change means switching the active video, so the conversation keeps going. The active interpreter is shown first, and one interpreter leaving does not end the call. Each service type has its own time limits: an on-demand session lasts 30 minutes and only the interpreter can add another 30, and SOS has no limit for the caller, only a technical safeguard. A dispatcher can swap the interpreter in a booked session. Video quality adapts to the user's connection.

Queues, SOS and night shifts

There are fewer interpreters than people who need one, and an SOS call cannot wait behind a question about rent. Each service (SOS, on-demand PJM, live transcription) has its own real-time queue built on WebSocket and Redis and driven by the duty roster, and a staff member listens to a queue only during their shift and only for the services on their roster. Shifts can cross midnight. Users see their place in the queue, and interpreters see how many people are waiting. SOS has the highest priority, every use is logged, and the function can be blocked if it is misused. Together with PZG we decided that SOS calls go to a priority queue, without automatic forwarding by a dispatcher. SOS does not replace 112: the interpreter contacts the emergency services. Night SOS shifts run in production. On a live panel, dispatchers follow staff status, breaks and per-service counters, assign and hand over tasks manually, and pull reports.

Identity and consent, online and at RCK points

An EU project needs a confirmed identity for every participant, and not everyone can use Poland's government login service. There are two ways to confirm identity. Online, the user does it on their own through login.gov.pl, the National Node (Profil Zaufany or the mObywatel app), and beneficiaries already use this path in production. At an RCK point, a coordinator checks a photo ID and generates a one-time code that confirms the account. The user can upload a disability certificate straight from the camera, consents are collected at registration, and data is deleted on request, as GDPR requires.

The system handles health and disability data, it is publicly funded, and the tender banned anything that would bring fees after the support period: subscriptions, per-minute charges, or SaaS without an on-premise option. It has to keep running for at least seven years.

The core components (LiveKit, PostgreSQL, Redis, Vosk) are open source, so there are no per-minute or per-user licence fees. Part of the infrastructure runs on AWS, and hosting and data stay in the EU.

• Video and telephony run on self-hosted LiveKit, an open-source media server, with no per-minute video API. Instances autoscale under load, and the video layer was designed for 30+ simultaneous sessions.
• High availability comes from a PostgreSQL cluster with failover and Redis Sentinel.
• Data is encrypted in the database and in S3 file storage. Only TLS 1.3 is allowed, and traffic between the load balancer and the servers uses mutual TLS.
• Access goes through a VPN, deployments run only through the tunnel, SSH is closed to the outside, the admin panel requires two-factor authentication, and admin actions are logged.
• Monitoring covers Grafana metrics for infrastructure and video, Sentry, and a Wazuh SIEM with ELK for detecting breaches.
• Security tests were completed before launch.
• The infrastructure is defined as code.

• Accessibility as engineering: testing with Deaf, blind and deafblind users and with real screen readers, and PJM built into the interface.
• One self-hosted media stack: video, phone and recordings on LiveKit, with a two-room bridge that keeps the phone line away from the encrypted call.
• Recordings that survive a closed tab: saved as the call goes on and uploaded with checksums.
• A person in the loop with AI: speech recognition speeds up the specialist and never decides what the user sees.
• Rules from practice, written into code: the system itself enforces interpreter shifts and PZG service standards.
• Ownership: the client owns the code and the copyright, and the core components are open source, with no per-minute or per-user licence fees.
• From tender to production: the specification split into modules, milestone acceptance, training and maintenance with an SLA.

• July 2025: planning workshops, and the tender requirements split into modules, each traced to a point of the specification.
• July-August 2025: a React and React Native (Expo) monorepo with shared code for web and mobile, and CI/CD from the first weeks.
• September-October 2025: chat, SOS, video, the phone gateway and registration. The stage 1 milestone went to PZG for testing.
• September 2025-January 2026: workshops and tests with Deaf and blind users. They produced a package of around 30 UX and UI changes: a high-contrast palette and button outlines, clearer selected states, a narrow content column with buttons at the bottom, a help section, and rejection reasons in PJM.
• February-April 2026: production infrastructure, security and performance tests, the WCAG audit, the stage 2 milestone, training for PZG staff, and publication in the App Store and Google Play. After training, interpreters asked to see their own image mirrored, and we added it.
• 20 April 2026: production launch.
• Since April 2026: maintenance. QA checks every change requested by PZG staff before it is closed.

The same people who built the system deployed it and still maintain it.