Posts tagged ‘Validación de sistemas computarizados’

Como usualmente solemos decir, la validación de los sistemas computarizados GxP es requerida para asegurar que cumplimos con las regulaciones, y además para demostrar que son adecuados para su propósito de uso.

Previo a la puesta en uso y nuevamente cuando hay cambios en el SC, la validación puede ser intensa en cuanto al tiempo y los recursos necesarios. Frecuentemente el mismo rigor es aplicado a todos los cambios en los SC, independientemente del impacto potencial, esto provoca un ahogo que puede llevar a tener SC estancados y un GAP creciente entre las soluciones y las necesidades de los usuarios del SC o del negocio.

Los vendedores actuales han reducido la carga de validación por medio de las ejecuciones de IQ y de OQ y/o proveer la documentación, sin embargo algunas soluciones en la nube tienen actualizaciones frecuentes y mandatorias.

Un proceso de gestión de cambio optimizado (basado en el riesgo) puede hacer que los sistemas se mantengan vigentes. Este enfoque consistente, permitirá reducir tiempos y esfuerzos.

Para esto es fundamente que el entrenamiento (conocimiento) del proceso de cambios sea adecuado.

Aplicaciones GxP en la nube.

La popularidad de aplicaciones basadas en la web, dispositivos inteligentes, usuarios están listos, hace que tengamos un ritmo constante de release de actualizaciones, introduciendo cambios más frecuentes que en el pasado. Por tal razón, es fundamental disponer de un proceso para el manejo de los cambios de los sistemas.

Las características de las aplicaciones de la nube tienen un impacto significativo en la validación de las organizaciones y en la estrategia de control de cambios.

En general hay dos tipos de opciones en la nube:

•           Hosted (alojado)

•           Multitenant (multiinquilino)

Una diferencia fundamental entre ambas es como sus vendedores gestionan y entregan las nuevas versiones de sus aplicaciones a sus clientes.

Hosted Cloud (HC)

Con este tipo de aplicaciones cada cliente tiene su propio software y un enfoque tradicional es usado para proveer una nueva versión.

El vendedor notifica al cliente cuando un nuevo release está disponible y el cliente decide si quiere la nueva versión, y cuando el vendedor debería efectuar la actualización.

Después de la actualización, son efectuadas las actividades de validación y su liberación para uso productivo.

No todos los clientes actualizan la última versión de un HC al mismo tiempo y alguno nunca lo hacen. Como resultado de esto, los vendedores de aplicaciones en la nube deben soportar múltiples versiones de sus aplicaciones.

Multitenant Cloud (MC)

En este modelo, múltiples clientes usan una versión única del software y coexiste sobre una infraestructura de IT compartida.

Se entrega una nueva versión del software para todos los clientes al mismo tiempo sobre una agenda predefinida por el vendedor. Como resultados de esto, cada cliente está siempre con la última versión de la aplicación y no hay viejas versiones para que el vendedor soporte.

Los clientes son notificados con anticipación cuando una actualización tomará lugar. Luego son efectuadas las actividades de validación y su liberación para uso productivo.

En este punto es de suma importancia trabajar con proveedores aprobados y disponer de un acuerdo de calidad.

La expectativa es la existencia de un proceso de cambio robusto, que nos permita mantener el estado validado de nuestros sistemas computarizados GxP y no comprometa la calidad del “producto” del sistema.

Los datos contemporáneos son datos registrados en el momento en que se generan u observan.

Expectativas para registros en papel

El registro contemporáneo de las acciones en los registros en papel debe realizarse, según corresponda, mediante el uso de:

  • procedimientos escritos, y capacitación y revisión y controles de auditoría y autoinspección que garanticen que el personal registre las entradas de datos y la información en el momento de la actividad directamente en los documentos oficiales (por ejemplo, cuadernos de laboratorio, Batch Records, etc.);
  • procedimientos que requieren que las actividades se registren en registros en papel con la fecha de la actividad (y también la hora, si es una actividad urgente);
  • buen diseño de documentos, lo que fomenta las buenas prácticas: los documentos deben diseñarse adecuadamente y debe garantizarse la disponibilidad de formularios / documentos en blanco en los que se registran las actividades;
  • registro de la fecha y hora de actividades utilizando fuentes de tiempo sincronizadas (instalaciones y relojes computarizados del sistema) que no pueden ser modificados por personal no autorizado. Siempre que sea posible, el registro de datos y tiempo de las actividades manuales (p. ej., Pesadas) debe realizarse automáticamente.

Expectativas para registros electrónicos.

La grabación contemporánea de acciones en registros electrónicos debe ocurrir, según corresponda, mediante el uso de:

  • ajustes de configuración, SOP y controles que aseguran que los datos grabados en la memoria temporal se envíen a medios duraderos al completar el paso o evento y antes de pasar al siguiente paso o evento para garantizar la grabación permanente del paso o evento en el momento en que se realiza;
  • fecha / hora segura del sistema que el personal no puede modificar;
  • procedimientos y programas de mantenimiento que aseguran que la hora / fecha esté sincronizada en las operaciones GXP;
  • controles que permiten determinar el momento de una actividad en relación con otra (por ejemplo, controles de zona horaria);
  • disponibilidad del sistema para el usuario en el momento de la actividad.

Consideraciones especiales de gestión de riesgos para el registro contemporáneo de datos GXP

  • Los programas de capacitación en Buenas Prácticas de Documentación deben enfatizar que es inaceptable registrar datos primero en documentación no oficial (por ejemplo, en un trozo de papel) y luego transferir los datos a la documentación oficial (por ejemplo, el cuaderno de laboratorio). Los datos originales deben registrarse directamente en registros oficiales, como hojas de trabajo analíticas aprobadas, inmediatamente en el momento de efectuada la actividad GXP.
  • Los programas de capacitación deben enfatizar que es inaceptable retroceder o adelantar un registro. La fecha registrada debe ser la fecha real de la entrada de datos. Las entradas tardías deben indicarse como tales con la fecha de la actividad y la fecha de la entrada que se registra.
  • Si una persona comete errores en un documento en papel, debe hacer correcciones de una sola línea, firmarlas y fecharlas, proporcionar los motivos de los cambios y conservar este registro en el conjunto de registros.
  • Si los usuarios de sistemas computarizados independientes cuentan con derechos de administrador completos para los sistemas operativos de la estación de trabajo en los que se almacenan los registros electrónicos originales, esto puede otorgar de manera inapropiada permiso a los usuarios para renombrar, copiar o eliminar archivos almacenados en el sistema local y cambiar la hora / fecha. Por esta razón, la validación del sistema computarizado autónomo debe garantizar restricciones de seguridad adecuadas para proteger la configuración de hora / fecha y garantizar la integridad de los datos en todos los entornos informáticos, incluido el sistema operativo de la estación de trabajo, la aplicación de software y cualquier otro entorno de red aplicable.

Tomado de la WHO Technical Report Series No. 996, 2016

¿Es necesario que exista un procedimiento para eliminar los datos?

Eliminar datos relevantes de GMP se considera crítico. La eliminación de los datos relevantes de GMP en un sistema computarizado debe ser registrada por un Audit Trail. El Anexo 11 de la EU-GMP  establece que Los sistemas de gestión de datos y documentos deben diseñarse para registrar la identidad de los operadores que ingresan, cambian, confirman o eliminan datos, incluida la fecha y la hora.

Básicamente, debe ser posible reconocer quién está eliminando datos dentro de tales sistemas. Eliminar datos pone en peligro la integridad de los datos y es un paso crítico. Los pasos de trabajo se deben describir en los procedimientos operativos estándar (SOP): el Capítulo 4 de la EU-GMP, sobre  Documentación GMP requerida: “Procedimientos: (también conocidos como Procedimientos Operativos Estándar, o SOP), brindan instrucciones para realizar ciertas operaciones”.

Se permite eliminar datos que ya no son necesarios. La eliminación es el último paso en el ciclo de vida de los datos. Deben establecerse procedimientos seguros para la eliminación de datos GMP.

Normalmente, los datos solo se deben eliminar después del final de su período de retención. Hay muy pocas excepciones en cuanto a cuándo se pueden eliminar los datos antes del final de su período de retención. Esto incluye, por ejemplo, datos que se han migrado a otro sistema. La eliminación de datos se debe describir en detalle en un SOP relevante.

Les dejo el link de las 2 guías:

Guía GMP de la UE – Capítulo 4

Guía GMP de la UE – Anexo 11

Tomado de la Newsletter de la ECA (27/6/2019)

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).

La nueva disposición de la ANMAT tiene establecidos requerimientos para los sistemas computarizados o informatizados en el Anexo 6 Sistemas Informatizados de la nueva Disposición.

