Jitsi Meet: por qué la transcripción para historias clínicas electrónicas requiere Jigasi y Vosk

Jitsi Meet soporta transcripción, pero en un producto real resulta no ser un botón en la interfaz, sino una capa de infraestructura separada. En el caso de rellenado automático de historias clínicas electrónicas tras consultas por vídeo, esta capa resultó ser la más laboriosa: fue necesario reunir Jigasi, XMPP/SIP, Vosk y posprocesamiento con LLM.

Arquitectura Bajo el Capó

La idea básica de Jitsi parece simple solo en la superficie. La propia videollamada es gestionada por el frontend Jitsi Meet, el servidor de medios Jitsi Videobridge, el gestor de conferencias Jicofo y la capa XMPP Prosody. Pero la transcripción no vive dentro de un único botón en la interfaz.

Jigasi es responsable de ello — una pasarela separada que se conecta a la sala como un participante regular, recibe audio de los interlocutores y envía el flujo a un servicio externo de reconocimiento de voz. Esto crea una falsa sensación de simplicidad al inicio. Por eso la tarea rápidamente transita del nivel "conectar una API" al nivel de infraestructura.

No basta simplemente activar una opción en la UI, sino coordinar varios servicios, conexiones de red y un backend STT separado. En el caso analizado, tal backend era Vosk, ejecutándose sobre WebSocket. El enfoque en sí es conveniente para procesamiento asincrónico tras una consulta: el sistema no necesita ajustarse a latencias estrictas en tiempo real, y el texto resultante puede procesarse cómodamente después de que termine la llamada.

Dónde Falla el Esquema

El problema principal es que la transcripción tiene varios puntos de fallo independientes de inicio. La configuración de Jigasi, los parámetros del frontend Jitsi Meet y la disponibilidad del servicio STT deben coincidir simultáneamente. Si una capa está mal configurada, el sistema frecuentemente no falla con un error claro, sino que simplemente no entrega el resultado esperado: el bot no entra en la sala, el archivo no se guarda o el texto es demasiado débil para uso práctico. Sin revisar los logs, tales fallos son fáciles de confundir con aleatoriedad.

"Jigasi es una pasarela SIP con transcripción, no al revés".

• una cuenta XMPP separada para Jigasi en Prosody: si hay error con ella, el bot transcriptor no aparecerá en la conferencia;
• permisos en el directorio con transcripciones: los subtítulos intermedios pueden pasar, pero el archivo final no se guardará en disco;
• elección del modelo STT: Vosk básico funciona para MVP, pero maneja peor términos médicos, nombres de medicamentos y dosis;
• detección del fin de sesión: Jigasi escribe el texto final solo cuando la sala está realmente vacía, pero el pipeline downstream necesita un disparador confiable para procesamiento.

Un matiz separado es la separación de canales para guardar y enviar resultados. Un conjunto de parámetros es responsable de grabar el texto final en disco tras la conclusión de la consulta, otro de reenviar fragmentos intermedios a participantes vía XMPP. Para un producto que rellena historias electrónicas posteriormente, es más importante obtener confiadamente el archivo final que mostrar subtítulos en tiempo real. De lo contrario, la siguiente etapa de procesamiento no tiene nada desde donde iniciarse, y toda la automatización se congela.

Del Texto al Registro Médico

Incluso después de configurar exitosamente Jitsi, la tarea no termina. La salida de Jigasi es un diálogo bruto con timestamps: el médico hace preguntas, el paciente responde, luego vienen citas y recomendaciones. Para una historia clínica, tal texto es casi inútil en su forma original, porque el sistema necesita no réplicas como tales, sino entidades estructuradas: quejas, historial de síntomas, medicamentos, dosis, régimen de administración y acciones posteriores.

Entre el reconocimiento de voz e historia clínica permanece otra gran capa de transformaciones. Por eso otra capa fue necesaria sobre STT — procesamiento con LLM. El modelo normaliza texto, corrige algunos errores de reconocimiento basándose en contexto, y desglosa el resultado en campos compatibles con estructuras FHIR.

Después, los datos van a un formulario frontend donde el médico verifica y confirma el registro antes de guardarlo finalmente en la historia clínica. Tal human-in-the-loop aquí no es exceso de precaución, sino un requisito obligatorio: en un escenario clínico, no puede escribirse automáticamente medicamentos, dosis y prescripciones en el registro sin revisión. Aquí es donde la limitación del STT "barato" se hace visible.

Si el modelo básico reconoce mal vocabulario de dominio, toda la resto de la cadena comienza a gastar recursos en corregir errores. Para una versión production, sugieren modelos Vosk más pesados, un motor especializado como Deepgram con perfil médico, o una combinación de STT y normalización con LLM donde el modelo de lenguaje compensa errores de reconocimiento. De lo contrario, el costo de errores es demasiado alto ya a nivel del registro médico.

Qué Significa Esto

La historia de Jitsi Meet muestra algo simple: la transcripción para un producto AI aplicado es un subsistema separado, no una característica cosmética. Para un MVP, un esquema asincrónico con Jigasi y Vosk funcionará, pero para production en medicina, se necesita ajuste preciso de toda la pila, buenos logs, control de conclusión de sesión y una capa de normalización que convierta una conversación en datos adecuados para historias electrónicas. Cuanto más estricto el dominio, más cara resulta la ilusión de que todo se resuelve con una única casilla en la interfaz.