OP.CONT.4 Medios alternativos

☑️Aplicación de la medida

De acuerdo al ANEXO II, 2 Selección de medidas de seguridad, la medida de seguridad OP.CONT.4 Medios alternativos sí aplica dada la categoría de seguridad del sistema.

Documentos de referencia

• ISO/IEC 27000:
  • 27031:2011 - Guidelines for information and communication technology readiness for business continuity
  • 27002:2013:
    • 17.1.1 - Planning information security continuity
    • 17.1.2 - Implementing information security continuity
• NIST SP 800-53 rev4:
  • [CP-2] Contingency Plan
  • [CP-6] Alternate Storage Site
  • [CP-7] Alternate Processing Site
  • [CP-8] Telecommunications Services
• Otras referencias:
  • ISO 22301:2019 - Security and resilience — Business continuity management systems
  • NIST SP 800-34 Rev.1 - Contingency Planning Guide for Federal Information Systems
  • FDA Cybersecurity in Medical Devices: Quality System Considerations

Guía de implantación

187. Se establecerán medios alternativos que permitan mantener el nivel de seguridad requerido cuando los mecanismos de protección habituales no puedan aplicarse.

Los medios alternativos contemplarán aspectos como:

• Mecanismos de comunicación alternativos en caso de fallo del principal
• Procedimientos manuales cuando no estén operativos los automatizados
• Ubicaciones alternativas para el personal clave cuando la principal no esté disponible
• Medios alternativos para el intercambio de información

Implementación en Legit Health Plus

Marco de medios alternativos

El sistema de medios alternativos de Legit Health Plus está diseñado para proporcionar capacidades de respaldo que permitan mantener operaciones críticas cuando los sistemas primarios no están disponibles, garantizando continuidad asistencial y cumplimiento regulatorio.

Principios de diseño de alternativas

• Diversidad tecnológica: Evitar puntos únicos de fallo mediante tecnologías diferentes
• Separación geográfica: Recursos alternativos en ubicaciones físicas distintas
• Degradación controlada: Funcionalidad reducida pero servicios críticos mantenidos
• Activación automática: Conmutación sin intervención manual donde sea posible
• Validación médica: Todas las alternativas validadas para uso clínico

Categorización de medios alternativos

Alternativos automáticos (Tier 1)

• RTO: < 5 minutos
• Activación: Automática mediante failover
• Funcionalidad: 90-100% del servicio normal
• Ejemplos: Failover de base de datos, balanceadores de carga

Alternativos manuales rápidos (Tier 2)

• RTO: 5-30 minutos
• Activación: Manual con procedimientos automatizados
• Funcionalidad: 70-90% del servicio normal
• Ejemplos: Cambio de región cloud, activación de instancias standby

Medios degradados (Tier 3)

• RTO: 30-60 minutos
• Activación: Manual con intervención técnica significativa
• Funcionalidad: 30-70% del servicio normal
• Ejemplos: Modo solo lectura, procedimientos manuales

Infraestructura alternativa

Sitios de procesamiento alternativo

Región primaria: AWS eu-west-1 (Irlanda)

Configuracion_Primaria:
  Region: "eu-west-1"
  AZs: ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  Instances:
    - diagnosis-service: "3x c5.xlarge"
    - database-primary: "db.r5.large"
    - web-frontend: "2x t3.medium"
  Storage: "S3 Standard + EBS gp3"
  Network: "VPC 10.0.0.0/16"

Región alternativa: AWS eu-central-1 (Frankfurt)

Configuracion_Alternativa:
  Region: "eu-central-1"
  AZs: ["eu-central-1a", "eu-central-1b"]
  Instances:
    - diagnosis-service: "2x c5.large (standby)"
    - database-replica: "db.r5.large (read-replica)"
    - web-frontend: "1x t3.medium (standby)"
  Storage: "S3 Standard-IA + Cross-region replication"
  Network: "VPC 10.1.0.0/16"

Activacion_Alternativa:
  Trigger: "Fallo completo región primaria"
  Tiempo_RTO: "15-20 minutos"
  Procedimiento: "Script automatizado + validación manual"
  Funcionalidad: "85% del servicio normal"

Sitio de contingencia híbrido (On-premise + Cloud)

Sitio_Contingencia_Madrid:
  Ubicacion: "Oficinas centrales Madrid"
  Configuracion:
    - Mini-cluster: "3x Intel NUC i7"
    - Storage: "Synology NAS 24TB RAID-6"
    - Network: "Fibra 1Gbps + 4G backup"
    - UPS: "15 minutos autonomía"

  Capacidad: "Solo servicios críticos básicos"
  Funcionalidad:
    - Consulta de estudios previos: "✓"
    - Captura nuevas imágenes: "✓ (local storage)"
    - Diagnóstico IA: "❌ (sin GPU suffciente)"
    - Integración EMR: "❌ (conectividad limitada)"

  Casos_Uso:
    - Fallo simultáneo de ambas regiones AWS
    - Problemas de conectividad generalizada
    - Escenarios de fuerza mayor (pandemia, catástrofe)

Medios de comunicación alternativos

Comunicaciones internas del equipo

Primario: Slack + Microsoft Teams

Comunicacion_Primaria:
  Plataforma: "Slack + MS Teams"
  Canales_Criticos:
    - "#incidents": "Gestión de incidentes"
    - "#on-call": "Equipo de guardia 24/7"
    - "#executive": "Management y decisiones"
  Integraciones:
    - PagerDuty: "Alertas automáticas"
    - Grafana: "Dashboards embebidos"
    - GitHub: "Notificaciones de deployments"

Alternativo 1: WhatsApp Business + Telegram

Comunicacion_Alternativa_1:
  Trigger: "Fallo de Slack/Teams > 10 minutos"
  Plataforma: "WhatsApp Business API"
  Grupos:
    - "Crisis Management": "CTO, CMO, DevOps Lead"
    - "Technical Response": "Todo el equipo técnico"
    - "External Comms": "PR, Legal, Customer Success"

  Ventajas:
    - "Disponible en móviles siempre"
    - "Funciona con conectividad limitada"
    - "Interfaz familiar para todos"

  Limitaciones:
    - "Sin integraciones automatizadas"
    - "Menos formal para comunicaciones críticas"
    - "Privacidad limitada"

Alternativo 2: SMS en cascada + Llamadas telefónicas

Comunicacion_Alternativa_2:
  Trigger: "Fallo comunicaciones digitales > 30 minutos"
  Metodo: "SMS Cascade + Conference Calls"

  SMS_Cascade:
    - CTO → CMO → DevOps Lead → Development Team
    - ISO → Legal → Customer Success → Support Team
    - Templates predefinidos para diferentes tipos de crisis

  Conference_Bridge:
    - Proveedor: "Zoom Phone + backup Cisco Webex"
    - Numero_Fijo: "+34 91 XXX XXXX"
    - PIN_Crisis: "[CONFIDENCIAL]"
    - Capacidad: "100 participantes"

  Procedimiento_Activacion: 1. "CTO envía SMS inicial con bridge details"
    2. "Cada receptor confirma con 'OK + nombre'"
    3. "Join conference call en 15 minutos"
    4. "Roll call y briefing de situación"

Comunicaciones externas (clientes y autoridades)

Primario: Email + Portal web + Llamadas directas Alternativo: SMS masivo + Redes sociales + Medios tradicionales

Comunicacion_Externa_Alternativa:
  SMS_Masivo:
    Proveedor: "Twilio SendGrid"
    Alcance: "Contactos técnicos de 150+ hospitales"
    Template: "URGENTE: Legit Health Plus - Interrupción del servicio.
      Estamos trabajando en la resolución.
      ETA: [XX:XX].
      Más info: status.legit.health"

  Redes_Sociales:
    Twitter: "@LegitHealth_ES"
    LinkedIn: "Legit Health Company Page"
    Uso: "Solo para crisis de alta visibilidad pública"

  Medios_Tradicionales:
    Contacto_Prensa: "PR Agency + CMO"
    Activacion: "Solo si crisis > 4 horas o impacto mediático"
    Templates: "Preparados para diferentes escenarios"

Procedimientos alternativos manuales

Diagnóstico manual sin IA

Cuando el servicio de diagnóstico automatizado no está disponible, se activan procedimientos manuales que mantienen la continuidad asistencial:

Protocolo de diagnóstico manual

## Procedimiento Manual de Diagnóstico Dermatológico

**Activación**: Fallo del servicio IA > 15 minutos
**Responsable**: Dermatólogo de guardia + Equipo técnico

### Paso 1: Captura y almacenamiento de imágenes

1. **Captura normal**: Usar interfaz web estándar
2. **Metadatos mínimos**:
   - ID paciente
   - Fecha y hora
   - Localización anatómica
   - Notas clínicas del profesional
3. **Almacenamiento temporal**: Local + sincronización diferida

### Paso 2: Evaluación clínica directa

1. **Triage médico**:
   - Urgente: Posible melanoma, lesiones inflamatorias severas
   - Normal: Seguimiento rutinario, lesiones benignas aparentes
   - Diferible: Controles preventivos, lesiones claramente benignas

2. **Documentación manual**:
   - Descripción clínica detallada
   - Índices ALEGI/DLQI estimados (basado en experiencia)
   - Recomendaciones de tratamiento
   - Plan de seguimiento

### Paso 3: Marcado para revisión posterior

- **Tag especial**: "MANUAL-REVIEW-REQUIRED"
- **Prioridad**: Basada en evaluación médica inicial
- **Timeline**: Revisión IA dentro de 24h de restauración del servicio

### Paso 4: Comunicación con paciente

"Su estudio ha sido evaluado por nuestro equipo médico especializado.
Debido a mantenimiento técnico temporal, el análisis automatizado se
completará en las próximas 24 horas para confirmación adicional."

Integración manual con EMR/HIS

Procedimiento de intercambio manual de datos

#!/bin/bash
# Script para exportación manual cuando falla integración automática

EMR_MANUAL_EXPORT_DIR="/tmp/emr_manual_exports"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# 1. Crear directorio temporal
mkdir -p $EMR_MANUAL_EXPORT_DIR

# 2. Exportar casos pendientes desde las últimas 4 horas
psql -d legit_health -c "
COPY (
    SELECT
        patient_id,
        study_date,
        diagnosis_result,
        alegi_score,
        dlqi_score,
        recommendations,
        'MANUAL_EXPORT_$TIMESTAMP' as export_batch
    FROM diagnostic_results
    WHERE created_at > NOW() - INTERVAL '4 hours'
    AND emr_sync_status = 'pending'
) TO '$EMR_MANUAL_EXPORT_DIR/export_$TIMESTAMP.csv'
WITH CSV HEADER;
"

# 3. Generar archivo compatible HL7 FHIR
python3 convert_csv_to_fhir.py \
    --input "$EMR_MANUAL_EXPORT_DIR/export_$TIMESTAMP.csv" \
    --output "$EMR_MANUAL_EXPORT_DIR/fhir_bundle_$TIMESTAMP.json" \
    --format "hl7_fhir_r4"

# 4. Cifrar para transferencia manual
gpg --encrypt --recipient hospital-integration@legit.health \
    "$EMR_MANUAL_EXPORT_DIR/fhir_bundle_$TIMESTAMP.json"

# 5. Notificar a hospitales sobre disponibilidad de datos
python3 notify_manual_data_available.py \
    --batch_id "$TIMESTAMP" \
    --record_count $(wc -l < "$EMR_MANUAL_EXPORT_DIR/export_$TIMESTAMP.csv") \
    --download_url "https://secure.legit.health/manual-exports/$TIMESTAMP"

echo "Exportación manual completada: $TIMESTAMP"
echo "Archivos disponibles en: $EMR_MANUAL_EXPORT_DIR"

Ubicaciones alternativas para personal clave

Trabajo remoto completo

Configuración de oficina en casa para roles críticos

Home_Office_Setup:
  Roles_Aplicables:
    - Crisis Manager (CTO)
    - Medical Safety Officer
    - DevOps Lead
    - Customer Success Manager

  Hardware_Proporcionado:
    - Laptop: "MacBook Pro 16' M3 Max"
    - Monitor: "Dell UltraSharp 27' 4K"
    - Webcam: "Logitech Brio 4K"
    - Headset: "Sennheiser MB Pro 2"
    - UPS: "APC Back-UPS 600VA"
    - Mobile Hotspot: "Verizon Jetpack 8800L"

  Conectividad:
    - Fibra doméstica: ">= 100 Mbps simetrico"
    - 4G/5G backup: "Unlimited data plan"
    - VPN corporativa: "Siempre activa"
    - Secure phone line: "VoIP + PSTN backup"

  Seguridad:
    - MFA obligatorio: "Hardware tokens"
    - Endpoint protection: "CrowdStrike Falcon"
    - Network monitoring: "Zscaler"
    - Physical security: "Caja fuerte para devices"

Centro alternativo temporal

Coworking space preparado (Plan B)

Coworking_Alternativo_Madrid:
  Ubicacion: "WeWork Castellana 77, Madrid"
  Capacidad: "10 personas simultáneas"
  Disponibilidad: "24×7 mediante acuerdo especial"

  Equipamiento_Preposicionado:
    - "5x Workstations completas"
    - "Router empresarial con doble WAN"
    - "Videoconferencing setup profesional"
    - "Whiteboard y flip charts"
    - "Caja fuerte para documentación sensible"

  Servicios_Incluidos:
    - "Fibra 1Gbps dedicada"
    - "Catering para sesiones largas"
    - "Servicios de limpieza"
    - "Seguridad 24×7"

  Activacion:
    Trigger: "Oficina principal inaccesible > 2 horas"
    Tiempo_Setup: "30 minutos"
    Procedimiento: "Llamada a WeWork + activación remota equipos"

Oficina satélite Barcelona (Plan C)

Oficina_Barcelona:
  Ubicacion: "22@ District, Barcelona"
  Tipo: "Oficina satelite permanente (pequeña)"
  Personal_Base: "2 desarrolladores + 1 customer success"

  Escalado_Crisis:
    Capacidad_Maxima: "8 personas"
    Equipamiento_Crisis: "Almacenado en armario dedicado"
    Tiempo_Activacion: "2 horas"

  Limitaciones:
    - "Sin acceso físico a hardware crítico"
    - "Conectividad dependiente de ISP local"
    - "Horarios de edificio (7:00-23:00)"

Medios alternativos para intercambio de información

Transferencia de datos críticos

Alternativas a transferencias digitales normales

Método primario: HTTPS + API REST Alternativo 1: SFTP + VPN dedicada Alternativo 2: Física + cifrado

Transferencia_Fisica_Cifrada:
  Casos_Uso:
    - "Fallo prolongado de conectividad"
    - "Requerimientos de alta seguridad"
    - "Volúmenes muy grandes de datos"

  Procedimiento: 1. "Cifrado AES-256 + GPG"
    2. "Almacenamiento en discos SSD cifrados"
    3. "Transporte por mensajería certificada"
    4. "Entrega con doble firma + ID verification"

  Proveedores:
    - Mensajeria: "SEUR Empresas + DHL Express"
    - Hardware: "Samsung T7 2TB cifrado por hardware"
    - Tracking: "GPS + blockchain proof-of-delivery"

  Timeline:
    - Madrid-Barcelona: "4-6 horas"
    - Madrid-Lisboa: "12-18 horas"
    - Madrid-Paris: "18-24 horas"

5.2 Comunicación segura con autoridades regulatorias

Canales alternativos para notificaciones críticas

AEMPS_Communication_Alternatives:
  Primary: "Portal electronico AEMPS"
  Alternative_1: "Email certificado + telefono"
  Alternative_2: "Fax + confirmacion telefonica"
  Alternative_3: "Entrega fisica en oficinas"

  Templates_Preparados:
    - "Incident notification < 24h"
    - "Service disruption > 4 hours"
    - "Data breach notification"
    - "Device malfunction report"

INCIBE_Communication_Alternatives:
  Primary: "Portal LUCIA + INES"
  Alternative_1: "Email a incidencias@incibe.es"
  Alternative_2: "Telefono 24×7: +34 917 042 222"
  Alternative_3: "Carmen platform backup"

  Auto_Escalation:
    - "Si no hay confirmación en 1 hora → llamada telefónica"
    - "Si no hay respuesta en 2 horas → escalado a supervisor"
    - "Si no hay contacto en 4 horas → contacto directo con CNCS"

Procedimientos de activación de medios alternativos

6.1 Matriz de activación automática vs manual

Tipo de Fallo	Alternativa	Activación	RTO	Decisor
DB Principal	Read replica	Automática	5 min	Sistema
Región completa	Segunda región	Manual	20 min	CTO
Servicio IA	Modo manual	Semi-auto	10 min	CMO
Conectividad	4G/5G backup	Automática	2 min	Sistema
Oficina principal	Remoto/Coworking	Manual	60 min	CTO
Todo el cloud	On-premise	Manual	120 min	CTO+CMO

6.2 Scripts de activación automatizada

Activación de región alternativa

#!/usr/bin/env python3
# Script de activación de región alternativa AWS

import boto3
import time
import logging
from typing import Dict, List

class AlternateRegionActivation:
    def __init__(self):
        self.primary_region = 'eu-west-1'
        self.alternate_region = 'eu-central-1'
        self.activation_log = []

    def activate_alternate_region(self) -> Dict[str, any]:
        """Activa infraestructura en región alternativa"""
        print("🚨 ACTIVANDO REGIÓN ALTERNATIVA")
        print(f"Región primaria: {self.primary_region} → Alternativa: {self.alternate_region}")

        try:
            # 1. Verificar estado de región alternativa
            self.verify_alternate_region_ready()

            # 2. Promocionar read replica a primary
            db_promotion = self.promote_database_replica()

            # 3. Escalar instancias de aplicación
            app_scaling = self.scale_application_instances()

            # 4. Actualizar DNS para redirigir tráfico
            dns_update = self.update_dns_routing()

            # 5. Verificar conectividad end-to-end
            connectivity_test = self.test_end_to_end_connectivity()

            # 6. Activar monitorización en nueva región
            monitoring_setup = self.setup_monitoring()

            activation_results = {
                'success': True,
                'timestamp': time.time(),
                'duration_seconds': time.time() - start_time,
                'components_activated': {
                    'database': db_promotion,
                    'application': app_scaling,
                    'dns': dns_update,
                    'connectivity': connectivity_test,
                    'monitoring': monitoring_setup
                }
            }

            # 7. Notificar éxito
            self.notify_successful_activation(activation_results)
            return activation_results

        except Exception as e:
            self.handle_activation_failure(str(e))
            return {'success': False, 'error': str(e)}

    def promote_database_replica(self) -> bool:
        """Promociona read replica a primary database"""
        print("📊 Promocionando read replica a primary...")

        rds = boto3.client('rds', region_name=self.alternate_region)

        # Promocionar replica
        response = rds.promote_read_replica(
            DBInstanceIdentifier='legit-health-replica-alt'
        )

        # Esperar hasta que esté disponible
        waiter = rds.get_waiter('db_instance_available')
        waiter.wait(
            DBInstanceIdentifier='legit-health-replica-alt',
            WaiterConfig={'Delay': 15, 'MaxAttempts': 40}
        )

        print("✅ Database promotion completado")
        return True

Testing y validación de medios alternativos

7.1 Programa de testing específico

Testing mensual de alternativas

Monthly_Alternative_Testing:
  Semana_1:
    - Test: "Database failover a read replica"
    - Duracion: "30 minutos"
    - Impacto: "Zero downtime"

  Semana_2:
    - Test: "Comunicaciones alternativas (WhatsApp)"
    - Duracion: "15 minutos"
    - Participantes: "Todo el equipo"

  Semana_3:
    - Test: "Trabajo remoto completo"
    - Duracion: "4 horas"
    - Scope: "Equipos críticos desde casa"

  Semana_4:
    - Test: "Procedimientos manuales diagnóstico"
    - Duracion: "2 horas"
    - Validacion: "Equipo médico"

7.2 Validación de capacidad alternativa

Métricas de performance de alternativas

class AlternativePerformanceMetrics:
    def __init__(self):
        self.metrics = {}

    def measure_alternative_performance(self, alternative_type: str):
        """Mide performance de medios alternativos vs primarios"""

        if alternative_type == "database_failover":
            return {
                'rto_measured': 4.2,  # minutos
                'rpo_measured': 0,     # sin pérdida datos
                'performance_degradation': 0.05,  # 5% más lento
                'functionality_available': 1.0    # 100% funcional
            }

        elif alternative_type == "region_failover":
            return {
                'rto_measured': 18.5,  # minutos
                'rpo_measured': 0.2,   # 12 segundos pérdida
                'performance_degradation': 0.15,  # 15% más lento
                'functionality_available': 0.85   # 85% funcional
            }

        elif alternative_type == "manual_procedures":
            return {
                'rto_measured': 8.0,   # minutos
                'throughput_reduction': 0.70,  # 70% menos throughput
                'accuracy_maintained': 0.95,   # 95% precisión mantenida
                'staff_overhead': 3.0          # 3x more staff needed
            }

Integración con plan de continuidad general

8.1 Coordinación con OP.CONT.2

Los medios alternativos se integran directamente con el plan de continuidad:

• Activación automática: Parte del failover automático definido en OP.CONT.2
• Escalado manual: Siguiendo la estructura de crisis management
• Comunicación: Usando los canales alternativos aquí definidos
• Métricas: RTO/RPO específicos para cada alternativa

8.2 Vinculación con análisis de impacto (OP.CONT.1)

Cada medio alternativo está dimensionado según:

• Criticidad de los servicios afectados
• Tiempo máximo aceptable de interrupción
• Coste/beneficio de mantener alternativas
• Requisitos regulatorios de continuidad

Consideraciones económicas

9.1 Coste de mantenimiento de alternativas

Annual_Alternative_Costs:
  Infrastructure_Standby:
    - AWS_Secondary_Region: "€24,000/año (instancias reservadas)"
    - OnPremise_Backup: "€8,000/año (hardware + mantenimiento)"
    - Network_Redundancy: "€6,000/año (dobles líneas)"

  Communication_Alternatives:
    - WhatsApp_Business: "€2,400/año"
    - SMS_Service: "€1,800/año (Twilio credits)"
    - Conference_Bridge: "€3,600/año"

  Personnel_Preparedness:
    - Home_Office_Equipment: "€15,000 one-time + €3,000/año mantenimiento"
    - Coworking_Space: "€12,000/año (retainer + usage)"
    - Training_Program: "€8,000/año"

  Total_Annual: "€84,800"
  Cost_Per_Hour_Saved: "€97 (based on €1,350/hour incident cost)"
  ROI_Breakeven: "63 hours downtime avoided per year"

Referencias cruzadas

• OP.CONT.1: Análisis de impacto (justifica necesidad de alternativas)
• OP.CONT.2: Plan de continuidad (procedimientos de activación)
• OP.CONT.3: Testing (validación de alternativas)
• OP.EXP.1: Inventario (alternativas como activos)
• OP.MON.1: Monitorización (detección para activar alternativas)
• R-TF-013-002: Riesgos (alternativas como controles de mitigación)

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001