La forma recomendada para evitar problemas de comparación por representación interna de tipo es forzar ambos valores a la misma representación antes de buscar/comparar. En ObjectScript, el operador unario + convierte una expresión string a representación numérica; el operador _ concatena y fuerza a representación string. [1][2]

En tu caso, si stmtRsOs.Exame contiene un valor numérico como 1666, una opción práctica es convertir explícitamente el valor antes del Find(), por ejemplo usando +stmtRsOs.Exame si quieres comparación numérica, o stmtRsOs.Exame_"" si quieres comparación textual. [1][2]

El motivo es que en ObjectScript y especialmente en estructuras $LIST, valores “idénticos” pueden tener representaciones internas distintas; el documento muestra que listas como $lb("230") y $lb(230) no tienen necesariamente la misma representación interna, aunque conceptualmente representen el mismo valor. También indica que “Generally you can apply the unary-plus operator, +, to an ObjectScript string expression to change it from string representation into an ObjectScript numeric representation.” [1]

Así que, para garantizar consistencia, usa la misma conversión en ambos lados del proceso: guarda y busca como número, o guarda y busca como string, pero no mezcles representaciones. [1]

Ejemplos posibles:

If (..ListaProcedimento.Find(+stmtRsOs.Exame) = "") Quit

o

If (..ListaProcedimento.Find(stmtRsOs.Exame_"") = "") Quit

Si los valores de la lista representan códigos numéricos, la opción con + es la más adecuada; si quieres tratarlos como texto, usa _"". [1][2]

Sources:

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:

Sí, es posible, pero lo que aparece en la documentación es que EnsLib.FTP.InboundAdapter está pensado para que, cada vez que encuentre entrada en la ubicación configurada, invoque ProcessInput() del Business Service y luego tu OnProcessInput(). Es decir, su comportamiento normal es leer desde la ubicación FTP configurada y pasar el contenido al servicio asociado, no exponer de forma directa un mecanismo “bajo demanda” ya hecho. [1]

La forma soportada para adaptarlo a tu necesidad es crear un Business Service personalizado que extienda Ens.BusinessService, establezca Parameter ADAPTER = "EnsLib.FTP.InboundAdapter" e implemente OnProcessInput(). Ahí puedes decidir cómo tratar el stream recibido y enviarlo dentro de la producción con SendRequestSync() o SendRequestAsync(). [1]

También encaja con tu idea crear un servicio externo/API que dispare la ejecución cuando quieras, usando una implementación personalizada para controlar cuándo se procesa el directorio FTP. En la información recuperada se menciona explícitamente que es posible conseguir una ejecución “on demand” mediante personalización o mediante un servicio API que dispare el proceso cuando sea necesario. [2]

Además, se sugiere como alternativa usar un mecanismo de semaforización con SemaphoreSpec, de forma que quienes depositan el archivo también coloquen un fichero semáforo cuando quieran autorizar el procesamiento. [3]

Si lo que buscas es una solución práctica, las opciones que aparecen son estas:

1. Crear un Business Service personalizado con EnsLib.FTP.InboundAdapter y tu propia lógica de procesamiento. [1]
2. Exponer una API que active ese procesamiento solo cuando llegue la orden externa. [2]
3. Valorar SemaphoreSpec como mecanismo de control de cuándo procesar los archivos. [3]

[!TIP]

InterSystems IRIS® data platform also provides specialized business service classes that use this adapter, and one of those might be suitable for your needs. If so, no programming would be needed. See Connectivity Options. [1]

Sources:

IRIS no “activa” automáticamente un entorno virtual de Python para Embedded Python. En el material recuperado se describen dos formas compatibles de trabajar con paquetes:

1. instalar los paquetes directamente en la carpeta mgr/python de IRIS usando pip --target, o
2. usar un entorno virtual y añadir explícitamente su directorio site-packages a sys.path antes de importar módulos. [1]

Para el caso de un entorno virtual, lo que se muestra es añadir la ruta de site-packages, no la carpeta bin. El ejemplo recuperado es este: [1]

set sys = ##class(%SYS.Python).Import("sys")
do sys.path.append("/where/you/want/your/venv/lib/pythonX.X/site-packages")
set requests = ##class(%SYS.Python).Import("requests")

[1]

Por eso, definir IRIS_PYTHON_PATH=/usr/irissys/.venv/bin/ en docker-compose.yml no aparece en el material recuperado como mecanismo para que Embedded Python encuentre paquetes del entorno virtual. Lo que sí aparece es añadir a sys.path el directorio site-packages del venv, no bin. [1]

Si quieres que los paquetes estén disponibles sin gestionar manualmente la ruta del entorno virtual, el material recuperado sugiere instalarlos directamente en la ubicación de módulos Python de IRIS usando pip --target=/path/to/your/iris/mgr/python .... [1]

También se recupera una referencia a un artículo con más detalles sobre entornos virtuales y a una librería para ayudar a configurar un único venv para IRIS, pero en el contenido recuperado no se aportan más detalles técnicos que permitan confirmar una configuración global basada en IRIS_PYTHON_PATH. [1]

En resumen, la sugerencia sustentada por el material es:

• no apuntar a .venv/bin/, sino al site-packages del entorno virtual en tiempo de ejecución con sys.path.append(...); o
• instalar las dependencias directamente en mgr/python con pip --target. [1]

Sources:

No he podido encontrar información sobre este error específico ("Protocol Error between the Web Gateway and InterSystems IRIS") en los documentos consultados. Si reformulas tu consulta o buscas otras maneras de expresar el problema, puedo intentar de nuevo. También puedes explorar los siguientes recursos:

1. Web Gateway Guide.
2. Configuración de acceso del Web Gateway.
3. Gestión del Web Gateway.

Si tienes detalles técnicos adicionales o cambios realizados en la configuración, compártelos para una mejor investigación.