La radiología moderna se enfrenta a un desafío crítico donde la precisión diagnóstica y la velocidad de reporte colisionan con la ineficiencia administrativa. Mientras las tecnologías de captura de imágenes evolucionan rápidamente, el proceso de redacción de informes médicos se mantiene como una tarea exhaustiva. Este artículo explora cómo la inteligencia artificial predictiva puede transformar este flujo de trabajo, priorizando el juicio clínico del especialista por sobre la labor de transcripción.

Contexto

La situación actual del sistema de salud en Chile presenta un escenario de alta demanda asistencial con recursos humanos limitados, contando con solo 2.92 radiólogos por cada 100.000 habitantes. Esta cifra contrasta fuertemente con los países europeos de la OCDE, los cuales promedian alrededor de 12 especialistas por cada 100.000 habitantes. Este déficit de especialistas es un fenómeno global que afecta incluso a países desarrollados.

El principal cuello de botella en esta disciplina es la redacción de informes, ya que el enfoque del profesional médico debería centrarse exclusivamente en el diagnóstico y no en la tarea de escribirlo. Actualmente, el ecosistema depende de herramientas como el dictado grabado, la transcripción manual y transcriptores automáticos. Aunque existen tecnologías modernas de reconocimiento de voz como Whisper, estas soluciones no comprenden el texto como un contexto clínico en evolución y son propensas a generar alucinaciones.

Para ilustrar el impacto en los tiempos de respuesta, los datos internos revelan diferencias significativas según la modalidad y la complejidad del examen. Los casos simples requieren aproximadamente tres minutos, mientras que los casos de mayor complejidad pueden extenderse hasta seis minutos.

Promedio de Tiempo de Visualización

Nota: Históricamente, los tiempos de elaboración de informes eran aproximadamente 1.6 veces mayores antes de la adopción de las herramientas actuales.

Problema

El desafío fundamental radica en que la elaboración del informe clínico aún exige una redacción completa por parte del médico. Las herramientas disponibles en el mercado no logran reducir de manera sustancial este tiempo invertido.

A nivel nacional, la inteligencia artificial aplicada a la imagenología presenta una baja tasa de adopción clínica debido a una desconfianza ante posibles falsos positivos o negativos, sumado a los altos costos de implementación. El sector de salud pública carece de los recursos necesarios para financiar estas plataformas, un escenario que describe perfectamente la realidad del cliente evaluado.

Sin embargo, el mercado hoy en día ofrece una nueva oportunidad técnica. El abaratamiento y la maduración de los modelos de predicción de texto permiten su aplicación en la escritura médica. El objetivo de esta iniciativa no es automatizar el diagnóstico clínico, sino asistir al radiólogo mediante la sugerencia de fragmentos estructurados, relevantes y fácilmente editables.

Solución

Para resolver esta problemática, se propone el desarrollo de un asistente virtual predictivo basado en una arquitectura Transformer. Este sistema fue entrenado utilizando un corpus de 270.000 informes anonimizados, los cuales fueron estructurados previamente por secciones clínicas, abarcando antecedentes, hallazgos e impresiones diagnósticas. El enfoque se inspira en los avances de modelos de lenguaje generativos y en trabajos previos de generación automatizada de reportes radiológicos. El desarrollo contempló la creación tanto de modelos generales como de modelos específicos adaptados a cada prestación médica para justificar la adecuación de la solución.

El diseño se fundamenta en estrictos principios técnicos y éticos para abordar el problema identificado. Para garantizar la privacidad del paciente, el sistema opera sin almacenamiento externo de datos, procesando la información directamente a través de la API del sistema original. Además, requiere obligatoriamente la revisión humana antes de cualquier validación final. El concepto operativo se inspira en el funcionamiento de herramientas colaborativas de código, dejando siempre el control definitivo en manos del profesional médico.

Impacto

Los resultados de la implementación se evaluaron en dos dimensiones principales para visualizar el impacto. Experimental y evaluación clínica.

Desde la perspectiva experimental, se ejecutaron tres pruebas comparativas con resultados medibles. Al contrastar modelos entrenados desde cero frente a modelos preentrenados, el enfoque desarrollado desde cero demostró una mayor eficiencia en el uso de recursos computacionales. Respecto a la arquitectura, los modelos configurados con dos y cuatro cabezales de atención evidenciaron el mejor desempeño. Finalmente, los modelos especializados por prestación médica superaron en precisión a los modelos de propósito general.

Para cuantificar el desempeño de los modelos, se utilizaron dos métricas principales. El Hit Ratio representa el porcentaje de predicciones correctas sobre el total de predicciones realizadas, indicando qué tan frecuentemente el sistema sugiere palabras que el médico efectivamente utiliza. Por otro lado, el Trabajo Reducido mide el esfuerzo ahorrado al usuario mediante la fórmula $(p + 0.4 \cdot q) / N$, donde $N$ es el total de palabras del informe, $p$ son las palabras predichas correctamente en cadenas largas (más de 1 palabra consecutiva) y $q$ son las palabras predichas de forma aislada. El factor 0.4 penaliza las predicciones de una sola palabra, ya que reducen menos el trabajo comparado con predecir frases completas.

Hit Ratio por Modelo

Comparación de Modelo General vs Modelo Específico por Prestación

En cuanto a la evaluación clínica, el sistema fue puesto a prueba en un entorno real con especialistas. El personal médico destacó la facilidad de uso de la plataforma. Si bien la comparación del antes y el después evidenció que la herramienta aún no agiliza el tiempo total de redacción frente a las soluciones de dictado actuales, los médicos validaron que las predicciones generadas son coherentes y poseen un alto valor clínico.

Conclusión

El desarrollo de este asistente predictivo representa un avance tecnológico significativo, demostrando que la herramienta no intenta reemplazar al médico. Aunque actualmente no disminuye los tiempos de dictado, el sistema comprende el contexto clínico, propone contenido válido y establece las bases para nuevas modalidades de trabajo. El futuro de la imagenología clínica no reside en automatizar el juicio del profesional, sino en acompañarlo mediante colaboración asistida.

Referencias

1. Vergara, M. and Osses, H. (2007). Mapa de los radiólogos de Chile. Revista Chilena de Radiología. Dato de 2.92 radiólogos por cada 100.000 habitantes.
2. Gálvez Moya, M. (2017). Inteligencia Artificial en Radiología: ¿Seremos reemplazados? Revista Chilena de Radiología.
3. Jeganathan, Shalini (2023). The Growing Problem of Radiologist Shortages: Australia and New Zealand's Perspective. Korean Journal of Radiology, 24, 1043–1045. https://doi.org/10.3348/kjr.2023.0831
4. Vaswani, Ashish et al. (2017). Attention is All You Need. Advances in Neural Information Processing Systems, 30.
5. Radford, Alec et al. (2018). Improving Language Understanding by Generative Pre-Training. OpenAI.
6. Brown, Tom B. et al. (2020). Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems, 33, 1877–1901.
7. Wang, Zhanyu et al. (2022). Automated Radiographic Report Generation Purely on Transformer: A Multicriteria Supervised Approach. IEEE Transactions on Medical Imaging, 41, 2803–2813. https://doi.org/10.1109/tmi.2022.3171661
8. Garay-Vitoria, Nestor and Abascal, Julio (2005). Text prediction systems: a survey. Universal Access in the Information Society, 4(3), 188–203. https://doi.org/10.1007/s10209-005-0005-9
9. Koester, Heidi H. and Levine, Simon P. (1998). Model simulations of user performance with word prediction. Augmentative and Alternative Communication, 14(1), 25–35. https://doi.org/10.1080/07434619812331278186
10. Bhayana, Rajesh (2024). Chatbots and Large Language Models in Radiology: A Practical Primer for Clinical and Research Applications. Radiology, 310(1), e232756. https://doi.org/10.1148/radiol.232756

