OP.EXP.4 Mantenimiento

Documentos de referencia

• Guías CCN-STIC:
  • Guía CCN-STIC-827 - Gestión y uso de dispositivos móviles
• ISO/IEC 27000
  • 27002:2013:
    • 11.2.4 - Mantenimiento de los equipos
    • 12.6.1 - Gestión de las vulnerabilidades técnicas
• NIST SP 800-53 rev4:
  • [CA-2] Security Assessments
  • [CA-7] Continuous Monitoring
  • [CA-8] Penetration Testing
  • [MA-2] Controlled Maintenance
  • [MA-3] Maintenance Tools
  • [MA-4] Nonlocal Maintenance
  • [MA-5] Maintenance Personnel
  • [MA-6] Timely Maintenance
  • [RA-5] Vulnerability Scanning
  • [SI-2] Flaw Remediation
  • [SI-4] Information System Monitoring
  • [SI-5] Security Alerts, Advisories, and Directives
• Otras referencias:
  • SANS - CIS Critical Security Controls - Version 6.1
    • CSC.4 - Continuous Vulnerability Assessment and Remediation
    • CSC.20 - Penetration Tests and Red Team Exercises
  • NIST SP 800-40 - Creating a Patch and Vulnerability Management Program
  • Manageable Network Plan
    • Milestone 6: Manage Your Network, Part I (Patch Management)

Guía de implantación

199. Proactivamente se deberá estar informado de los defectos anunciados por parte del fabricante o proveedor (como por ejemplo mediante suscripciones a listas de correo o RSS, consultando noticias en webs de tecnología, seguridad o fabricantes, etc.).

200. Deberá existir un procedimiento para establecer cuándo implantar los cambios y determinar su prioridad y urgencia proporcionada al riesgo que implica su no aplicación (cambios preaprobados, cambios de emergencia, etc.).

Implementación en la organización

Estrategia de mantenimiento para dispositivo médico

Categorías de mantenimiento

Categorías de Mantenimiento del Dispositivo Médico:

La organización clasifica el mantenimiento en cuatro categorías principales:

Categoría	Descripción	Frecuencia/Urgencia	Impacto Clínico	Ejemplos
Preventivo	Mantenimiento programado para prevenir fallos	Mensual/Trimestral/Anual según componente	Bajo (ventanas planificadas)	• Actualización de certificados SSL • Limpieza de logs y cachés • Optimización de bases de datos • Revisión de configuraciones de seguridad
Correctivo	Corrección de fallos identificados	Variable según severidad	Medio-Alto	• Parches de seguridad críticos • Corrección de bugs en algoritmos • Resolución de vulnerabilidades
Evolutivo	Mejoras y nuevas funcionalidades	Release cycles trimestrales	Variable (validación clínica requerida para cambios en IA)	• Actualización de modelos de ML • Nuevas integraciones HIS/EMR • Mejoras de rendimiento
Emergencia	Intervenciones críticas inmediatas	<2 horas	Alto	• Brecha de seguridad activa • Fallo crítico en diagnóstico • Pérdida de disponibilidad del servicio

Aprobación para Mantenimiento de Emergencia: Fast-track con notificación posterior a la Dirección y autoridades regulatorias si afecta funcionalidad clínica.

Matriz de prioridad de mantenimiento

Severidad	Impacto Clínico	Tiempo Respuesta	Ventana Mantenimiento	Aprobación Requerida
Crítica	Diagnóstico erróneo posible	<2 horas	Inmediato	Dirección + Responsable del Sistema
Alta	Funcionalidad degradada	<24 horas	Próxima ventana	Responsable del Sistema
Media	Sin impacto directo	<72 horas	Planificada	Responsable del Servicio
Baja	Mejoras cosméticas	<2 semanas	Release programado	Team Lead

Procedimientos de mantenimiento

Mantenimiento preventivo

Sistema de Mantenimiento Preventivo Automatizado:

La organización ejecuta un calendario automatizado de mantenimiento preventivo para garantizar la disponibilidad y seguridad del dispositivo médico.

Calendario de Mantenimiento Preventivo:

Tareas Diarias (Ejecutadas a las 02:00 UTC)

Quién: Sistema automatizado

Tareas:

