Posts tagged ‘Sistemas computarizados’

Una gestión de cambios eficiente debe ser ejecutada conjuntamente con la gestión de configuración. Los elementos claves incluyen:

1. Descripción documentada y beneficios del cambio para el negocio

2. Confirmación de la disponibilidad de recursos

3. Evaluación del impacto del cambio sobre la aplicación, la infraestructura necesaria, personal (usuarios, staff de soporte de Ingeniería) y la documentación

4. Aprovechamiento de la información del análisis de riesgos del proyecto original y evaluar cualquier riesgo nuevo introducido por el cambio para definir la estrategia de mantenimiento, esto incluye la necesidad de cualquier testeo de regresión.

5. Evaluación del cambio desde finanzas, IT (o ingeniería) y la perspectiva de cumplimiento al más bajo nivel de competencia técnica antes de gestionar la aprobación

6. Establecer y mantener la distinción entre cambios a nivel del sistema de calidad farmacéutico (impacto sobre el ciclo de vida del producto medicinal) vs cambios a nivel de la gestión del servicio de IT

7. Minimizar el número de puntos de aprobación en el proceso

8- Documentar y comunicar la decisión

9. Ejecutar y verificar el cambio, usando trazabilidad para identificar testeos existentes que aplican

10. Cerrar los registros del cambio en tiempo y forma

Debilidades en los sistemas de gestión de cambio que pueden llevar a ineficiencias, incluyen:

1. Falta de escalada de los cambios, ej cambios menores o de componentes de infraestructura que cambian regularmente

2. Falla en la ejecución de las etapas de gestión del cambio en la secuencia apropiada

3. Falla en la agenda de actividades o en identificar dependencias

4. Abuso o aplicación errónea de un proceso de cambios de emergencia

5. Falta de habilidad para prevenir cambios innecesarios

6. Falla en mantener las especificaciones vigentes

7. Falla para aprovechar documentación relativa a análisis de riesgos y control, matriz de trazabilidad o protocolos

8. Falta de seguimiento del proceso para cerrar un registro de cambio

9. Procesos de cambio independientes llevan a duplicar esfuerzos para procesos, equipos y Sistemas Computarizados.

10. La aplicación inadecuada de los principios de “like for like” en gestión de cambio.

11. Inadecuada gestión de cambios conducidos por un proveedor, conducen a ciclos de vida de documentos y registros de gestión de configuración que están fuera de fecha

12. Falta de un adecuado seguimiento de los cambios de emergencia

Basado en la GAMP5 edición 2 (julio 2022)

El enfoque del ciclo de vida de los Sistemas Computarizados utilizado por la GAMP5, hace referencia a 4 fases principales:

  • Concepto
  • Proyecto
  • Operación
  • Retiro

Hoy quiero referirme a la Operación.

Para alcanzar y mantener en cumplimiento un sistema computarizado GxP a lo largo de su ciclo de vida, en primera instancia el mismo debe ser validado (Plan y Reporte de Validación) y luego deben ser aplicados una serie de controles operacionales.

Esto aplica a la mayoría de los sistemas computarizados, cuando el sistema es parte de un proceso de manufactura. Puede ocurrir que no sea requerido una validación del sistema por separado, pero si es necesario verificar la adecuación del sistema computarizado al proceso.

Cuando nos referimos a la operación del sistema computarizado, debemos considerar que no todas las actividades deben ser aplicadas a todos los sistemas. Estas deben ser seleccionadas y escaladas de acuerdo a las características del sistema en cuestión, al riesgo y complejidad del sistema, a través de la aplicación del pensamiento crítico.

Luego de liberar el sistema para su uso, es necesario mantener el estado validado, a través de la gestión de cambios, el mantenimiento del sistema, la actualización de SOPs, mantener la Integridad de datos, efectuar la revisión periódica del sistema a partir del conocimiento adquirido y de la investigación de fallas, el análisis de causa raíz y la generación de CAPAs.

Con frecuencia veo que los laboratorios, suelen tener procesos de Back Up para sus servidores, aunque a veces los mismos no están correctamente procedimentados, o no cuentan con ensayos de recuperación de la información. También he visto que los procedimientos de respaldo y recuperación se incluyen en el Disaster Recovery Plan (DRP), sin embargo, se recomienda tener un SOP de respaldo dedicado.