Diseñado y publicado en 2026 por Nursoft ®.
Todos los derechos reservados.

Oficina Santiago
santiago@nursoft.cl
+562 2 604 8383
La Concepción 141, Oficina 907
Providencia — 7500010
Santiago, Chile

Sobre los Autores

• Ignacio Garcia-Huidobro, Data Engineer de Nursoft. Ing. Civil en Ciencias de la Computación de la Universidad de Chile.
• Gustavo Varas, Consultor de Nursoft. Ing. Civil en Ciencias de la Computación de la Universidad de Chile.

Las oportunidades de gestión de riesgo comercial son un pilar fundamental para el crecimiento de una empresa asegurada. La gestión de oportunidades ha utilizado un enfoque tradicional y reactivo, que depende del análisis manual de datos, un proceso inherentemente lento, subjetivo y propenso a errores. Este artículo detalla cómo una corredora de seguros líder transformó su vasto ecosistema de datos crediticios en un motor de gestión activa, eliminando la subjetividad manual para convertir cada hallazgo en una oportunidad de negocio ejecutada.

Contexto

La industria de seguros de crédito opera sobre un volumen masivo de información financiera. Actualmente, la tendencia global exige que las corredoras dejen de ser simples intermediarios para convertirse en asesores estratégicos basados en datos.

En la industria de créditos, existen cuatro actores relevantes: compañías aseguradoras, asegurados, deudores y corredores de seguro.

Nuestro cliente, una corredora de seguros líder en el rubro, en colaboración con Nursoft, logró una ventaja competitiva clave: una plataforma que unifica productos de múltiples aseguradoras, consolidando mensualmente más de 400.000 líneas de crédito. Esta herramienta no solo centraliza la información, sino que genera un benchmark de comportamiento comparable.

En este sector, una oportunidad de línea de crédito representa la posibilidad de ajustar la cobertura de un asegurado basándose en su comportamiento de riesgo y mercado. La optimización de estas líneas genera una sinergia de valor para todo el ecosistema: el asegurado expande su capacidad de venta al contar con mayores límites de crédito para sus clientes; la compañía aseguradora incrementa su volumen de prima mediante una colocación de riesgo más eficiente; y la corredora eleva su efectividad y calidad de servicio, impactando directamente en su estructura de comisiones. El desafío era claro: evolucionar de una gestión reactiva —esperar la solicitud del cliente— a una gestión activa basada en el análisis proactivo del benchmark.

Problema

A pesar de poseer una ventaja competitiva basada en datos, la corredora se enfrentaba a un desafío crítico de gobernanza y capacidad operativa. El benchmark, aunque robusto y de alto valor estratégico, se mantenía como un activo inerte debido al abrumador volumen de datos que generaba. Esta saturación de información hacía que la interpretación manual fuera no solo ineficiente, sino prácticamente inalcanzable para el equipo humano, derivando en una parálisis por análisis donde la inteligencia disponible no se traducía en acciones comerciales.

Esta desconexión entre el hallazgo y la ejecución se veía agravada por la ausencia de un proceso formal de asignación. Al no existir un flujo de trabajo que vinculara automáticamente una oportunidad detectada con un responsable directo, la gestión de la cartera permanecía en un estado reactivo. La consecuencia directa era la pérdida sistemática de oportunidades de negocio previamente identificadas: la empresa "sabía" dónde estaba el potencial de crecimiento, pero carecía del puente operativo para capturarlo. Sin una estructura que garantizara que cada oportunidad tuviera un dueño y un seguimiento trazable, el riesgo de inacción se convertía en un costo de oportunidad tangible, limitando la capacidad de la corredora para optimizar la prima gestionada y fortalecer su posición como asesor proactivo frente al asegurado.

Solución

Para cerrar la brecha, se implementó un módulo de Gestiones de Líneas de Crédito integrado directamente en la plataforma. La solución se basó en tres pilares:

Herramienta de Gestión Interna: Se crearon flujos de trabajo donde cada oportunidad permite el registro de comentarios, trazabilidad de estados y seguimiento técnico.

Asignación Automática Inteligente: Mediante algoritmos de distribución, la plataforma toma las oportunidades identificadas en el benchmark y crea automáticamente una "Gestión" asignada al tablero específico del ejecutivo responsable. Esto elimina el criterio manual y asegura que cada oportunidad tenga un dueño desde el segundo cero.

Consolidación Estadística: El proceso consultivo se digitalizó, permitiendo que cada interacción alimente un panel de estadísticas global.

Este enfoque asegura que el ejecutivo no tenga que "buscar" el trabajo, sino que la plataforma le presente las prioridades de forma estructurada.

Impacto

La implementación de este flujo automatizado ha permitido materializar el valor del benchmark en resultados financieros tangibles:

Actualmente, el 47,1% de las oportunidades detectadas por el sistema han sido aceptadas, lo que representa un acumulado de más de US$10M. Esta métrica no solo valida la precisión del benchmark para identificar necesidades reales en el mercado, sino que también confirma que dotar al ejecutivo de una herramienta de gestión directa incrementa drásticamente la probabilidad de éxito comercial. El respaldo histórico generado ahora permite a la corredora analizar tendencias y ajustar su estrategia consultiva con base en datos de rendimiento reales.

Conclusión

El avance fundamental de este proyecto no reside únicamente en la capacidad de análisis del benchmark, sino en la trazabilidad total de la oportunidad: desde el instante preciso en que el sistema detecta una oportunidad de mercado, el evento es registrado, asignado y monitoreado.

Esta visibilidad end-to-end garantiza que ninguna oportunidad se pierda en el volumen de información, proporcionando una gobernanza sin precedentes sobre la gestión comercial. En última instancia, la plataforma ha logrado institucionalizar la proactividad, asegurando que cada dato se convierta en una acción concreta que beneficia la rentabilidad de la corredora, la protección del asegurado y el crecimiento de la compañía aseguradora.

Referencias

Rakesh Maltumkar. Transforming Insurance Risk Management Through Advanced Data Analytics. International Journal of Scientific Research in Computer Science, Engineering and Information Technology, 11(1):2311–2321, 2025.

Deepak Saxena and Markus Lamest. Information overload and coping strategies in the Big Data Context: Evidence from the hospitality sector. Journal of Information Science, 44(3):287–297, 2018.

Diseñado y publicado en 2026 por Nursoft ®.
Todos los derechos reservados.

Oficina Santiago
santiago@nursoft.cl
+562 2 604 8383
La Concepción 141, Oficina 907
Providencia — 7500010
Santiago, Chile

Sobre los Autores

• Carlos Ruz, Software Engineer de Nursoft. Ing. Civil en Ciencias de la Computación de la Universidad de Chile.

Un proveedor de telerradiología necesitaba duplicar su capacidad a 200.000 estudios mensuales sin saber si su infraestructura lo permitía. En lugar de escalar a ciegas, Nursoft aplicó un diagnóstico riguroso basado en validación de hipótesis: pruebas de laboratorio controladas que revelaron la causa raíz de los eventos de memoria, el impacto real de la compresión DICOM y un cuello de botella de disco no contemplado. El resultado fue certeza técnica donde había opacidad, una propuesta de optimización con ahorro proyectado del 40% y una hoja de ruta clara para el crecimiento.