1. Verificar espacio en disco - Alertar si uso >80%
2. Rotar logs - Archivar logs antiguos para gestión de almacenamiento
3. Verificar backups - Confirmar que el backup nocturno se completó exitosamente
4. Verificar expiración de certificados - Detalles más abajo
5. Monitorizar endpoints API - Verificar disponibilidad y latencia
6. Validar rendimiento de modelos IA - Detalles más abajo

Tareas Semanales (Ejecutadas domingos a las 03:00 UTC)

Quién: Sistema automatizado

Tareas:

1. Optimización de base de datos - VACUUM, ANALYZE, reindexar
2. Escaneo de seguridad - Análisis de vulnerabilidades automatizado
3. Verificación de dependencias - Comprobar actualizaciones disponibles
4. Análisis de rendimiento - Revisar métricas de la semana
5. Limpieza de archivos temporales - Eliminar datos no necesarios
6. Validar integraciones - Verificar conectividad con sistemas HIS/EMR

Tareas Mensuales (Cada 30 días a las 04:00 UTC)

Quién: Sistema automatizado + Responsable del Servicio

Tareas:

1. Backup completo del sistema - Backup full de todos los componentes
2. Evaluación de vulnerabilidades - Escaneo exhaustivo con herramientas profesionales
3. Verificación de licencias - Compliance de software de terceros
4. Revisión de planificación de capacidad - Proyección de crecimiento
5. Prueba de recuperación ante desastres - Verificar procedimientos DR
6. Verificación de compliance regulatorio - MDR, FDA, ISO 13485, ENS

Tareas Trimestrales (Cada 90 días a las 05:00 UTC)

Quién: Responsable del Servicio + Responsable del Sistema

Tareas: (Lista de tareas trimestrales mayores como auditorías completas)

Procedimientos Específicos

Verificación de Expiración de Certificados SSL/TLS

Para cada certificado monitorizado:

1. Obtener fecha de expiración
2. Calcular días hasta expiración
3. Si quedan menos de 30 días: Crear ticket de mantenimiento con prioridad alta y asignar al Responsable del Servicio

Validación de Rendimiento de Modelos de IA

Para cada modelo monitorizado:

1. Obtener métricas de rendimiento actuales
2. Verificar precisión (accuracy): Si cae por debajo del umbral definido, crear alerta crítica
3. Verificar drift score: Si supera el umbral definido, activar pipeline de reentrenamiento y notificar al Responsable de la Información

Pruebas en preproducción

Cualquier actualización de sistema operativo, parche de seguridad o cambio de configuración debe probarse en un entorno aislado antes de aplicarse en producción, con un plan de rollback documentado.

Situación actual — satisfecho por diseño:

Dado que los activos del alcance son servicios gestionados de AWS y equipos macOS, la necesidad de pruebas en preproducción está cubierta por diseño:

• AWS managed services (ECS Fargate, DocumentDB, S3, CloudFront, etc.): Las actualizaciones de infraestructura las gestiona AWS de forma transparente. Los cambios en la configuración de servicios se prueban en el entorno de staging antes de aplicarse a producción mediante el pipeline CI/CD.
• macOS: Las actualizaciones del sistema operativo se aplican de forma automática por Apple. El equipo técnico verifica la compatibilidad de las herramientas de desarrollo tras cada actualización mayor antes de generalizar a todos los empleados.
• Wazuh y EDR: Las actualizaciones de agentes se prueban primero en un endpoint de referencia antes de desplegar al resto.

Contingencia para futuros activos:

Si la organización incorpora activos que requieran gestión directa de actualizaciones (servidores on-premise, appliances de red, etc.), se deberá:

1. Disponer de un entorno de preproducción aislado que replique la configuración de producción.
2. Probar cada actualización en preproducción antes de su aplicación, documentando los resultados.
3. Mantener un plan de rollback para cada actualización, con condiciones claras de activación y tiempo máximo de reversión.
4. Obtener la aprobación del Responsable del Sistema antes de aplicar la actualización en producción.

Plan de mantenimiento periódico (plan de control)

La siguiente tabla consolida todas las tareas de mantenimiento periódico, indicando si son automáticas o manuales, su frecuencia y el responsable. Este plan de control permite al auditor verificar que la gestión del mantenimiento es continua y sistemática.

