Qué infraestructura de software necesita una clínica con alto volumen de imagen

1. El colapso informático en centros de alta rotación

El síntoma es conocido y la dirección lo oye a diario: el sistema va lento cuando más gente lo usa. Conviene entender que no es mala suerte ni un ordenador viejo, sino una cuestión de cómo está montado el software.

1.1. La rueda que gira en pleno box

Abrir una OCT o una retinografía pesada mientras el paciente está sentado delante convierte cada consulta en una pequeña espera. Sumadas a lo largo del día, esas esperas son minutos de agenda perdidos y una sensación de lentitud que el paciente percibe. La velocidad de apertura de una prueba es un indicador de calidad tan real como el tiempo de sala de espera.

1.2. El bloqueo cuando coinciden varias consultas

El problema se agrava cuando varios profesionales abren pruebas a la vez. Un software que aguanta con un usuario se atasca con seis, porque no fue diseñado para repartir esa carga. La hora punta de la consulta es precisamente cuando el sistema tiene que ir más fino, y es cuando muchos van peor.

1.3. Por qué esto empeora con cada equipo nuevo

Cada equipo de imagen que entra multiplica el volumen de archivos y el número de accesos. Un montaje que servía cuando había un tomógrafo deja de servir con cuatro. Es el mismo cuadro de cómo se mueve una imagen médica entre sistemas, mirado desde la infraestructura que lo sostiene.

2. Por qué un programa genérico se satura con imagen

Antes de cambiar de sistema conviene entender la causa, porque muchas veces se culpa al hardware cuando el cuello de botella está en el diseño del software.

2.1. Un programa de gestión no es un visor de imagen

Muchos programas de clínica nacieron para llevar citas y facturas, y la imagen se les añadió después. Cargar un archivo grande en una herramienta pensada para textos y tablas la hace trabajar contra su naturaleza. No es que el ordenador no pueda: es que el programa intenta tragarse la imagen entera de una vez en lugar de mostrarla por partes.

2.2. Mezclar datos ligeros y archivos pesados

Cuando la misma base de datos guarda las citas, los textos y también las imágenes pesadas, cada consulta ligera acaba compitiendo con el peso de los archivos. El sistema se vuelve tan lento como su parte más pesada, y una simple búsqueda de un paciente tarda lo que tardaría abrir una tomografía.

2.3. La memoria del navegador, mal aprovechada

En los sistemas web, si el programa no gestiona bien lo que guarda en el navegador del médico, cada apertura vuelve a descargarlo todo. Un buen diseño reutiliza lo ya cargado y trae solo lo que falta; uno malo repite el trabajo cada vez, y esa diferencia se nota en cada clic.

3. Separar la gestión de las imágenes pesadas

La primera decisión de arquitectura, y la que más se nota, es no meterlo todo en el mismo sitio. Los datos de gestión y las imágenes pesadas tienen que vivir separados.

3.1. Datos transaccionales por un lado

Las citas, los textos clínicos, las facturas y los índices numéricos son datos ligeros que se consultan constantemente. Van en una base de datos preparada para responder rápido a muchas peticiones pequeñas. Que esa base no cargue con el peso de las imágenes es lo que mantiene ágil el día a día.

3.2. Las imágenes, en un almacén aparte

Los estudios de imagen —que ocupan mucho y se abren menos a menudo— van a un almacén específico, optimizado para guardar archivos grandes y servirlos por partes. Así, abrir una OCT no ralentiza la búsqueda de un paciente, ni al revés. Separar los dos mundos es lo que evita que el más pesado marque el ritmo del más ligero.

3.3. Un índice que encuentra sin abrir

Entre ambos, un índice bien hecho permite encontrar la prueba correcta sin tener que abrir nada: por paciente, por fecha, por tipo de estudio. Localizar es instantáneo y solo se carga el archivo cuando de verdad se va a mirar. Es la diferencia entre buscar en un catálogo y tener que abrir cada caja del almacén.

4. Caché local rápida y archivo en la nube

