BLOG para cGMPdoc.com

La revisión de los BRs de producción junto con la tendencia de los rendimientos y los desvíos son partes claves del proceso de QA para la elaboración de productos.

La revisión de BRs es típicamente una etapa de verificación que confirma la aceptabilidad del proceso de elaboración y empaque del producto. Si, de la revisión surge un desvío, el laboratorio gana información de valor desde la investigación que puede llevar a un CAPA y a la mejora del proceso.

Estas situaciones pueden ser detectadas antes que el rendimiento u otro parámetro exceda los límites de alerta o acción.

Debido a que es un proceso muy común, esta importancia puede ser pasada por alto más allá de los requerimientos regulatorios de las cGMP. Sin embargo la importancia de los registros está relacionada con el respaldo de la elaboración de los productos terminados.

Los requerimientos claves para el registro de la producción y control son encontrados en la subparte J del 21 CFR parte 211, la cual es una de las secciones más largas de la regulación cGMP de la FDA.

Hay un requerimiento cGMP para la confección de Master BR (21 CFR 211.186) identificando las etapas de elaboración / empaque de los productos. El MBR es usualmente la culminación de la transferencia tecnológica, scale up, lotes de validación, y la verificación de las etapas de manufactura alineadas con los requerimientos regulatorios.

El Batch Record, también llamado Batch Production Record o registro de producción del lote, es un documento que confirma el procedimiento paso a paso que los operadores o técnicos deben seguir para elaborar el producto.

Según el 21 CFR 211.188 “Un registro de producción y control de la producción del lote debe ser preparado para cada lote de producto producido y debe incluir información completa relacionada a la producción y control de cada lote”.

Cada BR es un documento controlado desde que es emitido hasta que puede ser eventualmente destruido.

Contiene la misma información que el master BR porque es una reproducción exacta del mismo que ha sido chequeado para su exactitud, fechado y firmado.

El registro del lote será ejecutado por varios operadores para documentar que cada etapa significativa en la manufactura, proceso, empaque o holding del lote fue cumplido.

Esto incluye entre otras cosas, lo siguiente:

• Fechas; cualquier firma además requiere tiempos
• Identidad de equipos individuales mayores y líneas utilizadas
• Identificación específica del lote de componente o material en proceso usado
• Pesos y mediciones de componentes usados durante el proceso
• Resultados de los controles en proceso y del laboratorio
• Inspección del área de elaboración / empaque / rotulado antes de su uso
• Una declaración del rendimiento actual y una declaración del porcentaje de rendimiento teórico para cada fase apropiada del proceso
• Registros de control de rotulados completos, incluyendo muestras o copias de todos los rótulos usados
• Descripción de los contenedores de producto y sus cierres / precintos
• Todo muestreo efectuado
• La identificación de las personas que efectuaron y supervisaron directamente o chequearon cada etapa significativa en la operación
• Cualquier investigación efectuada de acuerdo al 211.192
• Los resultados de las examinaciones hechas de acuerdo con el 211.134

Es destacado enfatizar que el “control” es el corazón de las cGMP y este control extiende a cada etapa crítica en el proceso de manufactura y empaque.

El BR para cada lote es una extensión de este control porque no es suficiente para liberar un producto para la venta hacerlo solo a partir de los resultados analíticos. Los datos de laboratorio deben confirmar los resultados esperados del proceso.

Cada lote ha sido elaborado con controles en proceso. El BR provee una documentación etapa por etapa de esos controles de la manufactura.

El BR completo se convierte en la verificación que todas las etapas críticas fueron efectuadas como estaban descriptas y cuando se combina con los resultados del laboratorio, la firma elaboradora tiene la documentación adecuada para efectuar la disposición del lote.

No nos olvidemos que en paralelo a estos requerimientos de las cGMP tenemos los de las BP de documentación.

Fundamentos del proceso de revisión:

Una vez que el proceso de empaque ha sido completado y que los registros han sido devueltos a la unidad de calidad quien registra tales documentos, el paso siguiente es la revisión de los BR para exactitud y conformidad de los estándares establecidos en los documentos.