Este Anexo aplica a todas las formas de sistemas informatizados usados como parte de las actividades reguladas por las BPF y se utilicen para crear, modificar, mantener,  archivar, obtener o distribuir registros electrónicos.

Además de Validar las aplicaciones, debemos calificar la Infraestructura  informatizada (IT).

La inclusión de un sistema informatizado en la manufactura no debe aumentar el riesgo total del proceso.

Estos lineamientos de la nueva GMP están basados en la GAMP5 (ISPE) A Risk-based Approach to Compliant GxP Computarized Systems.

Como parte del sistema de gestión de riesgos, las decisiones sobre la extensión de la validación y de los controles de la integridad de datos deben basarse en una evaluación de riesgos del sistema informatizado justificada y documentada.

La norma menciona diferentes figuras que deben existir, como: el propietario del proceso (process owner), el propietario del sistema (system owner), las Personas Calificadas e IT. Obviamente todo el personal debe estar calificado, con su nivel de acceso y definidas sus responsabilidades.

Los proveedores de sistemas informatizados deben estar evaluados y debe disponerse de acuerdos técnicos y acuerdos de confidencialidad (ppalmente. para acceso remoto). La necesidad de auditarlos debe estar basada en un análisis de riesgo del mismo.

Debe disponerse de un inventario de los sistemas computarizados del laboratorio.

La Validación debe ser proporcional al riesgo del sistema (clasificación del riesgo, por ejemplo Categoría GAMP5 y calificación del proveedor), a más riesgo más esfuerzos de validación.

La transferencia de datos debe ser efectuada de forma segura.

En cuanto a la Operación de los SC, debemos asegurar que los datos son guardados regularmente de forma integra durante el período de conservación de los mismos. Debe haber un Audit Trail y debe ser considerada la Gestión de cambios y configuración.

Los sistemas informatizados deben ser revisados periódicamente para verificar la validez de la validación. Esta revisión incluye por ejemplo documentos de operación, validación, cambios, eventos, accesos y manejo de back up, por ej.

También hace referencia a otros temas de importancia como el manejo de firmas electrónicas, plan de Disaster Recovery, etc.

Desde cGMPdoc les ofrecemos distintas alternativas como:

  1. Entrenamientos “In Company” para capacitar a su personal
  2. La implementación del proceso de CSV (Validación de Sistemas Computarizados), lo cual incluye la discusión del procesos internamente con el laboratorio, la confección de los SOPs necesarios, el entrenamiento del personal, la confección del PMV de sistemas computarizados y la ejecución de una validación a modo de ejemplo, de manera que Uds. puedan luego continuar con las actividades del Plan.
  3. La validación de un sistema computarizado
  4. Asesoramiento en la revisión de su proceso de CSV si lo necesita
  5. Pack de SOPs y documentos modelos sobre CSV

Espero que les resulte de utilidad.

La GAMP5 pone particular énfasis en dar lineamientos sobre un enfoque efectivo para compliance y para demostrar que el sistema es adecuado para sus propósitos de uso.

Por tal motivo da lineamientos sobre:

  • Un enfoque completo de ciclo de vida de los sistemas computarizados como parte de un sistema de gestión de calidad, desde la conceptualización del mismo hasta su retiro.
  • Un enfoque de escalado para alcanzar y mantener el cumplimiento GxP direccionado a la novedad, complejidad, riesgo al paciente, calidad del producto y de integridad de datos.
  • Clarificar el rol de la unidad de calidad y e introducir otros roles como Propietario del proceso, Propietario del sistema y SME (Subject Matter Expert).
  • En el entorno GMP, esfuerzos para disponer de claros requerimientos basados en el conocimiento del sistema y de los atributos críticos de calidad del proceso / producto, para facilitar la adopción de un enfoque de Quality by Design.
  • Aprovechar la documentación del proveedor y el conocimiento, si es posible, de forma de evitar duplicarlas de forma innecesaria.
  • Mejorar la eficiencia por medio de promover una interpretación práctica y efectiva de esta guía.
  • Maximizar el uso de documentación desde actividades, tales como desarrollo y commissioning, como evidencia de verificación.
  • La importancia de un seguimiento efectivo para alcanzar y mantener el cumplimiento.
  • Identificar oportunidades para mejorar de procesos y sistemas basados en la revisión periódica, análisis de causa raíz, y CAPA.

La guía intenta actualizarse a un entorno de cambio, además de buscar cumplir con las GxP vigentes y hacer foco en la Gestión de riesgos de Calidad.

 

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

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.