Continuidad operativa tras un incidente: RTO, RPO y qué se restaura antes

1. Brecha frente a caída técnica

Este artículo trata la continuidad operativa tras incidente. La brecha de seguridad con implicación sobre datos personales tiene tratamiento específico en brecha de seguridad en clínicas. Aquí se decide qué hacer cuando el sistema clínico no funciona por causa técnica sin compromiso de datos personales.

1.1. La caída técnica sin compromiso de datos

Fallo del sistema por incidencia en la infraestructura, caída de conexión, error de aplicación que impide el acceso al expediente, incidencia técnica del proveedor de la infraestructura. La caída interrumpe la operativa del centro pero no implica acceso indebido a datos personales por parte de tercero, y por tanto no activa el protocolo específico de brecha con notificación a la AEPD en 72 horas.

1.2. La brecha con compromiso de datos

Acceso no autorizado a datos personales, exfiltración de información del expediente, pérdida efectiva de datos sin posibilidad de recuperación íntegra. La brecha activa el protocolo específico con obligación de notificación a la AEPD dentro de las 72 horas y con posible comunicación a los interesados afectados según la valoración del riesgo.

1.3. Lo que este artículo no cubre

Este artículo no ofrece asesoría técnica sobre configuración concreta ni sustituye la valoración del responsable técnico. Cuenta cómo se planifica la continuidad operativa, qué indicadores se usan y en qué orden se restaura el servicio. La decisión sobre la política concreta corresponde al centro con asesoramiento cualificado.

2. Los indicadores RTO y RPO

La continuidad operativa se planifica con dos indicadores técnicos que fijan objetivos concretos: RTO —tiempo objetivo de recuperación— y RPO —punto objetivo de recuperación—. Ambos son objetivos, no promesas, y su valor real es que obligan al centro a decidir con antelación qué es aceptable y qué no.

2.1. RTO: cuánto tarda el sistema en volver

RTO es el tiempo máximo aceptable entre el momento en que el sistema cae y el momento en que vuelve a estar operativo. Un RTO de dos horas significa que la política del centro tolera hasta dos horas de interrupción antes de que el impacto asistencial sea inaceptable. Se define por servicio del sistema y puede variar: el acceso a la agenda puede tener RTO más corto que la exportación de informes históricos.

2.2. RPO: cuánta información se puede perder

RPO es el punto máximo aceptable entre el momento del incidente y la copia de datos que se recupera. Un RPO de una hora significa que la política del centro tolera perder hasta una hora de información introducida antes del incidente. La política del centro se apoya en la infraestructura del servidor que hace copias periódicas, tratada en copia de seguridad automática.

2.3. La combinación de ambos

RTO y RPO se definen conjuntamente por servicio y son la base del plan de continuidad. La política del centro identifica los servicios críticos con RTO y RPO cortos y los servicios menos críticos con objetivos más laxos, y planifica la restauración según esa jerarquía.

3. Los datos críticos que se restauran primero

Cuando el sistema vuelve tras la caída, la restauración no ocurre simultáneamente en todos los servicios. La política del centro identifica los datos críticos que se restauran primero y los que pueden esperar.

3.1. Los datos que la asistencia inmediata exige

Agenda del día en curso, historia clínica de los pacientes citados en las próximas horas, medicación activa y alergias de esos pacientes concretos. Este bloque tiene RTO más corto porque su ausencia impide directamente la atención asistencial al paciente que está a punto de llegar o ya está en el propio centro.

3.2. Los datos de continuidad clínica sostenida

Historia clínica completa de todos los pacientes activos del centro, informes recientes, resultados pendientes de comunicar al paciente. Este bloque tiene RTO intermedio porque su ausencia afecta a la operativa clínica ordinaria pero no impide la atención urgente de las próximas horas.

3.3. Los datos administrativos e histórico

