OP.EXP.5 Gestión de Cambios - Procedimiento Formal ENS

Documentos de referencia

Normativa ENS

• Real Decreto 311/2022, Anexo II, OP.EXP.5
• CCN-STIC 804: Guía de implantación del ENS
• CCN-STIC 821: Normas de seguridad en el ENS

Estándares internacionales

• ISO/IEC 27000
  • 27002:2013 - 12.1.2 Gestión de cambios
  • 27002:2013 - 14.2.2 Procedimientos de control de cambios
  • 27031:2011 - ICT readiness for business continuity
• ISO/IEC 20000-1:2018 - Service management system
• ITIL v4 - Change Management

Dispositivos médicos

• ISO 14971:2019 - Risk management for medical devices
• IEC 62304:2006 - Medical device software lifecycle
• MDR Art. 120 - Notificación de cambios sustanciales
• FDA 21 CFR 814.39 - Suplementos PMA para cambios

Otras referencias

• NIST SP 800-53 rev4: CM-4, CM-5, SI-2, SI-7
• SANS CIS Critical Security Controls v6.1

Propósito

Establecer un procedimiento formal y estructurado para la gestión de todos los cambios en los sistemas de información de Legit Health, garantizando:

• Cumplimiento con categoría MEDIA del ENS como PROVEEDOR de servicios sanitarios
• Control de cambios en dispositivo médico Clase IIa
• Trazabilidad completa y documentación adecuada
• Minimización de riesgos e impacto en la disponibilidad
• Validación clínica cuando sea requerida

Alcance

Este procedimiento aplica a todos los cambios en:

• Infraestructura tecnológica y cloud (AWS)
• Software del dispositivo médico y algoritmos de IA
• Configuraciones de seguridad ENS
• Arquitectura de red y comunicaciones
• Procesos y procedimientos del SGS
• Integraciones con sistemas externos
• Datos y modelos de aprendizaje automático

Guía de implantación ENS

El procedimiento para cambiar componentes del sistema requiere:

• Aprobación del responsable según matriz de autorización
• Documentación completa del cambio (RFC)
• Pruebas de seguridad en entorno no productivo
• Retención de versión previa (mínimo 30 días)
• Copias de seguridad de componentes (actual y anterior)
• Actualización del inventario de activos
• Actualización de procedimientos operativos
• Actualización del plan de continuidad

Clasificación de cambios

Matriz de clasificación ENS y dispositivo médico

Categorización MEDIA ENS

Como sistema de categoría MEDIA y PROVEEDOR (no prestador directo), aplicamos controles proporcionales sin sobre-ingeniería. Los tiempos de respuesta y niveles de aprobación reflejan nuestro rol de apoyo al servicio sanitario.

Clasificación de Cambios según ENS y Dispositivo Médico:

Tipo 1: EMERGENCIA

• Descripción: Cambios críticos para resolver incidentes activos
• Impacto ENS: Restauración inmediata de seguridad/disponibilidad
• Impacto Clínico: Riesgo para seguridad del paciente
• Tiempo de Respuesta: < 4 horas
• Aprobación Mínima: CISO o delegado 24/7; CMO (si afecta diagnóstico)
• CAB Requerido: No
• Documentación: Posterior en 24h
• Validación Clínica: Post-implementación si aplica
• Ejemplos:
  • Vulnerabilidad crítica explotada (CVSS >9)
  • Fallo diagnóstico con riesgo para paciente
  • Brecha de datos de salud activa
  • Caída total del servicio

Tipo 2: MAYOR

• Descripción: Cambios con impacto significativo
• Impacto ENS: Modificación de controles de seguridad
• Impacto Clínico: Afecta funcionalidad diagnóstica
• Tiempo de Respuesta: 48-72 horas
• Aprobación Requerida: CAB completo, CISO, CMO (Chief Medical Officer), QA/RA Manager
• CAB Requerido: Sí
• Documentación: Completa previa con análisis de impacto
• Validación Clínica: Requerida pre-implementación
• Notificación Regulatoria: Si modifica intended use
• Ejemplos:
  • Actualización algoritmo IA diagnóstico
  • Cambio arquitectura de seguridad
  • Nueva integración clínica (HL7/FHIR)
  • Migración de infraestructura crítica
  • Cambio en umbrales de decisión clínica

