Continuidad, respaldo y recuperación no son lo mismo
En tecnología solemos hablar mucho de disponibilidad, estabilidad y seguridad. Pero hay una pregunta que a veces evitamos hasta que ya es demasiado tarde:
¿Qué pasa cuando el PACS se cae?
Ningún sistema tecnológico es infalible.
Puede fallar un servidor. Puede interrumpirse una comunicación. Puede existir un problema de almacenamiento, energía, red, virtualización, sistema operativo o incluso un incidente externo que afecte la infraestructura.
Por eso, una arquitectura de imágenes médicas no debería diseñarse bajo la premisa de que nunca ocurrirá una falla.
Debería diseñarse bajo una pregunta más realista:
¿Qué haremos cuando ocurra?
La verdadera prueba de una arquitectura no ocurre cuando todo funciona, sino cuando algo deja de funcionar.
Tener backup no significa tener continuidad
Uno de los errores más frecuentes es utilizar como sinónimos palabras que representan cosas diferentes.
Backup, continuidad y recuperación no son lo mismo.
Un backup es una copia de información que permite recuperarla después de una pérdida o incidente.
Es indispensable.
Pero que exista una copia de seguridad no significa necesariamente que la operación pueda continuar.
Imaginemos que todos los estudios están perfectamente respaldados, pero el PACS principal deja de funcionar.
Las preguntas inmediatas serían otras:
¿Pueden las modalidades seguir enviando estudios?
¿Dónde se almacenan mientras el sistema principal está fuera de servicio?
¿Puede el radiólogo acceder a ellos?
¿Puede continuar informando?
¿Qué ocurre con los estudios realizados durante la interrupción?
¿Cómo regresarán después al sistema principal?
Es posible tener un excelente backup y, aun así, permanecer horas sin poder operar.
Resguardar la información y mantener la operación son dos problemas distintos.
Una buena arquitectura debe resolver ambos.
Continuidad: seguir trabajando mientras resolvemos el problema
La continuidad operativa busca reducir el impacto de una interrupción y permitir que los procesos críticos continúen funcionando mientras se restablece la plataforma principal.
En radiología esto tiene una dimensión especial.
El paciente sigue llegando.
Las modalidades continúan produciendo estudios.
El médico sigue esperando resultados.
Y el radiólogo necesita continuar trabajando.
Por eso, una estrategia de continuidad puede requerir mecanismos que permitan recibir temporalmente estudios, almacenarlos, ponerlos a disposición del personal autorizado y conservarlos hasta que el sistema principal pueda volver a recibirlos.
La continuidad no significa que todo deba funcionar exactamente igual que en condiciones normales.
Significa que las funciones esenciales puedan mantenerse.
Continuidad no es ausencia de problemas. Es capacidad para seguir operando a pesar de ellos.
Recuperación: volver a la normalidad
Una vez controlada la interrupción aparece una segunda tarea:
Recuperar el entorno normal de operación.
La recuperación puede incluir restaurar servidores, servicios, bases de datos, configuraciones, imágenes, integraciones y comunicaciones.
Pero existe otra parte igualmente importante:
Reconciliar lo que ocurrió durante la interrupción.
Si durante ese período se generaron nuevos estudios, estos deben incorporarse posteriormente al archivo principal de forma segura y ordenada.
El objetivo no es únicamente “levantar el sistema”.
Es recuperar la integridad de la operación.
Una recuperación incompleta puede dejar estudios dispersos, información duplicada o procesos sin cerrar.
Por eso, continuidad y recuperación deben diseñarse juntas.
Dos preguntas esenciales: ¿cuánto tiempo y cuánta información?
Cuando se planifica la recuperación aparecen dos conceptos útiles:
RTO — Recovery Time Objective
Es el tiempo máximo que una organización considera aceptable permanecer sin recuperar una determinada función.
No todas las instituciones tienen el mismo RTO.
Un pequeño centro puede tolerar una interrupción diferente a la de un hospital que opera las 24 horas.
RPO — Recovery Point Objective
Representa cuánta información puede perderse, expresada generalmente como un período de tiempo.
Por ejemplo, si el último respaldo disponible tiene varias horas de antigüedad, todos los cambios ocurridos después de ese punto podrían estar en riesgo.
RTO y RPO ayudan a convertir una idea vaga como “necesitamos estar protegidos” en objetivos que pueden ser diseñados, medidos y evaluados.
La pregunta no es solamente si podemos recuperarnos, sino cuánto tardaremos y qué podríamos perder.
¿Qué ocurre con las modalidades?
Este punto merece especial atención.
Cuando el PACS principal no está disponible, las modalidades pueden convertirse en una especie de almacenamiento temporal.
Muchos equipos pueden retener estudios durante cierto período.
Pero confiar exclusivamente en eso puede ser riesgoso.
Cada modalidad tiene una capacidad diferente, y su función principal es producir estudios, no convertirse en el sistema de contingencia de toda la institución.
Una estrategia de continuidad debería preguntarse:
¿Existe un destino alternativo al que las modalidades puedan enviar los estudios mientras el PACS principal está fuera de servicio?
Esto puede reducir la dependencia del almacenamiento local de cada equipo y facilitar la posterior recuperación.
La continuidad debe contemplar el flujo completo, no solamente el servidor.
La redundancia ayuda, pero tampoco resuelve todo
Otra palabra frecuente es redundancia.
Tener componentes duplicados puede reducir algunos puntos de falla.
Por ejemplo, pueden existir servidores, almacenamiento, conexiones o servicios alternativos.
Pero redundancia no significa automáticamente continuidad.
Dos servidores ubicados en el mismo lugar pueden quedar fuera de servicio por un mismo incidente.
Dos copias conectadas permanentemente pueden verse afectadas por el mismo problema.
Una buena estrategia debe analizar no solo cuántas copias o componentes existen, sino también:
dónde están;
cómo están conectados;
qué dependencias comparten;
qué sucede cuando uno falla;
y cómo se activa la alternativa.
La arquitectura debe analizar escenarios de falla, no solamente inventarios de infraestructura.
La nube tampoco elimina el problema
La nube ha agregado enormes posibilidades de disponibilidad, escalabilidad y recuperación.
Pero tampoco debe entenderse como una garantía absoluta.
Un servicio en la nube depende de conectividad, configuración, credenciales, disponibilidad del proveedor y de una arquitectura correctamente diseñada.
Si la institución pierde su acceso a Internet, una plataforma remota puede seguir funcionando perfectamente y, aun así, resultar inaccesible desde el lugar donde se necesita.
Por eso, las arquitecturas híbridas pueden tener sentido en determinados escenarios.
No porque “local” sea mejor que “nube” o viceversa.
Sino porque cada entorno tiene riesgos distintos.
La continuidad no depende de dónde esté la tecnología. Depende de cómo se haya diseñado la arquitectura.
Un plan que nunca se prueba es solamente una intención
Podemos tener documentación impecable.
Diagramas.
Procedimientos.
Backups.
Servidores alternativos.
Incluso una política formal de recuperación.
Pero existe una pregunta incómoda:
¿Lo hemos probado?
La única manera de saber si una estrategia realmente funciona es someterla periódicamente a pruebas.
¿Podemos restaurar el backup?
¿Podemos acceder a los estudios?
¿Las modalidades saben dónde enviar durante una contingencia?
¿El personal conoce el procedimiento?
¿Cuánto tardamos realmente?
¿La información producida durante la prueba vuelve correctamente al entorno principal?
Una copia de seguridad que nunca se ha restaurado es una promesa.
Un plan de continuidad que nunca se ha probado también.
Lo que no se prueba no debería asumirse que funciona.
La continuidad es también una decisión clínica
Es fácil pensar que todo esto pertenece exclusivamente al departamento de tecnología.
Pero cuando un PACS deja de estar disponible, el impacto llega rápidamente a la operación clínica.
Puede retrasarse una interpretación.
Puede dificultarse el acceso a estudios previos.
Puede detenerse un flujo de trabajo.
Puede afectar al médico referente.
Y, finalmente, puede afectar al paciente.
Por eso la continuidad de los sistemas de imágenes médicas no debería considerarse únicamente un asunto de infraestructura.
Es también parte de la calidad asistencial.
Diseñar para la falla
Una arquitectura madura no promete que nunca habrá interrupciones.
Reconoce que pueden ocurrir.
Y se prepara.
Esto significa proteger la información, mantener funciones críticas, definir tiempos de recuperación, disponer de mecanismos alternativos y comprobar periódicamente que todo funciona como fue diseñado.
En GT-IT Medical creemos que la continuidad debe formar parte de la arquitectura desde el principio, no añadirse después de que ocurra el primer problema.
La pregunta no debería ser:
¿Puede fallar nuestro PACS?
La respuesta siempre será sí.
La pregunta correcta es:
¿Estamos preparados para continuar y recuperarnos cuando ocurra?
Esta conversación continúa
La continuidad protege la operación frente a una interrupción.
Pero existe otra forma de dependencia que también merece atención:
¿Qué ocurre cuando una institución quiere cambiar de PACS?
¿Puede trasladar libremente sus imágenes?
¿El archivo está realmente bajo su control?
¿Es posible migrar desde una plataforma propietaria sin poner en riesgo años de historia clínica?
Ese será el tema de nuestra próxima entrega:
¿De quién son realmente sus imágenes médicas?
Propiedad, portabilidad e independencia tecnológica del archivo clínico.