1.

PROPOSITO
1.1. El propósito de este procedimiento es definir las actividades de Validación de Sistemas
Computarizados (CSV) necesarias para asegurar y mantener en un estado validado todos los
sistemas que automatizan cualquier parte del Sistema de Gestión de Calidad de dispositivos
electrónicos en conformidad con:

 CP-PROC-2015-0127  MHLW Ministerial Ordinance No. 169, 2004

 CFR 21 Part 820  ANVISA GMP RDC No. 16 of March 28, 2013
 CFR 21 Part 11  NORMA Oficial Mexicana NOM-241-SSA1-2012
 ISO 13485  Annex 11: Computerized Systems

2. ALCANCE
2.1. Este procedimiento es aplicable a todos los sistemas utilizados en Serial Technology SA de C.V. que
automatizan procesos/funciones que:

2.1.1. Crean, modifican, mantienen, archivan, obtienen o transmite datos relacionados con
dispositivos electronicos durante la manufactura, el almacenamiento, prueba o distribución.
2.1.2. Están involucrados en el proceso de manufactura, control, prueba, empaque, etiquetado,
almacenamiento o distribución de dispositivos médicos.

2.2. Fuera del alcance

2.2.1. Sistemas validados y mantenidos en estado validado por el Corporativo de Serial technology
según el TJ-CSVP-2022-001, siempre y cuando el uso en Serial Technology SA de C.V. sea
según el uso intencionado validado.
2.2.2. Todo el software integrado en equipos de manufactura/prueba automáticos (semi) como PLC
o similares que están bajo el alcance de TJ-CSVP-2022-001. La validación para su uso
intencionado y los controles deben incluirse como parte de la estrategia de validación de
procesos y validación de métodos de prueba.
2.2.2.1. Los equipos automatizados (semi) no requiere una validación separada. Por lo que el
equipo en su conjunto se deberá validar para su uso intencionado en su conjunto
 como parte del proceso de validación (consulte TJ-CSVP-2022-001.).
2.2.2.2. Los controles deberán garantizar el control de versiones de los equipos de
manufactura/prueba, y cuando sea necesario, incluir controles de acceso (nombre de
usuario/contraseña).
2.2.2.3. Si los datos del equipo automatizado se envían automáticamente a otro sistema para
su almacenamiento, ese proceso debe validarse como parte del uso intencionado del
equipo.
2.2.3. Si el software del equipo almacena el registro electrónico oficial (GxP record), entonces debe
ser validado según requiere el TJ-CSVP-2022-001.
2.2.4. Las rutinas de medición automatizada para el área de metrología bajo el alcance del TJ-
CSVP-2022-001, la validación para su uso intencionado debe garantizar con estudios de
repetibilidad y reproducibilidad, copias de seguridad, controles de seguridad y control de
versiones.
2.2.5. Aplicaciones que no están clasificadas como GxP.

3. RESPONSABILIDAD
Roles Responsabilidad
 Actualizar el inventario de sistemas computarizados.
 Prepara el Plan Maestro de Validación, priorizando y
planificando las actividades de validación.
Ingeniero de Calidad Validación de  Revisar y aprobar la documentación requerida de
Software validación.
 Asegurar que el personal esté entrenado en los
procedimientos de CSV.
 Crear, integrar y aprobar la documentación requerida de
validación.
Originador
 Crear, integrar, aprobar y cerrar la solicitud de cambio
(CR).
Gerente de Calidad  Revisar y aprobar la documentación requerida de
Gerente de Sistemas de Calidad validación.
Gerente de Ingeniería de Calidad  Revisar y aprobar desviaciones de CSV.
Gerente Calidad de Inspección de  Proveer recursos para verificar las ejecuciones de las
Recibos, Metrología y Calibración pruebas
 Roles Responsabilidad
 Departamento: Sistemas / IT
 Departamento: Ingeniería
Área: Prueba

 Ingeniero de Mantenimiento y
 Revisar y aprobar la documentación requerida de
Automatización Sr
validación.
 Ingeniero de Automatización Sr
 Garantizar la disponibilidad, soporte y mantenimiento de
 Asistente de Gerente de Ingeniería de
los sistemas, así como la seguridad de los datos que
Automatización
residen en dicho sistema.
 Ingeniero SME
 Líder de Ingeniería de Automatización y
Mantenimiento
 Ingeniero de Proyectos de
Automatización
 Es responsabilidad del dueño del proceso proporcionar