Tipo 3: NORMAL

• Descripción: Cambios planificados de impacto moderado
• Impacto ENS: Sin afectación a categorización
• Impacto Clínico: Sin impacto directo en diagnóstico
• Tiempo de Respuesta: 5-10 días
• Aprobación Requerida: CAB estándar, Product Owner, Responsable ENS
• CAB Requerido: Sí
• Documentación: Estándar con RFC
• Validación Clínica: Testing de regresión
• Ejemplos:
  • Actualizaciones de software no crítico
  • Mejoras UX/UI
  • Optimizaciones de rendimiento
  • Nuevas features secundarias

Tipo 4: MENOR

• Descripción: Cambios de bajo impacto
• Impacto ENS: Mínimo o nulo
• Impacto Clínico: Ninguno
• Tiempo de Respuesta: Según sprint
• Aprobación Requerida: Team Lead; notificación al CAB
• CAB Requerido: No
• Documentación: Simplificada
• Ejemplos:
  • Correcciones de documentación
  • Ajustes cosméticos
  • Scripts de mantenimiento
  • Actualizaciones de dependencias menores

Tipo 5: ESTÁNDAR

• Descripción: Cambios pre-aprobados
• Impacto ENS: Controlado y conocido
• Impacto Clínico: Ninguno
• Tiempo de Respuesta: Automático/programado
• Aprobación Requerida: Pre-aprobado anualmente
• CAB Requerido: No
• Documentación: Registro automático
• Ejemplos:
  • Renovación de certificados SSL
  • Rotación de logs
  • Backups programados
  • Limpieza de datos temporales

Criterios de evaluación de impacto

Sistema de Evaluación de Impacto de Cambios:

La organización evalúa automáticamente el impacto de cada solicitud de cambio según múltiples dimensiones de cumplimiento:

Dimensiones de Evaluación:

1. Seguridad ENS: Impacto en controles de seguridad del Esquema Nacional de Seguridad
2. Seguridad Clínica: Impacto en funcionalidad diagnóstica y seguridad del paciente
3. Protección de Datos: Impacto en tratamiento de datos personales (GDPR)
4. Disponibilidad: Impacto en disponibilidad del servicio
5. Regulatorio: Impacto en cumplimiento normativo (MDR, FDA)

Lógica de Clasificación Automática:

Cada dimensión se puntúa de 1 a 5 según el impacto evaluado:

• Si alguna puntuación es >= 4: El cambio se clasifica como MAYOR
• Si alguna puntuación es >= 3: El cambio se clasifica como NORMAL
• Si todas las puntuaciones son <= 1: El cambio se clasifica como MENOR
• En otros casos: El cambio se clasifica como NORMAL por defecto

Evaluación de Impacto Clínico (Específico):

Condición	Puntuación	Nivel
Afecta algoritmo diagnóstico	5	Crítico
Afecta datos clínicos	4	Alto
Afecta flujo de trabajo clínico	3	Medio
Sin impacto en funcionalidad clínica	1	Bajo

Change Advisory Board (CAB)

Composición del CAB

Miembros Permanentes del Change Advisory Board:

Rol	Responsabilidad	Voto
CTO	Aprobación técnica	Sí
CISO/Responsable Seguridad	Validación seguridad ENS	Sí
CMO/Responsable Clínico	Validación clínica	Sí
QA Manager	Aseguramiento calidad MDR	Sí
Responsable ENS	Cumplimiento ENS	Sí

Miembros Consultivos (Según Tipo de Cambio):

Rol	Participación Requerida en
DPO	Cambios con datos personales
Regulatory Affairs	Cambios con impacto regulatorio
Clinical Safety Officer	Cambios en algoritmos IA

Calendario de Reuniones:

• Ordinarias: Jueves 10:00 CET
• Extraordinarias: Según necesidad
• Emergencia: Convocatoria en 2 horas máximo
• Quorum Mínimo: 3 miembros con voto

Proceso de decisión

Flujo de Decisión del Change Advisory Board:

1. RFC Recibido → Se evalúa la clasificación del cambio

2. Clasificación del Cambio:

   • Emergencia → Aprobación directa por CISO
   • Mayor → Revisión por CAB completo
   • Normal → Revisión por CAB estándar
   • Menor → Aprobación por Team Lead

3. Para Cambios MAYOR - Evaluación por CAB Completo:

   • Si requiere información adicional → Solicitar detalles adicionales
   • Si riesgo evaluado es alto → Rechazar o diferir el cambio
   • Si riesgo es aceptable → Aprobar con condiciones

4. Tras Aprobación con Condiciones:

   • Elaborar plan de implementación detallado
   • Ejecutar validaciones requeridas
   • Obtener autorización final para implementación

Proceso de gestión de cambios

Solicitud de cambio (RFC)

Estructura de la Solicitud de Cambio (Request for Change):

Sección 1: Identificación

• ID: Formato RFC-YYYY-MM-NNNN
• Solicitante: Persona que solicita el cambio
• Fecha de solicitud: Fecha y hora de la solicitud
• Urgencia: BAJA | MEDIA | ALTA | CRÍTICA

Sección 2: Clasificación ENS

• Tipo de cambio: EMERGENCIA | MAYOR | NORMAL | MENOR | ESTÁNDAR
• Categoría ENS: INFRAESTRUCTURA | SOFTWARE | CONFIGURACIÓN | PROCESO

Sección 3: Descripción del Cambio

• Título: Descripción breve del cambio
• Descripción detallada: Explicación completa del cambio propuesto
• Justificación de negocio: Razones empresariales para el cambio
• Justificación clínica: (Si afecta dispositivo médico) Razones clínicas

Sección 4: Análisis de Impacto

• Componentes afectados: Lista de componentes del sistema impactados
• Servicios impactados: Servicios que se verán afectados
• Usuarios afectados: Número estimado de usuarios impactados
• Tiempo de indisponibilidad: Duración estimada en minutos

Sección 5: Análisis de Riesgos ENS

• Probabilidad: Escala 1-5
• Impacto: Escala 1-5
• RPN (Risk Priority Number): Probabilidad × Impacto
• Medidas de mitigación: Lista de medidas para reducir riesgo

Sección 6: Plan de Implementación

• Fecha propuesta: Fecha planificada para implementación
• Duración estimada: Tiempo en horas
• Pasos de implementación: Secuencia detallada de pasos
• Plan de validación: Procedimientos de validación post-cambio
• Plan de rollback: Procedimiento de reversión si falla

Sección 7: Validación Clínica (Si Aplica)

• Validación clínica requerida: Sí/No
• Tipo de validación: REGRESSION | CLINICAL_STUDY | EXPERT_REVIEW
• Protocolo de validación: Referencia al protocolo específico

Sección 8: Trazabilidad

• Incidentes relacionados: Códigos INC-XXXX vinculados
• Riesgos relacionados: Referencias al R-TF-013-002
• Requisitos PRS: Códigos de requisitos del producto afectados

Sección 9: Aprobaciones

• Aprobaciones requeridas: Lista de aprobadores necesarios
• Estado de aprobación: PENDIENTE | APROBADO | RECHAZADO | DIFERIDO

Evaluación y aprobación

Flujo de Procesamiento de RFC según Procedimiento ENS:

1. Validación Inicial
   • Verificar que el RFC está completo y cumple con formato requerido
   • Si no es válido → Rechazar RFC con lista de errores