Ahora que pasa con los sistemas que están fuera de la red? los standalone. En general suelo ver que los laboratorios disponen de procedimientos para el uso de los mismos y con su personal entrenado, pero la administración de accesos y el back up y recuperación de los datos en muchos casos es una tarea pendiente.

Los registros de respaldo deben almacenarse en una ubicación segura especificada en los SOP. El almacenamiento generalmente se realiza fuera del sitio en un edificio separado de los registros originales.

Algunos elementos a tener en cuenta al escribir el SOP de Back up y recuperación son los siguientes:

  • ¿Se ha descripto todo el proceso de copia de seguridad y restauración? Esto debe incluir la verificación exitosa de la copia de seguridad, los medios de copia de seguridad y la resolución de problemas
  • ¿Es seguro el transporte y el almacenamiento del respaldo?
  • ¿Cuál es el alcance de la copia de seguridad de datos (por ejemplo: todos los datos, datos de producción, fuente, datos de prueba, softwares)?
  • ¿Cuál es la frecuencia de respaldo y la programación? una vez a la semana, ¿copia de seguridad completa y cambios incrementales, diferenciales o copia de seguridad diarios de los datos instantáneamente a otro servidor u otra ubicación? Esto dependerá de la criticidad de los datos.
  • ¿Cuál es el cronograma de retención de respaldo y cómo se mantiene la calidad de los datos?
  • ¿Se han archivado los datos de acuerdo con la estrategia de archivo? ¿Sigue siendo necesario mantener las cintas de respaldo?
  • ¿Cómo se gestiona la restauración de datos? Esto incluye: frecuencia de las pruebas de restauración, qué se puede restaurar, ¿cuánto tiempo se conservarán los datos para solicitar la restauración?
  • ¿Alguna vez ha probado la tarea de restauración (a partir de datos “antiguos”)?

Las empresas que dependen de sistemas electrónicos y en papel deberían determinar la medida en que los procedimientos de respaldo y recuperación son necesarios en función de la necesidad de cumplir con los requerimientos que le aplican, disponer de una evaluación de riesgos justificada y documentada, y una determinación del posible efecto sobre la calidad y el registro de los datos integridad.

Por otra parte la copia de seguridad también debe incluir documentos críticos de la compañía que no están cubiertos por las autoridades reguladoras.

El acceso remoto por parte del proveedor ofrece muchas ventajas al mantener el software, solucionar problemas e instalar nuevas funcionalidades. Sin embargo, ¿qué regulaciones deben existir para el acceso remoto de los proveedores de servicios a los sistemas críticos de GxP? ¿Qué requisitos de integridad de datos se deben incluir?

¿Cómo se puede hacer que este proceso sea compatible con GxP?

El acceso remoto permite a los proveedores de servicios acceder a sistemas computarizados a través de una conexión de red para corregir errores o cambiar la configuración. Si se accede a un sistema computarizado crítico GxP de forma remota, las actividades del proveedor de servicios o la compañía de servicios pueden modificar el sistema de tal manera que el estado validado ya no se mantenga. Por lo tanto, el acceso remoto y las acciones realizadas durante esta sesión deben controlarse y documentarse. Esto significa que el acceso debe ser habilitado activamente por el RU (usuario regulado). Además, esto debe hacerse a través de una conexión de red segura y se debe mantener un registro de las actividades realizadas. Si es necesario, se debe iniciar un proceso de control de cambios.

El objetivo es mantener y controlar el estado validado del sistema.

Publicado en el Boletín GMP de la ECA (6/5/2020)

Aplicaciones en la Nube | Enkicode

Les dejo este artículo relacionado sobre aplicaciones en la nube.

Estos 5 conceptos claves son aplicados a lo largo de la GAMP5:

  • Comprensión de productos y procesos

Una comprensión del proceso soportado es fundamental para determinar los requisitos del sistema. La comprensión de productos y procesos es la base para tomar decisiones basadas en la ciencia y el riesgo para garantizar que el sistema sea adecuado para el uso previsto.

Los esfuerzos para garantizar la aptitud para el uso previsto deben centrarse en aquellos aspectos que son críticos para la seguridad del paciente, la calidad del producto y la integridad de los datos. Estos aspectos críticos deben ser identificados, especificados y verificados.

Los sistemas dentro del alcance de la GAMP5 admiten una amplia gama de procesos, incluidos ensayos clínicos, estudios toxicológicos, producción de API, producción de productos formulados, almacenamiento, distribución y farmacovigilancia.

Para algunos sistemas de fabricación, los requisitos del proceso dependen de una comprensión profunda de las características del producto. Para estos sistemas, la identificación de Atributos de calidad críticos (CQA) y los Parámetros críticos de proceso (CPP) relacionados permiten la definición de los requisitos de control de proceso.

La especificación de requerimientos debe estar enfocada en aspectos críticos. El alcance y el detalle de la especificación de requisitos deben ser acordes con el riesgo, la complejidad y la novedad asociados del sistema.

La comprensión incompleta del proceso dificulta el cumplimiento efectivo y eficiente y el logro del beneficio comercial.

  • Enfoque del ciclo de vida dentro de un QMS

Adoptar un ciclo de vida completo del sistema computarizado implica definir las actividades de una manera sistemática desde la concepción del sistema hasta su retiro. Esto permite el control de la gestión y un enfoque coherente en todos los sistemas.

El ciclo de vida debe formar parte intrínseca del QMS de la empresa, que debe mantenerse actualizado a medida que se desarrollan nuevas formas de trabajo.

A medida que se adquiere experiencia en el uso del sistema, el sistema de gestión de la calidad del servicio (QMS, por sus siglas en inglés) debe permitir mejoras continuas en el proceso y en el sistema basadas en revisiones y evaluaciones periódicas, datos operativos y de rendimiento, y análisis de causas de fallas. Las mejoras identificadas y las acciones correctivas deben seguir a la gestión del cambio.

Un ciclo de vida adecuado, aplicado adecuadamente, permite garantizar la calidad y la aptitud para el uso previsto, y lograr y mantener el cumplimiento de los requisitos reglamentarios. Un ciclo de vida bien gestionado y comprendido facilita la adopción de un enfoque QbD.

El enfoque del ciclo de vida es fundamental para la GAMP5 y representa cada uno de los otros conceptos claves.

  • Actividades escalables del ciclo de vida

Las actividades del ciclo de vida se deben escalar de acuerdo con:

  1. Impacto del sistema en la seguridad del paciente, la calidad del producto y la integridad de los datos (evaluación de riesgos)
  2. Complejidad y novedad del sistema (arquitectura y categorización de los componentes del sistema).
  3. Resultado de la evaluación del proveedor (capacidad del proveedor)

El impacto sobre el negocio también puede influir en la escala de las actividades del ciclo de vida.

La estrategia debe estar claramente definida en un plan y seguir las políticas y procedimientos establecidos y aprobados.

  • Gestión de riesgos de calidad basada en la ciencia

La gestión de riesgos de calidad es un proceso sistemático para la evaluación, control, comunicación y revisión de riesgos.

La aplicación de Quality Risk Management permite que el esfuerzo se centre en aspectos críticos de un sistema computarizado de manera controlada y justificada.

La gestión de riesgos de calidad debe basarse en una clara comprensión del proceso y un impacto potencial en la seguridad del paciente, la calidad del producto y la integridad de los datos. Para los sistemas que controlan o monitorean los CPP, estos deben ser rastreados a los CQA y, en última instancia, a las presentaciones reglamentarias relevantes para los sistemas de fabricación.

Se pueden utilizar técnicas cualitativas o cuantitativas para identificar y gestionar los riesgos. Los controles están desarrollados para reducir los riesgos a un nivel aceptable. Los controles implementados son monitoreados durante la operación para asegurar la efectividad continua.

  • Aprovechamiento de la participación del proveedor

Las compañías reguladas deben tratar de maximizar la participación del proveedor a lo largo del ciclo de vida del sistema para aprovechar el conocimiento, la experiencia y la documentación, sujeto a una evaluación satisfactoria del proveedor.

Por ejemplo, el proveedor puede ayudar con la recopilación de requisitos, las evaluaciones de riesgos, la creación de especificaciones funcionales y de otro tipo, la configuración del sistema, las pruebas, el soporte y el mantenimiento.

La planificación debe determinar la mejor manera de utilizar la documentación del proveedor, incluida la documentación de prueba existente, para evitar duplicación de  esfuerzos. La justificación para el uso de la documentación del proveedor debe ser proporcionada por el resultado satisfactorio de las evaluaciones del proveedor, que puede incluir auditorías del proveedor.

