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: