Posts tagged ‘URS’

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.

Si miramos las observaciones de las agencias como la FDA y la EMA, la validación de procesos y la calificación de equipos están dentro del top ten de deficiencias encontradas. Además de deficiencias relacionadas con el diseño de locales y equipos, y pobres instrucciones sobre calibración, limpieza y mantenimiento de los equipos.

¿Cómo podemos llevar a cabo una calificación que cumpla con las cGMP y, además sea eficiente?

Matthias Klein de CSL-Behring, reconoce que la clave del éxito radica en el uso eficiente de los documentos y procesos existentes (incluidos los sistemas de control de cambio y calibración) en las compañías farmacéuticas. La minimización del gasto también es posible aplicando de manera consistente las GPE de acuerdo con la Guía de referencia del ISPE sobre commissioning y calificación como un concepto de calificación integrado. Podemos mencionar los documentos de pruebas de aceptación de fábrica (FAT) o las pruebas de aceptación del sitio (SAT). Estas pruebas efectuadas por personal capacitado, y documentadas adecuadamente, nos permitirá evitar la duplicación de trabajo.

Para una efectuar una calificación eficiente y pragmática debemos usar el análisis de riesgos del proceso de manera apropiada (la ICH Q9 da los lineamientos y una serie de herramientas, entre las que mencionamos el FMEA).

El análisis de riesgos apropiado reduce aún más el esfuerzo de calificación.

Un análisis de riesgo general es la base para la calificación de diseño (DQ). Los componentes relevantes para la calificación son identificados y el grado de la calificación se determina mediante un análisis detallado del riesgo. El análisis de riesgo también debe considerarse durante el curso de la calificación y en la operación de rutina.

Durante el proyecto de calificación, el control de cambios se puede manejar de manera casi pragmática.

Las razones para las pruebas de calificación se cuestionan cada vez más en el contexto de las inspecciones y auditorías en las que el concepto integrador y una matriz de trazabilidad adecuada pueden garantizar que solo se realicen las pruebas que provienen del análisis de riesgos.

En cuanto a la recalificación ahora se requiere una evaluación periódica de los locales, sistemas, equipos y servicios en relación con el estado de calificación. También se deben evaluar pequeños cambios. La frecuencia de esta evaluación debe ser justificada.

La Guía de la FDA ya no contiene el término revalidación. Con el enfoque del ciclo de vida, el tema continúa en la etapa 3 Verificación continua del proceso, cuyo objetivo es mostrar que el proceso permanece en un estado validado durante la producción de rutina. Para este propósito, se solicita un sistema que detecte desviaciones de proceso no planificadas. El proceso no debe salirse de control. Aquí se hace una referencia directa a la Revisión Anual del Producto (21 CFR 211.180) para apoyar este programa en curso. Y se atribuye gran importancia a las estadísticas.

¿Y el futuro?

El ISPE y la ASTM (Sociedad Americana de Pruebas y Materiales) apuntan a una “calificación de valor agregado”. Debemos enfocarnos en las especificaciones de requisitos del usuario (URS) y la Calificación de proceso (PQ).

El ISPE resume los “Principios para la Calificación del Siglo 21” en diez puntos, que es un excelente resumen de los principios descritos en la norma ASTM E2500:

  1. Enfoque en la calidad del producto.
  2. “Requisitos del usuario” basados en el proceso. Se confirman como satisfechos en el PQ (IQ y OQ están subordinados en importancia).
  3. “Evaluaciones de riesgo”: el desarrollo del proceso y el diseño experimental son los elementos clave para identificar funciones y parámetros críticos.
  4. Solo se utilizarán los parámetros críticos del proceso como base para la calificación.
  5. Todas las actividades deben aportar valor al proceso (“No haremos nada solo por el cumplimiento de la normativa”).
  6. Actividades de calificación basadas en el riesgo. Ej. clasificación GAMP.
  7. “Documentos de valor agregado”.
  8. Uso de la documentación del proveedor, si es posible.
  9. Pruebas: por regla general, deben realizarse una sola vez. Pero puede ser necesario repetir algunas pruebas que se han llevado a cabo en una etapa anterior del desarrollo.
  10. Fomento de la innovación: se requiere la flexibilidad de los programas de calificación para poder implementar nuevas tendencias.

Todo esto requeriría grandes cambios organizativos en las empresas (probablemente uno de los mayores obstáculos) que a menudo tienen conceptos relativamente rígidos de calificación y validación.

El riesgo para la calidad del producto se deberá basar en el conocimiento del proceso.

Este proceso tiene lugar bajo el paraguas de las Buenas Prácticas de Ingeniería y sobre la base de la gestión de riesgos, la gestión de cambios y la revisión del diseño. El input al proceso es el conocimiento del producto, el conocimiento del proceso, los requisitos reglamentarios y los requisitos de calidad de la empresa.

El output esperado, es la operación y la mejora continua.

En la Guía de Validación de Procesos de la FDA, las actividades de calificación son parte de la Etapa 2 del ciclo de vida de validación del proceso de calificación del proceso. Los términos DQ, IQ y OQ ya no se usan en el documento. Esto es consistente con la Guía Estándar ASTM E2500 y GAMP 5. Ambos documentos se abstienen de usar estos términos y los sustituyen por “verificación”. La intención es dejar claro que las prácticas de la industria de DQ, IQ y OQ, etc. no son un requisito reglamentario y fomentar una aplicación más sólida de las Buenas Prácticas de Ingeniería (GEP).

La revisión del Anexo 15 va en la dirección de las GEP y el FAT y SAT, y si bien menciona etapas de calificación como DQ, IQ, OQ, PQ las mismas no son obligatorias.

De acuerdo a la Guía de Validación de Procesos de la FDA los lotes de la Calificación de Rendimiento del Proceso (PPQ), deben ser llevados a cabo por empleados de producción calificados utilizando instalaciones y equipos calificados; bajo las condiciones de fabricación comerciales y, en última instancia, pueden ser lanzados como lotes comerciales normales, dependiendo de un resultado de Calificación de Proceso global exitoso.

De acuerdo a la FDA “Una PPQ exitosa confirmará el diseño del proceso y demostrará que el proceso de fabricación comercial funciona como se esperaba”. Por lo tanto, la terminación de PQ antes de la comercialización es obligatoria.

La FDA considera PPQ en el sentido del documento PIC / S PI 006. Ha igualado PQ y la validación de procesos desde 1996. En el Anexo 15 revisado, PQ y Process Validation se pueden combinar.

Conclusión

El futuro de la calificación parece residir en una calificación aún más integrada que involucra a ingenieros y calificadores, en un proyecto estructurado basado en el análisis de riesgos e involucrando la mayor cantidad posible de documentos GEP. Las pruebas de los preceptos URS en el PQ serán la base para las principales pruebas de calificación. Seguramente el nuevo modelo de “verificación” de la norma ASTM E2500 reemplazará las etapas de calificación clásicas.

El futuro de la validación estará enfocado en la comprensión del proceso. Las estadísticas serán útiles para apoyar estos aspectos.

En Europa, el enfoque “tradicional” seguirá estando disponible como se indica en la Guía de la Validación de Procesos de la EMA y en el Anexo 15 revisado. Este enfoque tradicional ya no se menciona en la Guía de la FDA.

¿Qué hay de los productos heredados (productos antiguos)? La FDA dice que comienza con la etapa 3 “Verificación continua del proceso”. En el Anexo 15 revisado no hay pistas sobre productos heredados, aunque el enlace a PQR indica que los productos heredados también están en el foco de la verificación del proceso en curso.  El enfoque de EMA es muy intensivo en la “verificación continua del proceso” ahora, más que en la Guía de la FDA.

Hasta ahora, a menudo se consideraba que la PQ estaba relacionada principalmente con el equipo. La perspectiva cambió en la guía de la FDA, con la nueva expresión PPQ como parte de PQ (ahora conocida como Calificación de rendimiento del proceso).

Tomado de: ECA Validation Good Practice Guide

El ISPE nos da algunos principios para efectuar las actividades de calificación:

  • Enfoque en la calidad del producto: la calidad del producto debe ser garantizada por las actividades de calificación.  
  • Requisitos: el URS debe basarse en el proceso y esto se confirma en el PQ (calificación de performance). Esto significa que tanto el IQ como el OQ están subordinados en importancia.
  • Evaluaciones de riesgo: el desarrollo del proceso y el diseño experimental son los elementos clave para identificar funciones y parámetros críticos, los cuales serán la base para las actividades de calificación.
  • Actividades basadas en el riesgo, las mismas dependerán de la complejidad de la instalación (ej. Clasificación GAMP) y deben agregar valor a la calificación. No deberíamos incorporar solo actividades por el hecho de hacer volumen de documentación.
  • Uso de la documentación del proveedor: Si es posible.
  • Pruebas: por regla general, las pruebas deben realizarse una sola vez.
  • Fomento de la innovación: en este punto, se requiere la flexibilidad de los programas de calificación para poder implementar nuevas tendencias.

Todo esto requiere grandes cambios organizativos en las empresas (quizás es una de las partes más difíciles), que a menudo tienen conceptos relativamente rígidos de calificación y validación.

La gestión de calidad se centraría más en los procesos y análisis de riesgo, los planes de calificación y los informes de calificación. Por otro lado, también sería necesario fortalecer los sistemas de calidad de los departamentos especiales (por ejemplo, Ingeniería, IT, etc.) y la producción. El riesgo para la calidad del producto se determinaría en el contexto de una divulgación de riesgo sobre la base de la comprensión del proceso. El control de esos riesgos se calificaría entonces en la calificación de la performance.

En este artículo quiero mencionarles algunos problemas en la validación de los sistemas computarizados que es muy probable verlos una y otra vez.

Nuestro objetivo es que al abordar estos desafíos de validación, si Ud. los considera se ahorrará tiempo, dinero y dolores de cabeza.

Pero mencionemos algunos de ellos:

  1. Falta de información

Algunos documentos o registros omiten información fundamental o contenido que debería haber sido incluido.

  1. Inconsistencia

Algunos documentos contienen ciertas declaraciones inconsistentes con otras declaraciones acerca del mismo tema, en el mismo o en otro documento del paquete de validación.

  1. Falta de detalles necesarios

Esta deficiencia se aplica principalmente a los documentos de requerimientos. Los requerimientos del paquete de validación no describen adecuadamente las características de los datos, las interacciones de los usuarios con los procesos de negocio o los procesos claves internos del software.

A veces los requerimientos son compuestos, no son únicos, por ejemplo una declaración estipula 2 o más características del sistema. Esta deficiencia o falla frecuentemente trae aparejado problemas de trazabilidad.

También podes mencionar la falta de criterios de aceptación.

  1. Trazabilidad:

La matriz de trazabilidad está incompleta. Los detalles de los requisitos no se numeran explícitamente y se relacionan a las etapas de prueba asociadas

  1. Vaga redacción o texto ambiguo

Los documentos usan generalidades tales como “de acuerdo con un procedimiento aprobado” o “requisitos reglamentarios aplicables” o “todos los GxP y procesos de negocio asociados”. Además, los documentos utilizan palabras vagas como “puede”, “posiblemente”, “más o menos”, y “aproximadamente”.

A veces el texto puede ser interpretado de más de una manera, por lo que no estableció un requisito único y único. Las palabras “cualquiera” y “o” en el requisito son fuertes indicadores que el texto es ambiguo.

  1. Resultados de las pruebas no verificables

Los resultados esperados no son suficientemente descriptos para que un revisor independiente pueda comparar y verificar los resultados reales. El estándar IEEE para documentación de prueba de software, std. 829.1988, la cláusula 6.2.4 (1) establece “… proporcionar el valor exacto (con las tolerancias cuando sea apropiado) para cada salida o característica requerida”. Para los scripts ejecutados, los resultados reales no fueron registrados ni capturados de manera que permitiera a un revisor independiente compararlos con los resultados esperados. Por ejemplo, “OK” se anotó en la columna de resultados reales sin referencia a la captura de pantalla.

  1. Buena práctica de documentación (BPD)

Registros poco claros, a veces los datos que confirman un requisito específico son difíciles de encontrar en la evidencia proporcionada (por ej. Una planilla llena de datos pero no está clara la evidencia), fallas en la corrección de errores documentales.

Se hacen correcciones escritas a mano que cambian el sentido del requisito o el resultado esperado de la prueba, pero no se presenta informe de discrepancia o solicitud de cambio (ej. Cambio de un resultado esperado del indicador “Off” a “On”). En las BPD, se siguen las correcciones de la mano sin documentación adicional solo cuando se trata de un obvio error tipográfico, como letras que faltan o están transpuestas (ej. Corrección “mantenimeinto” a “mantenimiento”)

  1. Pruebas incompletas:

Los scripts de prueba no prueban completa o adecuadamente el requisito asociado.

  1. Requerimientos incompletos:

El análisis del sistema indica que el software tiene funcionalidades que fueron usadas pero NO han sido descriptas en el URS.

Análisis de impacto regulatorio y análisis de riesgo indican la necesidad de requerimientos que no están en el URS.

Un requerimiento implica otro requerimiento, posiblemente complementario, que necesita ser explicitado para asegurar su verificación.

  1. Falta de 1 proceso para resolver desvíos

Los documentos y registros más vulnerables:

  • Especificaciones (incluyendo el URS) las más frecuentes
  • Scripts de testeo
  • Plan de validación
  • Matriz de trazabilidad
  • Resultados de testeos

Menos problemas relacionados a CSV conducen a una inspección exitosa.

Control de cambios es un término común para describir el proceso del manejo de cómo los cambios son introducidos dentro de un sistema controlado.

La mayoría de los problemas de los softwares y sistemas computarizados son introducidos cuando son efectuados cambios durante el uso de los mismos. El control de cambios es requerido para asegurar que los sistemas validados permanecen bajo control aun cuando son sometidos a cambios.

La falta de documentación y pobres testeos después de los cambios son unas de las principales observaciones de las auditorías. De ahí la importancia de disponer de un sistema de control de cambios robusto.

El proceso de control de cambios

cambio

Los sistemas computarizados no son estáticos y requieren un programa de mantenimiento robusto luego de la validación inicial. Un procedimiento de control de cambios es crítico para asegurar que los cambios son evaluados, documentados, efectuados y seguidos consistentemente a lo largo de su ciclo de vida. Este procedimiento define el proceso a seguir para evaluar la implementación de los cambios.

El proceso de control de cambios está típicamente definido por medio de la propuesta de necesidad de un cambio, la aprobación del mismo, la ejecución del cambio y la aprobación final de todas las actividades y el cierre del control de cambio.

Veamos cada una de las etapas:

  1. Cambio propuesto: el solicitante del cambio efectúa el requerimiento formal del mismo, el cual necesita ser evaluado para asegurar que es apropiado y que el cambio propuesto no impactará negativamente sobre otros aspectos o capacidades del sistema.

El cambio debe ser clasificado, por ej. de emergencia, de rutina, etc. Algunos cambios no esenciales pueden ser reunidos y ejecutados de manera conjunta. Esta clasificación indicará el ritmo de implementación y las actividades asociadas. Es esencial que el procedimiento de control de cambios provea una vía expeditiva para los cambios de emergencia. Estos cambios, frecuentemente son necesarios para corregir problemas en el software o reestablecer operaciones del proceso rápidamente. Si bien los cambios deben ser completados en un período de tiempo muy corto, deben ser implementados de forma controlada. Los cambios de emergencia deben estar sujetos a controles similares a los cambios de rutina. Sin embargo el proceso puede ser relativamente abreviado para el requerimiento del cambio, su evaluación y aprobación para asegurar que los cambios queden hechos rápidamente.

Siempre que sea posible, los cambios de emergencia deben ser testeados antes de la implementación.

Si IT no está plenamente disponible para testear las modificaciones de emergencia antes de su instalación, es crítico que se disponga de apropiados back up de archivos y programas, como también tener un plan de back out in place.

  1. Aprobación y planeamiento: Un equipo multifuncional debe determinar como el cambio podría afectar al sistema antes que el cambio sea efectuado. Este equipo debe incluir al menos al Propietario del sistema, Aseguramiento de Calidad e IT. Dependiendo del análisis de riesgo del cambio, el nivel y rigor de la documentación y los testeos a efectuar.

La aprobación para avanzar con el cambio debe ocurrir antes que cualquier cambio en el sistema sea efectuado.

En el caso de cambio de emergencia (situación urgente) un cambio podría ser aceptado antes de completar el proceso formal del control de cambio. Sin embargo, el mismo debe ser documentado de la misma forma de acuerdo a lo indicado en el procedimiento de control de cambios.

La decisión sobre si aceptar o rechazar un cambio podría ser basada en una serie de preguntas:

  • El cambio es inevitable?
  • El cambio aumenta el beneficio general de la organización?
  • El equipo está disponible para hacer tal cambio?
  • Es mejor hacer el cambio ahora o puede ser mejor diferirlo?
  • El cambio impactará otras áreas o sistemas?

La determinación del impacto ayudará a definir el nivel de testeos requeridos para el sistema.

Adicionalmente la matriz de trazabilidad (MT) es un documento que vincula formalmente los requerimientos de diseño y los testeos a través del proceso de validación.

El análisis de regresión podría indicar la funcionalidad que requiere testeos de regresión así como también un racional sólido para excluir aquellas funciones que no son impactadas por el cambio.

Los siguientes documentos deben ser evaluados para el impacto potencial debido al cambio y sus actualizaciones deberían ser planeadas si son requeridas;

  • Paquete de validación incluyendo URS, especificación de requerimiento técnico (TRS), TM, DQ, IQ, OQ, PQ y plan y reporte de validación
  • Procedimientos para el uso y mantenimiento del sistema