La documentación debe evaluarse para determinar su idoneidad, precisión y exhaustividad. Debe haber flexibilidad con respecto a las prácticas aceptables de formato, estructura y documentación.

ISPE GAMP 5 A Risk Based Approach to Compliant GxP Computarized Systems (2008).

  1. Hay una separación clara de responsabilidades y cooperación entre todo el personal relevante tal como propietario del proceso de negocios, propietario del sistema, una persona calificada de QA e IT?
  2. Hay un Análisis de riesgo documentado efectuado a lo largo del ciclo de vida del sistema computarizado, teniendo en cuenta la justificación para la validación, seguridad del paciente, integridad de datos y la calidad del producto?
  3. La documentación de validación incluye los registros de Controles de Cambios (si los hay) y los reportes sobre cualquier desvío observado durante el proceso de validación?
  4. Hay una URS para cada sistema, donde se describen las funciones esperadas por los usuarios y estas son trazables a lo largo del ciclo de vida de los documentos?
  5. Para la validación de SC customizados / categoría 5 GAMP5, hay un proceso “in place” para asegurar el análisis formal y el reporte de calidad y medidas de la performance para todas las etapas del ciclo de vida del SC?
  6. En el caso que sean transferidos datos a otro formato de datos o sistema. La validación incluye la verificación que los datos no han sido alterados en valor y/o significado durante el proceso de migración?
  7. En el caso que el SC intercambie datos electrónicamente con otros sistemas. Hay chequeos incorporados apropiados para verificar el correcto y seguro ingreso y proceso de los datos, de manera de minimizar los riesgos?
  8. En el caso que sean ingresados datos de forma manual. Hay una verificación adicional efectuada por una segunda persona o medio electrónico validado para asegurar la exactitud de los mismos? La criticidad y las consecuencias potenciales de potenciales errores o datos ingresados de forma incorrecta debería ser cubierta por la gestión de riesgo.
  9. Cómo es la seguridad de los datos frente al daño (tanto física como electrónica)? Los datos almacenados deberían ser chequeados para su accesibilidad, lectura y exactitud. El acceso a los datos debe ser asegurado a lo largo del período de retención.
  10. Es efectuado un back up de los datos de forma regular? La integridad y exactitud del back up de datos y la capacidad para recuperar datos debe ser verificada durante la validación y el monitoreo periódico.
  11. Es posible obtener copias impresas de datos almacenados electrónicamente de forma clara?
  12. Para registros que soportan la liberación del lote, es posible generar impresiones indicando si alguno de los datos ha sido cambiado desde la entrada original?
  13. Hay un “Audit Trail” diseñado dentro del sistema el cual registra todo cambio GMP relevante y las eliminaciones?
  14. Todos los cambios y eliminaciones de datos GMP relevantes son documentadas con una justificación?
  15. Los audit trails están disponibles y convertibles a un formulario comprensible?
  16. Los cambios a un SC son incluidos en un sistema de configuración hecho en una forma controlada de acuerdo a un procedimiento definido?
  17. Todos los SC son periódicamente evaluados para confirmar que ellos se mantienen en un estado validado y están en cumplimiento de las GMP? Las evaluaciones deberían incluir, si es apropiado, el rango actual de funcionalidad, el registro de los desvíos, incidentes, problemas, historial de las actualizaciones, performance, confiabilidad y reportes de estatus de validación.
  18. Hay controles físicos y lógicos, “In Place” para restringir el acceso a los SC a las personas autorizadas? Por ejemplo, uso de claves, tarjetas, código personal con contraseñas, biométricas, para restringir el acceso a áreas del equipamiento computarizado y almacenamiento de datos.
  19. Los sistemas de gestión de datos y documentos están diseñados para registrar la identidad de los operadores que ingresan, cambian, confirman o borran datos incluyendo la fecha y la hora?
  20. Cómo son reportados y evaluados los incidentes? La causa raíz del incidente debe ser identificada y debe ser la base de la acción correctiva (CAPA).
  21. Ha sido efectuada la evaluación de la parte 11 para los sistemas relevantes?
  22. Hay un procedimiento que confirma que la firma electrónica tiene el mismo impacto que las formas manuscritas dentro de los límites de la compañía?
  23. Las firmas electrónicas permanecen relacionadas a sus respectivos registros electrónicos?
  24. Cuando el sistema computarizado es usado para la certificación y liberación de lotes, el sistema permite solo personas calificadas para certificar la liberación de los lotes y claramente identificada y registra la persona que libera y certifica los lotes? Esto podría ser efectuado utilizando una firma electrónica.
  25. Los datos han sido chequeados para su accesibilidad, disponibilidad e integridad?