El almacenamiento no es todo igual, y la clave está en combinar dos velocidades: lo del día, cerca y rápido; lo histórico, en un archivo grande y más lento pero barato.

4.1. Lo del día, a mano

Las pruebas de la jornada y las de los pacientes citados conviene tenerlas en una capa rápida, para que se abran sin espera. Es un volumen pequeño y muy usado, así que compensa que esté en lo más ágil de la infraestructura. El médico no debería notar ninguna carga con lo que va a mirar hoy.

4.2. El histórico, en la nube

Los años de pruebas anteriores ocupan mucho y se consultan de vez en cuando. Ese histórico vive en un almacenamiento en la nube pensado para gran capacidad, del que se trae un estudio concreto cuando se necesita. La Ley 41/2002 obliga a conservar la documentación clínica un mínimo de cinco años desde el alta, así que ese archivo crece sí o sí y hay que planificarlo.

4.3. Cuánto ocupa, con los datos del centro

El cálculo útil no es una cifra general, que engaña, sino la del propio centro: lo que ocupan las pruebas de un mes real, multiplicado por los años a conservar y con margen de crecimiento. Ese número decide el almacenamiento a contratar, y conviene tenerlo antes, no después, como se explica en qué hacer con los archivos de OCT de la consulta.

5. Tus datos, portables y en España

Al hablar de la nube aparecen las promesas grandes, y conviene distinguir lo que de verdad se ofrece de lo que suena bien y habría que poder demostrar.

5.1. Dónde están los servidores

En obeliOmed los servidores están en España, lo que es más concreto que «territorio europeo», y los documentos y los campos marcados como sensibles se cifran con AES-256-GCM. Es lo que se puede afirmar y verificar; no se prometen etiquetas de certificación que no se tienen.

5.2. Una copia de tus datos, cuando quieras

Cada centro puede descargar en cualquier momento una copia de sus propios datos. Es a la vez una garantía de portabilidad —no quedas atrapado en el proveedor— y la respuesta sensata a qué pasa si un día decides cambiar de sistema. No se promete una redundancia automática que habría que poder demostrar; se ofrece control sobre tu propia información.

5.3. Continuidad sin absolutos

Ningún proveedor serio garantiza que nunca habrá una incidencia. Lo razonable es preguntar qué ocurre cuando la hay: cuánto se tarda en recuperar el servicio, qué se hace con lo del día y cómo se comunica. Un proveedor que promete cero caídas está vendiendo un absoluto; uno fiable explica su plan cuando algo falla.

6. Rendimiento con varias consultas a la vez

El verdadero examen de una infraestructura no es abrir una prueba, sino abrir muchas a la vez. Ahí es donde se separan los sistemas que aguantan de los que se atascan.

6.1. Repartir la carga entre varios servidores

Cuando varios profesionales trabajan al mismo tiempo, la carga se reparte entre servidores en lugar de recaer sobre uno solo. Ese reparto es lo que permite que la consulta de las doce vaya igual de fluida que la de las nueve, cuando había menos gente conectada.

Repartir la carga entre servidores es lo que permite que la consulta de las doce vaya tan fluida como la de las nueve.

6.2. Servir la imagen por partes

Una prueba pesada no tiene por qué descargarse entera antes de verse: se puede empezar a mostrar mientras el resto sigue llegando. Ese detalle técnico es el que hace que un estudio grande aparezca en pantalla casi al instante en lugar de tras una espera. La imagen completa termina de cargar mientras el médico ya está mirando, un principio que también sostiene cómo reducir el tiempo de diagnóstico con redes en la nube.

6.3. Que la hora punta no cambie la experiencia

El objetivo, medible, es que el rendimiento sea parecido con uno o con diez usuarios. No es que nunca haya el más mínimo retraso —eso sería un absoluto—, sino que el sistema no se desmorone justo cuando más se usa, que es el fallo que más sufre un centro de alta rotación.

7. Dimensionar el hardware y la red del centro