En sistemas críticos, la intuición no basta. Este artículo detalla cómo un diagnóstico riguroso basado en el método científico permitió transformar una fuente de inestabilidad operativa en una estrategia de crecimiento con base técnica sólida para un sistema de imágenes médicas de alta demanda.

Contexto

La telemedicina y el diagnóstico radiológico remoto son pilares del sistema de salud moderno en Chile. En este escenario, los proveedores de telerradiología operan plataformas que deben estar disponibles las 24 horas del día: cuando un médico radiólogo recibe una tomografía computada o una resonancia magnética para diagnosticar, cada segundo de latencia tiene impacto clínico directo.

El estándar técnico que gobierna el almacenamiento y comunicación de estas imágenes es DICOM (Digital Imaging and Communications in Medicine), y el software que lo implementa se denomina PACS (Picture Archiving and Communication System).

El desafío del cliente era concreto: preparar la plataforma para duplicar su capacidad y alcanzar los 200.000 estudios mensuales hacia 2026. Pero el volumen no es el único vector de crecimiento: una tendencia sostenida en radiología es el aumento en el uso de instancias multiframe, archivos DICOM que contienen múltiples imágenes dentro de una misma instancia, propios de modalidades como tomografías computadas y resonancias magnéticas de alta resolución. A medida que estas técnicas se masifican, los archivos individuales serán cada vez más pesados, lo que multiplica la presión sobre la infraestructura más allá del simple aumento en cantidad de estudios.

Problema

La configuración de la plataforma había evolucionado de forma reactiva: cada parámetro---el límite de memoria de los pods, la cantidad de réplicas activas, los recursos de CPU asignados, la familia de máquinas utilizada---había sido ajustado bajo la presión de mantener la operación, no a partir de un entendimiento técnico profundo del sistema. El límite de RAM, por ejemplo, quedó fijado en 13 GB por prueba y error, como el valor mínimo que evitaba reinicios frecuentes por eventos Out of Memory (OOM).

El problema real era la incertidumbre estructural: no se sabía si la configuración era la correcta, qué factores realmente limitaban el rendimiento, cuántas réplicas eran necesarias y cuándo, ni si la familia de máquinas elegida era la más adecuada para la carga real. Escalar sin responder esas preguntas implicaba el riesgo de invertir en infraestructura equivocada o de comprometer la disponibilidad del servicio en el momento de crecer.

Las consecuencias de no resolver esto eran concretas: una plataforma que no puede garantizar sus acuerdos de nivel de servicio pierde competitividad, y escalar se convierte en una apuesta arriesgada que puede resultar en costos innecesarios o, peor aún, en fallos operativos.

Solución

Sin un error conocido ni un punto de partida claro, la primera tarea fue delimitar el espacio del problema. Se levantó un conjunto de hipótesis lo bastante amplio como para no dejar causas posibles sin explorar, y se diseñaron pruebas de laboratorio controladas para confirmar o descartar cada una. Las decisiones de optimización vendrían después, una vez que los datos hablaran.

Diagnóstico: Validación de Hipótesis

Hipótesis 1: Memory Leak en el software PACS de código abierto o sus plugins

Los gráficos de Kubernetes mostraban memoria subiendo hasta el límite configurado y manteniéndose ahí, patrón clásico de una fuga. Al analizar la métrica correcta---container_memory_rss, que excluye caché---el proceso del software PACS consume normalmente alrededor de 500 MB. El resto corresponde a caché del sistema operativo: Linux usa la RAM disponible para acelerar operaciones de disco, y Kubernetes la contabilizaba dentro del contenedor. No había fuga; el equipo estaba mirando la métrica equivocada. Hipótesis refutada.

Hipótesis 2: El software PACS escala de forma predecible bajo distintas condiciones de carga

No se sabía cómo respondía el sistema ante picos de demanda ni si añadir réplicas era la estrategia correcta. Pruebas de laboratorio con distintos niveles de carga simultánea mostraron que el tiempo de respuesta crece de forma aproximadamente lineal con los estudios concurrentes. La estrategia de escalar horizontalmente con réplicas es válida y el comportamiento del software es predecible. Hipótesis confirmada.

El tiempo de recepción crece de forma aproximadamente lineal con la carga. La visualización no se ve afectada significativamente.

Hipótesis 3: La compresión en disco impacta significativamente el rendimiento

La instancia tenía compresión DICOM activada por decisión histórica, pero nunca se había medido su impacto real. Con compresión activa, el tiempo de recepción de estudios es hasta el doble bajo carga alta. Sin embargo, la compresión reduce el espacio de almacenamiento en un factor de 2,1x en promedio. Hipótesis confirmada. Estas mediciones abrieron una pregunta adicional: si desactivar la compresión mejora el rendimiento, ¿qué impacto tiene eso sobre el disco?

Hipótesis emergente: La velocidad del disco es un factor limitante independiente de la compresión

Las pruebas de compresión revelaron un segundo factor limitante: sin compresión y con solo 5 estudios concurrentes, la velocidad de escritura al disco alcanzó 136 MB/s---por encima del máximo teórico del Filestore Basic HDD utilizado en producción (100 MB/s). Esto significa que incluso resolviendo el trade-off de la compresión, el almacenamiento se convierte en el próximo cuello de botella a medida que crece la carga. Este hallazgo no cambia las decisiones inmediatas, pero sí delimita hasta dónde puede llegar la arquitectura actual sin intervenir en la capa de almacenamiento.

Hipótesis 4: Limitación arquitectural en el manejo de instancias multiframe

Los reinicios por OOM coincidían con la llegada de estudios multiframe, pero no se sabía cuánta memoria requerían ni por qué. Usando Valgrind y Massif para perfilar el heap del software PACS durante la recepción de una instancia multiframe de 1,5 GB, se midió un consumo de 7,1 GB de RAM. La revisión del código fuente explicó el porqué: el software PACS carga cada instancia DICOM completa en memoria antes de procesarla, a diferencia de otros sistemas que usan streaming. El consumo puede alcanzar hasta 4,7 veces el tamaño del archivo. En los 60 días previos al análisis, la plataforma había recibido 319 estudios multiframe desde 35 centros médicos distintos---no es un caso aislado. Hipótesis confirmada.

Hipótesis emergente: ¿Es esta limitación propia del software o del estándar DICOM?

Confirmada la limitación, surgió la pregunta natural: ¿es una restricción del software PACS en uso o de la forma en que el estándar DICOM obliga a procesar instancias multiframe? Se ejecutó la misma prueba con una alternativa equivalente de código abierto, ampliamente usada en la industria. El resultado: la alternativa mantuvo un uso de memoria estable alrededor de los 900 MB independiente del tipo de instancia. La limitación es estructural al software PACS utilizado, no al estándar. Esto descarta una solución de configuración y apunta directamente a una decisión de software. Hipótesis confirmada.

La alternativa usa más memoria en reposo, pero se mantiene completamente estable ante instancias multiframe. La limitación no es del estándar DICOM.

Propuesta de Optimización

Con el diagnóstico completo, la propuesta se articuló en tres ejes.

Tuning del stack: mantener la compresión activada

