Jitsi Meet: por que a transcrição para prontuários eletrônicos exige Jigasi e Vosk

O Jitsi Meet oferece suporte a transcrição, mas num produto real isso não é um interruptor na interface, e sim um circuito de infraestrutura à parte. No caso do preenchimento automático de EMR após videoconsultas, essa camada foi a mais trabalhosa: foi preciso juntar Jigasi, XMPP/SIP, Vosk e pós-processamento com LLM.

Arquitetura por baixo do capô

A ideia básica do Jitsi só parece simples por fora. A videochamada em si é atendida pelo frontend do Jitsi Meet, pelo servidor de mídia Jitsi Videobridge, pelo gerenciador de conferências Jicofo e pela camada XMPP do Prosody. Mas a transcrição não vive dentro de um único botão da interface. Quem cuida dela é o Jigasi, um gateway separado que se conecta à sala como um participante comum, recebe o áudio dos interlocutores e envia o fluxo a um serviço externo de reconhecimento de fala.

Isso cria uma falsa sensação de simplicidade no início. Por causa disso, a tarefa passa rapidamente de «conectar uma API» para um problema de infraestrutura. Não basta ativar uma opção na UI: é preciso alinhar vários serviços, conexões de rede e um backend de STT separado. No caso analisado, esse backend foi o Vosk, executado via WebSocket. A abordagem é conveniente para o processamento assíncrono após a consulta: o sistema não precisa cumprir as latências rígidas do modo ao vivo, e o texto final pode ser analisado com calma depois que a chamada termina.

Onde o esquema quebra

O principal problema é que a transcrição tem aqui vários pontos de falha independentes. A configuração do Jigasi, os parâmetros do frontend do Jitsi Meet e a disponibilidade do serviço de STT precisam coincidir ao mesmo tempo. Se uma camada estiver mal configurada, o sistema muitas vezes não cai com um erro claro, apenas não entrega o resultado esperado: o bot não entra na sala, o arquivo não é salvo ou o texto fica fraco demais para uso prático. Sem olhar os logs, essas falhas são facilmente confundidas com acaso.

«O

Jigasi é um SIP gateway com transcrição, e não o contrário».

• uma conta XMPP separada para o Jigasi no Prosody: se houver erro nela, o transcriber bot não aparece na conferência;
• permissões no diretório de transcrições: legendas intermediárias podem fluir, mas o arquivo final não ser salvo em disco;
• escolha do modelo de STT: o Vosk básico serve para um MVP, mas lida pior com termos médicos, nomes de medicamentos e dosagens;
• detecção do fim da sessão: o Jigasi só grava o texto final quando a sala realmente esvazia, e o pipeline downstream precisa de um gatilho confiável para iniciar o processamento.

Um detalhe à parte é a separação entre os canais de salvamento e de envio dos resultados. Um conjunto de parâmetros controla a gravação do texto final em disco após a consulta; outro, o encaminhamento de trechos intermediários aos participantes via XMPP. Para um produto que preenche o EMR a posteriori, importa mais obter com garantia o arquivo final do que exibir legendas em tempo real. Caso contrário, a etapa seguinte não tem de onde partir, e toda a automação trava.

Do texto ao EMR

Mesmo depois de configurar o Jitsi com sucesso, o trabalho não termina. A saída do Jigasi é um diálogo bruto com marcações de tempo: o médico faz perguntas, o paciente responde, e em seguida vêm as prescrições e recomendações. Para um prontuário, esse texto é quase inútil na forma original, porque o sistema não precisa das falas em si, mas de entidades estruturadas: queixas, histórico de sintomas, medicamentos, dosagens, posologia e próximos passos. Entre o reconhecimento de fala e o EMR ainda há uma grande camada de transformações.

Por isso, foi preciso mais uma camada sobre o STT: o processamento com LLM. O modelo normaliza o texto, corrige parte dos erros de reconhecimento pelo contexto e distribui o resultado em campos compatíveis com estruturas FHIR. Depois, os dados vão para um formulário no frontend, onde o médico revisa e confirma o registro antes do salvamento final no EMR. Esse human-in-the-loop não é excesso de cautela, mas exigência obrigatória: em um cenário clínico, não se pode gravar automaticamente no prontuário, sem revisão, medicamentos, doses e prescrições.

É aqui que fica clara a limitação do STT «barato». Se o modelo básico reconhece mal o vocabulário do domínio, o resto da cadeia passa a gastar recursos corrigindo erros. Para uma versão de produção, surgem como opções modelos Vosk mais pesados, um motor especializado como o Deepgram com perfil médico ou uma combinação de STT e normalização com LLM, em que o modelo de linguagem compensa as falhas do reconhecimento. Do contrário, o custo dos erros é alto demais já no nível do registro médico.

O que isso significa

A história do Jitsi Meet mostra algo simples: a transcrição para um produto de IA aplicado é um subsistema separado, não um recurso cosmético. Para um MVP, serve um esquema assíncrono com Jigasi e Vosk, mas para produção na medicina são necessários ajuste preciso de toda a pilha, bons logs, controle do encerramento da sessão e uma camada de normalização que transforme a conversa em dados adequados ao EMR. Quanto mais rigoroso o domínio, mais cara fica a ilusão de que tudo se resolve com uma caixinha de seleção na interface.