Posts tagged ‘GxP’

En Julio 2022, fue publicada la segunda edición de la Guía ISPE GAMP® 5: un enfoque basado en el riesgo para sistemas computarizados compatibles con GxP.
Esta segunda edición de ISPE GAMP 5 resalta la importancia de los proveedores de servicios, del mayor uso de herramientas de software y automatización para lograr un mayor control, una mayor calidad y menores riesgos a lo largo del ciclo de vida y además destaca la importancia del “pensamiento crítico”.
En este punto quiero detenerme y dejarles un resumen de un artículo escrito por Charlie C. Wakeham, sobre Por qué necesitamos el pensamiento crítico:
Puede parecer que las únicas cosas que la industria farmacéutica ama más que los acrónimos son las nuevas frases de moda. Y eso puede ser verdad. Pero a veces, detrás de la frase de moda, hay beneficios reales, fuertes y alcanzables para nuestro trabajo, nuestra industria y nuestros pacientes finales.
El pensamiento crítico es una de esas frases de moda. Originadas fuera de nuestra industria y adoptadas con entusiasmo por instituciones académicas y consultores a nivel mundial, la mayoría de las definiciones son algo ininteligibles y difíciles de relacionar con la vida real.

Charlie menciona que hay no menos de 11 definiciones, pero me voy a quedar con la que para él es su propia definición:
Es elegir sabiamente, excluyendo la burocracia, la jerarquía, el ego, el sesgo y la ambición del proceso de toma de decisiones.
Se está enfocando en lo que importa, que tiene que ser la calidad en lugar del cumplimiento y la documentación. Obtenga la calidad correcta y el cumplimiento estará allí de todos modos.
Me parece más importante lograr que la industria utilice el pensamiento crítico que debatir las complejidades del paradigma.
Veamos algunos ejemplos de pensamiento crítico con sistemas computarizados GxP:
ESPECIFICACIONES DE REQUISITOS
Todos estamos de acuerdo en que necesitamos capturar lo que debe hacer un sistema computarizado cuando estamos planeando un nuevo sistema, es decir, la funcionalidad que proporcionará para respaldar un proceso de negocios en particular. Esto significa que debemos definir qué regulaciones se aplican y qué requisitos individuales deben cumplirse dentro del marco regulatorio general. Necesitamos requisitos para definir la funcionalidad específica que el sistema debe proporcionar en relación con el proceso comercial; cómo controlará una actividad, analizará una muestra, calculará un resultado y almacenará los datos. Puede haber restricciones particulares o requisitos de infraestructura: alojamiento en la nube, funcionamiento en una sala limpia, conexión o interfaz con un sistema existente.
Todos estos son tremendamente importantes y deben ser capturados como requisitos.
Requisitos sobre cuántos niveles de submenú se permiten en el sistema. Requisitos para “rápido, fácil, fácil de usar”. Estos no tienen sentido para el proceso comercial e inútiles para el paciente final.
¿Qué hay de capturar los requisitos en un documento de Word en lugar de utilizar una herramienta de gestión de requisitos? ¿Qué elección de logotipo, fuente, interlineado? ¿Serán los requisitos firmados a mano o aprobados electrónicamente? Nada de esto tiene ningún impacto en la calidad del producto o la seguridad del paciente. Siempre que los requisitos estén controlados, aprobados, protegidos contra cambios no autorizados, disponibles y actualizados durante toda la vida del sistema, el formato, los medios y la apariencia de la información tampoco tienen impacto en la integridad de los datos.
Mencioné “aprobado” en la lista anterior. Revisión por el propietario del proceso y el propietario del sistema, absolutamente. Revisión por otras cuatro personas sin conocimiento de sistemas o procesos que solo querían su nombre en el documento, sin sentido. Mi registro personal en un proyecto CSV era un cliente que demandaba un total de nueve revisores y aprobadores. Si un revisor no va a leer el contenido o entender el contenido, ¿qué representa su firma: un autógrafo para la posteridad? ¿Una confirmación de que creen que el crítico anterior probablemente lo leyó? No ayuda….
PRUEBAS
Se pueden obtener grandes beneficios al aplicar el pensamiento crítico a las pruebas y, por lo tanto, no sorprende que la excelente instigación de la FDA de los enfoques de Computer Software Assurance (CSA) tenga un enfoque significativo en las pruebas.
Yo estimaría de forma conservadora que los scripts de prueba detallados click a click tardan cinco veces más en escribirse que en ejecutarse. La mayor proporción de defectos encontrados por dichos scripts de prueba son, sin duda, errores en los propios scripts. Veamos la motivación para scripts de prueba tan detallados.
Motivación Pensamiento Crítico
Debe desafiar una ruta o rama específica en el software; las instrucciones detalladas aseguran que llegue al camino o ramal. Esto aporta valor en la detección de defectos y beneficios finales para la seguridad del paciente.
El evaluador no sabe cómo operar el software, por lo que necesita las instrucciones de click a click.

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.

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