Desactivar la compresión mejora el rendimiento de recepción, pero el análisis de costos descarta esta opción. Sin compresión, los estudios ocupan 2,1 veces más espacio en disco: pasar de 1 TB a 2,5 TB en Filestore Basic HDD eleva el costo de almacenamiento de USD 225 a USD 563 mensuales. Además, como muestran las pruebas de disco, desactivarla satura el almacenamiento antes que las máquinas. El ahorro en almacenamiento supera al potencial ahorro en cómputo: la compresión se mantiene.

Modernización de infraestructura: familia de máquinas C4

Los procesadores Emerald Rapids de la familia C4 ofrecen un 20% mejor rendimiento en visualización respecto a las máquinas C2 en uso, con una granularidad de recursos superior que permite ajustar CPU y RAM de forma más precisa. La máquina propuesta (c4-highcpu-8: 8 vCPU, 16 GB RAM) puede absorber la carga habitual en una única instancia del software PACS---con 13 GB de RAM reservados, suficientes para recibir la instancia multiframe más grande registrada en producción---y escalar automáticamente mediante HPA ante picos de demanda. El costo de máquinas se reduce en un 59% respecto a la configuración actual.

Precios con CUD de 3 años, región Santiago. En negrita, la configuración propuesta. C4 permite elegir entre perfiles highcpu, standard e highmem según el balance CPU/RAM requerido; C2 solo ofrece una relación fija.

Nueva arquitectura de separación: recepción y visualización diferenciadas

A mediano plazo, la limitación estructural del software PACS apunta hacia una separación de responsabilidades en la infraestructura: nodos de alta RAM dedicados a la recepción de estudios---donde el pico de memoria es la restricción crítica---y nodos ligeros y escalables para visualización, donde la CPU es el factor dominante. Esta diferenciación no es viable con el software PACS actual por su diseño monolítico, pero es el punto de partida natural de cualquier migración a una alternativa o desarrollo de un PACS propio: ambas opciones permiten dimensionar cada capa de forma independiente y absorber el crecimiento en volumen y peso de los estudios sin intervenir en toda la infraestructura simultáneamente.

Impacto

Eliminación de la incertidumbre

El resultado más valioso del proyecto no fue una métrica de ahorro, sino la certeza técnica: por primera vez, el equipo comprende con precisión qué factores determinan el comportamiento de la plataforma. Las decisiones de escala dejaron de basarse en intuición y prueba y error, y pasaron a estar fundadas en evidencia de laboratorio reproducible.

Potencial de ahorro identificado del ~40%

La propuesta de optimización proyecta un ahorro del 59% en el costo de máquinas. Considerando el conjunto de la infraestructura, el ahorro neto proyectado se sitúa en torno al 40%. Gran parte de ese ahorro proviene de elegir una máquina con exactamente los recursos que la carga requiere, sin pagar por CPU o RAM que el sistema no utiliza.

La validación en producción confirmó que la consolidación de instancias es viable en términos de costos, aunque reveló una pérdida de rendimiento del 20% en los tiempos de respuesta bajo la configuración sin máquinas C4. Dado que las máquinas C4 no estaban disponibles en el datacenter de Santiago al momento de aplicar el cambio, este fue revertido para no impactar la plataforma.

Seguridad operativa ante el crecimiento

El diagnóstico confirma que la plataforma puede absorber el volumen de 200.000 estudios mensuales con la arquitectura actual, y que no existe una urgencia operativa inmediata que obligue a intervenciones estructurales. Las limitaciones identificadas---el manejo de instancias multiframe y la velocidad de escritura del disco---marcan el techo de lo que puede optimizarse en configuración, pero no impiden el crecimiento proyectado.

Lo que el diagnóstico sí entrega es la información necesaria para tomar esa decisión con evidencia: el costo de migrar a otra solución PACS o parchear el software actual debe evaluarse frente al costo de escalar con la arquitectura actual hasta el techo de producción del mercado chileno---estimado en 600.000 estudios mensuales---antes de comprometer recursos en un cambio que puede no ser necesario.

Como primer paso en esa dirección, el equipo consultó a la comunidad del software sobre el comportamiento identificado en instancias multiframe ^[1]. La respuesta del equipo de mantenimiento fue clara: el soporte de streaming---que resolvería el problema de raíz---está en el roadmap, pero requiere cientos de horas de desarrollo sin financiamiento asegurado. No hay una corrección oficial disponible en el corto plazo, lo que convierte la evaluación de alternativas en una decisión concreta, no solo una precaución.

Anticipación de un cuello de botella no visible

Las pruebas de compresión identificaron la velocidad de escritura del disco como un factor limitante independiente, no contemplado en las hipótesis originales. Con compresión activada y la carga actual, el disco opera a 39,9 MB/s---dentro del margen del Filestore Basic HDD (100 MB/s máximos teóricos). Pero sin compresión, con solo 5 estudios concurrentes, la escritura alcanza los 136 MB/s, superando ese límite.

Este hallazgo no requiere acción inmediata, pero delimita con precisión cuándo y cómo el almacenamiento se convierte en el próximo cuello de botella. A medida que el volumen de estudios crece y los archivos se vuelven más pesados, la presión sobre el disco aumenta de forma proporcional---independientemente de cuántas máquinas o réplicas se agreguen. El siguiente nivel de Filestore (Basic SSD) cuesta USD 1.075 mensuales, frente a los USD 225 actuales, lo que convierte la decisión de almacenamiento en una variable estratégica que debe planificarse con anticipación, no bajo presión operativa.

Conclusiones

El cliente enfrentaba una presión concreta: duplicar la capacidad de una plataforma clínica crítica sin saber si la arquitectura actual lo permitía, cuánto costaría, ni qué estaba realmente fallando. La única certeza era que escalar sin entender el sistema primero era un riesgo que no podían asumir.

El mayor logro de este proyecto no fue resolver un fallo puntual, sino construir conocimiento técnico fundamentado donde había opacidad. Al terminar el análisis, el equipo del cliente sabe con precisión qué factores determinan el comportamiento de su plataforma, hasta dónde puede crecer con la arquitectura actual, qué decisiones pueden tomarse hoy y cuáles requieren más evidencia antes de comprometer recursos. Eso es lo que permite planificar el crecimiento con confianza en lugar de reaccionar bajo presión.

Este tipo de problema---técnicamente complejo, sin causa raíz evidente, con consecuencias de negocio directas---es exactamente el escenario donde una metodología rigurosa marca la diferencia. No porque garantice una solución inmediata, sino porque convierte la incertidumbre en conocimiento accionable: hipótesis concretas, experimentos reproducibles, datos que respaldan cada decisión. El resultado no es solo una recomendación técnica; es la capacidad de tomar decisiones estratégicas de infraestructura con evidencia, no con intuición.

Referencias

https://discourse.orthanc-server.org/t/high-memory-consumption-during-ingestion-of-large-1-5-gb-multi-frame-instances/6408 ↩︎

Diseñado y publicado en 2026 por Nursoft ®.
Todos los derechos reservados.

Oficina Santiago
santiago@nursoft.cl
+562 2 604 8383
La Concepción 141, Oficina 907
Providencia — 7500010
Santiago, Chile

Sobre los Autores

• Vicente Lineros Pardo, Software Engineer de Nursoft. Ing. Civil en Informática de la Universidad Técnica Federico Santa María.