2. Clasificación Automática
   • Asignar clasificación del cambio (EMERGENCIA, MAYOR, NORMAL, MENOR, ESTÁNDAR)
3. Análisis de Impacto ENS
   • Evaluar impacto en controles de seguridad ENS
   • Documentar componentes y servicios afectados
4. Verificación de Cumplimiento
   • Verificar cumplimiento con políticas de seguridad
   • Verificar requisitos regulatorios (MDR, GDPR)
5. Determinación de Aprobadores
   • Identificar qué roles deben aprobar según clasificación
   • Asignar aprobadores específicos
6. Revisión por CAB (Si Aplica)
   • Para cambios MAYOR o NORMAL: Programar revisión por CAB
   • CAB evalúa el RFC y emite decisión
7. Validación Técnica
   • Revisión técnica detallada de la propuesta
   • Verificación de viabilidad y riesgos técnicos
8. Validación Clínica (Si Aplica)
   • Para cambios que afectan dispositivo médico
   • Revisión por CMO o Clinical Safety Officer
9. Decisión Final
   • Consolidar todas las validaciones
   • Emitir decisión: APROBADO | RECHAZADO | DIFERIDO

Implementación de cambios

Procedimiento de implementación

Proceso de Implementación de Cambio Aprobado según ENS:

Fase Inicial - Preparación:

1. Verificaciones Pre-Implementación
   • Confirmar que todas las aprobaciones están completadas
   • Verificar disponibilidad de recursos necesarios
   • Validar ventana de mantenimiento programada
2. Crear Punto de Restauración
   • Generar backup completo del estado actual
   • Documentar configuración pre-cambio
   • Almacenar punto de restauración (retención mínima 30 días)
3. Notificar Usuarios Afectados
   • Comunicar inicio de ventana de mantenimiento
   • Informar impacto esperado y duración
4. Activar Ventana de Mantenimiento
   • Marcar sistema en modo mantenimiento
   • Registrar inicio en log de cambios

Fase de Ejecución:

5. Ejecutar Pasos de Implementación
   • Seguir secuencia definida en RFC aprobado
   • Documentar resultado de cada paso
   • Verificar salud del sistema tras cada paso crítico
   • Si falla verificación: Activar procedimiento de rollback inmediatamente
6. Validación Post-Implementación
   • Ejecutar pruebas funcionales definidas
   • Verificar que todos los servicios están operativos
   • Confirmar ausencia de errores críticos
7. Validación Clínica (Si Aplica)
   • Para cambios en dispositivo médico
   • Validar funcionalidad clínica según protocolo
   • Aprobación por CMO o Clinical Safety Officer

Fase de Cierre:

8. Actualizar Documentación
   • Actualizar manuales de usuario si aplica
   • Actualizar procedimientos operativos
   • Documentar en Design History File (MDR)
9. Actualizar Inventario ENS
   • Registrar nuevas versiones de componentes
   • Actualizar inventario de activos (OP.EXP.1)
10. Cerrar Ventana de Mantenimiento
    • Restaurar servicio normal
    • Notificar usuarios del cierre
    • Marcar implementación como exitosa

En Caso de Fallo:

• Ejecutar Rollback según plan definido
• Documentar causa del fallo y error específico
• Notificar fallo a todos los stakeholders
• Crear incidente si el cambio es de tipo EMERGENCIA
• Documentar resultado incluyendo rollback ejecutado

Resultado Final:

• Registro completo de implementación con estado: SUCCESS o FAILED
• Log con todos los pasos ejecutados y tiempos
• Documentación de cualquier rollback ejecutado

Validación y verificación

Requisitos de Validación Post-Cambio:

Validación Funcional:

• Pruebas de regresión completas
• Verificación de casos de uso críticos
• Validación de integraciones con sistemas externos

Validación de Seguridad ENS:

• Escaneo de vulnerabilidades
• Verificación de configuraciones de seguridad
• Test de penetración (para cambios MAYOR)
• Validación de controles ENS afectados

Validación de Rendimiento:

• Pruebas de carga
• Verificación de tiempos de respuesta
• Monitorización de recursos del sistema

Validación Clínica MDR:

• Validación de algoritmos diagnósticos
• Verificación de umbrales de decisión clínica
• Testing con dataset de validación
• Revisión y aprobación por CMO

Actualización de Documentación:

• Actualización de manual de usuario
• Actualización de procedimientos operativos
• Registro en DHF (Design History File)
• Actualización de risk management file

Gestión de rollback

Plan de rollback

Gestión de Rollback según Procedimiento ENS:

Cada cambio aprobado debe incluir un plan de rollback detallado antes de la implementación.

Componentes del Plan de Rollback:

1. ID del RFC: Vinculación con la solicitud de cambio original

2. Condiciones de Activación del Rollback:

   • Fallo crítico en producción
   • Pérdida de integridad de datos
   • Brecha de seguridad detectada
   • Fallo en validación clínica
   • Degradación de rendimiento > 50%

3. Tiempo Máximo de Rollback: Calculado según criticidad del cambio y RTO del sistema

4. Pasos de Rollback: Secuencia inversa de implementación con instrucciones detalladas

5. Validación Post-Rollback: Pruebas para confirmar vuelta al estado anterior

6. Recuperación de Datos: Procedimiento de restauración de datos si aplica

Procedimiento de Ejecución de Rollback:

1. Notificar Inicio de Rollback
   • Comunicar a todos los stakeholders
   • Registrar motivo del rollback
2. Ejecutar Pasos de Rollback
   • Seguir secuencia definida en el plan
   • Documentar resultado de cada paso
3. Validar Integridad del Sistema
   • Verificar que el sistema ha vuelto al estado anterior
   • Confirmar funcionalidad completa
4. Documentar Rollback
   • Registrar todos los pasos ejecutados
   • Documentar tiempo total de rollback
   • Anotar cualquier incidencia
5. Crear Informe Post-Mortem
   • Análisis de causa raíz del fallo
   • Lecciones aprendidas
   • Acciones correctivas para futuros cambios

Control de versiones

Esquema de versionado

Sistema de Versionado Semántico:

Formato: MAJOR.MINOR.PATCH.BUILD

Criterios para Incremento de Versión:

MAJOR (versión mayor):

• Cambios breaking en API
• Nueva funcionalidad clínica mayor
• Cambio de arquitectura fundamental

MINOR (versión menor):

• Nueva funcionalidad compatible con versiones anteriores
• Mejoras significativas en funcionalidad existente
• Nuevas integraciones con sistemas externos

PATCH (parche):

• Corrección de bugs
• Parches de seguridad
• Mejoras menores

BUILD (número de compilación):

• Número automático generado por sistema CI/CD

Etiquetado en Git:

• Formato de tags: v{MAJOR}.{MINOR}.{PATCH}
• Ejemplo: v2.1.4

Anotaciones en Tags de Versión:

• Release notes con lista de cambios
• Estado de validación clínica
• Aprobación regulatoria (si aplica)
• Checksum de artefactos para verificación de integridad

Trazabilidad de cambios

Sistema de Registro de Cambios (Change Log):

La organización mantiene un registro completo y trazable de todos los cambios implementados en el sistema.

Campos del Registro de Cambios:

Campo	Descripción
rfc_id	Identificador único del RFC (clave primaria)
change_date	Fecha y hora del cambio
change_type	Tipo: EMERGENCIA, MAYOR, NORMAL, MENOR, ESTÁNDAR
version_before	Versión del sistema antes del cambio
version_after	Versión del sistema después del cambio
components_affected	Lista de componentes afectados (JSON)
clinical_impact	Indica si hubo impacto clínico (Sí/No)
ens_controls_affected	Controles ENS afectados (JSON)
approvers	Lista de aprobadores del cambio (JSON)
implementation_time	Tiempo de implementación en minutos
rollback_executed	Indica si se ejecutó rollback (Sí/No)
success	Indica si fue exitoso (Sí/No)
post_mortem_required	Indica si requiere análisis post-mortem (Sí/No)
regulatory_notification	Indica si requiere notificación regulatoria (Sí/No)
created_at	Fecha de creación del registro
updated_at	Fecha de última actualización