Es recomendable, es más diría que hoy es un requerimiento, que sea efectuada una revisión del BR de manufactura o empaque por parte del equipo de manufactura o personal de empaque antes de regresar el registro del lote al departamento de QA.

El requerimiento regulatorio para BRR es hallado en el 21 CFR 211.192 y declara: “todo registro de producción y control de producto, incluyendo aquellos de empaque y rotulado, deben ser revisados y aprobados por la unidad de control de calidad para determinar su cumplimiento con todo lo establecido, aprobado en procedimientos escritos antes que el lote sea liberado o distribuido. Cualquier discrepancia no explicada (incluyendo un porcentaje de rendimiento teórico que excede el máximo o mínimo establecido en el Maestro de producción y los registros de control) o la falla de un lote o cualquiera de sus componentes para cumplir con cualquiera de sus especificaciones debería ser exhaustivamente investigada, haya sido o no distribuido el lote. La investigación debe ser extendida a otros lotes del mismo producto e incluso a otros productos que hayan podido ser afectados por la falla o discrepancia. Un registro escrito de la investigación debe ser efectuado y debe incluir conclusiones y seguimiento”.

Cada BR es típicamente específico para el producto y potencia del producto porque contiene las cantidades de API y excipientes requeridos. En el caso de comprimidos el Br puede indicar por medio de imagen o foto, o un dibujo, la descripción del tamaño, forma, color y cualquier estampado en relieve sobre el comprimido. Si el comprimido es recubierto, las letras sobre el comprimido y el color puede ser registrado.

En el caso de líquidos orales, pueden ser descriptos su color y aroma. Estos detalles pueden ser parte del MBR.

Así como la elaboración de productos es guiada por procedimientos y por los BR, la revisión del BR debe ser manejada a través de un SOP. A pesar que la revisión del BR puede ser menos complicada que la elaboración y empaque de productos, un SOP debería hacer que el proceso sea más consistente y disponer además de un check list para la revisión asegurará que las etapas y parámetros críticos sean revisados.

En un segundo artículo hablaremos sobre el SOP de BRR (revisión de BR) y su check list, correcciones de BR y algunas inconsistencias en la revisión de BRs.

Muchos cálculos son usados en el laboratorio. En muchos laboratorios la mayor parte de los cálculos se realizan por sistemas (ej. Empower ) y utilizando hojas de cálculo Excel, de manera de facilitar los cálculos.

Los cálculos utilizando Empower y las hojas de cálculo de Excel, las cuales contienen cálculos y macros utilizados para propósitos GMP deben estar Validadas.

Las hojas de cálculos no son modificadas por los usuarios, y las mismas son solo utilizadas para introducir datos, luego la hoja de cálculo final se imprime, se revisa y se firma y se conserva como evidencia y no se almacena electrónicamente con fines regulatorios.

La calificación consiste en comprobar que las hojas de cálculo están bloqueados adecuadamente para protegerla de cambio (ubicación de la red, protección con contraseña, acceso de solo lectura, el bloqueo de la células / hoja / libro, esto se verifica en las pruebas de IQ) y  la exactitud y confiabilidad apropiada de la hoja de cálculo es demostrada con las pruebas de OQ.

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.

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.

Este artículo tiene por objetivo adoptar los requisitos de la nueva guía de la EMA (European Medicines Agency) para determinar los límites de exposición de salud para su uso en la identificación de riesgos en la fabricación de diferentes productos medicinales en instalaciones compartidas

1. Criterios de aceptación para los residuos

La justificación científica para la determinación del ACQ para una limpieza se basa en la premisa de que la dosis diaria máxima de un producto no debe contener un nivel de residuos del producto anterior que pueda causar cualquier efecto adverso (farmacológico o toxicológico) si un individuo se expone a esa dosis todos los días durante toda la vida.

ACQ = (PDE) x (tamaño más pequeño del lote de producto siguiente)/(MDD del producto siguiente)

Donde:

ACQ (Acceptable Carryover Quantity): La máxima cantidad permitida de una sustancia monitoreada que puede ser arrastrada en el siguiente lote a elaborar.

PDE (Permitted Daily Exposure): una dosis de una sustancia específica que es improbable que cause un efecto adverso si un individuo es expuesto a esa dosis o menores dosis cada día durante toda su vida.

MDD (Maximun Daily Dose): la dosis máxima de una sustancia activa típicamente administrada a un paciente en un período de 24 hs.

• Datos para la PDE,

La fuente de la PDE se basará en todos los datos farmacológicos y toxicológicos disponibles, incluyendo tanto los datos clínicos y no clínicos.

La PDE debería ser revisada de forma rutinaria con una frecuencia no mayor a 5 años. Si la PDE cambiara como parte de esta revisión, el proceso de cleaning validation debe ser revisado y documentado a través de un control de cambio.

• Límites de aceptación para un equipo dedicado

La limpieza entre lotes de la misma etapa para el mismo producto (por ejemplo, varias granulaciones de un lote que luego se mezclan para su compresión) normalmente no es requerida, a menos que haya evidencia desde Desarrollo o Transferencia de Tecnología de cualquier problema (por ejemplo, degradación).

Una limpieza simple entre lotes durante una campaña de producción debe considerarse siempre que sea posible.

En ambos casos, deben ser establecidos límites de tiempo entre las limpiezas.

Donde la limpieza se lleva a cabo en un equipo dedicado, el mínimo criterio de aceptación es que el equipo esté visiblemente limpio.

Cuando se requieren fabricar lotes del mismo producto pero con diferentes dosis de API por lote, la dosis más baja debe producirse primero (menor a mayor). Esto es particularmente importante en la producción de formulaciones líquidas.

2. Determinación de los niveles de residuo

La superficie de muestreo (Prueba de hisopado) proporciona datos cuantitativos para los residuos de una superficie dada. Resultados de las pruebas de hisopo individual de diferentes partes del equipo dan lugar al residuo total medido (MC = Measure Carryover) para la comparación con el ACQ calculado para el cambio de producto.

El MC debe ser menor que el ACQ.

Los resultados de las pruebas Hisopo deben ser corregidos por el factor de recuperación determinado previamente.

• cantidad permitida para cada Hisopo

Partiendo del supuesto de una distribución uniforme del producto remanente en el equipo, es posible calcular la cantidad de producto que se obtendría por cada hisopo si la cantidad remanente es igual al ACQ.

Cantidad permitida por hisopo = ACQ x Superficie muestreada (por hisopo)/ Superficie total del tren de equipos

Si todos los resultados de hisopado están por debajo de esta cantidad permitida entonces el MC será menor que el ACQ y el equipo está limpio.

Cuando uno o más resultados de hisopado individuales son mayores que esta cantidad es entonces necesario calcular la MC para demostrar la limpieza. Es permisible para hisopos individuales resultados mayores que la cantidad permitida siempre y cuando el MC sea menor que el ACQ.

Es recomendable como una buena práctica que ningún hisopo individuo debe ser mayor que 10 veces la cantidad permitida para cada hisopo (para cubrir la incertidumbre en la toma de muestras y la determinación de arrastre), sin embargo, si se supera este valor x10, una investigación y evaluación debería llevarse a cabo .

• MC

La cantidad de residuos se calcula sumando los resultados de hisopados individuales multiplicado por el área de cada parte de cada equipo.

• Cómo sigo si el residuo total (MC) es mayor de lo permitido por la ACQ?

Si el proceso no está validado, debo efectuar una limpieza adicional y revisar el procedimiento de limpieza para su ajuste y validación. Toda actividad adicional debe ser documentada adecuadamente.

Si el proceso de limpieza está validado, debo iniciar un desvío para determinar la causa de la falla y el impacto debe ser investigado a fin de establecer si el proceso de limpieza tiene que ser cambiado y revalidado.

1.Plazos / puntualidad

–Tomar las acciones en un plazo de tiempo razonable, considerando el riesgo y la magnitud del problema.

2.Cada cosa es un hecho aislado

–Es esta la primera vez que sucede?

–Buscar información de eventos previos

–Considerar procesos similares

3.Causa raíz no identificada

–Falta de adecuado sistema de análisis de causa raíz

–Síntomas y factores casuales vs. causa raíz.

4.Corregir los síntomas en lugar de la causa

–Una simple pregunta, puede la corrección del síntoma evitar que vuelva a ocurrir la causa?

5.Falta de medidas correctivas provisionales

–Tomar acciones para mitigar el efecto de la causa raíz identificada mientras la acción permanente es implementada.

6.Causa raíz identificada, pero incorrecta

–Una simple pregunta: la acción correctiva propuesta (s) será capaz de solucionar todas la causas raíces identificadas?

7.Falta de acciones preventivas verdaderas

–Evaluar, analizar, investigar NO son acciones preventivas verdaderas.

8.Falta de verificación de la efectividad de las acciones tomadas

–Una simple pregunta : cómo sé que la CAPA evita la recurrencia / ocurrencia de una cauza raíz?.

9.Múltiples sistemas CAPA sin correlación.

–Desvíos, reclamos, auditorías, etc.?

10. Abuso de errores humanos y re-entrenamiento

Una de los temas que requiere una interpretación cuidadosa es la discusión sobre el promedio de los resultados de los ensayos, particularmente cuando hay resultados OOS y resultados que pasan.

Las agencias suelen encontrar en los laboratorios, situaciones donde el valor del ensayo reportado fue calculado usando ambos resultados (OOS y los que pasan), sin embargo los resultados de las pruebas OOS no deben ser ‘mezclados’ con los resultados de pruebas que pasan cuando el resultado reportado se calcula como el valor promedio.

Todos los resultados de los ensayos válidos, incluyendo OOS y los resultados que pasan, deben ser reportados de forma individual y cada resultado considerado en la decisión de disposición del lote.

Qué debemos hacer?

1. Cuando el resultado reportable final se calcula como un promedio de los resultados de pruebas individuales, compruebe que este cálculo no permite la ‘mezcla’ resultados OOS y los que pasan. Los resultados de los ensayos OOS deben ser visibles a la persona que toma la decisión de disposición del lote.
2. Verifique que la decisión de disposición del lote se toma con pleno conocimiento de todos los resultados de la prueba y que cualquier resultado de ensayo OOS válidos está considerado junto con los resultados del ensayo que pasan para la disposición del lote. Cuando se utilice un sistema LIMS para registrar y reportar los resultados del ensayo, asegúrese que se reportan todos los resultados.
3. En caso de Certificados de Análisis (CoA) que sólo permiten reportar un único resultado del ensayo:

• Compruebe que el sistema considera todos los resultados del ensayo – OOS válido y los que pasan – como parte de la decisión de disposición del lote.
• Si la decisión de disposición del lote es liberarlo, el único resultado informado es un promedio de los resultados de las pruebas que pasan. No incluya el resultado del ensayo OOS no confirmado o inválido en la determinación del promedio.

Para los interesados les dejo la posibilidad de un taller “In Company” sobre el manejo de resultados OOS, consulte en info@cgmpdoc.com

Si revisamos los nuevos lineamientos para la Validación de procesos, vamos a encontrar la etapa 3 correspondiente a la Verificación Continua del Proceso (VCP), cuya finalidad es: Demostrar que el proceso permanece en un estado de control.

Esto es un requerimiento para aquellos que actualmente exportan (o planean hacerlo) productos a USA o a la Comunidad Europea.

Para ello es necesario:

• Implementar sistemas que permitan detectar excursiones del proceso no previstas.
• Reunir y analizar la información y datos acerca del desempeño del proceso.

Para los interesados, les dejo una serie de preguntas, las cuales les permitirá autoevaluarse en cuanto al cumplimiento de estos lineamientos:

1. Tiene (en borrador o finalizado) un procedimiento para manejar la VCP?
2. Tiene (en borrador o finalizado) un procedimiento para análisis o tendencia de datos?
3. Elabora o empaca algún producto que tiene registrada la metodología VCP para el mantenimiento en curso del ciclo de vida de validación?
4. Calcula regularmente el Cpk (capacidad de proceso) para materiales, controles en proceso (IPC), parámetros críticos del proceso o atributos críticos de calidad (resultados de liberación)? Si sí, quién (qué role) efectúa dichos cálculos?
5. Confecciona regularmente Cartas / tendencias de materiales, controles en proceso (IPC), parámetros críticos del proceso o atributos críticos de calidad (resultados de liberación)? Si sí, qué role efectúa dichos tendencias?
6. Qué métodos de análisis estadísticos utiliza? (ej. Cartas de control Shewhart, Western Electric Rules, Cartas Cusum, cartas de rango móvil, etc.)
7. Qué herramientas de análisis estadísticos utiliza? (ej. CARS, CLIMB, Excel, Minitab, SAS, Quality Companion, etc.)
8. Qué job roles o departamentos revisan la capacidad de proceso y / o la tendencia de performance, y con qué frecuencia?
9. Cómo define cuáles parámetros monitorear?
10. Cómo define con qué frecuencia monitorear los parámetros?
11. Cómo se maneja ante la identificación de tendencias o cambio de una etapa?
12. A partir de que documentos o sistemas tendría que obtener los siguientes datos: atributos de materiales, parámetros críticos de proceso y atributos críticos de calidad (IPC o resultados de liberación).
13. Actualmente usa en su laboratorio un LIMS? Si no, qué sistema es utilizado para registrar los resultados de Control de Calidad (QC)?
14. Actualmente usa en su laboratorio las funciones de límites de alerta o tendencias de su LIMS?
15. Su laboratorio tiene un equipo de primera línea o individuos de apoyo técnico?
16. Su laboratorio actualmente tiene (o planea implementar) un sistema de recopilador de datos históricos? Ej. Wonderware, Aspentech
17. Su laboratorio actualmente tiene (o planea implementar) un sistema inteligente de procesos? Ej. Discoverant
18. Su laboratorio actualmente tiene (o planea implementar) un sistema de Batch Records Electrónicos?

Esperamos que el cuestionario les sea de utilidad y por último les dejo para quienes aún no hayan comenzado con este tema, un curso “In Company” sobre el tema:

Si bien algunas regulaciones no exigen un Plan Maestro de Validación (PMV) formal, como por ej. el Código Federal de Regulaciones (CFR) en USA, en nuestro País la Disposición 3827/2018 sí lo exige, y suele ser uno de los primeros documentos que los inspectores solicitan al auditar el laboratorio.

El PMV es una herramienta muy útil para documentar la forma en que las actividades de Validación son manejadas en el laboratorio.

Inicialmente el PMV debería definir la Política de Validación, la organización y el alcance de las actividades.

Podemos dividir al PMV en 3 principales secciones:

1. Inventario de los sistemas, considerando equipos, procesos, áreas, métodos, etc. Indicando cuáles de ellos deben ser validados y el nivel de validación de cada uno.
2. Agenda de las actividades de validación, la cual nos da el orden de acuerdo a prioridades, obviamente no podemos validar un proceso sino tenemos calificados los equipos que son utilizados en dicho proceso.
3. Actividades de mantenimiento del estado validado, se trata de las actividades de monitoreo de la performance de los sistemas. Un ejemplo de esto es confeccionar un reporte anual de monitoreo ambiental para zonas limpias validadas.

Además es importante mencionar en el PMV las referencias a las regulaciones que lo rigen y los procedimientos y documentos (protocolos y reportes) que serán escritos para cumplir con los requerimientos del PMV.

En el caso que un laboratorio que ya ha iniciado las actividades de validación y NO tiene un PMV, es recomendable escribir uno. Este PMV retrospectivo sería esencialmente un resumen formal de las actividades que están ejecutadas , como fueron ejecutadas y además listar las actividades pendientes.

La estrategia y el contenido del PMV refleja la aptitud de la organización para la Validación. El tiempo invertido en la confección de un PMV reporta en beneficios cuando el mismo es solicitado por los inspectores de las agencias regulatorias.

Planeamiento e implementación, paso a paso, de un sistema de gestión de Calidad.

Un sistema de Gestión de Calidad documenta las políticas y procedimientos que definen la manera que opera una empresa, con el fin de garantizar la calidad uniforme de sus productos o servicios. A continuación les dejo un flujograma donde se detallan los pasos necesarios para planificar e implementar un sistema de gestión de calidad. El punto de partida es designar un responsable de coordinar y llevar adelante el proceso de gestión de calidad . Esta persona debería estar firmemente comprometida con la organización y con la “Cultura de Calidad”, tener un buen manejo de equipos y cumplir con lo objetivos.

Hace tiempo incluimos un Check de verificación del estatus de CSV (Validación de sistemas computarizados) y parte 11 (Firmas y registros electrónicos), acá les dejo el link.

Este check que estamos incluyendo en este artículo intenta ser una guía para auditar el cumplimiento de CSV en el laboratorio (o en su proveedor). Esperamos que le sirva de ayuda.

1. Desarrollo del Sistema
   • Proveedores

• Verificar si hay un método para aceptar el producto, incluyendo los requerimientos técnicos y de calidad del producto.
• Verificar como los requerimientos técnicos y de calidad son considerados por el proveedor y/o sub contratado. ¿Hay un proceso definido? ¿El mismo es cumplido?
• En el caso de sub contratar actividades, verificar la experiencia y calificación del mismo (por ej. verificar entrenamientos o certificaciones).
• Si la evaluación del proveedor involucró una auditoria, verificar el estatus de los hallazgos.
• ¿Dispone de un procedimiento para la evaluación de proveedores?, ¿dicho procedimiento es seguido?
• Si el Sistema es provisto por un proveedor, verificar si el mismo ha sido evaluado.
• Verificar si el Sistema fue elaborado “In House” o desarrollado por un proveedor.
  • Requerimientos
• Verificar que todos los requerimientos GMP del proceso, incluyendo la parte 11 (firmas y registros electrónicos) han sido incluidos.
• Verificar que los requerimientos son revisados y aprobados por los departamentos apropiados, incluyendo como mínimo responsable del proceso de negocios y al responsable de QA.
  • Diseño y codificación
• Verificar que existe un documento de diseño cubriendo todos los requerimientos del usuario y la trazabilidad entre los requerimientos y los elementos del diseño.
• Verificar que la especificación de diseño es revisada y aprobada por los departamentos apropiados.
• Confirmar que la especificación de diseño fue aprobada antes de que el codificado comience.
• Confirmar que existe un estándar de codificado (por ej. Java, etc.). En caso de no haberlo, debe haber una justificación adecuada.
• Verificar que la revision de código fue efectuada.
• Determinar si todo el código es revisado o si es revisado una muestra, en éste ultimo caso, determinar como fue seleccionada la muestra.
• Confirmar que los revisores de código son independientes y están adecuadamente calificados.
• Confirmar que los defectos encontrados durante la revisión son corregidos y las acciones correctivas tomadas para evitar su re ocurrencia.
  • Testeo
• Revisar la documentación de testeo asociada con el Sistema a auditar.
• Verificar que existe una estrategia de testeo explicando los testeos efectuados en cada etapa de desarrollo (ej. Testeos de módulo, testeo de integración, testeos de interface) y testeos de aceptación.
• Confirmar a través del proceso de testeo que los requerimientos funcionales críticos han sido testeados.
• Verificar que los testeos cubren condiciones límites, fallas y estrés, así como pruebas diseñadas para confirmar que el sistema funciona como se espera. Además, que incluye el control de seguridad de accesos lógicos.
• Verificar que los testeos sean efectuados por personal independiente y calificado (el desarrollador y el autor de los ensayos).
• Confirmar que los scripts de testeo están escritos, y que los mismos contienen claramente los criterios de aceptación.
• Verificar que los resultados de los ensayos han sido documentados y se dispone de la evidencia adecuada. Donde hay desvíos los mismos son documentados.
• Verificar que el test que falló ha sido evaluado respecto de la criticidad del requerimiento funcional.
• Verificar que cuando un test ha fallado la funcionalidad requerida no es crítica para el proceso ni para el cumplimiento GMP. Confirmar que existe una solución de procedimiento adecuada.
• Si es utilizada una herramienta automatizada para los testeos, verificar que la misma ha sido calificada para asegurar que funciona correctamente, que hay procedimientos para su uso, que las firmas de las aprobación de los scripts de testeos son registradas y que los cambios a la herramienta o scripts electrónicos son controlados y aprobados.
  • Entregables de Validación