Es muy común que las empresas no tengan sus procesos internos documentados. Esto provoca que la forma en que se ejecutan dichos procesos dependa casi exclusivamente de la experiencia y criterio de cada uno de sus trabajadores, resultando en variabilidad y riesgo constante de errores, aparte de una gran dificultad para mantener estándares de calidad. A continuación se presenta un levantamiento de procesos con un enfoque cualitativo (planteando un análisis cuantitativo en el futuro) con el objetivo de modelar la situación actual de una empresa y planificar cambios que permitan disminuir sus costos operacionales, habilitando el crecimiento de esta organización.

Contexto

La empresa a analizar es líder en su rubro y se enfrenta a un gran crecimiento comercial. Entre 2023 y 2024 duplicó su producción y, según las proyecciones, su tasa de crecimiento anual compuesto (CAGR[1]) alcanza un 137%. Este crecimiento, aunque positivo, evidencia altos costos operacionales y el riesgo de que estos costos escalen más rápido que los ingresos si los procesos internos se mantienen tal y como están.

La siguiente gráfica, elaborada a octubre de 2024, muestra la evolución mensual de la producción desde enero de 2022 hasta septiembre de 2024.

En la gráfica se observa un crecimiento sostenido de la producción con un salto marcado durante 2024, donde la producción más que duplica en varios meses la de 2022 y 2023. Esta trayectoria confirma la presión que ejerce el crecimiento sobre los procesos internos, que deben adaptarse para mantener la calidad y disminuir sus costos.

Problema

Se identifica rápidamente que los procesos no están documentados y se transmiten de boca en boca. A pesar de estar llevando a cabo el mismo proceso, cada trabajador lo desarrolla de distinta manera, generando inconsistencias en los resultados y gran dependencia de su criterio personal. Esta informalidad se tradujo en un nivel de madurez organizacional muy bajo según el CMMI (Capability Maturity Model Integration)[2], el cual define a la organización en el nivel 2, avanzando incipientemente a nivel 3. Esto quiere decir que los proyectos se planifican y llevan a cabo, pero no están estandarizados ni documentados. De esta forma, es difícil garantizar resultados constantes a un mismo proceso e incorporar nuevos trabajadores a la empresa.

Solución

Para abordar el problema de altos costos operacionales, se realiza un levantamiento cualitativo de procesos por medio de entrevistas a los trabajadores de la empresa. Los resultados de cada entrevista fueron modelados en notación BPMN y luego consolidados en un gran modelo BPMN indicando no sólo los flujos, sino también la cantidad de trabajadores que efectivamente ejecutan cada tarea descrita. Estos modelos permiten identificar variaciones entre cada persona, además de visibilizar el contraste entre el proceso esperado y el que realmente se está llevando a cabo.

Este ejercicio demostró que la organización no cuenta con procesos definidos y estandarizados, confirmando su ubicación en los niveles iniciales de madurez según el CMMI. Durante el desarrollo del proyecto con esta organización se espera establecer un proceso definido y documentado, habilitando a la empresa a avanzar a niveles superiores de madurez, lo que permitirá mejora continua.

Impacto

Los resultados del levantamiento mostraron que en uno de los procesos, apenas el 66% de las tareas se realizaban en completitud por todos los trabajadores, mientras que en otro el cumplimiento llegaba solo a un 41%. En algunos casos incluso se identificaron errores recurrentes que las jefaturas no habían detectado, además de múltiples situaciones en que los trabajadores, a falta de una definición clara para algunos casos bordes, recurrían al criterio propio, lo que aumenta la complejidad y riesgo de errores en los procesos.

Además, los resultados preliminares fueron utilizados de inmediato por las jefaturas para corregir las vulnerabilidades más críticas que fueron identificadas. Este levantamiento también permitió dimensionar la variabilidad en los procesos y visibilizar la urgencia de estandarizarlos.

Otro punto importante revelado por los resultados de las entrevistas fue la identificación de una clara tensión entre la calidad y la producción de la empresa. Se pudo observar que en momentos de alta demanda, todos los trabajadores tienden a disminuir la calidad de los procesos para permitir cumplir con la cantidad de trabajo, privilegiando una entrega a tiempo. Será importante a futuro mantener en cuenta esta tensión para cualquier propuesta de mejora.

Conclusión

El levantamiento cualitativo mostró que los procesos existen en la práctica, pero su variabilidad los hace riesgosos y poco confiables. El hecho de que ningún trabajador ejecute un proceso completo según el modelo BPMN consolidado refleja la ausencia de un estándar claro. Esto genera altos costos de capacitación, aumenta la probabilidad de errores y limita la posibilidad de automatización, lo que permitiría disminuir en gran medida los costos operacionales.

El uso de CMMI como marco de referencia permitió situar a la organización en un nivel inicial de madurez y ayudó a reforzar la necesidad de avanzar hacia niveles más avanzados. Documentar y estandarizar procesos es una necesidad para sostener el crecimiento.

La siguiente etapa es un levantamiento cuantitativo de los procesos, midiendo costos para identificar las mayores oportunidades de mejora en los procesos. Con los levantamientos como base se puede elaborar una propuesta de estandarización (y posible automatización) de los procesos, de tal forma que la empresa pueda verse habilitada para el crecimiento comercial pronosticado con procesos claros, que entreguen resultados replicables y de alta calidad.

Referencias

1. Investopedia. Compound Annual Growth Rate (CAGR). 2024.
2. Mary Beth Chrissis, M. Konrad, Sandy Shrum. CMMI: Guidelines for Process Integration and Product Improvement. 2003.

Diseñado y publicado en 2026 por Nursoft ®.
Todos los derechos reservados.

Oficina Santiago
santiago@nursoft.cl
+562 2 604 8383
La Concepción 141, Oficina 907
Providencia — 7500010
Santiago, Chile

Sobre los Autores

• Natalia Herrera, Consultora de Nursoft. Ing. Civil en Informática de la Universidad Técnica Federico Santa María.

Contexto: La Invisibilidad del Impacto Organizacional

En sectores donde la disponibilidad de la información es crítica, como la salud digital, la operatividad bajo condiciones de red heterogéneas es un requisito de diseño fundamental. El caso de estudio de este cliente de Nursoft se centra en una plataforma que soporta a aproximadamente 800 usuarios mensuales, quienes operan frecuentemente en entornos de baja capacidad, ya sea por su ubicación geográfica o por las limitaciones de la infraestructura institucional [1]. Este escenario es representativo de cualquier sistema con usuarios distribuidos y despliegues frecuentes, como ERPs, CRMs o plataformas logísticas, donde cada segundo de latencia se traduce en un costo transaccional.

El desafío identificado involucraba un patrón de uso donde las transiciones entre módulos —de la agenda a la estación de diagnóstico— forzaban descargas de datos redundantes. Para una organización con ciclos de actualización semanales, esto significaba que su base de usuarios re-descargaba código que no había cambiado para ellos, generando una fuga silenciosa de tiempo y recursos. Lo más crítico es que este impacto solía ser invisible para el equipo de desarrollo, ya que el problema es prácticamente imperceptible en entornos con conectividad de alta velocidad.

El Problema: El Impacto de lo Invisible

La identificación de la ineficiencia requirió observar más allá de los síntomas superficiales. Mientras que la percepción general apuntaba a una "red lenta", el diagnóstico técnico permitió detectar que la causa podía residir en un detalle casi imperceptible del proceso de construcción del software: las variables de ambiente estaban embebidas directamente en el paquete de código (el bundle) durante el build. En frameworks modernos como Vite o Webpack, esta práctica es el estándar por defecto, pero sus implicaciones en entornos de producción son profundas y a menudo ignoradas [2].

