En este post se explica la gestión de riesgos en validación de sistemas informatizados para laboratorios farmacéuticos.

Gestión de riesgos en sistemas informatizados – Validación

Validación de sistemas informatizados. ¿Quién tiene que hacerlo?

En primer lugar, observo mucha confusión en las empresas, sobre quién tiene que hacer la validación de los sistemas informáticos. Hay una respuesta. La validación abarca el ciclo de vida completo. En consecuencia, parte la hace el fabricante del sistema, y parte el cliente final.

De forma simplificada, un sistema informatizado tiene dos grandes partes: El equipo/instrumento y el software de control. El equipo puede ser una máquina de inspección 100% de integridad de envases. O bien, el instrumento puede ser un UHPLC del laboratorio, con todos sus módulos. Y, el software de control, es esa maravilla con la que podemos gobernar el sistema, haciendo que haga cosas, capture datos, los procese y genere resultados. No entraré ahora en el hardware y el software de infraestructura. Todo se tiene que tener en cuenta en las pruebas de validación.

De una forma simplificada, el fabricante se encarga de validar el sistema según está diseñado. Y, el cliente final se encarga de validar la configuración y el uso, dentro de un entorno regulado. Esto hay que entenderlo bien claro. Por ejemplo, cuando compramos un sistema con software 21 CFR parte 11, significa que tiene capacidad de cumplir. Pero es el cliente final (tú), quien hace que el software cumpla 21 CFR parte 11. Mediante su configuración y uso (ambas cosas las haces tú). Eso es precisamente lo que requiere el anexo 11 de las UE GMPs. Validación de sistemas informatizados.

 

Gestión de riesgos en sistemas informatizados. ¿Qué niveles de evaluación son necesarios?

Ahora, recordemos lo que requiere el anexo 15 de validaciones:

RA→URS→SA→DQ→FAT/SAT→IQ→OQ→PQ

RA es un ejercicio de gestión de riesgos. Bueno son dos: Evaluación inicial de riesgos y evaluación de riesgos funcionales. Y se hace al principio. Lo hace el fabricante cuando va a crear un sistema informatizado. Y, lo hace el cliente final, cuando quiere comprar. El alcance es diferente y los usos también.

Risk assessment del fabricante

El fabricante usa su RA para establecer su especificación interna de requisitos de usuario. Y de ahí, las especificaciones funcionales, la especificación de la configuración y después, configurar el producto (software). A continuación, lo prueba. Hace test para probar la configuración, las funcionalidades y el acuerdo con los requisitos iniciales. Son ejercicios internos, confidenciales, puesto que es su know-how. Son exhaustivos, y si queremos asegurar que están bien hechos, debe hacerse mediante un Supplier Assessment.

Risk assessment del cliente (tú)

El Risk Assessment del cliente (tú) se usa para identificar lo que es importante para el cliente (intención de uso, GMPs, data integrity, funcionalidades específicas). Siempre desde el uso que el cliente va a dar al sistema, dentro de un entorno regulado por las GMPs. La evaluación de riesgos inicial se enfoca en caracterizar si el sistema impacta en GMPs. Es decir, seguridad del paciente, eficacia y calidad del producto e integridad de datos. Y la evaluación de riesgos funcionales, se orienta para diseñar la especificación de compra (o bien, la URS) y el plan de cualificación del sistema informatizado. Este plan se ejecuta en las conocidas etapas DQ, FAT/SAT, IQ, OQ y PQ. Mediante protocolos de cualificación. Y se documenta mediante los informes de cualificación y sus anexos de evidencias.

Más reparto de tareas:

De una forma orientativa, la DQ, FAT/SAT y PQ, las hace mayoritariamente el cliente. Y la IQ, OQ, las hace mayoritariamente el fabricante. Dicho. Esto es así, porque lo primero, es básicamente demostrar que el sistema hace lo que queremos. Y lo segundo, es básicamente demostrar las capacidades del sistema, pero no según nuestro uso. Otra cosa, solemos usar mucho menos de lo que da un sistema informatizado. Y sólo tenemos que validar la parte que usamos. Otra cosa más, usamos el sistema informatizado mediante su software. Es decir, evaluamos la respuesta del sistema comunicándonos con él a través de su software.

Gestión de riesgos en sistemas informatizados: Evaluación inicial.

En validación de sistemas, lo primero, debemos definir el uso. Una vez definido, podemos identificar si tiene impacto en calidad, si es un sistema crítico y cuál es su complejidad. Estos tres factores de evaluación del riesgo permiten cuantificar las fuentes de riesgo. Después, mediante una tabla de filtrado, podemos clasificar el sistema como de alto, bajo o medio riesgo, y establecer la principal acción de mitigación de riesgos. Es decir, la necesidad de validar o no. Esto está así, resumido, para entender el concepto. Luego hay que armarlo bonito y técnico, en formato ICH Q9.

