Cómo Utilizar la Metodología de GAMP de la ISPE para Validar el Software del Sistema de Monitoreo Ambiental

Los sistemas de monitoreo continuo (Continuous Monitoring Systems, CMS) se utilizan en la industria farmacéutica para detectar condiciones fuera de las especificaciones establecidas (out-of-specification, OOS) en entornos de fabricación, procesamiento y distribución. Estas aplicaciones de monitoreo modernas basadas en la Web también pueden enviar alarmas por correo electrónico para notificar al personal a fin de tomar medidas correctivas antes de que las condiciones OOS, como temperatura y humedad extremas, puedan tener un efecto negativo en la calidad y la seguridad de los productos. Debido a que un sistema de monitoreo puede considerarse un “sistema automatizado”, podemos gestionar este sistema utilizando las pautas de las Buenas prácticas de fabricación automatizada (Good Automated Manufacturing Practice, GAMP) publicadas por la Sociedad Internacional de Ingeniería Farmacéutica International Society for Pharmaceutical Engineering, ISPE). Específicamente, consideraremos las publicaciones de la ISPE: “The GAMP Guide for Validation of Automated Systems in Pharmaceutical Manufacture” y “GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems”.

Mantener las condiciones ambientales dentro de las especificaciones del producto es una parte fundamental de las operaciones de las Buenas prácticas (Good Practices, GxP). Comúnmente, esto implica un sistema automatizado que proporcione monitoreo constante y alarmas en tiempo real. Las condiciones a las que se exponen los productos farmacéuticos deben registrarse con precisión para probar que el producto se creó, procesó y almacenó dentro de los parámetros adecuados.

Un sistema de monitoreo continuo, como todos los sistemas basados en software, tiene un ciclo de vida. Comienza en la adquisición e instalación, continúa con la implementación y el mantenimiento, y luego con el retiro final del sistema. Estos pasos describen a grandes rasgos el ciclo de vida del desarrollo de software (Software Development Life Cycle, SDLC) que es la manera típica de manejar un software de Buenas prácticas de fabricación (Good Manufacturing Practices, GMP). En este artículo, nos centraremos en las fases de calificación y validación del ciclo de vida de un software de monitoreo. Estas fases son importantes porque un software para sistemas de monitoreo continuo puede olvidarse fácilmente; generalmente funciona en segundo plano en las operaciones diarias de una instalación. Sin embargo, el software para sistemas de monitoreo no debería ser ignorado cuando se trata de la validación. Un CMS calificado inadecuadamente puede dar como resultado observaciones no deseadas al momento de la inspección, y preguntas incómodas durante las auditorías de clientes. Para garantizar una calificación de software que cumpla completamente con las GMP, recomendamos utilizar la metodología GAMP como una guía sistemática para garantizar que su software de sistema de monitoreo se desempeñe como se espera durante su ciclo de vida.

Aquí describimos una guía de 10 pasos para aplicar la metodología GAMP a la validación del software de sistemas de monitoreo continuo. El objetivo de este artículo es simplificar el enfoque GAMP y destacar los pasos específicos que se pueden realizar para integrar fácilmente sus esfuerzos de validación con los
sistemas de gestión de la calidad existentes. También mostramos cómo el nivel de esfuerzo requerido en los procesos de validación está relacionado con la complejidad del sistema de monitoreo (es decir, según las categorías de sistema GAMP). En general, un enfoque GAMP en cuanto a la validación, según se describe en este artículo, debería incrementar la vida útil, la usabilidad y el cumplimiento de su software para CMS.

Este es un proceso de diez pasos, con caminos diferentes para las diferentes categorías de sistemas (es decir: clasificados según GAMP 4 y/o 5), y cada uno implica diferentes niveles de esfuerzo

El primer paso para seleccionar un CMS adecuado es determinar sus necesidades mediante el desarrollo de un documento de especificaciones de requerimientos de usuario. La creación de este documento, idealmente, debería llevarse a cabo antes de la selección del CMS, aunque (desafortunadamente) no es lo que sucede normalmente. La creación de un documento de URS es el elemento más importante del proceso GAMP. Repita: La creación de un documento de URS es el elemento más importante del proceso GAMP. Idealmente, el documento de URS se crea ANTES de que se seleccione el sistema porque es una herramienta importante que utilizaremos para determinar si un sistema candidato es adecuado. Es el documento que describirá las funciones requeridas del sistema. El documento de URS también puede identificar las necesidades de diversas partes interesadas para crear un consenso en la selección del sistema.

El objetivo del documento de URS es crear una lista de los requerimientos del sistema necesarios para permitir que su CMS se alinee con su sistema de gestión de la calidad existente (Quality Management System, QMS) y se incluya en él. Cualquier diferencia que haya entre el CMS y el QMS aumenta el riesgo de incumplimiento. Cuantas menos sean las diferencias entre su sistema de monitoreo y su QMS, menor será el riesgo, tanto en el cumplimiento como en la seguridad del producto. El documento de URS desarrollado adecuadamente garantiza que su nuevo sistema encaje con sus procesos de calidad existentes.

Además, el proceso de creación de un documento de URS con diversas partes interesadas puede iniciar discusiones sobre funciones completamente nuevas y enfoques nuevos y más eficientes sobre monitoreo. Esto es de esperarse. Crear el documento de URS es una oportunidad para ser flexible, creativo y estratégico al asegurarse de que el sistema que seleccione coincida con las necesidades de sus entornos, sus productos y el QMS.

Un documento de URS para un sistema de monitoreo típico incluirá secciones específicas para las funciones de un CMS, incluidos: sensores, redes, servicios públicos, infraestructura, seguridad, alarmas, TI y otros requerimientos específicos para su instalación o su producto. Los requerimientos incluidos deben cumplir con las pautas “SMART” (por sus siglas en inglés): específicos, mensurables, alcanzables, relevantes y comprobables. Este último elemento debería informar cómo elegir los requerimientos del sistema; si crea un requerimiento de sistema que no es comprobable, esto causará problemas más adelante. Aquí hay algunos ejemplos de los requerimientos (note el uso de la palabra “debe”).

Cada uno de los requerimientos arriba mencionados es específico y comprobable. En la práctica, un comité de partes interesadas desarrollará el documento de URS, cada una de las partes traerá al debate a un área de especialización. Un beneficio de involucrar a las partes interesadas durante este paso temprano crucial ya que la aprobación por parte de los mismos es generalmente más fácil si se han involucrado en el proceso de definir los requerimientos del sistema. Se realizarán revisiones, y probablemente habrá más requerimientos que los que puede cumplir adecuadamente un sistema cualquiera. Esto es de esperarse. Puede ser de ayuda documentar los requerimientos que no fueran satisfechos para la trazabilidad. Esto garantizará la transparencia del proceso para cualquier solución temporal que deba crearse para satisfacer los requerimientos insatisfechos. Si elimina los requerimientos insatisfechos, es posible que no se documenten adecuadamente las soluciones temporales y no se incluyan en su QMS.

Mientras la selección basada en las necesidades de diversas partes interesadas es necesariamente un compromiso, crear un documento de URS que esté basado en una amplia variedad de necesidades antes de la compra de un sistema aumenta la probabilidad de encontrar la mejor coincidencia para su instalación o aplicación. Idealmente, las empresas impulsan la innovación y la creatividad desde proveedores de sistemas mediante el desarrollo de sus requerimientos basados en las necesidades reales de sus aplicaciones de Buenas prácticas, en lugar de basados en lo que está disponible en el mercado.

Esta es la herramienta que organizará todo el esfuerzo de calificación, comenzando con la selección del sistema. La matriz de trazabilidad realizará un seguimiento de los requerimientos enumerados en el documento de URS para garantizar que cada requerimiento sea representado por una función que le corresponda en el sistema. La matriz también ayuda a verificar que se realice una prueba de cada función. Efectivamente en una hoja de cálculo gigante, usted utilizará la primera columna para los requerimientos que se incluyeron en el documento de URS, y completará las columnas restantes (Especificación funcional, Especificación de configuración y Protocolo de prueba) a medida que seleccione y califique su sistema.

El siguiente paso es encontrar un sistema que cumpla con los requerimientos descritos en su documento de URS. Deberá evaluar cada sistema de monitoreo potencial utilizando su documento de URS como una herramienta para determinar el ajuste adecuado con respecto a su QMS. Es posible que tenga diversas limitaciones para considerar en su documento de URS, como su presupuesto de adquisiciones, el costo total de propiedad a largo plazo o las capacidades de validación de su empresa. Por ejemplo, ¿puede llevar a cabo la instalación del sistema y la calificación del funcionamiento internamente, o deberá encargar ese trabajo a un contratista o al proveedor del sistema?

Su objetivo es identificar una pequeña lista de sistemas candidatos para examinar en detalle. Una vez que tenga la pequeña lista, auditará a los proveedores de dos maneras. Puede auditar su sistema de calidad y las instalaciones para evaluar su compromiso con la calidad, y puede auditar el CMS en sí. Con la segunda opción, utilizará su matriz de trazabilidad como herramienta. Realice una copia de la matriz para cada sistema que audite y, luego, compare las capacidades del sistema con sus propios requerimientos del sistema. La mayor diferencia de los sistemas será el tipo de software, como se los define en las pautas GAMP

La ISPE ha determinado categorías para clasificar tipos de software; se crearon cinco categorías para facilitar su identificación. Las categorías clave en cuanto a los sistemas de monitoreo son:

• Categoría 3: Listo para ser utilizado
  
• Categoría 4: Configurado
  
• Categoría 5: Personalizado
  

Tenga en cuenta que la nomenclatura cambió sutilmente entre GAMP 4 y GAMP 5. Para el tipo de software, nos referiremos a software “disponible para la venta”, GAMP 4 lo llamaba “estándar” y GAMP 5 lo renombró “sin configuración”. Ambos son tipos de software de categoría 3; este tipo de software, que frecuentemente se llama “de instalación automática”, está diseñado para que al comprarlo pueda usarse directamente. Es fácil de implementar, pero no debería requerir configuración además de las configuraciones de tiempo de ejecución.

Con esto se refiere a las simples tareas de configuración que permiten que el sistema funcione, pero no cambian los procesos empresariales. Un ejemplo serían los elementos que dejan margen para ingresar el nombre de un departamento y de la empresa para los títulos del informe, y para configurar las impresoras predeterminadas o los tipos de usuarios.

El siguiente tipo de software es de categoría 4, que en GAMP 4 se llamaba “software configurado” y en GAMP 5, “productos configurados”. Estos sistemas no pueden implementarse directamente después de la compra porque ciertos parámetros deben establecerse para que se correspondan con los procesos empresariales antes de su uso. Los ejemplos incluyen cadenas de entrada para menús desplegables, y la creación de informes específicos. Si bien estamos realizando configuraciones además de las de tiempo de ejecución, no hay un código personalizado. Esto significa que el código en el software no es nuevo: es estándar y se ha sometido a pruebas minuciosas por parte del proveedor del sistema, aumentando así la confianza del usuario.

El software de categoría 5 es “software personalizado” en GAMP 4 y “productos personalizados” según GAMP 5. Este tipo de sistema generalmente se refiere directamente a los sistemas programados que requieren codificación. Sin embargo, también incluye cualquier sistema que requiera algún código nuevo, incluso si ese código fue creado mediante el uso de funciones no personalizadas dentro de la aplicación. El código personalizado está diseñado especialmente para crear nuevos procesos. Debido a que el proceso es nuevo, el proveedor del sistema no lo ha probado y el usuario deberá someterlo a pruebas minuciosas. Los ejemplos varían desde sistemas únicos especialmente diseñados, hasta macros creadas en VBA en una aplicación de Microsoft Excel.

La ISPE realizó grandes esfuerzos para crear estas categorías porque las diferencias en esfuerzo y costo eran bastante importantes. Por esto, esta categorización distintiva se convirtió en una herramienta valiosa para evaluar sistemas en términos de los recursos que requerirán para la validación, y para comprender cómo un nuevo sistema se integrará con los procesos de calidad de una empresa

Cuando tenga su lista reducida de sistemas candidatos, usted creará un documento de especificación funcional (FS). Este describe todas las funciones del software y cómo el software debe satisfacer los requerimientos establecidos en el documento de URS. El documento de especificación funcional para un sistema “disponible para la venta” y “configurado” debe ser tan específico y detallado como sea posible. Un proyecto de la versión suele estar disponible de parte del proveedor del sistema. El documento de FS para un sistema personalizado podría ser impreciso, ya que el sistema todavía no existe. Si usted es un desarrollador de un sistema personalizado, es probable que esto sea algo que debe proveer usted.

A medida que se creen y evalúen los documentos de especificación funcional, es posible que ellos revelen nuevas aplicaciones para el CMS que pueden agregarse al documento de URS.

Cada función debe abordar un requerimiento; cada función se incluye en la matriz de trazabilidad:

Los documentos de URS y FS no siempre se emparejarán con precisión, y la actualización de la matriz de trazabilidad confirmará qué requerimientos se han (y no se han) satisfecho. Es importante recordar que no todos los requerimientos tienen el mismo nivel de importancia; algunos serán esenciales y otros simplemente “deseables”. Usted puede integrar esta clasificación a un proceso de ponderación de los requerimientos con las partes interesadas a fin de priorizar los requerimientos según su importancia. Si fuera necesario, puede revisar el documento de URS con una declaración sobre los elementos que el sistema no satisface funcionalmente. Recuerde observar el proceso o la solución temporal que satisfará este requerimiento.

Ya es momento de finalizar su selección de sistema. Solo recuerde que el tipo de sistema que termine eligiendo (de categoría 3, 4 o 5) afectará cuánta validación se requiere. Si selecciona un sistema de categoría 3, no se necesitan más especificaciones y se puede comenzar con el desarrollo de los documentos de prueba (paso 7). En el caso de los sistemas de categoría 4 o 5, se necesitan más documentos, por lo tanto, continúe con el paso 6. La mayoría de los sistemas de monitoreo que se venden son de categoría 4. Los sistemas de monitoreo de categoría 5 normalmente contienen dispositivos y controladores de diversos proveedores, y se requiere una codificación personalizada para permitir que las partes se comuniquen y se integren en un sistema completamente funcional (sistema de automatización de edificios (BAS o BMS).

Al seleccionar un sistema, recuerde que los recursos necesarios para la validación serán proporcionales al tipo de sistema.

Los documentos de especificación detallada (DS) describen cómo el sistema propuesto debe configurarse o programarse para realizar las funciones identificadas en el documento de FS. Estos documentos de especificación no son necesarios para los sistemas de categoría 3, ya que estos ya están en su forma definitiva.

Para un sistema de categoría 4 configurado el documento de especificación detallada se conoce como especificación de configuración (Configuration Specification, CS). El documento de CS describe cómo el sistema se configurará para emparejar sus funciones con el proceso empresarial. El proceso de configuración real normalmente se lleva a cabo en sitio, después de la instalación del sistema, y puede ser realizada por el proveedor del sistema.

Para un sistema de categoría 5 personalizado el documento de especificación detallada se conoce como especificación de diseño detallada (Detailed Design Specification, DDS). El sistema todavía no existe y en esta etapa aún debe ser creado. El documento de DDS describirá exactamente cómo funciona el sistema, que se describió a grandes rasgos en el documento de FS, y cómo se estructurará y programará. Esto puede servir como un ejemplo de por qué los sistemas de categoría 5 requieren la mayor cantidad de pruebas y documentación de todas las categorías. Un análisis más detallado del documento de DDS es un tema especializado y se encuentra fuera del alcance de este artículo.

Los elementos del documento de CS ahora deben registrarse en la matriz de trazabilidad junto a las funciones y los requerimientos correspondientes que cada elemento de configuración debe satisfacer. Observe que en el ejemplo a continuación, la especificación de configuración es específica y describe en detalle cómo se configurará la función y lo que debe hacer para probar la función.

Ahora que el sistema ya se ha elegido y se ha determinado la configuración específica (si fuera necesario), puede comenzar el desarrollo de los documentos de prueba. Este es un paso necesario para todas las categorías de sistemas, y es esencial que el proceso incluya todos los elementos GMP identificados en los documentos de URS, FS y CS. Para simplificar este proceso, puede usar las técnicas de evaluación de riesgos. Si no es una función de GMP dentro del software, es posible que no haya motivos para probarla. Aquí es donde los requerimientos S.M.A.R.T entran en juego, porque eso ayudará a identificar qué se relaciona realmente con las GMP.

Los protocolos de prueba deben ingresarse en la matriz de trazabilidad para garantizar que haya un test para cada requerimiento. En nuestra matriz de ejemplo, se agregó Prueba de retraso de la alarma como un protocolo de prueba para garantizar que el retraso de 10 minutos esté configurado correctamente y funcione según lo especificado.

La matriz de trazabilidad debería actualizarse en cada paso, basado en los documentos de URS, FS, CS, DS y los documentos de prueba. Mientras revisa su TM, es posible que note pruebas que no tienen requerimientos; reevalúe si necesita una prueba. Similarmente, es posible que haya requerimientos que no pueden probarse. Anote esto en la matriz; ¿por qué no puede probarse esto? ¿Cuál será la solución temporal?

¡Aquí es donde comienza la diversión! Todos los requerimientos deben probarse utilizando la matriz de trazabilidad como una lista de verificación. Este es el motivo por el que es esencial completar la matriz a cada paso. Los sistemas estarán funcionando en un entorno real, a probablemente haya pocos problemas, con suerte solo menores. La mayoría de estos se resolverán, pero si las cosas realmente no funcionan, intente revisando los requerimientos, desarrollando una solución temporal, o contactando al proveedor para ver si se pueden arreglar. Podría haber un problema en el sistema; esto requerirá un parche que proporcione el proveedor.

Una vez que el sistema funcione sin problemas, esté validado y listo para su uso, necesitará ser mantenido. Esto garantizará el funcionamiento óptimo, el cumplimiento y un riesgo reducido, así como también una prolongada vida útil del sistema. Recuerde, el enfoque GAMP es un enfoque en el ciclo de vida, lo que significa mantener el sistema hasta su retiro.

Los pasos de mantenimiento clave para cualquier sistema automatizado son los siguientes:

• SOP
  
• Capacitación
  
• Calibración
  
• Validación
  
• Control de cambios (para asegurarse de que los cambios se introduzcan de forma controlada)

Estos elementos están más allá del alcance de este informe.

Desde 1991, el foro de las Buenas prácticas de fabricación automatizada ha estado trabajando para clarificar y diseminar las mejores prácticas en el uso correcto de los sistemas computarizados para las industrias reguladas. Sus pautas reconocidas internacionalmente se han convertido en metodologías confiables para la validación y calificación de sistemas que afectan la calidad de los fármacos, los productos biológicos y los dispositivos. Esperamos que los pasos y categorías descritos aquí presenten una interpretación simplificada pero aplicable del enfoque de GAMP basado en los riesgos sobre la validación de software. El objetivo era proporcionarle una pauta ilustrativa para validar adecuadamente un software de sistema de monitoreo que se integre con sus sistemas de gestión de la calidad.

Paul Daniel, experto sénior en Cumplimiento Regulatorio de Vaisala, ha trabajado en las industrias de dispositivos farmacéuticos, biotecnológicos y médicos desde 1996. Ha trabajado en una amplia variedad de proyectos de calificación, que incluyen la validación de procesos, limpieza, envíos, equipos de laboratorio, empaques, software, redes y computadoras. Tiene una gran experiencia en la aplicación de los principios de los Apartados 11, 210, 211 y 820 del CFR 21 de la FDA, además de la autoría y ejecución de protocolos de validación para la validación de la fabricación farmacéutica y de software. Daniel es licenciado en Biología (con honores) de la Universidad de California en Berkeley.