Este detalle técnico provoca que cada nuevo despliegue genere identificadores únicos (hashes) para los archivos, lo que obliga al navegador del usuario a descartar preventivamente todo el caché almacenado, aunque la lógica del negocio no haya variado [2]. Al reproducir estas condiciones mediante una simulación de red 3G, las métricas fueron contundentes: una segunda carga recurrente transfería 8MB de datos, resultando en esperas de 1.4 minutos. La red no causaba el problema; simplemente exponía una arquitectura de entrega que trataba componentes estables como si fueran volátiles, saturando el canal de comunicación sin una justificación técnica funcional.

La Solución: Ingeniería para la Continuidad

La resolución de este conflicto no requirió un aumento en el ancho de banda, sino una reingeniería del modelo de entrega para proteger la estabilidad de los recursos en el cliente. La estrategia se centró en desacoplar la configuración operativa de la lógica de negocio. La primera medida consistió en separar la configuración en runtime, trasladando las variables de ambiente a un archivo externo de apenas 2KB. Al servirse sin políticas de caché, este archivo permite que los paquetes de código principales permanezcan inmutables y persistentes en el dispositivo del usuario, incluso tras múltiples actualizaciones del sistema [1].

De forma complementaria, se ejecutó una migración hacia Vite para implementar estrategias avanzadas de lazy loading y code splitting. Al refactorizar la estructura de los imports, se garantizó que la plataforma descargara únicamente los fragmentos de código estrictamente necesarios para la vista activa, reduciendo el peso del bundle inicial de 8MB a 4.8MB [3]. Esta intervención técnica asegura que, tras la primera visita, el usuario solo necesite validar un archivo mínimo, recuperando el resto de la plataforma desde su memoria local de forma casi instantánea.

Impacto: Recuperando Capacidad Operativa

Los resultados obtenidos bajo las mismas restricciones de conectividad demuestran cómo la atención a los detalles arquitectónicos puede transformar la viabilidad de un producto. La optimización de los recursos fue drástica: el tiempo de espera para una carga recurrente descendió de 1.4 minutos a solo 17 segundos, lo que representa una recuperación del 88% en la velocidad de acceso percibida por el profesional.

En términos de eficiencia de datos, el volumen transferido por sesión se redujo de 8MB a solo 2KB, una disminución del 99%. Este cambio eliminó el costo oculto asociado a cada despliegue semanal, donde anteriormente se forzaba la descarga masiva de código de forma redundante. Para la organización, esto no es solo una métrica de rendimiento; es la recuperación de miles de horas de uso efectivo para sus 800 usuarios activos, transformando un cuello de botella tecnológico en una ventaja de disponibilidad operativa. Una comparativa de rendimiento evidencia los resultados:

Conclusiones: El Valor de la Precisión Técnica

Este caso de estudio subraya que el rendimiento en producción es el resultado de decisiones de diseño que a menudo se consideran secundarias. El antipatrón de embeber configuración volátil en estructuras estables es una práctica común que permanece invisible en entornos ideales, pero que se vuelve crítica en la operación real [4].

La separación de lo volátil de lo estable debe considerarse una condición mínima de arquitectura para sistemas distribuidos en cualquier industria [4]. En última instancia, la mejora de 1.4 minutos a 17 segundos nos recuerda que los grandes problemas de eficiencia suelen resolverse examinando con rigor técnico aquellos procesos invisibles que ocurren en el milisegundo de la creación del software.

Diseñado y publicado en 2026 por Nursoft ®.
Todos los derechos reservados.

Oficina Santiago
santiago@nursoft.cl
+562 2 604 8383
La Concepción 141, Oficina 907
Providencia — 7500010
Santiago, Chile

Sobre los Autores

• Gustavo Varas, Consultor de Nursoft. Ing. Civil en Ciencias de la Computación de la Universidad de Chile.

Contexto

La industria financiera, en específico la de riesgo crediticio, cuenta con múltiples desafíos; variación del perfil de riesgos constante de los clientes y deudores, evaluaciones de crédito con sesgo, un mercado creciente (crecimiento anual sobre el 10%) y volátil (en el contexto actual)[1][2], disgregación de datos, pérdida de oportunidades por falta de información, entre otros.

Algunos de estos desafíos se arrastran por décadas dada la naturaleza e historia de la industria; la diferencia es que las condiciones tecnológicas hoy son superiores.

En la industria de créditos, existen cuatro actores relevantes: compañías aseguradoras, asegurados, deudores y corredores de seguro.

El desafío: Cómo consolidar la cartera de diferentes compañías para generar un análisis integrado

Todos los días se deben procesar más de 2 millones de créditos, que corresponden a la cartera de clientes del cliente. Además, como la información proviene de las compañías aseguradoras, cada una presenta sus propias reglas de negocio. A pesar de ser un servicio regulado por la Comisión de Mercados Financieros en Chile (CMF), cada empresa tiene criterios y definiciones diferentes. Esto se debe principalmente por:

1. A pesar de ser un proceso comercial estándar, por razones comerciales, como presentan este proceso de calificación de deudores es diferente, así logran generar una diferencia comercial con sus clientes para resaltar sus servicios.
2. Reglas de negocio antiguas y difíciles de actualizar están presentes. Como cualquier negocio e industria que lleva varios años y décadas operando, no necesariamente las decisiones pasadas se mantienen hasta el día de hoy. Pero se deben seguir dando el servicio con dichas decisiones, porque existen clientes activos con esas condiciones. Por lo tanto, nos encontramos con reglas obsoletas pero siguen vigentes.
3. Condiciones especiales diseñadas para casos específicos, donde algún acuerdo comercial entre un asegurado y compañía aseguradora resulta atractivo, que se deben definir reglas de negocio nuevas no utilizadas anteriormente.
4. La búsqueda de siempre presentar la data de la mejor forma posible, así como la compañía aseguradora siempre puede mostrar datos favorables a su gestión, pero que no necesariamente son un reflejo de la realidad.
   

La consecuencia de los puntos anteriores, es que cada compañía aseguradora cuente con sus propias definiciones para elementos que son por lo general genéricos. Es por esto que nos encontramos con aseguradoras que cuentan con:

• Hasta 12 clasificaciones de tipo de deudores.
• Más de 5 tipos de líneas de crédito.
• Más de 4 tipos de montos otorgados dependiendo de ciertas características y reglas.

Para poder consolidar y luego analizar, se requería poder homologar conceptos a un proceso unificado de la empresa, así realizar las gestiones independiente de la entidad aseguradora.

Solución: Diseñar un proceso propio, independiente de la fuente

Para poder llevar a cabo una consolidación, establecimos un solo proceso independiente de la compañía aseguradora. Redujimos y unificamos criterios, a un proceso con reglas de negocio claras que homologan - sin perder información - lo obtenido de la fuente de información (aseguradoras).

Para esto, se realizó un levantamiento de los productos disponibles en el mercado y cómo se gestionan en cada compañía; así definir reglas de negocio claras. Establecimos criterios claros de aceptación para cada tipo de dato, logrando así:

[*] Existen más estandarizaciones a las reflejadas en la tabla, se incluyen algunas con el fin de resumir.

Para lograr estas estandarizaciones, diariamente, en un horario reservado por las compañías para nosotros, se implementó un sistema de extracción, transformación y carga de datos (ETL).

Impacto