Facturación, agenda de próximas semanas, expedientes antiguos sin actividad reciente, información administrativa del propio centro. Este bloque tiene RTO más laxo porque su restauración diferida no compromete la atención asistencial inmediata ni la operativa clínica sostenida de los próximos días.

4. La secuencia de restauración

Se restaura primero lo que la asistencia inmediata exige. El resto puede esperar sin comprometer la operativa.

La secuencia concreta de restauración sigue la jerarquía de criticidad definida por la política del centro. Ejecutarla bien exige ensayo previo, porque la primera vez que se prueba una restauración no es en el momento adverso.

4.1. La verificación del incidente

El equipo técnico verifica el alcance del incidente: qué servicios están caídos, si hay pérdida efectiva de datos, cuál es la ventana temporal afectada. La verificación es paso previo a la restauración porque orienta qué copia se restaura y desde qué punto.

4.2. La restauración por orden de criticidad

Se restaura primero el bloque de datos críticos que la asistencia inmediata exige. Cuando el servicio vuelve a estar operativo sobre este bloque, la atención asistencial puede continuar mientras el resto de bloques se restaura en paralelo o secuencialmente según la infraestructura permita.

4.3. La verificación post-restauración

Cada bloque restaurado se verifica funcionalmente antes de declarar operativo el servicio: apertura de expediente reciente para confirmar acceso, prueba de escritura de datos nuevos para confirmar que la funcionalidad es completa, comprobación de integridad de datos restaurados desde la copia. La verificación evita declarar operativo un servicio que en realidad no lo está.

5. Agenda frente a historia clínica

La agenda del centro y la historia clínica tienen objetivos de continuidad distintos aunque ambas viven en el mismo sistema. La política del centro reconoce la distinción y aplica RTO y RPO específicos a cada una.

5.1. La agenda como servicio crítico inmediato

La agenda es el servicio con mayor visibilidad operativa durante la caída: la recepción no puede confirmar horarios, el equipo no sabe qué pacientes vienen a qué hora, la operativa del propio día se paraliza. Su RTO es habitualmente el más corto del sistema y su restauración tiene prioridad máxima.

5.2. La historia clínica del día en curso

La historia clínica de los pacientes concretamente citados el día del incidente tiene también RTO corto porque la atención asistencial la exige. La política habitual restaura esta parte en paralelo con la agenda del día para que la consulta pueda continuar cuando el paciente llegue.

5.3. La historia clínica completa e histórico

La historia clínica completa de todo el archivo del centro y los expedientes históricos tienen RTO más laxo. Su restauración se completa en horas siguientes sin comprometer la operativa asistencial inmediata que ya se recuperó con los dos bloques anteriores.

6. Qué se le dice al paciente

Durante la caída del sistema, el paciente puede llegar al centro sin saber que hay incidencia, llamar al mostrador o consultar la web del centro. La comunicación al paciente durante el incidente es parte de la propia continuidad operativa.

6.1. La comunicación al paciente ya en el centro

El paciente que llega a su cita mientras el sistema está caído recibe información concreta sobre lo que está ocurriendo, opciones disponibles —esperar a que el sistema vuelva, reprogramar la cita, atención por vía alternativa cuando aplique— y estimación honesta del tiempo previsible. La comunicación específica evita que el paciente se marche enfadado por falta de información.

6.2. La comunicación al paciente por teléfono

El paciente que llama al centro y descubre que no se le puede atender por caída del sistema recibe también información concreta sobre lo que está pasando y cuándo se prevé volver a funcionar. La política del centro puede prever recogida manual de la incidencia en papel para gestionarla cuando el sistema vuelva, con la trazabilidad correspondiente.

6.3. La comunicación proactiva cuando el incidente se prolonga

Si el incidente se prolonga más allá del RTO previsto, la comunicación proactiva al paciente afectado por cita en las próximas horas es la práctica habitual: reprogramación anticipada, información sobre alternativas, contacto directo cuando la naturaleza del caso lo exige. La proactividad evita que el paciente se desplace inútilmente al centro y protege la relación posterior con el propio centro.

