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

O Jitsi Meet suporta transcrição, mas em um produto real isso acaba sendo não um botão na interface, mas uma camada de infraestrutura separada. No caso de preenchimento automático de prontuários eletrônicos após consultas por vídeo, essa camada provou ser a mais trabalhosa: foi necessário unir Jigasi, XMPP/SIP, Vosk e pós-processamento com LLM.

Arquitetura Sob o Capô

A ideia básica do Jitsi parece simples apenas na superfície. A própria videochamada é gerenciada pelo frontend Jitsi Meet, pelo servidor de mídia Jitsi Videobridge, pelo gerenciador de conferências Jicofo e pela camada XMPP Prosody. Mas a transcrição não vive dentro de um único botão na interface.

Jigasi é responsável por isso — um gateway separado que se conecta à sala como um participante regular, recebe áudio dos interlocutores e envia o fluxo para um serviço externo de reconhecimento de fala. Isso cria uma falsa sensação de simplicidade no início. Por causa disso, a tarefa rapidamente transita do nível "conectar uma API" para o nível de infraestrutura.

Você não precisa apenas ativar uma opção na UI, mas coordenar vários serviços, conexões de rede e um backend STT separado. No caso analisado, tal backend era Vosk, rodando sobre WebSocket. A abordagem em si é conveniente para processamento assíncrono após uma consulta: o sistema não precisa se encaixar em latências estritas em tempo real, e o texto resultante pode ser confortavelmente analisado após a chamada terminar.

Onde o Esquema Quebra

O principal problema é que a transcrição tem vários pontos de falha independentes logo de cara. A configuração do Jigasi, os parâmetros do frontend Jitsi Meet e a disponibilidade do serviço STT devem coincidir ao mesmo tempo. Se uma camada estiver mal configurada, o sistema frequentemente não falha com um erro claro, mas simplesmente não entrega o resultado esperado: o bot não entra na sala, o arquivo não é salvo ou o texto é muito fraco para uso prático. Sem visualizar os logs, essas falhas são fáceis de confundir com acaso.

"Jigasi é um gateway SIP com transcrição, não o oposto".

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

Uma nuance separada é a separação de canais para salvar e enviar resultados. Um conjunto de parâmetros é responsável por gravar o texto final no disco após a conclusão da consulta, outro por encaminhar fragmentos intermediários aos participantes via XMPP. Para um produto que preenche prontuários após o fato, é mais importante obter confiadamente o arquivo final do que mostrar legendas em tempo real. Caso contrário, o próximo estágio de processamento não tem nada para começar, e toda a automação trava.

Do Texto ao Prontuário

Mesmo após configurar com sucesso o Jitsi, a tarefa não termina. A saída do Jigasi é um diálogo bruto com timestamps: o médico faz perguntas, o paciente responde, depois vêm consultas e recomendações. Para um prontuário médico, tal texto é quase inútil em sua forma original, porque o sistema precisa não de réplicas como tais, mas de entidades estruturadas: queixas, histórico de sintomas, medicamentos, dosagens, esquema de administração e ações futuras.

Entre o reconhecimento de fala e o prontuário permanece outra grande camada de transformações. É por isso que outra camada foi necessária no topo do STT — processamento com LLM. O modelo normaliza texto, corrige alguns erros de reconhecimento baseado em contexto, e divide o resultado em campos compatíveis com estruturas FHIR.

Depois disso, os dados vão para um formulário frontend onde o médico verifica e confirma o registro antes de salvar finalmente no prontuário. Tal human-in-the-loop aqui não é excesso de cautela, mas um requisito obrigatório: em um cenário clínico, você não pode escrever automaticamente drogas, doses e prescrições no prontuário sem revisão. É aqui que a limitação do STT "barato" fica visível.

Se o modelo básico reconhece mal vocabulário de domínio, toda a resto da cadeia começa a gastar recursos em corrigir erros. Para uma versão production, modelos Vosk mais pesados sugerem-se, um mecanismo especializado como Deepgram com perfil médico, ou uma combinação de STT e normalização com LLM onde o modelo de linguagem compensa erros de reconhecimento. Caso contrário, o custo de erros é muito alto já no nível do registro médico.

O Que Isso Significa

A história do Jitsi Meet mostra uma coisa simples: transcrição para um produto AI aplicado é um subsistema separado, não um recurso cosmético. Para um MVP, um esquema assíncrono com Jigasi e Vosk funcionará, mas para production em medicina, é necessário ajuste preciso de toda a pilha, bons logs, controle de conclusão de sessão e uma camada de normalização que transforme uma conversa em dados adequados para prontuários. Quanto mais rigoroso o domínio, mais caro fica a ilusão de que tudo é resolvido com uma única caixa de seleção na interface.