A pesar de que en el presente caso se enfoca en el proceso de extracción, transformación y carga, el impacto del proyecto en su totalidad fue significativo para el cliente, logrando:

• Se consolidó la información en un solo sistema, generando analítica avanzada, de más de 2.000.000 de créditos, de más de 400.000 deudores para más de 200 pólizas.
• Logramos generar un sistema de gestión automático, mediante detección automática de anomalías, capturando oportunidades de créditos sobre USD $946 millones anuales; un incremento de hasta un 23% de sus ingresos anuales.Se logró generar una gestión que podría impactar positivamente la aprobación crediticia de sus asegurados en hasta 350 puntos base, la aprobación general de la empresa, logrando así una mejor gestión crediticia.

Diseñado y publicado en 2024 por Nursoft ®.
Todos los derechos reservados.

Oficina Santiago
santiago@nursoft.cl
+562 2 604 8383
La Concepción 141, Oficina 907
Providencia — 7500010
Santiago, Chile

Sobre los Autores

• Gonzalo Larraín, Consultor de Nursoft. Ing. Civil en Informática de la Universidad Federíco Santa María.
• Rafik Mas'ad, Socio Consultor de Nursoft. Ing. Civil en Informática y Msc. en Ciencias de la Computación de la Universidad Federíco Santa María.
• Sebastián Mas'ad, Socio Consultor de Nursoft. Ing Comercial y Msc. Estrategia de la Universidad Adolfo Ibáñez.

Contexto

El sistema de salud chileno está sometido a un alto nivel de exigencia, atendiendo a millones de pacientes al mes con un déficit de profesionales y recursos. Esto ha implicado, al igual que la evolución en otras industrias, una mayor exigencia en eficiencia y eficacia. El impacto marginal en optimización de procesos puede significar reducción de tiempo en profesionales escasos, aumentando la cantidad de prestaciones, generando ingresos adicionales relevantes para las empresas.

En Nursoft hemos trabajado con múltiples actores de la industria de la salud, entendiendo en profundidad los dolores y espacios de impacto en los desafíos del negocio de nuestros clientes.

Desde el año 2018 colaboramos con una empresa que trabaja con más de 400 mil pacientes anuales. El proyecto, que impacta transversalmente al cliente, es de un gran tamaño tecnológico y es utilizado intensamente por más de 200 usuarios, 24 horas al día, los 7 días de la semana. Se atienden pacientes ambulatorios, hospitalizados y urgentes.

Sus procesos de gestión son sumamente exigentes por la demanda del mercado y su cartera de clientes. El atraso en algunos pocos minutos puede ser la diferencia entre una multa o no, o, en el peor de los casos, la vida o la muerte de un paciente urgente.

Producto de los múltiples desafíos del cliente, la plataforma está construida mediante una arquitectura de microservicios, con diferentes tecnologías y alta cantidad de funcionalidades. La alta disponibilidad, los tiempos de respuesta y la eficiencia pasan a ser requerimientos críticos dado el uso intensivo de los usuarios de la solución.

Nota técnica

En el diseño de un sistema de microservicios un desafío constante es cómo equilibrar un sistema con alta cohesión y bajo acoplamiento. Esto, en la práctica, permite que, manteniendo microservicios de alta coherencia interna, se minimice la cantidad de consultas que tienen dependencia con otro microservicio.

En particular esto es crítico cuando existen consultas de usuarios que en un sistema monolítico se implementarían con un join de tablas, ya que se pierde esa capacidad al tener bases de datos separadas haciendo mucho más costosas estas consultas.  Este es un problema común en sistemas de microservicios, que por la naturaleza de cada negocio, no siempre se puede evitar.

El problema de nuestro cliente: Cómo aumentar la eficiencia de sus colaboradores para mejorar sus costos.

El objetivo del proyecto es poder impactar de forma positiva la eficiencia  - sin dejar de lado la seguridad - de los procesos de gestión de los exámenes médicos; así mejorar su competitividad en costos versus su competencia.

Dado este objetivo, desglosamos las diferentes acciones y funcionalidades que utilizan los usuarios para detectar (1) las más utilizadas y (2) las que se pueden optimizar con el fin de impactar la productividad.

Con este análisis se detectó que la búsqueda de procedimientos (prestaciones médicas) es una funcionalidad que se ocupa hasta 1.000 veces al día por usuario, y dado el alto volumen de datos y la arquitectura, contaba con un déficit de velocidad subsanable rápidamente generando valor en el corto plazo. Una consulta podría demorarse hasta 12 segundos.

En sus inicios, esta funcionalidad se demoraba una fracción de segundos dado que era utilizada por menos usuarios y la base de pacientes y procedimientos era más pequeña. Al aumentar el uso, la cantidad de datos y habilitar funcionalidades que fomentaban la búsqueda de procedimientos por datos de pacientes, los tiempos de respuesta rápidamente aumentaron.

Problema Técnico: Data Disgregada, Búsqueda Unificada

Con el diagnóstico y el contexto del negocio claros, nos enfocamos en buscar una solución técnica en miras a generar un impacto positivo en los resultados para nuestro cliente.

El desafío fue cómo lograr unificar la búsqueda de más de 2.000.000 pacientes almacenados que cuenta con información disgregada en 2 microservicios: pacientes y procedimientos.

Cuando se filtraba por datos del paciente, se tenía que buscar todos los posibles pacientes que calzaran con la búsqueda e introducir ese resultado en la consulta del servicio de procedimientos.

A modo de ejemplo, si un usuario busca por «19» (para buscar todos los usuarios con Identificador Nacional 19 millones), en una tomografía computada de cerebro y con diagnóstico de accidente cerebrovascular, el microservicio de pacientes encontraba sobre 15 mil pacientes con Identificador Nacional 19.***.***-* y estos se enviaban al servicio de procedimientos para aplicar los otros dos filtros correspondientes a este servicio. En vez de procesar 25 procedimientos con sus 25 (o menos) pacientes, procesamos 15 mil pacientes y 25 procedimientos.

Solución

El equipo de consultores de Nursoft evaluó diferentes alternativas al desafío técnico con el fin de solucionar el problema de negocio:

• Fusionar el servicio de pacientes y procedimientos, lo cual se descartó por que eran los dos servicios de mayor envergadura. La base de código hubiese resultado muy extensa, de alta complejidad y baja cohesión.
• Replicar la información del paciente en el servicio de procedimientos, lo cual descartamos por mantenibilidad y escalabilidad. Entendiendo el volumen de datos y transacciones, era muy propenso a que las bases de datos quedarán desincronizadas e incoherentes.
• Agregar un campo de texto que contiene todos los valores más frecuentes que se pueden utilizar para buscar como texto en los procedimientos, tanto los campos del paciente (nombre, identificador nacional, correo electrónico) como del procedimiento en sí (número de ficha).
  

Esta última opción permite que el usuario al buscar «23» encuentre todos los procedimientos cuyo RUT, correo electrónico y número de ficha contiene «23», de forma expedita.

Para esto, se creó un servicio que de forma asíncrona mediante eventos, al recibir una actualización de datos de un paciente, actualizaba ese campo en todos los procedimientos de dicho paciente.

Además, a todos los campos que la plataforma permite filtrar, se le agregaron índices (más de 30 índices nuevos). En particular, este campo de texto para la búsqueda se le agregó un índice para búsqueda de similaridad mediante trigramas.

Resultados e Impacto