recursos para generar la documentación necesaria para la
validación y la ejecución de las pruebas según sea
necesario.
 Es responsabilidad del dueño del proceso proporcionar
recursos para garantizar que el sistema computarizado se
Empleado valide antes de su uso y mantenerlo en un estado validado
durante la etapa de operación del siclo de vida del sistema
(SLC).
 Revisar y aprobar la documentación requerida de
validación.
 Definir los requerimientos de usuario (URS) en función de
las necesidades de la unidad de negocio.

4. DEFINICIONES
4.1. La tabla de definiciones se encuentra en el Anexo 1.

5. PROCEDIMIENTO
5.1. Las validaciones de sistemas computarizados son obligatorias según el Sistema de Gestión de
Calidad para dispositivos médicos en Serial Technology en los sitios de Baja California. Por lo tanto,
todos los sistemas que automaticen cualquier parte del sistema de calidad regulado deberán ser
validados para su uso intencionado previo a su implementación.

5.1.1. La lista siguiente incluye algunos ejemplos de sistemas que pueden requerir validación:
 Instrumentos con software integrado con funciones especiales distintas de las verificadas
durante el proceso de calibración
 Software o herramientas estadísticas
 Bases de datos y registros ubicados en servidores, equipos locales, unidades de uso
compartido, dispositivos móviles o cualquier otro dispositivo de almacenamiento.
 Almacenamiento electrónico de registros GxP como imágenes o escaneos en cualquier
formato como (registros de Excel, XLS, PPT, DOC, TXT, JPG)
  Hojas de cálculo con tablas dinámicas, reglas, fórmulas personalizadas o macros
 Aplicaciones web, aplicaciones de escritorio y aplicaciones móviles
 Firmwares en equipos automatizados / semiautomatizados / instrumentos
 Servicios en la nube, IAAS, PaaS, SaaS
 Cualquier sistema que utilice software desarrollado internamente, propiedad del cliente,
desarrollado externamente o disponible en el mercado.

5.2. Es responsabilidad del dueño del proceso proporcionar recursos para garantizar que el sistema
computarizado se valide antes de su uso y mantenerlo en estado validado durante toda la etapa de
operación del ciclo de vida del sistema (SLC).
5.3. Al realizar la validación de sistemas computarizados (CSV), las siguientes actividades deberán
completarse según la etapa del SLC según apliquen:

Tabla 1: Actividades para la etapa del ciclo de vida del sistema computarizado
Etapa 1: Etapa 2: Etapa 3: Etapa 4:
Concepto Proyecto Operación Retiro del sistema
 Requerimientos  Requerimientos de usuario (URS)  Entrenamiento  Plan de retiro
de usuario  Evaluación inicial de riesgo (GxP  Operación  Plan de migración
generales Assesment)  Cambios (CR)
 Definir calendario  Evaluación de proveedores  Revisiones
 Asignar recursos  Especificación funcional (FS) periódicas
al proyecto  Especificación de diseño (DS)  Plan de migración
 Especificación de configuración
(Actividades no (CS)
reguladas)  Revisión de diseño (DR)
 Plan del proyecto de validación (VP)
 Instalación del sistema
 Pruebas del sistema (IQ, OQ, PQ)
 Reporte de validación (VR)
5.3.1. El enfoque basado en riesgo podrá considerarse en cada etapa del ciclo de vida del sistema.

5.4. Los entregables de validación se definirán y completarán en la etapa 2 del ciclo de vida del sistema
antes de mover el sistema a la operación (etapa 3), el enfoque de la validación deberá considerar la
categoría de software del sistema para determinar los entregables necesarios para la validación, en
la siguiente tabla se incluye la relación entre los entregables y la categoría de software:

Categoría de software
Categoría 1 Categoría 3 Categoría 4 Categoría 5
Plantilla
Infraestructura No configurado Configurado Personalizado
URS TJ-CSVP-2022-001. N/A Obligatorio Obligatorio Obligatorio
GxP
TJ-CSVP-2022-001. N/A Obligatorio Obligatorio Obligatorio
Assesment
FS TJ-CSVP-2022-001. N/A N/A N/A Obligatorio
DS TJ-CSVP-2022-001. N/A N/A N/A Obligatorio
CS TJ-CSVP-2022-001. N/A N/A Obligatorio Si aplica
DR TJ-CSVP-2022-001. N/A N/A N/A Obligatorio
 Categoría de software
