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 Legit Health Plus

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 al CMO 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	CMO + CTO
Alta	Funcionalidad degradada	<24 horas	Próxima ventana	CTO + QA Manager
Media	Sin impacto directo	<72 horas	Planificada	DevOps Lead
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 + DevOps Lead

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: DevOps Lead + QA Manager

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

Procedimientos Específicos

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

Certificados Monitorizados:

• app.legit.health (/etc/ssl/certs/app.crt)
• api.legit.health (/etc/ssl/certs/api.crt)

Proceso:

1. Para cada certificado, 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 HIGH
   • Título: "Certificate expiring soon: [domain]"
   • Descripción: "Certificate expires in [X] days"
   • Asignar a DevOps Lead

Validación de Rendimiento de Modelos de IA

Modelos Monitorizados:

• lesion_classifier_v2.3.1 (Clasificador de lesiones)
• severity_scorer_v1.8.0 (Puntuación de severidad)
• dlqi_predictor_v1.2.4 (Predictor DLQI)

Proceso:

1. Para cada modelo, obtener métricas de rendimiento actuales
2. Verificar precisión (accuracy):
   • Si accuracy < 90%: Crear alerta CRÍTICA
   • Mensaje: "Model [name] performance degraded: [accuracy]"
3. Verificar drift score:
   • Si drift_score > 0.15: Activar pipeline de reentrenamiento automático
   • Notificar al Clinical Safety Officer

Umbrales Críticos:

• Accuracy mínima: 90%
• Drift score máximo: 0.15 (15%)

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	CTO + Security Officer
High Security	Vulnerabilidades con impacto significativo	7.0 - 8.9	< 72 horas	Full regression en staging	DevOps Lead
Medical Device Updates	Actualizaciones que afectan funcionalidad clínica	Impacto clínico directo	Ventana de mantenimiento planificada	Validación clínica requerida	CMO + 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 + Security Officer

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: Security Officer + DevOps Lead

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: DevOps Lead + QA Manager

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: https://monitoring.legit.health/api/v1

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	Prometheus + Grafana	• CPU, Memory, Disk usage • Network throughput y latency • Container health (Docker/Kubernetes) • Database performance	• Resource exhaustion (>80% uso) • Service unavailability • Abnormal error rates
Application Monitoring	New Relic APM	• Response times • Error rates • Transaction traces • Database query performance • AI model inference times	• Diagnostic algorithm failures • API endpoint degradation • Image processing delays
Security Monitoring	Splunk 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: "Legit Health Plus - 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: Security Officer + 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: DevOps Lead + QA Manager

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 CATEGORIA MEDIA	Compliant	Todos los controles implementados

Distribución del Informe:

• Management (CEO, CTO, CMO)
• 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

Referencias y documentación relacionada

• T-024-008: Procedimiento de gestión de incidentes
• T-024-009: Plan de recuperación ante desastres
• T-024-010: Guía de gestión de vulnerabilidades
• GP-005: Control de cambios
• GP-013: Gestión de la ciberseguridad
• R-TF-013-002: Registro de gestión de riesgos

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