• La labor más realizada por la empresa en la plataforma era buscar, llegando a más 30.000 búsquedas por hora. Esto significaba que un grupo de operadores podía pasar hasta un 40% de su tiempo esperando que la plataforma encuentre los pacientes según sus criterios de búsqueda. Como resultado del proyecto, se mejoró logrando que sea menos de un 0.6% del tiempo, generando que los resultados de búsqueda sean casi instantáneos.
• En promedio se disminuyó a 0.125 segundos cada resultado de búsqueda, que en un comienzo eran cercanos a los 10 segundos.
• Los operadores ocupaban hasta dos horas diarias en total esperando que la búsqueda terminara de cargar. Actualmente las búsquedas dan resultados prácticamente instantáneos.
• En total se logró impactar la eficiencia de la operación del cliente aumentando su eficiencia en hasta un 40% diaria, aumentando así su capacidad productiva y reduciendo sus costos operacionales. Esto, producto no solo de disminuir los tiempos de respuesta, si no al mayor uso de la funcionalidad de búsqueda producto de su optimización.
  
  

Diseñado y publicado en 2024 por Nursoft ®.
Todos los derechos reservados.

Hay dos características que hacen especiales a los proyectos tecnológicos: tienden a ser riesgosos y rentables. Estas variables, en equilibrio, estudiadas, nos permite tener una perspectiva más acertada de cómo gestionar nuestro desarrollo de software.

Antes de seguir con el artículo, es importante señalar: la tecnología es una disciplina que trabaja con sistemas de alta complejidad, tanto por la naturaleza técnica como por la gestión social que esta requiere.

Una buena gestión no requiere solo un análisis big picture. Es importante entender la propia naturaleza del software para que estos proyectos obtengan su máximo potencial y retorno.

En el presente artículo nos referiremos a cómo, dado un proyecto específico con sus requerimientos definidos, podemos obtener el mayor retorno en menor tiempo.

Composición de un proyecto de software

Un desarrollo de software se debe dividir, ante cualquier circunstancia, en la mayor cantidad de funcionalidades. Entre más pequeña estas sean, mejor, ya que nos permite aislar la necesidad y controlar mejor su varianza.

En las metodologías ágiles, que permiten avanzar rápidamente a soluciones que generan valor (una forma de ver el desarrollo ya no tan moderna), habitualmente, cada funcionalidad se le conoce como historias de usuario, ya que cada una de estas le permite a un usuario completar una actividad que le genera valor.

Estas historias de usuarios se pueden agrupar en grandes historias, a lo que – al igual que en la literatura – se le denominan épicas, que no son más que múltiples funcionalidades que en conjunto añaden más valor que individualmente.

Las épicas puede (y deben) ser administradas como un portafolio. La tecnología no es un costo directo o gasto, se asimila más bien a un activo de inversión que genera retorno con su riesgo asociado.

Gestión de nuestro portafolio de épicas

El gran desafío en la gestión de un proyecto tecnológico está en distribuir los recursos escasos (tiempo de desarrollo) para obtener el mayor retorno. Ante esto, es importante considerar:

• Entre antes se obtenga el valor, mejor. Reduce riesgo ante incertidumbre futura.
• Cuando las funcionalidades a ser desarrolladas no son estructuradas, la mayoría de las veces es incierta la respuesta de los usuarios, por lo tanto, diversificar resulta eficiente.
• El costo de cada funcionalidad no es un valor fijo y predecible, tiene un comportamiento variable.

Dado lo anterior, el trabajo de gestión de un proyecto o un portafolio de épicas se basa en priorizar. Qué funcionalidades debo hacer primero y porqué.

Al igual que cualquier portafolio, existen métodos eficientes de hacerlo. Para esto debemos entender tres dimensiones de cada funcionalidad, o mejor dicho épica:

1. Costo: es decir cuantas horas de desarrollo implica esta funcionalidad (esto es transformable en costo monetario dado que conocemos los sueldos, gastos, etc).
2. Retorno directo: es decir una épica cuanto incremento en ventas significará (por ejemplo: clientes están esperando un set de funcionalidades para usar nuestro producto) o cuanto costo directo reducirá.
3. Retorno indirecto: es decir el aporte estratégico de la épica, pensando en por ejemplo en funcionalidades que no se traducen en ventas, pero si en posicionamiento.

Estos tres factores se deben ponderar para determinar el orden de desarrollo de las épicas, es decir el orden de inversión en nuestro portafolio.

Cuantificar el costo de una funcionalidad

Dado que el comportamiento de un proyecto de desarrollo opera con gran varianza, es esperable es que existan sobrecostos – y no menores- al finalizar el proyecto. Esto es un factor fundamental a la hora de cuantificar el costo de una épica.

A pesar de que existen muchas técnicas, que por lo general no muy precisas, en Nursoft utilizamos técnicas estocásticas de inteligencia artificial para simular el comportamiento de las épicas, y en consecuencia, del proyecto. Es decir, dada las funcionalidades, historias de usuario, podemos simular distintos escenarios de cómo se va a comportar un proyecto. Esto lo realizamos mediante técnicas de machine learning contra una base de datos que contiene más de 100.000 registros detallados.

Con nuestro sistema, llamado BlackSheep, logramos reducir la varianza de los proyectos de un 200% a un 25%, lo que permite mejor gestión de estos.

Con esto, tenemos rangos de comportamientos que nos permiten tener escenarios optimistas, pesimistas y esperado de cada funcionalidad. Esto implica mayor control del proyecto.

La gestión diaria eficiente o, cómo priorizar

Dada todas las variables anteriores, podemos estructurar cada épica evaluándola en las tres variables: costos, retorno directo e indirecto, y finalmente optimizando este orden obtenemos que debemos hacer primero.

A modo de ejemplo, simulamos 50 épicas, cada una con su costo y retorno directo estimado, para que se considere en el análisis:

• El costo directo se consideró se realizaron 10.000 simulaciones, donde se ponderó el peso de cada épica para determinar el costo unitario, el costo considerado es el promedio ponderado de los escenarios llevados a valores horas estándar.
• El retorno se consideró el incremento de ingresos dado el valor por cada usuario nuevo durante un año.
• Más allá de cómo se estimó cada parámetro, el objetivo es distinguir la priorización.

Al tener cada parámetro objetivo (el retorno indirecto no se consideró en esta ocasión) definido, es posible distinguir que existen épicas de mayor retorno a menor costo y viceversa.

Dado lo anterior, aquellas que se ubican en el cuadrante I, son épicas que cuestan menos inversión y retornan más, a diferencia de las del cuadrante IV, que son lo opuesto, por lo tanto, el orden de trabajo queda definida lógicamente la gestión del proyecto.

Esto resulta sumamente familiar al compararlo con un portafolio, la frontera eficiente se sitúa en aquellos activos que tienen menor volatilidad (costo) y mayor retorno (retorno directo) dado un presupuesto dado. Estas técnicas ya descritas en la década de los 50 son completamente extrapolables a la gestión de un proyecto tecnológico.

Los requerimientos cambian

Sabemos que los negocios son cambiantes, y los proyectos tecnológicos no se eximen de esto. Es por eso por lo que dado que avanza el desarrollo es natural ver que las épicas han ido mutando, algunas se desechan y otras se añaden.

Es por esto que el trabajo de gestión es continuo y lo presentado en este artículo responde a un momento dado, ante cambios es importante volver a repetir el ejercicio de gestión para mantener alineada la tecnología con el negocio.