Tarea	Activo/Control	Tipo	Frecuencia	Responsable
Verificación de backups	AWS S3, DocumentDB	Automática	Diaria	Sistema automatizado
Rotación de logs	CloudWatch, Wazuh	Automática	Diaria	Sistema automatizado
Verificación de certificados SSL/TLS	CloudFront, ALB	Automática	Diaria	Sistema automatizado
Monitorización de endpoints y APIs	Todos los servicios	Automática	Continua	CloudWatch + Wazuh
Escaneo de vulnerabilidades	Infraestructura completa	Automática	Semanal	Sistema automatizado
Verificación de dependencias (npm audit, pip-audit)	Software del producto	Automática	Semanal (CI/CD)	Sistema automatizado
Optimización de base de datos	DocumentDB	Automática	Semanal	Sistema automatizado
Actualización de firmas antimalware	XProtect, Wazuh, EDR	Automática	Cada 4 horas	Sistema automatizado
Evaluación de vulnerabilidades exhaustiva	Infraestructura completa	Manual	Mensual	Resp. Seguridad
Verificación de licencias de software	Software de terceros	Manual	Mensual	Resp. Servicio
Revisión de planificación de capacidad	CloudWatch métricas	Manual	Mensual	Resp. Servicio
Prueba de recuperación ante desastres	Plan de continuidad	Manual	Mensual	Resp. Sistema
Revisión de permisos de acceso	AWS IAM, Google, GitHub	Manual	Semestral	Resp. Sistema + Resp. Seguridad
Revisión de configuraciones de seguridad	Todos los activos	Manual	Semestral	Resp. Sistema + Resp. Seguridad
Auditoría completa de seguridad	Sistema completo	Manual	Anual	Auditor externo
Renovación de certificados de firma de código	Certificados de software	Manual	Anual	Resp. Sistema
Actualización de macOS (versión mayor)	Equipos empleados	Manual	Según disponibilidad	Resp. Sistema
Actualización de agentes Wazuh/EDR	Endpoints	Manual	Según disponibilidad	Resp. Sistema

Gestión de parches y actualizaciones

Política de Gestión de Parches:

La organización clasifica las actualizaciones según su criticidad y aplica diferentes procesos de aprobación y despliegue.

Clasificación de Actualizaciones

Tipo	Descripción	CVSS Score / Impacto	Ventana de Despliegue	Testing Requerido	Aprobación
Critical Security	Vulnerabilidades explotables remotamente	≥ 9.0	< 24 horas	Smoke tests en staging	Responsable del Sistema + Responsable de Seguridad
High Security	Vulnerabilidades con impacto significativo	7.0 - 8.9	< 72 horas	Full regression en staging	Responsable del Servicio
Medical Device Updates	Actualizaciones que afectan funcionalidad clínica	Impacto clínico directo	Ventana de mantenimiento planificada	Validación clínica requerida	Dirección + Regulatory Affairs
Routine Updates	Actualizaciones rutinarias sin impacto clínico	Sin impacto clínico	Ventana semanal de mantenimiento	Suite de testing automatizada	Team Lead

Proceso de Gestión de Parches (5 Fases)

Fase 1: Descubrimiento (Discovery)

Quién: Sistema automatizado + Responsable de Seguridad

Actividades:

• Escaneo automatizado de vulnerabilidades (Qualys, Nessus)
• Monitorización de boletines de seguridad de vendors
• Seguimiento de base de datos CVE (Common Vulnerabilities and Exposures)
• Monitorización de avisos de seguridad de dispositivos médicos (FDA MAUDE, EU EUDAMED)

Fase 2: Evaluación (Assessment)

Quién: Responsable de Seguridad + Responsable del Servicio

Actividades:

• Puntuación de riesgo basada en CVSS y contexto clínico
• Análisis de dependencias (qué componentes se verán afectados)
• Testing de compatibilidad (verificar que no rompe funcionalidad existente)
• Evaluación de impacto regulatorio (notificación a autoridades si es necesario)

Fase 3: Testing

Quién: QA Team + Clinical Safety Officer (si aplica)

Actividades:

• Despliegue en entorno de test aislado
• Testing automatizado de regresión
• Validación clínica (si la actualización afecta algoritmos diagnósticos)
• Benchmarking de rendimiento (comparar antes/después)

Fase 4: Despliegue (Deployment)

Quién: DevOps Team

