Validación de planillas de cálculo

Transitando desde hace tiempo el siglo XXI, resulta innecesario explicar la imperiosa necesidad de validar nuestros sistemas informáticos y mucho más específicamente en esta industria. El proceso de validación de los sistemas informáticos es clave para garantizar la calidad de los procesos, asegurando la trazabilidad e integridad de datos, tanto como la seguridad de la información a lo largo de todo su ciclo de vida.

El foro de las Buenas Prácticas de Fabricación Automatizada (GAMP) fue fundado en 1991 por profesionales de la industria farmacéutica del Reino Unido para hacer frente a necesidades y exigencias de las agencias reguladoras de Europa. Pocos años después se asoció con la Sociedad Internacional de Ingeniería Farmacéutica (ISPE) para publicar las primeras directrices GAMP, convirtiéndose rápidamente en un influyente reconocimiento de la calidad del trabajo en toda Europa. Con el tiempo, se convirtió en el órgano de expertos más reconocido para abordar cuestiones de validación de los sistemas informáticos. La última directriz GAMP 5, emitida en febrero de 2018, representa la herramienta más reciente y actualizada en el enfoque para validar sistemas informáticos GxP, las que no convalidan de manera alguna, las erróneas afirmaciones anteriores.

Las entidades reguladas que administran su información crítica a través de sistemas o planillas de cálculo deben poder asegurar y demostrar el correcto funcionamiento y gestión de las herramientas informáticas con las que operan.

Un sistema validado garantiza que sea adecuado para su uso y que cumpla con la legislación vigente, focalizándose en la calidad del producto y por ende en la seguridad o salud de las personas.

El proceso de validación de los sistemas informáticos es clave para garantizar la calidad de los procesos, asegurando la trazabilidad e integridad de datos, tanto como la seguridad de la información a lo largo de todo su ciclo de vida.

Transitando desde hace tiempo el siglo XXI, resulta innecesario explicar la imperiosa necesidad de validar nuestros sistemas informáticos y mucho más específicamente en esta industria, pero, aun así, se siguen planteando algunos errores conceptuales que confluyen en afirmaciones inconsistentes como:

Estamos instalando un sistema “ya validado”, por lo tanto, no debemos validarlo.

Compramos un instrumento de laboratorio de una marca reconocida internacionalmente que viene con su software incorporado, por ende, no debemos validarlo.

Nosotros no tenemos un sistema informático para gestionar el laboratorio, nos manejamos con planillas de cálculo y las planillas electrónicas no hay que validarlas.

Todos los sistemas que cumplan con los requisitos ya mencionados deben validarse con los criterios que se determinen de acuerdo con las clasificaciones y categorizaciones de GAMP5, gestión de riesgos, calificación de proveedores y CFR 21 parte 11. Una de las definiciones más claras al respecto indica que “la validación de software es el proceso de comprobación de que el producto se conforma estrictamente con las necesidades, los requisitos, y/o las especificaciones definidas por el usuario, bajo condiciones de funcionamiento determinadas”. Es decir que sin requerimientos ni especificaciones no existe validación posible, pero, además, por bueno, reconocido y completo que resulte el sistema adquirido o a adquirir, el mismo se parametrizará y configurará de acuerdo con criterios propios y específicos, pero además se ejecutará dentro de una plataforma tecnológica propia y particular. Por lo tanto, junto con los requerimientos deberá validarse que toda la funcionalidad reaccione correctamente dentro de ese entorno.

En cuanto al tema que nos ocupa, que en esta oportunidad son las planillas de cálculo, claramente también deben ser validadas en función de los mismos paradigmas.

Existen distintos proveedores y productos, aunque mayoritariamente se utilice uno de ellos.

Excel; Hoja de Cálculo; Calc; Gnumeric; Quattro Pro

Conceptos básicos

Se debe desarrollar un Plan Maestro de Validación.
Se debe desarrollar un Plan de Validación y Ejecución para una planilla o un grupo de planillas asociadas o relacionadas.
Se deben definir los Requerimientos de Usuario (URS).
Se debe contar con un “inventario de planillas involucradas”
Se deben detallar las pruebas de verificación de estos requerimientos.
Se debe hacer foco en las definiciones, en las pruebas de las fórmulas y también en la seguridad de cada hoja limitando las partes que los usuarios puedan editar.

Principales funcionalidades en las hojas de cálculo

Bases de datos
Operaciones aritméticas básicas
Agrupación de operaciones
Hipervínculos y referencias
Filtros
Gráficos
Seguridad
Formulas, gráficos e inferencias lógicas
Formatos y plantillas
Macros y programación

Ítems importantes para tener en cuenta

Fórmulas y algoritmos
Protección y seguridad
Formatos de datos y condicionales
Vínculos e hipervínculos
Filtrado y manejo de base de datos
Procedimientos
Control documental y manejo de versiones
Distribución y capacitación
Versión del software
Infraestructura

Registros electrónicos

Medios de captura
Difusión
Archivo, respaldo y restauración
Unidades de medida
Riesgos inherentes a las hojas de cálculo
Control de formato y versiones
Protección de datos y formulas contra cambios no autorizados
Redacción de las formulas
Operación inapropiada
Formatos de entrada y de salida
Programación de macros
Vínculos
Formatos condicionales

Especificaciones de diseño

