Lo que describes apunta a un problema de codificación/locale y de tablas de traducción de E/S, no necesariamente a corrupción física de las bases de datos. En un caso parecido, se indica que cuando el locale está en enuw, la tabla de traducción para lectura puede ser RAW, mientras que otros locales tienen por defecto una tabla como UTF8. En ese escenario, los caracteres especiales pueden verse mal salvo que se especifique explícitamente la tabla de traducción o se use un locale cuyo valor por defecto sea adecuado. [1]

Además, en otro caso con terminales externos se recomienda comprobar que cliente y servidor usen la misma codificación. Se menciona revisar el valor de $ZMODE y, si aparece RAW en vez de UTF8, establecer manualmente la traducción del terminal con:

u 0:(/IOT="UTF8")
w $zm

Esto es especialmente relevante con WRQ Reflection, porque se comenta que algunos emuladores antiguos no pueden trabajar correctamente con UTF-8, o lo muestran pero no permiten introducir correctamente caracteres extendidos. [2]

También hay evidencia de que cambiar el locale puede tener impacto en la intercalación/ordenación y en comportamientos por defecto del sistema, especialmente en temporales como CACHETEMP/IRISTEMP, por lo que un cambio de ENUW a ESPW no es neutro y puede afectar más cosas que solo la visualización. [3]

Si en el terminal del sistema antiguo “todo parece normal” pero desde Reflection no puedes introducir ni visualizar bien acentos y eñes, el material recuperado sugiere revisar, en este orden:

1. el locale activo y sus tablas de traducción por defecto;
2. la traducción de E/S de la sesión/terminal, verificando si está en RAW o UTF8;
3. si WRQ Reflection soporta correctamente UTF-8 para entrada, porque hay antecedentes de que algunos emuladores no lo hacen bien. [1][2]

No puedo confirmar a partir del material recuperado que esto esté relacionado con que sea una licencia Community, porque no aparece soporte documental para esa relación en los resultados. [1][3][2]

Sources:

Tu propuesta encaja muy bien con varios patrones y capacidades ya mostrados sobre InterSystems IRIS, aunque en los documentos recuperados no aparece una solución específica de telemedicina con Chrome Extension MV3 + WebRTC + Whisper/GPT-4o-mini exactamente igual a la tuya. Sí hay material relevante para respaldar varios componentes de la arquitectura. [1][2][3][4]

Puedes presentar la parte de InterSystems IRIS como el backend que expone una REST API para recibir datos clínicos generados por la capa de IA. Hay un ejemplo directo de una clase REST en IRIS basada en %CSP.REST, con rutas definidas en XData UrlMap, recepción de parámetros desde %request y devolución de JSON con %ToJSON(). [3][4]

También puedes respaldar el uso de IRIS como capa de integración entre la API y servicios inteligentes mediante Interoperability / Productions. En los documentos se muestra un flujo donde una REST API llama a un BusinessService, que a su vez delega en un BusinessProcess y finalmente en un BusinessOperation; además, se indica que en la capa de operación puede hacerse la llamada al LLM mediante Python. Ese patrón es compatible con una canalización del tipo captura/transcripción → procesamiento semántico → generación de nota clínica → persistencia. [3][4]

Para la parte de documentación clínica, existe una aplicación llamada iris-CliniNote que demuestra que IRIS puede usarse como plataforma de documentación clínica con:

• gestión de pacientes,
• episodios,
• notas clínicas,
• REST API,
• ObjectScript,
• y capacidades semánticas con vector search. [2]

En concreto, iris-CliniNote se describe como una “Modern clinical documentation platform for tracking patient episodes and detailed notes with semantic search capabilities”, construida con InterSystems IRIS, ObjectScript, REST API y vector search. Esto te sirve como referencia para posicionar tu PoC dentro del ámbito de documentación clínica moderna apoyada en IA. [2]

Sobre la integración con IA, hay evidencia de proyectos en IRIS que usan un enfoque de asistente inteligente y comunicación con modelos externos. El proyecto IRIS Agent muestra integración de IA con IRIS usando interoperabilidad, generación automática de documentación OpenAPI para operaciones y un servidor intermedio en Node.js para comunicación mediante MCP. Aunque no trata telemedicina, sí valida el patrón de combinar IRIS + Node.js + servicios de IA como arquitectura práctica. [1]