Categoría 1 Categoría 3 Categoría 4 Categoría 5
Plantilla
Infraestructura No configurado Configurado Personalizado
Revisión del Si está
TJ-CSVP-2022-001. N/A N/A N/A
código disponible
Protocolos de
TJ-CSVP-2022-001. N/A Obligatorio Obligatorio Obligatorio
validación
Reportes de
TJ-CSVP-2022-001. N/A Obligatorio Obligatorio Obligatorio
validación
Matriz de
TJ-CSVP-2022-001. N/A Obligatorio Obligatorio Obligatorio
Trazabilidad
Nota 1: Sistemas que integran softwares de múltiples categorías, deberán usarse el de mayor categoría.
Nota 2: Para sistemas pequeños o de riesgo bajo, los entregables pueden combinarse según sea necesario.
Nota 3: Considerar el plan de validación como entregable para sistemas grandes y/o complejos
Nota 4: Las herramientas (software de infraestructura) generalmente son altamente confiables y están
significativamente apartados de los aspectos de riesgo. Por definición, esta categoría es para softwares
utilizados para gestionar el entorno operativo de un sistema de categoría superior que es utilizado para
automatizar un proceso regulado. Por lo tanto, no requiere de validación, pero dichos softwares son calificados
indirectamente durante la validación del sistema con softwares de categoría superior.

5.5. La documentación de validación se aprobará como mínimo por:

5.5.1. El Dueño del proceso
5.5.2. El Ingeniero de Calidad / Ingeniero de Validación de Software Líder
5.5.3. Opcional: Se recomienda el Dueño del sistema, pero no es obligatorio

5.6. Para los sistemas que impactan proceso / productos vendidos en el mercado mexicano, los
protocolos y reportes de validación se escribirán como mínimo en español. Sin embargo,
documentos de soporte usados para generar el protocolo y reporte, relacionados al diseño del
sistema, como especificaciones funcionales, configuraciones, manuales y guias, deberán
permanecer en su lenguaje original en el que fueron escritos.

5.7. Para nuevos sistemas computarizados (Etapa de proyecto):

5.7.1. Generar especificación de requerimientos de usuario (URS): el dueño del proceso es

responsable de proporcionar la especificación de requerimientos de usuario (URS) en función
de las necesidades del negocio. La URS define, de forma clara y precisa, lo que el proceso
regulado requiere que el sistema haga, es importante considerar los requisitos reglamentarios,
las políticas de seguridad y protección. El requerimiento de usuario contendrá como mínimo:
 URS ID: número de ID no repetido que identifica a cada requisito.
 Descripción: Define lo que el sistema requiere hacer
 GxP relevante: Define si los requerimientos de usuario son relevantes para la
calidad del producto o las actividades reguladas.

5.7.2. Generar la evaluación inicial de riesgo: El Ingeniero de Validación es responsable de

generar la evaluación utilizando el formato TJ-CSVP-2022-001. y definir el impacto general
que el sistema computarizado tiene según la regulación, la calidad del producto y la integridad
de los datos debido a su función dentro del negocio. Si el riesgo total del sistema (SRR) es
 alta o media, el sistema se validará a través de fases de calificación; para sistema con SSR
bajo o sin impacto en el producto / sistemas de calidad, estos no requerirían de pruebas como
parte de la estrategia de validación.

SRR Riesgo Estrategia

> 60 Alto Prueba necesaria para la validación
30 a 60 Medio Prueba necesaria para la validación
< 30 Bajo No se requieren pruebas para la validación

5.7.3. Generar especificación funcional (FS): El ingeniero de validación deberá integrar el FS

generado por el desarrollador / proveedor del software en la documentación de validación
utilizando el formato TJ-CSVP-2022-001. Este documento define lo que el sistema debe hacer
para satisfacer las necesidades del usuario como se describe en un URS.

5.7.4. Generar especificación de diseño (DS): El ingeniero de validación deberá integrar el DS

generado por el desarrollador / proveedor del software en la documentación de validación
utilizando el formulario TJ-CSVP-2022-001. Este documento define cómo el sistema hará lo
que se define en el FS.

5.7.5. Generar especificación de configuración (CS): El ingeniero de validación deberá integrar el

CS generado por el desarrollador / proveedor del software en la documentación de validación
utilizando el formulario TJ-CSVP-2022-001. Este documento define la configuración apropiada
del software sistema para cumplir los requisitos especificados.

5.7.6. Generar revisión de diseño (DR): El ingeniero de validación es responsable de realizar y

documentar la revisión del diseño con el apoyo de los expertos (SMEs) e integrarlo a la
documentación de la validación TJ-CSVP-2022-001, el DR evalúa los entregables contra los
estándares y requisitos, identifica problemas y proponer las acciones correctivas requeridas a
los defectos en las primeras oportunidades en el ciclo de vida.

5.7.7. Generar protocolo de validación: El ingeniero de validación es responsable de generar el

plan de validación, protocolos de IQ, OQ y PQ aplicables del según sea necesario utilizando el
formato TJ-CSVP-2022-001 y de conducir la ejecución de la validación. El nivel de validación
se debe basar en el riesgo, en la siguiente tabla se muestran detalles a considerar en el
protocolo:

Para sistemas grandes y complejos donde las fases de calificación no se

pueden combinar en un solo documento, se deberá generar un plan de
Plan de validación validación para el proyecto que incluya la estrategia de validación y una
lista de actividades / documentos necesarios para implementar el
sistema, así como los criterios generales de aceptación.
Identificación de Para sistemas grandes y complejos, la prioridad del riesgo se calculará
funciones críticas utilizando la evaluación del riesgo (método derivado del FMEA) según sea
en el sistema necesario. Cuando el sistema tiene impacto en el proceso de
manufactura / calidad del producto, el gerente de calidad deberá aprobar
las decisiones basadas en riesgo.
Protocolos IQ, OQ y Los protocolos IQ, OQ, PQ dependerán de la estructura del sistema y de
PQ la complejidad del sistema. Una aplicación pequeña puede requerir IQ y
PQ solamente. Sin embargo, las aplicaciones grandes como SAP
requerirán Múltiplos IQs, OQs y PQs para demostrar que el sistema
cumple con el uso intencionado.

Utilice “V-Model” para determinar la fase de calificación según aplique

para la categoría de software:

Cuando una fase de calificación no sea aplicable, se proporcionará un

racional en la documentación de la validación utilizando un enfoque
basado en el riesgo. Cuando el sistema tiene impacto en el proceso de
manufactura / calidad del producto, el gerente de calidad deberá aprobar
las decisiones basadas en riesgo.
Definición de caso
de prueba Las rutinas de prueba en los
protocolos deben considerar el
impacto en la calidad y la
complejidad del sistema.

Los sistemas a medida requieren

más pruebas comparado con

Severidad
sistema disponible en el mercado
(utilizado por muchos usuarios)
y/o validadas previamente.

Cuando un sistema impacta el

proceso de manufactura / calidad
de proceso, el gerente de calidad
Categoría de Software
deberá aprobar las decisiones
basadas en riesgo.

Ejemplo:
función Sin impacto Bajo riesgo Alto riesgo
El sistema Pruebas de límites:
mostrará 9.9, 10.0, 10.1, 19.9,
"Aprobado" 20.0 20.1
No se
para los Prueba 9.9, Valores nulos
requieren
resultados de 15.0, 20.1 Precisión decimal
pruebas
las pruebas incorrecta
entre 10.0 y alfanumérico
20.0

Cuando el sistema mantiene registros de calidad, considerar si la

frecuencia de respaldo es apropiada para el sistema. Referencias: TJ-
CSVP-2022-001.

Para múltiples fases de calificación, las pruebas pueden definirse en la

Forma 4 de la Tabla 1 y anexarla al protocolo, a menos que se
especifique de otra manera en el protocolo.
 Ejecución  Es responsabilidad del dueño del proceso proporcionar los recursos
para la ejecución del protocolo según sea necesario (usuarios del
sistema / personal calificado según se requiera/ materiales / equipos).
 El personal será entrenado utilizando la Forma 1 de la tabla 1 en el
protocolo aprobado antes de la ejecución a menos que se especifique
de otra manera en el protocolo.
 Los casos de pruebas de validación (PQ) se ejecutarán en un entorno
operativo.
 Utilice la Forma 3 de la tabla 1 durante la ejecución de la prueba para
documentar la evidencia objetiva recopilada a menos que se
especifique de otra manera en el protocolo.

Nota 5: En el caso de pruebas operativas se ejecutan en un entorno de