7. El registro del incidente

Cada incidente de continuidad operativa queda registrado como acto específico con la información suficiente para reconstruir después el propio proceso y para aprender de él.

7.1. El registro cronológico completo

Momento de detección del incidente, alcance identificado, decisiones tomadas durante el incidente, momento en que cada servicio se restauró, verificación post-restauración de cada bloque. La cronología completa se documenta durante el propio incidente y no se reconstruye después, porque la reconstrucción posterior siempre pierde información.

7.2. Los pacientes afectados

Lista de pacientes con cita durante el periodo del incidente, comunicaciones dirigidas a cada uno, reprogramaciones realizadas, atenciones por vía alternativa cuando aplique. La lista es referencia posterior útil para seguimiento del propio paciente y para responder a preguntas sobre el impacto del incidente sobre casos concretos.

7.3. La documentación técnica del incidente

Causa técnica identificada del incidente, medidas técnicas aplicadas para restaurar el servicio, análisis posterior de la propia causa. La documentación técnica es responsabilidad del propio proveedor de la infraestructura que gestionó la restauración, y se comparte con el centro como parte de la relación de encargo del tratamiento, tratada en contrato de encargado del tratamiento.

8. El aprendizaje posterior

La primera vez que se prueba un plan no es en el incidente real. El ensayo periódico separa plan real de plan declarado.

Cada incidente es oportunidad de aprendizaje para reducir la probabilidad y el impacto del siguiente. La política del centro programa revisión sistemática de cada incidente y aplica mejoras concretas sobre el plan de continuidad.

8.1. La revisión con el proveedor de la infraestructura

Reunión posterior al incidente con el proveedor de la infraestructura para revisar la causa técnica, la respuesta del propio proveedor, el ajuste de RTO y RPO efectivos frente a los objetivos, y las mejoras posibles sobre el plan de continuidad. La reunión produce documento con acciones concretas y responsables asignados.

8.2. La actualización del plan de continuidad

Los aprendizajes del incidente se incorporan al plan de continuidad del centro: ajuste de RTO y RPO cuando la experiencia lo justifica, refinamiento de la secuencia de restauración, mejora del circuito de comunicación al paciente durante la caída, actualización de la política sobre atención por vía alternativa mientras el sistema no está disponible.

8.3. El ensayo periódico del plan

Además del aprendizaje de incidentes reales, la política del centro programa ensayo periódico del plan de continuidad —simulación de caída en horario controlado, verificación del propio proceso de restauración sobre entorno de prueba— para asegurar que el plan sigue vigente y que el equipo del centro sabe ejecutarlo cuando llegue el incidente real.

9. Qué aporta obeliOmed

La continuidad operativa se apoya en varias capas de la pila técnica del centro. obeliOmed aporta como sistema clínico la parte que le corresponde: información técnica sobre RTO y RPO efectivos, coordinación con el propio proveedor de la infraestructura para la restauración cuando el incidente ocurre, y facilitación del registro cronológico del incidente para el aprendizaje posterior.

9.1. La parte del sistema clínico dentro del plan

obeliOmed es el sistema clínico que corre sobre la infraestructura del centro. Las copias periódicas que sostienen el RPO efectivo las hace el propio servidor, no el sistema clínico. Cuando aparece un incidente, la coordinación entre el centro, el sistema clínico y el proveedor de la infraestructura es lo que define la calidad efectiva de la respuesta. La política del centro sobre continuidad se documenta con el detalle de qué hace cada capa y quién es responsable de cada paso del propio plan. La responsabilidad de tener el plan escrito y probado corresponde al centro; lo que el sistema aporta es la información técnica y la coordinación con el resto de la pila cuando toca ejecutar la restauración.

9.2. Con qué se combina

La continuidad operativa se combina con la propia infraestructura del servidor donde vive el sistema clínico y con el plan de contingencia ante brecha específica de datos, tratado aparte en plan de contingencia ante brecha de seguridad.