Índices para Reportes:

El sistema mantiene índices sobre los campos clave para facilitar la generación de reportes:

• Índice por fecha de cambio
• Índice por tipo de cambio
• Índice por impacto clínico
• Índice por éxito del cambio

Métricas e indicadores KPI

KPIs de gestión de cambios

Indicador	Fórmula	Objetivo MEDIA	Frecuencia
Tasa éxito cambios	(Cambios exitosos / Total cambios) × 100	> 95%	Mensual
Tasa éxito primera vez	(Éxito sin rollback / Total) × 100	> 90%	Mensual
Tasa rollback	(Rollbacks / Total cambios) × 100	< 5%	Mensual
Tiempo medio implementación	Σ(Tiempo implementación) / N	< 4 horas	Mensual
Cambios de emergencia	(Emergencias / Total) × 100	< 10%	Mensual
Cumplimiento CAB	(Con CAB requerido / Total que requieren) × 100	100%	Mensual
Documentación completa	(RFC completos / Total RFC) × 100	100%	Mensual
Cambios no autorizados	Número absoluto	0	Mensual
Incidentes por cambios	(Incidentes causados / Total cambios) × 100	< 2%	Trimestral
Validación clínica exitosa	(Validaciones OK / Total requeridas) × 100	100%	Trimestral

Dashboard de monitorización

Informe Mensual de Gestión de Cambios:

Quién: Change Manager + Compliance Officer

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

Estructura del Informe:

1. Información del Período:

• Período: YYYY-MM (año y mes)
• Total de cambios ejecutados en el período

2. Distribución por Tipo:

Tipo de Cambio	Cantidad	% del Total
Emergencia	Número	Porcentaje
Mayor	Número	Porcentaje
Normal	Número	Porcentaje
Menor	Número	Porcentaje
Estándar	Número	Porcentaje

3. Métricas de Éxito:

• Success Rate: % de cambios completados exitosamente
• First Time Success: % de cambios exitosos sin reintento
• Rollback Rate: % de cambios que requirieron rollback
• Unauthorized Changes: Número de cambios no autorizados detectados (objetivo: 0)

4. Métricas de Compliance:

• CAB Compliance: % de cambios mayores aprobados por CAB
• Documentation Completeness: % de cambios con documentación completa
• ENS Compliance: % de conformidad con requisitos ENS

5. Métricas Clínicas (Dispositivo Médico):

• Clinical Validations: Número de validaciones clínicas realizadas
• Validation Success Rate: % de validaciones exitosas

6. Análisis de Tendencias:

• Comparación con meses anteriores
• Identificación de patrones
• Evolución de KPIs

7. Recomendaciones:

• Acciones correctivas propuestas
• Mejoras en el proceso
• Áreas de preocupación

Integración con otros controles ENS

Matriz de integración

Control ENS	Integración con OP.EXP.5
OP.EXP.1	Actualización automática inventario post-cambio
OP.EXP.2	Verificación configuración seguridad
OP.EXP.3	Mantenimiento según ventanas aprobadas
OP.EXP.4	Coordinación ventanas mantenimiento
OP.EXP.7	Gestión incidentes que requieren cambios
OP.EXP.8	Registro detallado de cambios
OP.CONT	Actualización plan continuidad
MP.SI	Verificación integridad post-cambio
ORG.2	Aprobación según roles y responsabilidades

Procedimientos específicos dispositivo médico

Cambios que requieren notificación regulatoria

Requisitos de Notificación a Autoridades Regulatorias:

Notificación bajo MDR (Artículo 120):