prueba separado, un racional deberá justificará la equivalencia de los
resultados comparado contra el entorno de operación.
Nota 6: Los sistemas bajo validación no deben estar en desarrollo o
depuración.
Desviaciones Cada fallo detectado durante la ejecución de la prueba deberá ser
investigado y resuelto antes de generar el reporte de validación, el
ingeniero de validación es responsable de documentar las desviaciones
utilizando la Forma 2 de la Tabla 1 a menos que se especifique de otra
manera en el protocolo. Todas las desviaciones serán aprobadas por el
Gerente de Calidad / Ingeniero de Calidad.

5.7.8. Generar reporte de validación: El ingeniero de validación es responsable de generar el

reporte de IQ, OQ, PQ y cierre del plan (sumario) aplicables según sea necesario utilizando el
formato TJ-CSVR-2022-001. El reporte de validación listara toda la documentación
completada para la validación, así como los entregables y las actividades solicitadas en el plan
de validación para el proyecto.

5.7.9. Generar Matriz de Trazabilidad y mantener actualizada: El Ingeniero de Validación es

responsable de generar y actualizar la matriz de trazabilidad utilizando el formato TJ-CSVP-
2022-001, el documento deberá proporcionar trazabilidad desde los requerimientos y a través
de cada nivel de especificación hasta la verificación realizada. Considere la categoría del
software como se muestra en la tabla siguiente:
Categoría 3 Categoría 4 Categoría 5
No configurado Configurado Personalizado
 URS  URS  URS
 Descripción  Descripción  Descripción
 Prueba / Referencia de  Referencia de CS  Referencia del servicio fijo
protocolo  Prueba / Referencia de  Referencia de DS
 Comentarios protocolo  Referencia de CS
 Comentario  Prueba / Referencia de
protocolo
 Comentarios
Nota 7: Dependiendo del riesgo y la complejidad del sistema, alguna referencia FS/DS/CS
podrían no aplicar, el racional se deberá integrar a la documentación de validación.
5.8. Para las actualizaciones del sistema durante la fase de operación:

5.8.1. Cualquier cambio, incluso un cambio aparentemente pequeño, puede afectar al estado
validado y crear la necesidad de realizar actividades de revalidación para mantener el estado
validado. Por lo tanto, se deberán evaluarán todos los cambios del sistema y/o cambios en las
necesidades del usuario, y cuando sea necesario, deberá validarse previo a su
implementación.
5.8.2. Generar una solicitud de cambio (CR): el dueño del proceso es responsable de asignar
recursos para garantizar que cada cambio del sistema se valide antes de su implementación.
5.8.3. El líder del Proyecto asignado deberá generar y cerrar el CR utilizando el formato TJ-CSVP-
2022-001.
5.8.4. Complete y evalúe el cambio siguiendo la TJ-CSVP-2022-001.
5.8.5. El plan y las actividades de validación se determinarán utilizando un enfoque basado en el
riesgo y considerar el tipo de cambio que aplique según el siguiente diagrama:

Tipo de Cambio

Riesgo Alto Riesgo Medio Riesgo Bajo

Parches in
Cambio en sistema Parche aplicación
Actualización de aplicaciones
primaria
Versión secundarias
Uso
intencionado Aplicación primaria
Actualización de
versión Procedimientos de IT
Aplicación secundaria

Cambios en
Control de cambio de aplicaciones clientes
Alto Riesgo

Control de cambio de
Medio Riesgo

5.8.6. Si el cambio en el sistema tiene impacto en el proceso de manufactura / producto, la solicitud

de cambio se generará siguiendo el T TJ-CSVP-2022-001.
5.8.7. Si el cambio afecta el almacenamiento o la estructura de los registros de calidad, se debe
considerar un plan de migración en función del riesgo durante el plan de implementación.
5.8.8. Cambios de emergencia: cambios de software que se debe implementar en producción antes
de que se apruebe un CR. Esto podría ocurrir cuando los parches son implementados por el
proveedor de software, se descubre un error que detiene producción o hace que el software se
utilice de una manera que no está programado intencionalmente. Todos los cambios de
emergencia se deberán evaluar una vez implementados; y las necesidades de pruebas
 deberán determinarse usando un enfoque basado en el riesgo.

5.9. Revisión periódica durante la fase de operación:

5.9.1. El dueño del proceso es responsable de asignar recursos para revisar periódicamente el
estado actual del sistema y determinar si su estado validado permanece o si hay ajustes
necesarios en la documentación, procedimientos, diseño del sistema, mantenimiento y/o
acciones correctivas.
5.9.2. El ingeniero del proyecto asignado deberá generar la revisión periódica siguiendo las
instrucciones de TJ-CSVP-2022-001. La frecuencia de la revisión periódica se basará en el
SRR según se indica en la siguiente tabla:
SRR Riesgo Revisión periódica
> 60 Alto Cada 2 a 3 años
30 a 60 Medio Cada 3 a 5 años
< 30 Bajo No aplicable (N/A)

5.10. Fase de retiro

5.10.1. Es responsabilidad del dueño del proceso asignar recursos para garantizar que al final de
la vida útil del sistema, este se remueva apropiadamente sin impactar la calidad del producto o
causar impacto regulatorio.
5.10.2. El ingeniero del proyecto asignado deberá generar el CR de retiro utilizando el TJ-CSVP-
2022-001.
5.10.2.1. El plan considerará la documentación que requiera actualizaciones
5.10.2.2. Definir controles para mantener los registros de calidad que deberán mantenerse
durante el período de retención de registros.

 Categoría de software

5.11. Evaluación de riesgo

5.11.1. Para la evaluación de riesgos aplicable (método derivado de FMEA) en cualquier etapa
del ciclo de vida del sistema, un equipo multidisciplinario determinará la combinación de
gravedad, probabilidad de ocurrencia y detectabilidad de fallas para establecer la prioridad de
riesgo para cada modo de falla potencial. Utilice las tablas siguientes para los cálculos:
Tabla de Traducción
Ingles Español
Severity Severidad: Impacto en la seguridad del paciente, la calidad del producto y la
integridad de los datos (u otros daños)
Probability Probabilidad: Probabilidad de que se produzca la falla
Detectability Detectabilidad: Probabilidad de que la falla se note antes de que ocurra el daño
Risk Class Clase de riesgo = Severidad por probabilidad
Risk Priority Prioridad de riesgo = Clase de riesgo por detectabilidad
High Alto
Medium Medio
Low Bajo

5.11.2. Utilice la tabla siguiente para determinar el valor de severidad adecuado:

Severidad Descripción del impacto en la calidad
 Efecto peligroso, falla repentina o incumplimiento de la regulación.
Alto  Insatisfecho, o efecto extremo/mayor en el proceso.
 Rendimiento del dispositivo/proceso severamente afectado pero funcional.
 Algo de insatisfacción. afectación moderada en el desempeño del proceso.
Medio
 Falla en paso del proceso no vital.
 Sin efecto en el desempeño del proceso o en los procesos posteriores
Bajo  Experimente molestias menores. Efecto menor en el desempeño del
proceso
5.11.3. Para definir la probabilidad, consulte la tabla siguiente:
Instalaciones de Desechables o
Probabilidad Sistemas Individual
dispositivos DPMO
N ≥ una vez cada 180 días
Alto N ≥ 1/100 o 1% N ≥ 1 / 1000
(3 a 4 veces/año)
N ≥ una vez cada 730 días
Medio N ≥ 1/10.000 o 0,01% N ≥ 1 / 1.000.000
(1 vez / 2 años)
N < 1 / 730
Bajo N < 1/10.000 o 0,01% N < 1 / 1.000.000
(por debajo de 1 > 2/año)
 5.11.4. Para la detectabilidad, consulte las siguientes definiciones:
Detectabilidad Descripción
Alto  Buena a muy alta probabilidad de que los controles detectan el error.
 Los controles actuales casi siempre detectan el error Los controles de
Medio detección son confiables se conocen y se utilizan en procesos similares.
 Los controles actuales tienen una probabilidad media de detectar el error.
 No hay controles conocidos disponibles para detectar el error.
Bajo  Muy leve a leve probabilidad de que los controles de corriente detecten el
fallo.

6. DOCUMENTOS DE REFERENCIA
Documento Descripción
TJ-CSVP-2022-001.
Annex 1: Definitions for CSV / Anexo 1: Definiciones para CSV

Table 1: CSV Forms / Tabla 1: Formas para CSV

Description / Descripción Form / Forma

Form 1: TRAINING FORM FOR CSV

Forma 1: FORMA DE ENTRENAMIENTO PARA CSV

Form 2: DEVIATION FORM FOR CSV

Forma 2: FORMA DE DESVIACION PARA CSV

Form 3: EVIDENCE FORM FOR CSV

Forma 3: EVIDENCIA DE CSV

Form 4: TEST CASE FORM

Forma 4: FORMATO DE PRUEBAS