Buena parte del rendimiento no depende del software sino de la red interna del centro, y esa parte sí es responsabilidad de la dirección. Conviene dimensionarla con criterio.

7.1. Ancho de banda y latencia para trabajar sin papeles

Un centro que mueve imagen necesita una conexión con capacidad suficiente y, sobre todo, con poca latencia. La latencia —el retraso de cada petición— pesa más que la velocidad bruta cuando se abren muchos archivos. Conviene medir la que hay antes de decidir, porque una línea aparentemente rápida puede tener una latencia que lo estropea todo.

7.2. La red interna de gabinetes y quirófanos

Dentro del centro, la red que une los equipos de imagen con los puestos de consulta tiene que estar pensada para el volumen que va a mover. Cables de categoría adecuada, electrónica de red con capacidad y una topología que no obligue a que todo pase por un único punto. Es infraestructura poco vistosa que decide la experiencia diaria.

7.3. Los puestos de consulta

Los ordenadores del box no necesitan ser potentes si el trabajo pesado se hace en el servidor y la imagen llega por partes. Eso permite alargar la vida del parque informático y gastar el presupuesto donde de verdad importa: la red y el almacenamiento, no una torre cara en cada mesa.

8. Qué exigir a un proveedor sobre volumen

Para la dirección que evalúa un cambio, estas exigencias separan a quien está preparado para el volumen de quien lo estará «en la siguiente versión».

• Arquitectura: ¿la gestión y las imágenes pesadas viven separadas o comparten la misma base de datos?
• Carga por partes: ¿una prueba pesada empieza a mostrarse antes de descargarse entera?
• Concurrencia: ¿cómo se comporta con diez usuarios abriendo pruebas a la vez, no con uno?
• Almacenamiento: ¿hay una capa rápida para lo del día y un archivo grande para el histórico?
• Custodia: ¿dónde están los servidores, qué se cifra y cómo se registra cada acceso?
• Portabilidad: ¿puede el centro descargar una copia de sus datos cuando quiera?

8.1. Pide una prueba con carga real

La demostración con un solo usuario y el estudio que trae el proveedor no dice nada. Lo que hay que ver es el sistema abriendo pruebas del propio centro con varios usuarios a la vez. El rendimiento en vacío engaña; el que importa es el de la hora punta, y solo se ve provocándolo a propósito.

8.2. Desconfía de los absolutos

«Nunca se ralentiza», «disponibilidad garantizada al cien por cien», «capacidad ilimitada»: en infraestructura, un absoluto es una bandera roja. Un proveedor serio da números concretos y explica sus límites, en lugar de prometer que no los tiene. Es la misma lógica de gestión que sostiene el software de gestión para clínicas privadas.

9. Qué hace obeliOmed con esto

El mecanismo, sin lista de funciones: la gestión y la imagen viven separadas, la prueba se sirve por partes y el histórico se planifica en lugar de sufrirse.

9.1. Gestión e imagen, cada una en su sitio

La historia clínica, la agenda y la contabilidad viven sobre un mismo núcleo ERP de código abierto, con un motor relacional preparado para muchas peticiones ligeras, mientras las imágenes pesadas van a su propio almacén. Así una búsqueda de paciente no compite con la apertura de una tomografía.

9.2. El visor que sirve por partes

El visor de imágenes DICOM —un módulo a +8 €/⁠mes— muestra el estudio dentro del expediente sin descargarlo entero, como detalla la página del visor universal para oftalmología. La imagen aparece rápido y termina de cargar mientras el médico ya trabaja.

9.3. La custodia y su límite

Servidores en España, cifrado de documentos y campos sensibles, trazabilidad de cada acceso y una copia de tus datos cuando quieras. Sin promesas de disponibilidad absoluta ni certificaciones que no se tienen. Y un histórico de imagen crece con los años: conviene dimensionar el almacenamiento antes, no después.

Separar los datos de gestión de las imágenes pesadas es lo que evita que el archivo más pesado marque el ritmo del más ligero.