CSV

El proceso de Análisis de riesgos conducido como parte del ciclo de vida de validación de sistemas computarizados, nos permite poner el énfasis y la atención apropiada en aquellas partes del sistema que pueden tener potencial impacto sobre la seguridad al paciente, la calidad del producto y la integridad de datos.

mitigarriesgo1

Es recomendable conformar un equipo para el manejo de la validación de los sistemas computarizados inicialmente, y para el posterior manejo de los cambios que pudiera tener el sistema durante su uso productivo. Este equipo debe tener como mínimo de los siguientes roles:

  • Propietario del sistema (inicialmente este role puede ser llevado a cabo por el manager del proyecto)
  • Propietario de procesos del negocio
  • Proveedor (o representante técnico)
  • Representante de IT (con formación en Compliance)
  • Representante de Quality Assurance

Los principios de evaluación y gestión de riesgos son aplicados desde que se introduce un sistema informático a la planta, y además durante el control de cambios, la revisión periódica y el decomiso del mismo.

Como parte de la implementación inicial del sistema computarizado, se evalúan los riesgos del proyecto, por ejemplo: restricciones de recursos, falta de conocimiento técnico, financiación, estabilidad del proveedor, etc. Estos riesgos del proyecto pueden ser manejados por el Propietario de procesos del negocio o Project Manager.

Registro del sistema y determinación del impacto regulatorio

Se trata de la primera etapa de análisis de riesgos del sistema, donde se efectúa una evaluación regulatoria (por ej. si el sistema tiene impacto GxP), o es crítico para el negocio, SOx, Finanzas, Privacidad de datos, eDiscovery. Luego de esta evaluación, se toma y se registra la decisión sobre si el sistema será validado.

Clasificación de riesgo del sistema

Si un sistema computarizado debe validarse entonces debe llevarse a cabo una clasificación de riesgo del sistema para ayudar a determinar el nivel y el alcance de las actividades de validación requeridas. Los resultados de la clasificación de riesgos deben ser registrados.

La clasificación de riesgos del sistema asigna un score que puede ser Alto, Medio o Bajo basado en:

  • El status GxP del sistema
  • El status de evaluación del proveedor (Rojo, Amarillo o Verde)
  • La categoría GAMP5 del sistema
  • Si el sistema almacena registros GxP
  • Si el sistema tiene una red de conectividad.

Estos factores son registrados en el sistema de registro.

Esta clasificación de riesgo pretende reflejar el potencial nivel de riesgo que el sistema tiene para el proceso de negocio, por ej. Si el sistema fue desarrollado a medida, de acuerdo a las GAMP es categoría 5, o el proveedor tiene un sistema de gestión de calidad que NO es lo suficientemente maduro, la clasificación de riesgo del sistema establecida será mayor para asegurar que se aplican controles más exhaustivos durante el ejercicio de validación del sistema.

Para cada sistema, los entregables requeridos son descriptos en el Plan de Validación del sistema computarizado. El nivel de las actividades de validación dependerá de la clasificación del sistema, bajo, medio o alto, el paquete de testeos y su ejecución podría ser efectuado por el proveedor en el caso de un sistema de bajo riesgo, aunque en el caso de un sistema de alto riesgo, el paquete suele ser desarrollado en conjunto (proveedor + laboratorio) y la ejecución puede ser efectuada por el proveedor con la aprobación final del laboratorio o efectuada por el laboratorio.

Análisis de riesgo funcional