Impacto en calidad:

Un sistema tiene impacto en calidad si cumple tan sólo una de estas características:

  • Tiene contacto directo con el producto
  • Produce o tiene contacto directo con una materia prima o solvente que exponga al producto.
  • Se emplea en sistemas de limpieza o esterilización.
  • Preserva la seguridad, eficacia y calidad del producto.
  • Proporciona una utilidad o función, o afecta al desempeño de un sistema con impacto directo.
  • Produce o mantiene datos que se utilizan para aceptar o rechazar productos
  • Produce o mantiene datos que se utilizan en el registro de estudios de estabilidad.
  • Proporciona o mantiene información, utilizada para un registro regulatorio (o informes técnicos que respaldan la presentación).

Sistema crítico:

Un sistema es un sistema crítico si cumple tan sólo una de estas características:

  • Gestiona datos para demostrar el cumplimiento de un proceso regulado.
  • El funcionamiento normal o el control del sistema tienen un efecto directo sobre la calidad del producto
  • El fallo del sistema de alarmas o transmisión de datos tiene un efecto directo en la calidad o eficacia del producto.
  • La información es parte del registro de lotes, los datos de liberación de lotes o la documentación relacionada con GxP.
  • Crea o conserva datos regulados propios o de otro sistema GxP.
  • Permite o conserva mecanismos de seguridad o acceso para su propio acceso o para el acceso de otro sistema GxP.
  • Permite o mantiene la sincronización de datos, ni gestiona la comunicación para sí mismo, o para otro sistema GxP.

Sistema complejo:

Un sistema es complejo si:

  • Es un equipo sensible, con tecnología sofisticada, componentes o procesos muy selectivos.
  • Los operarios y técnicos de mantenimiento deben estar altamente cualificados.
  • El mantenimiento, la reparación o el reemplazo requieren un esfuerzo especializado o mucho tiempo
  • Los sistemas de respaldo, la reparación, el mantenimiento o el reemplazo no están fácilmente disponibles.

Por estas razones, la gran parte de los sistemas son sistemas altamente complejos con un impacto crítico en la calidad, seguridad y eficacia del producto terminado, y en la toma de decisiones, y deben manejar los datos en un ambiente que asegure la integridad de la información. Por lo tanto, todos los sistemas informatizados requieren Validación (con mayor o menor extensión).

Gestión de riesgos en sistemas informatizados. Relación entre la URS y la evaluación de riesgos.

En este apartado voy a explicar que, en verificación y validación del software, la URS se redacta en función del riesgo.

En las actividades de cualificación y validación se utiliza un enfoque de gestión de riesgos. La evaluación de riesgos se debe repetir (de forma continuada) a medida que aumenta el conocimiento y la comprensión del sistema informatizado durante las fases de proyecto o producción comercial. Incluyendo el control de los cambios en ambas fases. La herramienta y metodología de la evaluación de riesgos se documenta alineada con la ICH Q9.

Entonces, debemos partir de una especificación de requisitos:

Las especificaciones para un sistema informatizado se definen en una especificación de requisitos de usuario (URS). Y en una especificación funcional (FS). O bien, en una sabia combinación de ambas cosas. Que llamaremos también URS, desde el punto de vista de cliente, para simplificar. Los elementos esenciales del sistema informatizado deben incorporarse en esta etapa. Para satisfacer la intención de uso del sistema informatizado. Cualquier riesgo de GMPs debe ser mitigado a un nivel aceptable en esta etapa. La URS es un punto de referencia durante todo el ciclo de vida de la validación (y del sistema informatizado).

Esto es lo que dicen los anexos 11 y 15 de validaciones, así como la GAMP 5.

Es decir, que ya la URS debe redactarse a partir de un ejercicio de evaluación de riesgos del sistema, para cumplir con la intención de uso.

Confusión y evolución:

La realidad es que hoy, hay confusión y evolución. Antes, las cosas no se hacían así. Las URS se escribían y ya está. Y luego se validaba a piñón fijo contra la URS (Cuando las había. Dejémoslo ahí). Pero luego entró la gestión de riesgos y nos pilló con muchas URS escritas, y con la cabeza amueblada para escribir URS.

¿Qué hicimos? Pues sobre la estructura documental de una URS, comenzamos a aplicar gestión de riesgos, pero ya en la etapa de cualificación (para empezar a hacer planes y protocolos). Construimos tablas en que para cada punto de la URS (qué va a hacer), se evaluaba funcionalmente (cómo lo va a hacer), se miraba el modo de fallo (vamos bien) y determinábamos si este riesgo estaba mitigado o no, con un control, y finalmente, en qué etapa de la cualificación/validación, comprobaríamos ese control.

Fijaros que, en este grado de evolución, hay dos problemas. Primero: Puede fallar la validación si el riesgo de un modo de fallo no está mitigado. Segundo: Hay riesgos que ni siquiera se tuvieron en cuenta en el diseño, o sea, en la URS. Si tenemos suerte, esto lo veremos en la etapa de proyecto. Antes de terminar la validación. Y antes de liberar el sistema para su uso. Pero también sucede que esto lo vemos en la etapa de producción (uso). A golpe de OOSs – desviaciones. Y como esto ya se sabe hace tiempo, por eso dicen lo que dicen los anexos 11 y 15.

Validación de sistemas informatizados. ¿Cómo redactar las URS de sistemas nuevos?

Las URS de sistemas nuevos deben redactarse realizando primero el ejercicio de gestión de riesgos. Basado en la intención de uso. Ordenándolo según el ciclo de vida del sistema y sus procesos. Y caracterizando cada acción de mitigación de riesgo como un punto específico de la URS. A continuación, se deben extraer todos los puntos específicos de la URS y armarlos en el documento final completo. Llamado URS, a secas. De esta forma, dentro del ejercicio de gestión de riesgos, es posible llegar a construir la matriz de trazabilidad. Como parte del plan de validación y sus protocolos. Cuadra todo.

Esto es lo que podríamos llamar OPCION 1.

Validación de sistemas informatizados. ¿Cómo aplicar gestión de riesgos? Si ya tengo el sistema y su URS:

Será que no pasa…

La primera auditoría del sistema informatizado debe identificar el conflicto y disparar una recualificación. Tenemos dos posibilidades: Primera: Hacer borrón y cuenta nueva, y aplicar la OPCIÓN 1. Segunda: Aplicar la OPCIÓN 2.

OPCIÓN 2:

Primero: Crear un diagrama de flujo de procesos (incluyendo actuaciones de automatización y gestión de datos). Desmenuzarlo en etapas ordenadas. Según el ciclo de vida. Cuanto más pequeñas mejor.

Segundo: Revisar el ejercicio de riesgos (el que se montó según el orden de la URS) existente. Para cada modo de fallo identificar la etapa del flujo del proceso al que está ligada. Estudiar, para esa etapa, todos los OTROS posibles modos de fallo. Meterlos como nuevos en el ejercicio. Como una revisión del ejercicio. Actuar en consecuencia, en términos de acciones de mitigación, plan de re-validación y sus protocolos.

Fijaros que es un proceso iterativo. Esto también lo dice la GAMP 5.

En consecuencia, es un proceso iterativo:

¿Hemos descubierto la rueda? NO. En esencia esto es lo que nos pide la ICH Q9 en la etapa de la revisión de los ejercicios de gestión de riesgos. En uno de los casos, es un fallo de validación, o una desviación en el uso, lo que dispara una revisión de la evaluación de riesgos, y la generación de una revisión de la URS. En el segundo de los casos, es una auditoría del sistema informatizado lo que la dispara. Todo cuadra.

Para terminar, una síntesis de lo que es un Risk Assessment funcional:

  

Gestión de riesgos en sistemas informatizados: Risk Assessment funcional.

Esta evaluación puede usar una combinación de FMEAC y HACCP como herramienta de evaluación de riesgos.

Esto se hace para:

  • Identificar las vulnerabilidades potenciales del sistema a lo largo de todo su ciclo de vida.
  • Identificar qué elementos del Sistema de Calidad (Puntos Críticos de Control) controlan las vulnerabilidades.
  • Identificar los controles de vulnerabilidades que debería tener el sistema.
  • En consecuencia, identificar punto a incluir en la especificación de requisitos de usuario (URS).
  • Servir de base para redactar la matriz de trazabilidad. La que cuadra los requisitos de usuario con los scripts de prueba.
  • Servir de base para redactar los test de cualificación (scripts de prueba).

Flujo de procesos:

Para ello, hay que desmenuzar el uso del sistema en un flujo de procesos. O sea, qué cosas hace el sistema y en qué secuencia. Considerando si son actuaciones (automatización) o gestión de datos. Cuanto más pequeñas sean las piezas desmenuzadas, mejor. ¿Por qué? Porque nos podemos enfocar mejor para identificar los modos de fallo de esa pieza y su impacto (consecuencias). Vistos los modos de fallo individuales (vulnerabilidades), podemos idear (URS) qué debería tener el sistema para evitarlo. O si no, para detectarlo (y de paso, nos olvidamos de la probabilidad de ocurrencia. Puede o no puede suceder, pero me da igual con qué probabilidad). Esto son los controles. Pues a la URS. Visto el control que debería tener, lo siguiente será, en qué nivel de la cualificación y en que test script probaré que funciona (Matriz de trazabilidad).

Esto es concepto de anexo 15 y anexo 11 puro y duro. Basado en ICH Q9.

Orden lógico:

Si queremos que los documentos sean vivos y sirvan para algo, el orden lógico es:

Plan de validación del sistema → Risk Assessment (inicial y funcional) → URS → Assessment del fabricante →Protocolos de cualificación, su matriz de trazabilidad y sus test scripts → Ejecución → Informe de cualificación.

La cosa es que muchas veces no se empieza esta secuencia hasta que ya se ha comprado el sistema. Y ahí es donde empiezan los problemas… Que acaban desembocando en deficiencias regulatorias en inspecciones. Ver el capítulo anterior.

¿Cómo te ayuda ERANOVA PHARMA en gestión de riesgos en validación de sistemas informatizados?

ERANOVA PHARMA dispone de consultores expertos en validación y gestión de riesgos de sistemas informatizados.

ERANOVA PHARMA ofrece servicios de colaboración adaptados a tus necesidades:

  • Primero: Acuerdo de colaboración para asesoramiento por un tiempo definido, para la evaluación de tus sistemas informatizados e implementación de la actividad de validación.
  • Segundo: Aplicación de las herramientas de gestión de riesgos para la evaluación de uno o varios sistemas concretos.
  • Tercero: Formación en gestión de riesgos y en validación de sistemas informatizados. Sin más.
  • Cuarto: Acciones de validación para sistemas aislados, según tus necesidades concretas.

Pídenos información, y sube ya el nivel de Cumplimiento, antes que sean las inspecciones las que lo hagan. Si tú quieres, ven con esas inquietudes y novedades que tienes en la cabeza. Disfrutamos ayudándote a encontrar tu solución exacta, y a implementar validación de sistemas informatizados en tu planta: Pincha aquí.

Contenidos adicionales de interés:

También puede interesarte en esta web:

Guía de respuestas rápidas:

¿Cómo validar un sistema informático?

Validar un sistema informático requiere la redacción de un protocolo de validación, ejecutarlo y redactar un informe de validación. El Informe debe anexar evidencias que demuestren que el sistema informático funciona de acuerdo a la intención de uso.

¿Qué es la validación de un sistema informático?

La validación de un sistema informático es demostrar que el sistema informático funciona de acuerdo a la intención de uso. El diseño parte de un documento llamado especificación de requisitos de usuario. La intención de uso se describe mediante un procedimiento de obligado cumplimiento. Todo parte de un principio. El principio es un ejercicio de gestión de riesgos. Este ejercicio de gestión de riesgos se enfoca en garantizar que el sistema no aporta riesgos adicionales para la seguridad, eficacia y calidad del medicamento, ni para la integridad de la información gestionada.

¿Qué son los riesgos de un sistema informático?

Los riesgos de un sistema informático son carencias del código de programación cuyas consecuencias tienen impacto en la calidad, seguridad o eficacias del medicamento, o bien en la integridad de la información.  Los riesgos no mitigados se llaman vulnerabilidades y el diseño del software debe impedirlos, o bien ofrecer controles para que no pasen desapercibidos, y puedan ser mitigados externamente.

¿Cuáles son los pasos del proceso de validación?

Los pasos del proceso de validación, según los anexos de GMPs de la Unión Europea, son:

RA→URS→SA→DQ→FAT/SAT→IQ→OQ→PQ

Donde, según siglas en inglés:

RA:         Es un ejercicio (o varios) de gestión de riesgos.

URS:       Es la escritura de una especificación de requisitos de usuarios.

SA:          Es la evaluación del fabricante del sistema informatizado.

DQ:         Es la cualificación del diseño del sistema.

FAT:       Son las pruebas de aceptación del sistema en casa del fabricante.

SAT:       Son las pruebas de aceptación del sistema a la recepción en la planta del cliente.

IQ:           Son las pruebas de cualificación del proceso de instalación en la planta del cliente.

OQ:         Son las pruebas de cualificación de las funcionalidades del sistema informatizado.

PQ:         Son las pruebas de cualificación del sistema tal y como el cliente lo va a usar con sus procedimientos y configuración.

FIN DEL POST