• Verificar que hay un conjunto de documentos de validación consistente con una clara relación de los mismos a los requerimientos.
• Verificar que los entregables de validación son declarados en el plan de validación, han sido completados y están resumidos en el reporte de validación.
• Verificar que las excepciones (si aplica) del reporte de validación han sido registradas como acciones para su seguimiento.
  • Liberación
• Revisar como es liberado el Sistema para el uso.
• Verificar los controles y chequeos utilizados para asegurar que todas las actividades fueron completadas.
• Verificar que los roles y responsabilidades para la liberación están claras y se han cumplido.
• Verificar que todos los entregables requeridos fueron parte del paquete de liberación, por ej. un código de construcción del Sistema, certificado de liberación, manuales de uso, material de entrenamiento.

2. Gestión del sistema
   • General

• Establecer como es provisto el soporte al Sistema, confirmar que los roles y responsabilidades del hepdesk, de los administradores y soporte técnico están claramente definidas. Asegurar que el entrenamiento adecuado para cada rol fue suministrado.
• Verificar que el Sistema tiene un propietario que lo maneja con suficiente autoridad y con un presupuesto para su mantenimiento.
  • Manejo de problemas
• Confirmar que hay un procedimiento vigente para el reporte de problemas, con registro, investigación y resolución de los mismos.
• Verificar que las acciones correctivas y preventivas son implementadas.
• Verificar que hay una relación entre el reporte de incidentes y la gestión de cambios para el Sistema.
  • Gestión de cambio
• Asegurar que los procedimientos para iniciar, autorizar y documentar los cambios del Sistema están vigentes.
• Confirmar que los cambios son evaluados para asegurar que el impacto sobre las funcionalidades relacionadas es entendido.
• Asegurar que la gestión de los cambios incluye la actualización de la documentación del Sistema, instrucciones de uso, entrenamiento, datos maestros como la funcionalidad técnica.
• Asegurar que los testeos hechos como soporte de los cambios del Sistema confirman que las funciones relacionadas no son adversamente afectadas y además aseguran que los cambios requeridos son alcanzados.
  • Accesos y seguridad
• Revisar que las medidas de seguridad físicas están definidas para el Sistema y están en uso efectivo. Verificar como son controlados los accesos físicos al hardware.
• Revisar que las medidas de seguridad del software están definidas para el Sistema. Verificar como son controlados los accesos a las funcionalidades críticas son restringidas a los usuarios apropiados. Verificar que donde la capacidad de enmendar datos maestros ha sido restringida.
• Verificar la existencia de un procedimiento para otorgar y remover los accesos al Sistema de los usuarios. Verificar que los accesos son revisados periódicamente para asegurar que solo tengan acceso al Sistema los usuarios requeridos.
• Asegurar que los ambientes de desarrollo, de testeo y productivo son rutinariamente revisados en búsqueda de virus.
• Determinar si los elementos del Sistema tales como Sistema operativo, base de datos y aplicaciones del software son mantenidos con los últimos parches de seguridad disponibles.
  • Datos maestros
• Asegurar que existe un proceso para el mantenimiento de los datos maestros requeridos por el Sistema.
• Confirmar que los roles y responsabilidades están claras respecto a la gestión y aprobación de datos maestros.
• Verificar si los datos maestros son chequeados periódicamente para verificar su exactitud.
  • Planeamiento de Business Continuity /Disaster Recovery (incluyendo back up y recuperación)
• Verificar que el Sistema tiene un plan de continuidad del negocio (BC), y que el mismo tiene en cuenta la criticidad del sistema.
• Verificar que el Sistema tiene un plan de disaster recovery (DR), y que el mismo tiene en cuenta la criticidad del sistema.
• Verificar que existe un régimen de back up y recuperación para el Sistema y que el mismo está documentado, mantenido y testeado. Verificar si el mismo tiene en cuenta la criticidad del Sistema.

3. Revisión periódica

• Verificar que el Sistema es sujeto a revisiones periódicas para determinar que actividades tienen que ser efectuadas para mantener el estado validado.
• Confirmar que los resultados de la revisión son registrados y cualquier acción es seguida hasta que se complete.