En un laboratorio acreditado, hacer bien las cosas no alcanza. Hay que poder demostrar que se hicieron bien, con evidencia ordenada, fechada y atribuible.
Con los equipos esto está resuelto hace décadas: se calibran, se registra, hay certificado. Con el software casi nunca. Y el software influye en el resultado igual que el instrumento: calcula, redondea, decide si algo está dentro de tolerancia y emite el informe que firma alguien.
Qué pide la norma, en cristiano
ISO/IEC 17025 pide que el software usado para adquirir, procesar, registrar, informar, almacenar o recuperar datos esté validado como apto para su uso.
Eso, llevado a la práctica, significa poder responder cuatro preguntas para cada pantalla del sistema:
- ¿Qué tenía que hacer? — el caso de uso.
- ¿Cómo se comprobó? — el caso de prueba, la condición concreta que se verifica.
- ¿Quién lo verificó y cuándo? — la validación, con nombre y fecha.
- ¿Qué pasó cuando falló? — la ronda siguiente, la corrección y la nueva verificación.
Si esas cuatro se pueden responder para cualquier pantalla, la auditoría deja de ser un evento.
Por qué el Excel se queda corto
Casi todos empiezan con una planilla. Y funciona un tiempo, hasta que aparecen tres problemas:
- No hay historia. Si un caso se rechazó, se corrigió y se volvió a validar, la planilla suele quedarse con el último estado. Se perdió la ronda intermedia, que es justamente la que muestra que el control funcionó.
- No hay atribución confiable. Una celda con iniciales no prueba quién la escribió ni cuándo. Cualquiera pudo cambiarla después.
- Se pierde el vínculo. La planilla dice que la pantalla se validó, pero no contra qué versión ni con qué condición exacta.
Nada de eso importa mientras nadie pregunte. Importa el día que preguntan.
Lo que sí sirve
Cuatro decisiones de diseño que cambian el resultado:
Jerarquía, no lista plana
Sistema → pantalla → caso de uso → caso de prueba → validación. Cada nivel cuelga del anterior. Así se puede responder tanto "¿está validado el sistema?" como "¿por qué se validó esta condición puntual?".
Estados que no se saltan
Un caso no puede pasar de propuesto a validado sin recorrer el camino. Una máquina de transiciones lo impide por diseño, en vez de confiar en que nadie se equivoque.
Validaciones por ronda
Cada intento queda: qué se verificó, quién, cuándo y con qué veredicto. La ronda que falló no se borra — es evidencia de que el control detectó algo.
Lo reconstruido, marcado como reconstruido
Esta es la que más veces se hace mal.
Cuando se importa el histórico de una planilla vieja, esos registros no son evidencia primaria: son una reconstrucción. Si se cargan sin distinguirlos, todo el registro queda contaminado, porque el auditor no puede saber cuál es original y cuál se rearmó después.
Marcarlos con su origen es lo que permite usarlos sin que resten credibilidad al resto. Es la diferencia entre un dato y un problema.
Y una regla que parece obvia
El sistema que valida no puede escribir en el sistema validado. Si hay que traer datos del sistema en producción, la conexión va de solo lectura, y solo la usan los procesos de importación.
Suena evidente hasta que alguien, para arreglar algo rápido, deja abierta la puerta al revés.
De dónde sale esto
Lo escribimos porque lo construimos. Sitragol QA es un desarrollo a la medida para registrar exactamente esto: la trazabilidad de validación de cada funcionalidad, con el histórico rescatado del Excel marcado como reconstruido, roles separados de desarrollador y validador, bitácora de cada cambio, y un informe de estado para el cumplimiento de la norma y del procedimiento interno.
Trabajamos con laboratorios desde hace años —calibración, análisis clínico, salud ocupacional— y el patrón se repite: la operación está bien llevada y la evidencia de la parte informática es la que falta.
Si tenés que demostrar la validación de tus sistemas, conversemos.