En más de una ocasión, sobre todo en los talleres de Validación de planillas Excel, suele aparecer la discusión sobre si las mismas son validables, hablamos de su inviolabilidad y generalmente llegamos a la conclusión que las planillas Excel, no son a prueba de balas, pero las necesitamos.

Diseñar e implementar una hoja de cálculo debería ser la última opción. La decisión final de encargar el desarrollo y la implementación de las hojas de cálculo debe basarse en una investigación elaborada con respecto a la disponibilidad de software “existente” y probado, que ya está destinado a ser utilizado dentro de las industrias sanitarias reguladas.
Se recomienda realizar cálculos en entornos seguros y validados con funciones para cumplir con las regulaciones aplicables, por ejemplo: sistemas de datos cromatográficos (CDS), sistemas de gestión de información de laboratorio (LIMS).
Existen en el mercado softwares que le dan a las planillas Excel la posibilidad de una mayor seguridad y funcionalidad de compliance, por ejemplo, Audit Trail, firmas electrónicas, gestión de usuarios, control de versiones.

Ahora nuestra realidad, es que tenemos muchas planillas Excel, las cuales utilizamos para calcular Atributos críticos de calidad, planillas con impacto sobre la calidad de nuestros productos y mientras esto sea así, tenemos que hacer todo lo posible para tener planillas Excel correctas y seguras, por eso tenemos que validarlas y luego implementar una excelente administración y seguimiento de las mismas.

Pero ojo, no debemos validar el software Excel (la aplicación), el cual ya esta probado por el uso y es confiable, pero si todo aquello que hemos configurado, todo lo que nosotros decidimos que la planilla hará.

Usualmente mencionamos Metada y la definimos como:

La información contextual requerida para comprender los datos.

Un valor de datos,  en sí mismo no tiene sentido sin información adicional sobre el mismo. A menudo se la llama como datos sobre datos. Metadata es información estructurada que describe, explica o hace que sea más fácil recuperar, usar o administrar datos.

Por ejemplo, el número “23” no tiene sentido sin la metadata, como la indicación de la unidad “mg.” Entre otras cosas, la metadata para una pieza en particular de datos podría incluir un sello de fecha / hora para cuando se adquirieron los datos, una identificación de usuario de la persona que realizó la prueba o el análisis que generó los datos, el ID del instrumento utilizado para adquirir los datos, pistas de auditoría, etc.

La metadata asociada requerida para reconstruir la actividad cGMP (p. ej., 211.188/89 y 211.194). Las relaciones entre los datos y su metadata debe ser preservada de una manera segura y trazable.

Relación entre los Datos y la Metada.

Tal como les comentaba antes, la metada es necesaria para describir el contexto y el significado de los datos. Los datos deben cumplir con el acrónimo ALCOA:

  • Atribuibles a una persona o sistema que los genera;
  • Legibles y permanentes durante todo su ciclo de vida;
  • Contemporáneos, registrados en el momento en que ocurren;
  • Originales o copias certificadas de los mismos y
  • Exactos (Accurate)