Si es requerido, un análisis de riesgo funcional es llevado a cabo. Esto se puede hacer a un nivel alto y / o un nivel funcional. El factor clave para llevar a cabo una evaluación de riesgos funcional es en los casos donde los escenarios de riesgo y la probabilidad y controles de mitigación no pueden determinarse sólo por hacer una evaluación de alto nivel y donde se requiere más detalle. Evaluación del riesgo sólo puede llevarse a cabo una vez que el diseño del sistema se ha acordado y aprobado. Los sistemas de bajo riesgo no necesitan someterse a una Evaluación de Riesgos. Los sistemas clasificados como de medio y alto riesgo deben someterse a una evaluación de riesgos en un nivel alto como mínimo. Una evaluación de riesgo alto nivel considera requisitos en grupos.

  • La primera etapa es para clasificar los requerimientos. Dentro del URS, para cada requerimiento:
    • Establecer el impacto GxP
    • Establecer la criticidad para el negocio
    • Establecer cualquier otra área sujeta a regulación, ej. SOx, Financiera, Privacidad de datos, eDiscovery.
  • La segunda etapa implica la realización del análisis de riesgo para cada requerimiento

El foco de la evaluación está en la interacción del sistema con el proceso de negocio.

El análisis de riesgo debe considerar, para cada requerimiento:

  • Qué podría salir mal (modos de fallas);
  • Probabilidad
  • Impacto
  • Detectabilidad

Luego se lleva adelante un sistema de score de riesgos basados en la probabilidad de ocurrencia, el impacto o severidad del evento y la detectabilidad del mismo (según el enfoque de la GAMP5), el foco debe estar en aquellos ítems donde la clasificación final del riesgo del sistema es medio o alto.

A modo de ejemplo podemos utilizar los siguientes valores:

Probabilidad (1-3)

Severidad (1-3)

Detectabilidad (1-5)

De acuerdo a estos valores, el score mínimo es 1 y el máximo a obtener es 45 y podemos valorar los riesgos de la siguiente manera:

Bajo riesgo (1-4)

Riesgo medio (5-10)

Alto riesgo (>10)

  • La tercera etapa en el proceso es para identificar los controles de mitigación para cada requerimiento. Los controles incluyen testeos técnicos y de negocios, SOPs, requerimientos de entrenamiento, etc.
  • El reporte de la Evaluación de Riesgos funcional, puede ser elaborado utilizando un modelo o template adecuado, y el mismo debe ser aprobado por QA.

Introducción

Cualquier planta GMP que elabore, envase, controle y/o distribuya productos farmacéuticos se apoyará en mayor o menor grado en sistemas computarizados. Estos son fundamentales para garantizar que los procesos y los datos son fiables y seguros. Con el fin de lograr esto,  los sistemas computarizados deben mantenerse en un estado validado.
La validación de un sistema computarizado es el establecimiento de pruebas documentadas que proporciona un alto grado de seguridad que funcionará consistentemente, de acuerdo con las especificaciones predeterminadas y atributos de calidad durante todo su ciclo de vida.

CSV

¿Qué es una auditoría de sistemas informáticos en una planta GMP?

Una auditoría de los sistemas informáticos es una revisión o inspección de las prácticas, los procedimientos, métodos y normas de la planta GMP que se aplican durante el ciclo de vida del sistema informatizado.
Su objetivo es determinar si la validación del sistema informático es adecuada para satisfacer las expectativas de la regulación y del laboratorio y que el proceso se ejecuta constantemente y de acuerdo con los procedimientos establecidos.
La auditoría también determina cómo se desarrollan, mantienen y utilizan en la Planta los sistemas informáticos.
Gestión de los Sistemas Computarizados

Es importante establecer que los sistemas informáticos son manejados adecuadamente dentro de la planta. Ellos deben estar cubiertos por un sistema de gestión de calidad. Este puede ser el mismo que el resto de la planta o puede ser uno específico, a medida, para los sistemas computarizados.
Procedimientos y normas deben existir para abordar las siguientes áreas:

  • Ciclo de Vida de los sistemas computarizados
  • Requerimientos funcionales
  • Especificaciones de Diseño
  • Testeos
  • Instalación / Implementación
  • Soporte / Mantenimiento
  • Control de Cambios / Gestión de la Configuración
  • Back UP / Restauración
  • Continuidad del negocio y recuperación de desastres
  • Seguridad
  • Decomiso
  • Gestión de desvíos

Es importante determinar el papel de Aseguramiento de la Calidad (QA) en la gestión de los sistemas informáticos. Aseguramiento de la Calidad puede estar involucrado en cada paso del proceso de validación o limitada a la aprobación independiente de las entregas de validación. Es posible que una función separada de Gestión de Calidad IS (ISQM) (dentro de la organización IS) lleve a cabo todas o algunas de las actividades de control de calidad. Es importante que la relación y el papel de las organizaciones de control de calidad e ISQM están documentadas y que la independencia del grupo de desarrollo del sistema se mantenga.
Los procedimientos deben describir qué nivel de aprobación se requiere para cada entregable de validación. Como mínimo, la aprobación QA se esperaría para los Planes de validación, requerimientos e informes de validación y documentación de control de cambios. Si se producen desviaciones a los procedimientos, confirmar que están documentados, evaluados y aprobados.
Un inventario de los sistemas debe existir para identificar todos los sistemas de la planta, detallando el propietario y el impacto GMP. Cualquier sistema con un impacto GMP que se encuentra actualmente en funcionamiento debe ser validado. La infraestructura de IT también debe ser identificada.
Sistemas críticos GMP pueden incluir:

  • Sistema de Control de Procesos (SCADA (Supervisory control and data acquisition), autoclaves)
  • Sistemas de Monitoreo Ambiental
  • LIMS (Laboratory Information Management System)
  • MES (Manufacturing Execution Systems)
  • Sistema de gestión de documentos
  • ERP (Enterprise Resource Planning) por ejemplo, BPCS, SAP, etc.
    Debe quedar claro cómo se determina, evalúa y documenta el impacto GMP o criticidad de un sistema.

Validación

Entregables de validación

En general, las prácticas de documentación GMP estándar debe aplicarse a toda la documentación de validación del sistema computarizado. Como mínimo esto incluye paginado, datos, historial de revisiones, versión de los documentos, aprobaciones, y otras buenas prácticas de documentación.
Plan de Validación

El Plan de Validación proporcionará información de planificación específico en lo que respecta a las actividades de validación que se realizarán para el sistema. El Plan de Validación describe el enfoque de validación que debe tomarse, indica los entregables de validación y proporciona criterios de aceptación claros. El alcance y la profundidad de validación del sistema computarizado varían, dependiendo de la naturaleza y la complejidad del sistema. Un enfoque de categorización se puede tomar donde los sistemas se agrupan en función de su complejidad y su uso.

La GAMP5 clasifica a los sistemas en 4 categorías:

  • 1. Sistemas Operativos disponibles en el mercado. Las aplicaciones se desarrollan para funcionar bajo el control de estos sistemas operativos. Ej. DOS. Otros sistemas de categoría 1 son los Firmware, los instrumentos y controladores a menudo incorporan firmware. La configuración puede ser necesaria para el set up y los parámetros del proceso del entorno de ejecución.
  • 3. Paquetes de software estándar
    Son paquetes estándares disponibles en el mercado, proporcionando una solución de estante. Se requiere configuración limitada para establecer el entorno de ejecución.
  • 4. Paquetes de Software configurables
    Los paquetes de software configurables que proporcionan interfaces y funciones que permiten la configuración de usuario o procesos de negocio específicos estándar.
  • 5. Software a medida
    Software desarrollado para satisfacer las necesidades específicas del negocio.

El plan debe indicar la aprobación del propietario de procesos de negocio o el propietario del sistema, los representantes técnicos y Aseguramiento de la Calidad.
Especificación de requerimientos

La especificación de requisitos (puede ser llamada como URS – especificación de requerimientos de usuarios o simplemente requisitos del usuario) describe lo que el usuario necesita que haga el sistema.
Los requisitos deben ser únicos y priorizados. Deben estar escritos a un nivel detallado, identificando con precisión los criterios aceptables para el éxito desde la perspectiva de los usuarios.
Especificación funcional

La especificación funcional (puede ser llamada como Especificaciones de Diseño) describe cómo el sistema está diseñado para alcanzar los requisitos funcionales. Este entregable es un documento técnico que identifica la solución técnica para la aplicación, el software subyacente y el hardware necesario para apoyar el sistema. Debe haber trazabilidad clara entre los requisitos y el diseño funcional. Esto puede conseguirse usando una matriz, referencias cruzadas, la numeración común o cualquier otro enfoque que hace que sea claro cómo cada requisito se satisface mediante el diseño.

Programación del sistema.