Cambios que requieren notificación a AEMPS:

• Cambio en intended use: Modificación del uso previsto del dispositivo
• Modificación indicaciones clínicas: Cambio en indicaciones o contraindicaciones
• Cambio en población objetivo: Modificación de la población de pacientes
• Nuevo riesgo identificado: Identificación de riesgos no contemplados previamente

Plazo: 30 días antes de implementación

Suplemento FDA 510(k):

Cambios que requieren nuevo 510(k) o Special 510(k):

• Cambio algoritmo diagnóstico principal: Modificación del algoritmo de IA que genera diagnósticos
• Nueva funcionalidad clínica: Adición de funcionalidad diagnóstica nueva
• Modificación arquitectura sistema: Cambios mayores en la arquitectura técnica

Plazo: Aprobación FDA requerida antes de comercialización

Vigilancia Post-Mercado:

Cambios que requieren reporte inmediato:

• Corrección seguridad crítica: Parches de seguridad que afectan funcionalidad clínica
• Actualización por incidente reportado: Cambios resultantes de eventos adversos
• Mejora basada en datos clínicos: Actualizaciones por resultados de vigilancia

Plazo: Inmediato (< 48 horas)

Validación clínica obligatoria

Determinación de Requisitos de Validación Clínica:

Quién: Clinical Safety Officer + Regulatory Affairs

Triggers que Requieren Validación Clínica:

Tipo de Cambio	Validación Requerida	Tipo de Validación
Modificación de algoritmo	✓ Sí	Validación con dataset clínico
Cambio de threshold	✓ Sí	Análisis de sensibilidad/especificidad
Actualización modelo IA	✓ Sí	Validación completa con 15,000+ imágenes
Cambio en soporte decisión clínica	✓ Sí	Usability study + validación clínica
Modificación criterios diagnósticos	✓ Sí	Estudio clínico comparativo
Nueva funcionalidad clínica	✓ Sí	Estudio clínico completo
Cambio UI/UX clínico	Depende	Usability study
Cambios infraestructura	No	Regression testing técnico

Tipos de Validación:

Tipo	Descripción	Duración Estimada	Aprobación Requerida
FULL_CLINICAL_STUDY	Estudio clínico completo con protocolo	6-12 meses	IRB + Regulatory
VALIDATION_DATASET_TEST	Testing contra dataset de validación	2-4 semanas	Clinical Safety Officer
USABILITY_STUDY	Estudio de usabilidad con usuarios clínicos	4-8 semanas	Clinical Safety Officer
REGRESSION_TESTING	Testing técnico de regresión	1-2 semanas	QA Manager

Criterios de Decisión:

• Afecta algoritmo diagnóstico central: → FULL_CLINICAL_STUDY
• Afecta modelo de IA: → VALIDATION_DATASET_TEST
• Afecta flujo de trabajo clínico: → USABILITY_STUDY
• Solo cambios técnicos: → REGRESSION_TESTING

Plantillas y formularios

Enlaces a plantillas

• [RFC-TEMPLATE]: Plantilla solicitud de cambio
• [CAB-MINUTES]: Plantilla acta CAB
• [ROLLBACK-PLAN]: Plantilla plan rollback
• [VALIDATION-REPORT]: Plantilla informe validación
• [POST-MORTEM]: Plantilla análisis post-mortem

Referencias

Documentación interna

• GP-005: Control de cambios QMS
• GP-110: Ciberseguridad ENS
• R-TF-013-002: Registro gestión riesgos
• R-024-013: Registro cambios implementados

Guías externas

• CCN-STIC 804: Implementación ENS
• ITIL v4 Change Management
• ISO/IEC 20000-1:2018

Control del documento

• Versión: 2.0.0
• Fecha: 2024-11-15
• Autor: Responsable ENS
• Revisado por: CISO, CMO, QA Manager
• Aprobado por: Comité de Seguridad
• Próxima revisión: 2025-11-15

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