Los cambios deben ser planeados y ejecutados mínimamente involucrando a IT y QA y al propietario del sistema o del negocio. Los cambios deben ser comunicados a todas las áreas y funciones afectadas.

  1. Ejecución del cambio: el cambio es en esta etapa efectuado en un entorno de testeo de manera que puede ser testeado antes de la implementación en productivo. El cambio (y otros aspectos del sistema que pueden haber sido afectados) es testeado para asegurar la exactitud del sistema, confianza y asegurar una performance consistente acorde a su propósito.

El ensayo debe ser documentado y los resultados deben conducir a correcciones y testeos adicionales o confirmar que los resultados finales después del cambio son lo que se pretendía. La documentación asociada con el cambio debe ser además completada.

Los cambios deben ser inicialmente implementados lejos del entorno de producción del sistema validado. Esto asegurará que no son efectuados cambios en el entorno de producción hasta que ellos han sido completamente validados y funcionan bien.

En relación a los sistemas computarizados es recomendable tener algunos entornos virtuales como por ejemplo:

  • Entorno de desarrollo (a veces se lo llaman “sandbox” o arenero), un entorno virtual donde un código / configuración experimental toma lugar, como el configurador / desarrollador está probando diferentes soluciones haciendo testeos preliminares, etc.
  • Sistema de testeo, un entorno virtual usado para testear preliminares del sistema conducidos por IT.
  • Validación, un entorno virtual que está congelado y es representativo de producción, seteado para el testeo de validación y controlado y NO modificable a lo largo de los testeos de validación.
  • Entrenamiento, no siempre usado por todos las compañías para todos los sistemas, un entorno virtual usado para manejar entrenamientos sobre un sistema nuevo o revisado.
  • Producción, es el entorno del negocio vivo o “instancia” del sistema.

El testeo debe verificar lo siguiente:

  • La performance del sistema luego que los cambios son efectuados y que los nuevos cambios no introducen errores que mantienen el sistema fuera de la performance buscada.
  1. Aprobación final / implementación del cambio: la aprobación final para liberar la nueva versión a productivo es concedida basada sobre los resultados de testeos exitosos y luego de disponer del paquete documental completo.

Si es requerido entrenamiento, el personal afectado (por ej. Usuarios, super-users, soporte de IT) deben ser entrenados antes que ellos estén notificados para el uso del sistema o antes de la implementación del sistema en el entorno productivo.

La aprobación final es típicamente concedida por medio del propietario del sistema y aprobada por personal autorizado de QA e IT.

La nueva versión del sistema es entonces liberada para el entorno productivo.

Cuando en una auditoría es incluida la inspección de cualquier sistema computarizado utilizado para un propósito regulado, los inspectores revisan típicamente la documentación del sistema, incluyendo los registros de los cambios, como fueron evaluados y la documentación de los mismos.

Resumiendo:

El proceso de control de cambios es importante para asegurar y evitar potenciales riesgos del negocio. Un proceso de toma de decisión objetivo debe ser usado para determinar el nivel y la complejidad de los cambios propuestos. El nivel del impacto que el cambio podría tener debe ser además determinado y esto nos indicará la profundidad de los testeos y  documentación requerida.

Un proceso de control de cambios es necesario para prevenir inapropiadas modificaciones o modificaciones que conducirán a efectos adversos. Un control de cambio efectivo es un aspecto importante para mantener el estado validado de los sistemas, permitiendo continuas mejoras y previniendo gaps de compliance.

  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

La validación es mandatoria para los sistemas GxP.

El nivel de la validación dependerá de la configuración del software y de cómo el proveedor diseñó, desarrolló y testeó el sistema computarizado (hardware y software).

La evaluación del proveedor y la categoría del software (de acuerdo a la GAMP5) son claves en el proceso de análisis de riesgo e influenciarán en la determinación de cuanto esfuerzo será requerido para la validación del sistema computarizado.

Les dejo los flujogramas propuestos para las actividades de validación de las categorías 3, 4 y 5, de acuerdo a la GAMP5 (2008).

Flujograma para un sistema de categoría 3.

Vmodel_cat3

Flujograma para un sistema de categoría 4 (adaptado).

Vmodel_cat4

 

Flujograma para un sistema de Categoría 5 (a medida).

Vmodel_Cat5

 

¿Qué tipos de sistemas computarizados debemos considerar?

En principio los relacionados a las actividades de controles del proceso, los relacionados al laboratorio, las aplicaciones de IT y lo relacionado a infraestructura.

Espero que les haya resultado interesante.