Codificación deben cumplir con los estándares de programación para las pantallas, menús, anotaciones de código, etc. Cuando sea posible utilizar estándares de codificación de la industria, los mismos deben ser usados. El cumplimiento de los estándares de codificación debe ser evaluado a través de la revisión formal de código. Un enfoque basado en el riesgo se puede aplicar a la revisión de código con el código seleccionado basa en la complejidad, criticidad o la experiencia del desarrollador.
Los defectos encontrados durante la revisión de código deben ser registrados con las acciones correctivas y preventivas, según corresponda.

Procedimientos para el mantenimiento y el control de versiones múltiples de código fuente deben estar disponibles. En la práctica esto se logra a menudo usando software de gestión de la configuración comercial por ejemplo, CVS, Microsoft Visual SourceSafe o IBM Rational ClearQuest.
Siempre que sea posible deben ser utilizados ambientes separados, para el desarrollo y para los testeos. Estos deben ser lo más similar posible al entorno de producción para el sistema con el fin de asegurar la validez de las pruebas del sistema.

Especificación de testeos

La especificación de testeos describe las pruebas que se realizan para asegurar que el sistema cumple con los requisitos de los usuarios. Los scripts de testeos deben ser escritos de forma clara. Las pruebas deben probar límites, las fallas y condiciones de estrés, así como la ejecución exitosa de la funcionalidad requerida. Debe haber trazabilidad de los requisitos. Debe ser posible demostrar que toda la funcionalidad requerida ha sido probada de forma adecuada.
Es una buena práctica para los tests para ser escritos por alguien que no sea el desarrollador y ejecutados por otra persona independiente.
Resultados esperados deben estar claramente identificados y los resultados obtenidos se deben documentar con pruebas suficientes para demostrar el cumplimiento. Las desviaciones de las etapas de testeso o resultados esperados deben estar documentados.
Las fallas de los tests deben ser registradas e investigadas. Dependiendo del impacto de la falla y la criticidad de las opciones de la función, puede incluir corregir el código y volver a probar la función (y otras funciones implicadas) o proporcionar una solución de procedimiento.
Las pruebas pueden llevarse a cabo utilizando un software de testeos automatizados. Deben existir procedimientos que cubran el mantenimiento de la herramienta de testeos y los scripts de testeos. Los softwares y herramientas de testeos automatizadas deben ser validados.

Las pruebas pueden existir en diferentes niveles con:

  • Testeos de unidad (o módulo) – se trata de pruebas técnicas, a veces realizada por el desarrollador, para demostrar que los módulos de código individual o funciones performan correctamente
  • Testeos de integración – aseguran que los módulos funcionan correctamente juntos como un sistema en su conjunto. Esta fase puede incluir la verificación de las interfaces con otros sistemas, aunque las pruebas de la interfaz puede ser una fase separada.
  • Testeos de aceptación de usuario – esta fase confirma que las necesidades de los usuarios se han cumplido

Es aceptable tener cada vez mayor formalidad aplicada a fases de prueba en términos del grado de documentación de la prueba y las pruebas recogidas.
Informe de validación

El informe de validación resume las actividades de validación asociadas con el desarrollo del sistema. Contiene un resumen de las conclusiones de testeos e informes sobre otros requisitos de validación, por ejemplo, entrenamiento de usuarios y procedimientos actualizados. Proporciona recomendaciones para la aceptación del sistema. El Informe también presenta una estrategia para mantener el sistema en un estado validado. Cuando hay alguna excepción a los entregables requeridos por el plan de validación, éstas se detallan en el informe junto con una justificación. Cualquier acción a ser completada después de la implementación del sistema debe ser rastreada hasta su finalización.
El Informe de Validación debe ser aprobado antes de que el sistema entre en uso operacional.

Liberación / instalación

La liberación e implementación del sistema se basa en el cumplimiento de los entregables de validación y otros requisitos previos necesarios para la gestión del sistema. Estos pueden incluir: una construcción confirmada desde el sistema de gestión de configuración, los procedimientos de instalación, manuales de referencia técnica, manuales de referencia del sistema, manuales de operación del sistema, procedimientos de procesos, capacitación.
En el artículo II, desarrollamos, estrategia de mantenimiento y gestión del cambio, medidas de seguridad, firmas y registros electrónicos, e integridad de datos. para leerlo haga click aquí.

Además para aquellos interesados en el tema, le proponemos un Taller sobre el tema, consúltenos en info@cgmpdoc.com