Los datos precisos son aquellos que se generan, se mantienen de acuerdo con el proceso al que pertenecen y durante el ciclo de vida. Ejemplo: la metada asociada a los datos de temperatura pueden ser la ubicación, la hora y el dispositivo utilizados para la medición de la temperatura.

Los requisitos regulatorios y los tipos de medios de registro utilizados pueden estipular la necesidad de metada específica. Tres ejemplos de tipos de medios de registro y el requisito de metada resultante:

  • Para registros en papel, fecha, hora, nombre de la persona y firma de la persona que crea la nota que consta de, por ej. un valor medido, su unidad física y su número de etiqueta para identificación / referencia escritos en una hoja de papel en blanco o en forma pre-impresa.
  • Para registros electrónicos, audite la información del recorrido indicando la fecha, hora, nombre de usuario, elementos de datos nuevos / anteriores y nuevos, y el motivo para escribir / cambiar un conjunto específico de elementos de datos.
  • Para los registros híbridos, la metada debe incluir la metada anterior para los registros en papel y electrónicos, así como la metada que describe el contexto y el significado de la interconexión de los registros en papel con los registros electrónicos asociados y su ubicación en los respectivos sistemas computarizados.
  • Para los registros híbridos, el conjunto definido de tipos de medios debe mencionarse específicamente en cada tipo de medio de registro diferente en una forma legible por humanos que mantenga la integridad reverencial. Por ej. en un registro en papel para una declaración de lanzamiento de producto con fecha, firmado y fechado manualmente, debe haber referencias específicas a los registros de producción electrónica subyacente y registros de datos analíticos electrónicos contenidos en Sistemas Computarizados específicamente referenciados y viceversa. Es decir, en registros electrónicos relacionados, deben existir referencias que indiquen cuándo existen registros en papel que hacen referencia a un conjunto específico de registros electrónicos.

Es importante administrar los registros de cualquier tipo con respecto a la buena documentación y los procesos de gestión de registros. Los registros deben identificarse como GxP y si es primario, maestro, copia, etc. de acuerdo con el proceso de administración de documentos.

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.

El doble chequeo es un aspecto crítico e importante de las GxP. El impacto de un error, mix-up, o una equivocación puede ser monumental. Cada uno conoce lo importante que el chequeo y doble chequeo puede ser.

Quiero darles un ejemplo, para hacerlo más entendible y mantener la conciencia en el más alto nivel.

Durante algunos años trabajé en una Planta farmacéutico en el sector de producción y muchas veces cuando volvía de regreso a casa, conduciendo mi auto, pasaban unos cuantos km hasta que tomaba conciencia de que estaba manejando. Alguna vez les ha pasado esto?  Supongo que a muchos de Uds. Es más en ese momento pensaba, “que suerte que mi coche conoce el camino”.

El tema es que, conducir el auto es una habilidad que tenemos bastante fácilmente dominada, y para la mayoría de nosotros, una habilidad que hemos aprendido y dominado hace largo tiempo. Conducir el auto es una actividad de rutina, repetitiva, una tarea redundante, realmente no requiere mucho pensamiento. La mayoría de nosotros realiza su camino a través del tráfico de la ciudad cada día sin realmente prestar mucha atención a lo que estamos haciendo.

doble-check-azul

Entonces, me pregunto, cuantas tareas o trabajos en la compañía pueden ser caracterizadas como bastantes rutinarias, repetitivas y redundantes. La respuesta es la mayoría de ellas. Estas tareas o trabajos son caldo de cultivo para la complacencia. Así como muchos accidentes de tránsito son el resultado de complacencia, muchos mix-ups y errores en nuestras operaciones son el resultado de complacencia.

El doble chequeo es una efectiva herramienta para protegerse de la complacencia. Un efectivo doble chequeo requiere disciplina. Muchos lugares en nuestros documentos requieren una segunda firma. Esto significa una verificación independiente, No solo una segunda firma. La segunda firma es el doble check. La persona que efectúa el doble check (verificación independiente), debe entender la importancia de su role y las consecuencias si ella no efectúa la tarea exactamente y de manera completa.

Démosle valor a la firma.

Tomado de David Markovitz (GMP Training Systems).

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.