Asimismo, hay un ejemplo de solución hospitalaria sobre IRIS que usa REST API, ObjectScript, Globals y SQL para integrar subsistemas clínicos y reducir complejidad de interfaces. Esto respalda tu mensaje de interoperabilidad clínica y de uso de IRIS como núcleo de integración entre componentes heterogéneos. [5]

Si quieres describir tu arquitectura de manera alineada con lo recuperado, podrías resumirla así:

• una interfaz de captura y experiencia de usuario para médico/paciente;
• una capa de procesamiento inteligente para transcripción y generación de contenido clínico;
• una REST API en InterSystems IRIS para ingreso estructurado de la minuta o nota;
• y una producción de interoperabilidad para enrutar, transformar y persistir la información clínica. [1][3][4]

Lo que sí no puedo respaldar con estos documentos es detalle específico sobre:

• Chrome Extension MV3,
• WebRTC/DataChannel/STUN,
• Whisper,
• GPT-4o-mini,
• UTF-8 + saneo ASCII para Latin-1,
• o una estructura exacta de endpoint como /api/telemed/minuta,
  
  porque eso no aparece descrito en los resultados recuperados. [1][2][3][4]

Si quieres, puedo ayudarte a convertir esta descripción en:

1. un texto técnico para LinkedIn/Open Exchange,
2. una arquitectura de referencia sobre IRIS, o
3. un esqueleto de implementación REST + Interoperability en ObjectScript usando solo los patrones mostrados en estas fuentes. [5][1][2][3][4]

Sources:

IntegratedML con AutoML puede tardar en PREDICT porque no se limita a “leer un valor ya calculado”, sino que aplica el modelo entrenado sobre los datos de entrada mediante funciones SQL como PREDICT(<modelo>). La documentación de uso muestra precisamente ese patrón de ejecución sobre filas de una tabla o vista, por ejemplo SELECT ..., PREDICT(TitanicSurvival) ... FROM ... o SELECT PREDICT(TestModel) FROM test_table LIMIT 1; [1][2]

En la información recuperada no aparece una explicación específica de por qué una predicción para una sola fila puede tardar prácticamente lo mismo que una predicción para unas 3300 filas, ni se documenta el comportamiento interno de coste fijo por invocación, materialización de la consulta base, caché, inicialización del proveedor o evaluación por lotes en PREDICT para AutoML. Por tanto, no puedo afirmar la causa exacta de ese comportamiento con base en estas fuentes. [2][1]

Sí hay indicios de que:

• el entrenamiento puede llevar tiempo según el tamaño y complejidad de los datos;
• AutoML realiza automáticamente tareas como selección de variables, codificación de datos y selección de modelo;
• para conjuntos grandes puede hacer muestreo durante la selección de modelos para acelerar el proceso de entrenamiento. [3][4]

Pero esos puntos hablan del TRAIN MODEL, no del coste concreto de PREDICT por una fila frente a miles, así que no bastan para justificar tu caso concreto. [3][4]

Para investigar con la información disponible, puedes revisar:

• INFORMATION_SCHEMA.ML_TRAINING_RUNS, donde se muestra duración y log del entrenamiento. [4]
• INFORMATION_SCHEMA.ML_MODELS, para confirmar definición del modelo y columnas WITH. [2][4]
• si la consulta de predicción se ejecuta sobre una vista compleja, comprobar también el coste de esa SELECT base por separado, porque PREDICT se usa dentro de una consulta SQL sobre la tabla o vista de entrada. [1][2]

Si compartes el SELECT exacto con el que estás invocando PREDICT, junto con el plan de ejecución SQL de esa consulta y si la fuente es la vista compleja o una tabla materializada, se podría acotar mejor qué parte del tiempo pertenece a la vista y cuál al propio PREDICT. [1][2]

Sources:

Sí, es posible establecer el idioma preferido en un manifiesto, y la referencia encontrada indica que para cambiar el idioma, la configuración que debes usar es Config.NLS.Locales -- Install(), no una simple etiqueta <SystemSetting> genérica. También indica que los locales disponibles se pueden ver en System Administration > Configuration > National Language Settings > Locale Definitions. [1]

La información recuperada no muestra el XML completo del manifiesto, pero sí afirma explícitamente que ese cambio “se puede poner en un manifest” usando Config.NLS.Locales -- Install(). [1]

Sources: