.jpg){kind=link}
- Publicación
- Actualización
- Fuentes revisadas
En la notificación de seguridad, generar el expediente, completar la evaluación médica y seguir la comunicación son tareas distintas. Ninguna demuestra por sí sola que las otras estén terminadas. Al diseñar las operaciones de notificación SUSAR en Turquía, deben abordarse conjuntamente la responsabilidad de evaluación, los plazos, la calidad del mensaje electrónico y los registros de seguimiento. Este artículo transforma las fuentes de 2026 sobre ensayos con medicamentos de uso humano en un plan de trabajo aplicable por el equipo.
El módulo nacional SUSAR y el alcance de la actualización de 2026
El anuncio de la TİTCK del 20 de mayo de 2026 explica la creación del módulo nacional SUSAR dentro del módulo de ensayos clínicos. Indica el 15 de mayo de 2026 como fecha de publicación y entrada en vigor de las guías correspondientes. El documento KAD-KLVZ-07 examinado es la revisión 13. Estas fechas son distintas del 27 de octubre de 2026, fecha de publicación de este artículo.
No deje la evaluación de la transición únicamente al equipo informático. Farmacovigilancia, evaluación médica, asuntos regulatorios y operaciones del ensayo deberían examinar el mismo caso de ejemplo desde sus respectivas responsabilidades. El objetivo va más allá de comprobar que se abre una pantalla: debe poder demostrarse que los traspasos de trabajo dentro de la organización funcionan.
Asocie cada plazo al acontecimiento y al responsable correctos
El apartado 6.20 de KAD-KLVZ-07 establece un máximo de 7 días desde que la información llega al promotor para SUSAR mortales o que ponen en peligro la vida, y de 15 días desde el conocimiento inicial para las demás SUSAR. La regla de 24 horas para que el investigador comunique acontecimientos adversos graves figura en el apartado 6.17, junto con la excepción prevista en el protocolo.
Nuestra recomendación operativa es separar el conocimiento del acontecimiento, su traslado para evaluación y el registro del envío, en vez de usar una única columna de «fecha límite». Defina también un suplente para cada tarea. El registro no automatiza la clasificación médica: facilita examinar qué información llegó a quién y cuándo. El cómputo debe verificarse frente a la disposición aplicable al ensayo.
Validar XML E2B(R3) no es una simple comprobación de formato
El apartado 6.23.1 de KAD-KLVZ-07 describe la notificación individual en XML E2B(R3) de las SUSAR pertinentes ocurridas en Turquía. El anexo 2 diferencia conformidad XSD, obligatoriedad y repetición de campos, reglas de negocio ICH y controles adicionales de la TİTCK. Por tanto, un XML que puede abrirse técnicamente no debe considerarse aprobado en todos los controles de contenido.
Transforme cada error en una tarea resoluble: campo afectado, error observado, responsable de corregirlo y resultado de la nueva comprobación. Frente a errores similares, revisar la correspondencia con el sistema de origen resulta más útil que reenviar repetidamente el archivo. Para probar casos de ejemplo, prefiera datos ficticios controlados a información real de participantes.
Lea el estándar internacional junto con las reglas locales
El módulo III de formación E2B(R3) de ICH, fechado en enero de 2026, explica la importancia de las guías regionales junto al estándar común. El envío, la recepción, los acuses de recibo y las interrupciones del sistema son aspectos de implementación diferentes. Producir un mensaje válido para un país no implica satisfacer todas las expectativas locales de otro.
En una adaptación práctica, identifique primero la correspondencia de cada campo con el sistema de origen. Después defina los controles propios de Turquía, el tratamiento de los campos ausentes y los escenarios que volverán a probarse ante un cambio de versión. Considerar esto una conversión de archivos que se hace una sola vez dificulta detectar el efecto de futuras actualizaciones.
Mantenga bajo control la herramienta de envío y sus cambios
La guía de EMA sobre sistemas informatizados en ensayos clínicos aborda las cuentas individuales, el acceso según funciones, la trazabilidad de cambios y la validación conforme al uso previsto. Se utiliza aquí como fuente internacional para evaluar el diseño de calidad de un sistema multinacional de notificación, no para añadir una nueva regla de presentación en Turquía.
A partir de este marco, registre qué versión del programa genera o edita los mensajes. Si cambia una correspondencia de campos o una regla de control, reevalúe los escenarios afectados. Revise los accesos cuando haya cambios de personal y evite que, durante un traspaso de funciones, las notificaciones abiertas queden sin responsable.
Unifique el seguimiento alrededor del identificador del caso
Que un caso tenga nombres distintos en equipos diferentes dificulta localizar el expediente y valorar su estado. En el registro operativo que proponemos, deben verse juntos el identificador interno, el ensayo relacionado, el responsable y la acción de seguimiento. Este registro no modifica la evaluación clínica: organiza la comunicación entre equipos.
Especifique desde el principio la evidencia necesaria para cerrar una acción. No agrupe bajo el mismo estado un problema de envío, una solicitud de información pendiente y un asunto que espera evaluación médica. Así, un indicador verde en el panel de gestión no ocultará una dependencia sin resolver. La revisión de retrasos podrá mostrar dónde se bloquea el proceso en vez de limitarse a buscar un error individual.
Lista operativa para preparar al equipo
- ¿Están definidos los responsables y suplentes de evaluación, preparación técnica y presentación?
- ¿Pueden seguirse los registros de conocimiento y traspaso sobre el mismo acontecimiento?
- ¿Se han probado casos ficticios tanto en el flujo habitual como con campos incorrectos?
- ¿Cada error de control tiene un responsable de resolución y un registro de reevaluación?
- ¿Son accesibles las instrucciones oficiales vigentes y el canal de apoyo para una interrupción?
- ¿El nuevo responsable acepta las acciones abiertas cuando se traspasa el trabajo?
Preguntas frecuentes
- ¿Basta con que el XML se abra para notificar una SUSAR?
- No. El anexo 2 de KAD-KLVZ-07 distingue el esquema técnico, las reglas de campos, las reglas de contenido ICH y los controles TİTCK como etapas separadas.
- ¿Este artículo incluye las notificaciones de seguridad de productos sanitarios?
- No. La fuente examinada se refiere a ensayos con medicamentos de uso humano. En productos sanitarios debe revisarse por separado el procedimiento oficial que corresponda al producto y la investigación.
- ¿El estado mostrado en un portal acredita que la notificación oficial está completa?
- No por sí solo. Debe distinguirse el estado de la tarea interna del registro y resultado del procedimiento oficial; el cierre debe basarse en la evidencia correspondiente.
Fuentes
- TİTCK — Anuncio sobre ensayos clínicos, 20 de mayo de 2026
- TİTCK — Notificación de seguridad, KAD-KLVZ-07, revisión 13
- TİTCK — Fuentes oficiales y enlaces a los módulos de ensayos clínicos
- ICH — Módulo III de formación E2B(R3), enero de 2026
- EMA — Guía sobre sistemas informatizados y datos electrónicos en ensayos clínicos, 2023