Deben definirse las necesidades de cada planilla. El propósito de este documento es describir cómo se han implementado los requisitos.
Este documento debe incluir la información suficiente para que un desarrollador pueda crear el proyecto de software completo basado en la información contenida en él y de la lectura de la especificación.
Generalmente se determinan cuatro secciones.

Entradas

Tratamiento

Salidas

Seguridad

Entradas

Determinar y documentar de las celdas donde se espera que el usuario entre o actualice datos.
En un sistema automatizado también puede definir la fuente o los datos de entrada o instrucciones.
Si las reglas de validación se utilizan para reforzar un ingreso de datos correcto, estos deben ser documentados aquí.

Tratamiento

Se trabaja principalmente en la documentación de las fórmulas que se utilizan en la hoja. Las macros personalizadas o código de programación también deben documentarse.
La mayoría de los errores se encuentran en la validación de las fórmulas. La mejor manera para tratar las fórmulas consiste en definir claramente el contenido de cada celda, fila o columna y el significado de cada fórmula.

Salida

Las salidas por lo general pertenecen a una de las siguientes tres categorías principales:

1. La celda o rango de celdas que contienen el resultado final de todos los cálculos anteriores.

2. Gráficos – muchas veces estos se imprimen y se guardan con los informes externos.

3. Datos que se copian en una hoja de resultados finales o se exportar en un archivo separado o base de datos.

Seguridad

Debe definirse qué celdas o rangos de celdas que no sean de entrada deben ser bloqueadas para prevenir cambios no deseados, quiénes pueden editar y modificar el contendido de distintas celdas o rangos, ejecutar una macro, función, etc.

Protocolos de prueba

La prueba de cualquier hoja de cálculo debe demostrar que los requisitos se aplican correctamente según las especificaciones de diseño.
La Calificación de la Instalación (IQ) de prueba se limita a asegurarse que el archivo está en un lugar donde los usuarios pueden acceder, a menos que el archivo sea parte de un proyecto de automatización más grande.
La Calificación Operacional (OQ) es en su mayoría sobre la verificación de las fórmulas, macros, y también para poner a prueba la seguridad de cada hoja verificando que todas las celdas que no son de entrada estén bloqueadas para evitar cambios. El IQ y OQ se pueden combinar en un único protocolo de IOQ según sea necesario. En algunos casos también se define como IOPQ
Para empezar a generar los casos de prueba, conviene chequear los cuatro componentes: Entrada – Tratamiento – Salida – Seguridad.

Proceso y salida de prueba

Al escribir los casos de prueba conviene concentrarse especialmente en las fórmulas.
¿Las fórmulas son correctas? Existen varios métodos para verificar y probar fórmulas:
Continuar con las pruebas hasta que todas las celdas de entrada tengan datos introducidos y modificados, y que el resultado haya sido verificado.
El punto clave es la búsqueda de fórmulas que no sean correctas o gráficos que no están utilizando el conjunto de exactitud e integridad de los datos, o si apunta a las columnas de datos incorrectos.
Las macros se pueden probar mediante la introducción de una serie de datos y comparar los resultados o mediante una inspección visual de que la función llevada a cabo como se esperaba.
Los gráficos pueden ser probados por una combinación de la inspección visual o la verificación de las propiedades, incluyendo el conjunto de datos utilizados.

Pruebas de seguridad

Está totalmente relacionado con los criterios de seguridad informática de la organización.
El tipo y la cantidad de pruebas de seguridad dependen principalmente de cómo está configurada la seguridad general en la red o en el computador.
Como mínimo, se debe probar que los usuarios se limitan a introducir datos en las celdas de entrada determinadas y que no tienen la capacidad de alterar cualquier otra parte de la hoja de cálculo.
No hacer esto puede comprometer la integridad de los esfuerzos de validación y de cualquier dato o información generada por el libro.

Conclusión

Esta metodología debe incluir las Especificaciones de Requerimientos de Usuario (URS), requisitos funcionales, una especificación de software de diseño y un protocolo IOPQ listo para su aprobación y ejecución.
Los desvíos encontrados durante las pruebas pueden ser manejados de acuerdo con las prácticas de validación existentes y un informe de resumen que muestra que todas las actividades especificadas en el Plan Maestro de Validación o SOP se han realizado.

Resumen – Pasos necesarios

Especificaciones de requerimiento de usuario y funcionalidad.
Construcción de la hoja de cálculo, (nombre de archivo, fecha de creación, etc.).
Revisión del código/diseño (funciones, macros, algoritmos y parámetros).
Prueba de calificación de instalación (capacidad de acceso, uso en red).
Calificación operacional (prueba de exactitud, integridad numérica, celdas inválidas).
Calificación de desempeño (resultados idénticos obtenidos por hoja de cálculo y cálculo manual o externo).
Control de hoja de cálculo (solo lectura, contraseña de protección).
Revisión del estado de validación (revisión cambios no autorizados, confirmación de versión de software).
Control de cambios (procedimiento de control, revalidar la hoja de cálculo).
En síntesis, la mayoría de las compañías, cuenten o no con un sistema de gestión para su laboratorio (LIMS) continúan administrando información crítica y sensible mediante planillas de cálculo. Esta realidad exige incluirlas de inmediato dentro de su Plan Maestro de Validación.

Marcelo Cabezón
Share on facebook
Share on twitter
Share on linkedin