Actividades:

• Rollout escalonado: canary (1%) → staging (100%) → production (gradual)
• Health checks en cada etapa antes de continuar
• Capacidad de rollback automatizado si se detectan problemas
• Monitorización en tiempo real durante el despliegue

Fase 5: Verificación (Verification)

Quién: Responsable del Servicio + Responsable del Sistema

Actividades:

• Validación post-despliegue (verificar que todo funciona correctamente)
• Revisión de métricas de rendimiento
• Recolección de feedback de usuarios clínicos
• Actualización de documentación de compliance (registro en DHF si es dispositivo médico)

Herramientas de automatización de mantenimiento

Sistema de Automatización de Mantenimiento:

La organización utiliza Ansible para automatizar tareas de mantenimiento de manera consistente y reproducible.

API de Monitorización: Endpoint interno del sistema de monitorización

Ejecución de Playbooks de Mantenimiento

Quién: DevOps Team (ejecución) + Sistema automatizado

Proceso:

1. Pre-Maintenance Checks:
   • Verificar que los hosts objetivo están disponibles
   • Confirmar que no hay otros mantenimientos en progreso
   • Validar configuraciones previas
   • Si fallan las comprobaciones: Cancelar mantenimiento y alertar
2. Crear Ventana de Mantenimiento:
   • Duración: 60 minutos (configurable)
   • Servicios afectados: Hosts especificados
   • Notificar al sistema de monitorización para suprimir alertas
3. Ejecutar Playbook Ansible:
   • Directorio de trabajo: /opt/ansible
   • Playbook: playbooks/[nombre].yml
   • Variables extra:
     • maintenance_mode: True (activar modo mantenimiento)
     • backup_before_change: True (crear backup antes de cambios)
     • notify_users: True (notificar a usuarios clínicos)
4. Resultado de la Ejecución:
   • Si exitoso: Registrar éxito en logs con detalles
   • Si falla: Manejar fallo (rollback si es necesario)
5. Cerrar Ventana de Mantenimiento:
   • Siempre se ejecuta (finally block)
   • Restaurar sistema de monitorización normal

Flujo Automatizado de Parcheo

Proceso de 4 Pasos:

Paso 1: Escanear Actualizaciones Disponibles

• Ejecutar escáneres de vulnerabilidades
• Consultar repositorios de vendors

Paso 2: Clasificar y Priorizar

• Aplicar matriz de priorización (ver sección 2.2)
• Asignar ventanas de despliegue según criticidad

Paso 3: Generar Change Requests

• Si prioridad CRITICAL:
  • Crear change de emergencia (fast-track)
  • Notificar inmediatamente a aprobadores
• Si no es crítico:
  • Crear change estándar
  • Seguir proceso normal de aprobación (CAB)

Paso 4: Ejecutar Cambios Aprobados

• Obtener lista de cambios aprobados del sistema
• Para cada cambio, ejecutar proceso de parcheo (ver abajo)

Ejecución del Parcheo

Para cada sistema objetivo:

1. Crear Snapshot del Sistema (para rollback si es necesario)
2. Aplicar Parches:
   • Iterar por cada parche de la lista
   • Aplicar parche al sistema
3. Validar Salud del Sistema:
   • Ejecutar health checks post-parcheo
   • Si falla: Lanzar excepción
4. Actualizar CMDB:
   • Registrar nuevas versiones de componentes
   • Actualizar registro de compliance
5. Manejo de Errores:
   • Si algo falla:
     • Revertir desde snapshot (rollback automático)
     • Registrar fallo con detalles
     • Alertar al equipo responsable

Monitoreo y diagnóstico

Sistema de monitoreo integral

Stack de Monitorización Integral:

La organización implementa un sistema de monitorización multicapa para supervisar todos los aspectos del dispositivo médico.

Componente	Herramienta	Métricas Monitorizadas	Alertas Configuradas
Infrastructure Monitoring	AWS CloudWatch	• CPU, Memory, Disk usage • Network throughput y latency • ECS task health • Database performance	• Resource exhaustion (>80% uso) • Service unavailability • Abnormal error rates
Application Monitoring	AWS CloudWatch + X-Ray	• Response times • Error rates • Transaction traces • Database query performance • AI model inference times	• Diagnostic algorithm failures • API endpoint degradation • Image processing delays
Security Monitoring	Wazuh SIEM	• Authentication failures • Unauthorized access attempts • Configuration changes • Privilege escalations	• Brute force attempts • Data exfiltration patterns • Malware detection
Clinical Performance Monitoring	Custom Medical Device Dashboard	• Diagnostic accuracy trends • False positive/negative rates • Processing time per diagnosis • User satisfaction scores	• Accuracy below threshold • Unusual diagnostic patterns • Clinical safety events

Dashboard de mantenimiento

Dashboard de Mantenimiento en Tiempo Real:

La organización mantiene un dashboard React que se actualiza automáticamente cada 30 segundos para monitorizar el estado de mantenimiento del sistema.

Encabezado del Dashboard:

• Título: "Maintenance Dashboard"
• Estado de Compliance: "MDR Compliant | FDA Listed | ISO 13485:2016"

Tarjetas de Métricas Principales:

Métrica	Objetivo	Indicador de Estado
System Uptime	99.9%	Verde si ≥99.9%, Amarillo si <99.9%
Patch Compliance	100%	Verde si 100%, Rojo si <100%
MTTR (Mean Time To Repair)	<2 horas	Mostrado en horas
Vulnerability Score	<3.0	Verde si <3.0, Amarillo si ≥3.0

Sección de Gráficos:

1. Maintenance History (Últimos 30 Días):
   • Tipo: Line Chart (gráfico de líneas)
   • Datos: Histórico de actividades de mantenimiento
2. System Component Health:
   • Tipo: Bar Chart (gráfico de barras)
   • Datos: Salud de cada componente del sistema

Tabla de Ventanas de Mantenimiento Programadas:

Columnas mostradas:

• Date/Time: Fecha y hora programada
• Type: Tipo de mantenimiento (Preventivo, Correctivo, etc.)
• Components: Componentes afectados
• Expected Duration: Duración estimada
• Clinical Impact: Impacto clínico (con código de color según severidad)

Actualización Automática: El dashboard obtiene datos en tiempo real cada 30 segundos de las siguientes APIs:

• api.getMaintenanceMetrics() - Métricas de mantenimiento
• api.getUpcomingMaintenance() - Mantenimientos programados
• api.getSystemHealth() - Salud del sistema

Gestión de vulnerabilidades

Proceso de gestión de vulnerabilidades

Sistema de Gestión de Vulnerabilidades:

Fuentes de Información:

• Base de datos CVE: https://cve.mitre.org/data/downloads/
• Base de datos FDA de dispositivos médicos: https://www.fda.gov/medical-devices/databases/
• Scanner de red: nmap

Escaneo Exhaustivo de Vulnerabilidades

Quién: Responsable de Seguridad + Sistema automatizado

Proceso (5 tipos de escaneo):

1. Network Vulnerability Scan - Escaneo de vulnerabilidades de red
2. Application Vulnerability Scan - Escaneo de aplicación web y APIs
3. Dependency Vulnerability Scan - Escaneo de librerías y dependencias
4. Medical Device Specific Vulnerabilities - Escaneo específico para dispositivos médicos (detallado abajo)
5. AI/ML Model Vulnerabilities - Escaneo de modelos de IA

Consolidación:

• Todas las vulnerabilidades se consolidan en un único reporte
• Se priorizan según contexto clínico (ver proceso abajo)
• Se genera plan de remediación
• Para vulnerabilidades CRITICAL o HIGH: Crear ticket automáticamente

Escaneo Específico para Dispositivos Médicos

Verificaciones Realizadas:

1. Comunicaciones de Seguridad FDA - Verificar alertas de la FDA
2. CVEs de Dispositivos Médicos - Buscar vulnerabilidades conocidas específicas
3. Compliance de Seguridad - Validar cumplimiento con estándares de seguridad de dispositivos médicos
4. Credenciales Hardcodeadas - Buscar credenciales embebidas en código (problema común en dispositivos médicos)
5. Cifrado de Datos de Pacientes - Validar que todos los datos están cifrados correctamente

Priorización de Vulnerabilidades

Fórmula de Priorización:

Priority Score = CVSS Base Score × Clinical Multiplier × Exploitability Factor

Multiplicador de Impacto Clínico:

• DIRECT (impacto clínico directo): × 1.5
• INDIRECT (impacto clínico indirecto): × 1.2
• NONE (sin impacto clínico): × 1.0

Factor de Explotabilidad:

• Exploit disponible públicamente: × 1.3
• Sin exploit disponible: × 1.0

Asignación de Prioridad y Plazos de Remediación:

Priority Score	Prioridad	Plazo de Remediación
≥ 9.0	CRITICAL	1 día
7.0 - 8.9	HIGH	7 días
4.0 - 6.9	MEDIUM	30 días
< 4.0	LOW	90 días

Resultado: Lista de vulnerabilidades ordenadas por priority_score (de mayor a menor)

Procedimientos de recuperación

Plan de recuperación ante fallos

Plan de Recuperación ante Desastres:

Objetivos RTO/RPO por Servicio

Servicios Críticos (Prioridad P1):

Servicio	RTO (Recovery Time Objective)	RPO (Recovery Point Objective)	Justificación Clínica
Diagnostic Algorithm API	2 horas	1 hora	Funcionalidad diagnóstica crítica - los clínicos dependen para decisiones
Clinical Image Storage	4 horas	15 minutos	Almacenamiento de imágenes de pacientes - mínima pérdida de datos aceptable
User Authentication	1 hora	5 minutos	Acceso al sistema - bloqueo total sin autenticación

Servicios de Soporte:

Servicio	RTO	RPO	Prioridad
Reporting Module	8 horas	1 hora	P2
Admin Dashboard	24 horas	4 horas	P3

Procedimiento de Recuperación (5 Fases)

Fase 1: Detección y Alerta

Mecanismos de Detección:

• Alertas automatizadas del sistema de monitorización
• Reporte manual de incidentes por usuarios
• Fallos en health checks automáticos

Quién: Sistema automatizado + Equipo de guardia (on-call)

Fase 2: Evaluación

Quién: Incident Commander + Technical Lead

Actividades:

1. Determinar alcance del fallo (qué componentes están afectados)
2. Identificar componentes específicos dañados
3. Estimar tiempo de recuperación basado en objetivos RTO
4. Notificar a stakeholders:
   • Clinical Safety Officer (si afecta funcionalidad clínica)
   • Management (si RTO > 4 horas)
   • Usuarios clínicos (siempre)
   • Autoridades regulatorias (si impacta seguridad del paciente)

Fase 3: Ejecución de Recuperación

3.1 Fallo de Base de Datos:

1. Cambiar a réplica standby (failover automático)
2. Si réplica no disponible: Restaurar desde último backup
3. Reproducir transaction logs para minimizar pérdida de datos (hacia RPO)
4. Validar integridad de datos (checksums, foreign keys)

3.2 Fallo de Aplicación:

1. Rollback a versión anterior estable
2. Desplegar desde imagen de backup validada
3. Restaurar configuración desde baseline aprobado
4. Ejecutar health checks completos

3.3 Corrupción de Modelos de IA:

1. Cargar versión anterior validada del modelo
2. Verificar checksums del modelo (garantizar integridad)
3. Ejecutar contra dataset de validación (verificar precisión)
4. Requerido: Verificación clínica antes de poner en producción

Fase 4: Validación Post-Recuperación

Quién: QA Team + Clinical Safety Officer (si aplica)

Tests Obligatorios:

• Pruebas de funcionalidad del sistema (smoke tests)
• Verificaciones de integridad de datos
• Si componentes de IA/diagnóstico afectados: Validación clínica completa
• Benchmarks de rendimiento (comparar con línea base)

Fase 5: Documentación

Quién: Incident Commander

Documentos Requeridos:

1. Informe de incidente (R-024-008) - Documentar qué pasó, cuándo, impacto
2. Análisis de causa raíz (Root Cause Analysis) - Por qué ocurrió
3. Lecciones aprendidas - Qué se puede mejorar
4. Actualización de procedimientos DR - Incorporar mejoras al plan

Métricas e indicadores de mantenimiento

Sistema de Métricas de Mantenimiento:

KPIs de mantenimiento

Categorías de KPIs Monitorizadas:

Disponibilidad del Sistema

Métrica	Descripción	Objetivo
System Availability	Porcentaje de tiempo que el sistema está operativo	≥ 99.9%
Uptime Percentage	Tiempo de actividad vs. tiempo total	≥ 99.9%

Rendimiento de Mantenimiento

Métrica	Descripción	Objetivo	Fórmula
MTBF (Mean Time Between Failures)	Tiempo promedio entre fallos	> 720 horas (30 días)	Σ(tiempo operativo) / número de fallos
MTTR (Mean Time To Repair)	Tiempo promedio para reparar	< 2 horas	Σ(tiempo de reparación) / número de incidentes
MTTD (Mean Time To Detect)	Tiempo promedio para detectar fallos	< 5 minutos	Σ(tiempo de detección) / número de incidentes

Gestión de Parches

Métrica	Descripción	Objetivo
Patch Compliance Rate	% de sistemas con parches actualizados	100%
Critical Patch Deployment Time	Tiempo promedio para desplegar parches críticos	< 24 horas
Patch Success Rate	% de parches desplegados exitosamente	≥ 95%

Vulnerabilidades

Métrica	Descripción	Objetivo
Open Vulnerabilities	Número de vulnerabilidades abiertas	< 10
Average Vulnerability Age	Edad promedio de vulnerabilidades abiertas	< 30 días
Vulnerability Remediation Rate	% de vulnerabilidades remediadas a tiempo según SLA	≥ 90%

Cumplimiento

Métrica	Descripción	Objetivo
Maintenance Window Compliance	% de mantenimientos completados dentro de ventana	100%
SLA Compliance	Cumplimiento de SLAs con usuarios clínicos	≥ 99%
Regulatory Compliance Score	Puntuación de compliance agregada	100%

Informe mensual de mantenimiento

Quién: Responsable del Servicio + Responsable del Sistema

Frecuencia: Mensual (generado el día 1 de cada mes)

Estructura del Informe:

1. Encabezado:

• Período del informe: YYYY-MM (mes anterior)

2. Resumen Ejecutivo:

• Resumen de alto nivel del estado de mantenimiento
• Incidentes mayores del mes
• Logros destacados
• Áreas de preocupación

3. KPIs Detallados:

• Todas las métricas descritas en la sección 6.1
• Comparación con mes anterior (tendencia)
• Desviaciones respecto a objetivos

4. Actividades de Mantenimiento:

• Lista de todas las actividades de mantenimiento realizadas
• Clasificadas por tipo: Preventivo, Correctivo, Evolutivo, Emergencia
• Tiempos de ejecución y resultados

5. Resumen de Incidentes:

• Incidentes ocurridos durante el mes
• Severidad y tiempo de resolución
• Impacto en usuarios clínicos

6. Mantenimiento Programado:

• Ventanas de mantenimiento planificadas para el próximo mes
• Impacto esperado
• Coordinación requerida

7. Recomendaciones:

• Acciones correctivas sugeridas
• Mejoras propuestas
• Inversiones requeridas

8. Estado de Compliance Regulatorio:

Regulación	Estado	Comentarios
MDR 2017/745	Compliant	Dispositivo Clase IIa en compliance
FDA	Compliant	510(k) cleared
ISO 13485:2016	Compliant	Sistema de calidad certificado
ENS CATEGORÍA ALTO	Compliant	Todos los controles implementados

Distribución del Informe:

• Dirección
• Regulatory Affairs
• Quality Manager
• Archivo en sistema documental (GP-001)

Integración con otros controles ENS

• OP.EXP.1: Actualización del inventario tras mantenimiento
• OP.EXP.2: Verificación de configuraciones post-mantenimiento
• OP.EXP.3: Actualización de baselines de configuración
• OP.EXP.5: Coordinación con gestión de cambios
• OP.EXP.7: Registro de incidentes durante mantenimiento

Consideraciones específicas para dispositivo médico

Validación post-mantenimiento

• Verificación de funcionalidad clínica obligatoria
• Pruebas de precisión diagnóstica con dataset de validación
• Confirmación de integridad de modelos de IA
• Documentación en DHF de todos los cambios

Comunicación con usuarios clínicos

• Notificación anticipada de ventanas de mantenimiento
• Guías de contingencia durante indisponibilidad
• Informes post-mantenimiento con cambios relevantes
• Canal dedicado para feedback clínico

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 Design & Development Manager, JD-004 Quality Manager & PRRC
• Approver: JD-001 General Manager

ㅤ