Posts tagged ‘IT’

¿Cuáles son los requerimientos mínimos de Calidad y Compliance para la Resiliencia de la continuidad del negocio, la gestión de la continuidad de los servicios de IT y la planificación de recuperación de desastres? 

Nos estamos refiriendo a los procesos del negocio soportados por sistemas computarizados, dentro del laboratorio y a todos los sistemas computarizados y los servicios que los soportan.

¿Qué deberíamos considerar?

  • Gestión de la Continuidad del Negocio

Esta gestión debe asegurar para todos los procesos de negocios del laboratorio, que tras la disrupción, la operatividad comercial se mantiene en un nivel aceptable.

Cuando no se requieran planes de continuidad del negocio, esta decisión debe ser documentada y justificada con una evaluación de riesgos adecuada que tenga en cuenta el impacto sobre el negocio.

  • Gestión de la Continuidad del Servicio de IT

La Gestión de la Continuidad del Servicio de IT debe asegurar que la infraestructura de IT del laboratorio y sus servicios se pueden restaurar en los plazos determinados de conformidad con los Niveles de Servicio después de un desastre. Todos los Servicios de IT   requieren planes de recuperación y procedimientos establecidos de acuerdo a su criticidad.

Los planes de Gestión de Continuidad del Servicio de IT debe incluir la planificación de procesos y ajuste de procedimientos durante desastres, así como de Planes de recuperación Servicio específicos direccionados a la recuperación técnica.

Estos planes deben revisarse y ensayarse sobre bases regulares para asegurar viabilidad y efectividad. Los planes y capacidades de recuperación deben ajustarse de acuerdo a los resultados de los ensayos realizados.

Se deben realizar  evaluaciones y revisiones de riesgo periódicas para identificar si la probabilidad de un desastre o interrupción del servicio serio para el laboratorio ha cambiado y / o para identificar nuevas amenazas o vulnerabilidades. Los planes de Mitigación de Riesgo / Mejora de Servicio se deben desarrollar según el caso.

  • Gestión de Recuperación de Desastre (incluyendo recuperación de aplicaciones)

Se deben considerar Planes de Recuperación de Desastre y de Aplicaciones para todos los sistemas computarizados utilizados por el laboratorio.

El Propietario del Sistema es responsable por asegurar la existencia, en el lugar, de un Plan de Recuperación de Desastre y Aplicaciones y de las pruebas asociadas.

Cuando los Planes mencionados no se necesitan, la decisión se debe documentar y justificar con un análisis de riesgo que considere el impacto en el negocio.

En caso de un evento de Desastre, todas las aplicaciones y sistemas computarizados serán recuperados de acuerdo al orden de prioridad, el cual se basa en aquellos sistemas que están dentro de los Planes de Recuperación (o contrato) del lugar. De no existir contratos de Recuperación de Desastres, la recuperación de las aplicaciones y sistemas se hará de manera “comercialmente razonable”, basando el orden en prioridad para el negocio (las aplicaciones sin contrato de recuperación de desastres se podrían recuperar dentro de un período de semanas o meses).

  • Sistema Crítico

Un Sistema Crítico o conjunto de sistemas se define como un conjunto de sistemas computarizados críticos y la infraestructura soporte, que, si no es accesible, podría afectar seriamente al laboratorio. 

Factores a evaluar:

  • La dependencia del negocio de la aplicación o servicio y
    • El Tiempo de Recuperación que se requiere para evitar un impacto no aceptable en el negocio.

Los Sistemas que están dentro del listado de críticos, junto con la infraestructura soporte y los procesos, deben tener Planes de Continuidad de negocio y Recuperación de Desastre, disponibles en el lugar.

El listado de Conjuntos críticos debe ser revisado trimestralmente, para su actualización.

Excepciones

No todos los procesos y sistemas requieren planes de Continuidad de Negocio o de Recuperación de Desastre. Esto se basa en su uso y en el nivel de riesgo e impacto que representan en lo que respecta a la criticidad del negocio.

La decisión acerca de que un proceso o sistema no requiera plan de Continuidad de Negocio o de Recuperación de Desastre debe ser documentada y aprobada por el Propietario  del Sistema o el Proceso de Negocio.

 (*) Según Wikipedia:

La resiliencia es la capacidad de los seres humanos para adaptarse positivamente a las situaciones adversas. Sin embargo, el concepto ha experimentado cambios importantes desde la década de los 60. En un principio se interpretó como una condición innata luego se enfocó en los factores no solo individuales, sino también familiares y comunitarios y actualmente en los culturales. Los investigadores del siglo XXI entienden la resiliencia como un proceso comunitario y cultural, que responde a tres modelos que la explican: un modelo «compensatorio», otro de «protección» y por último uno de «desafío».

Asimismo, la resiliencia es la capacidad de tener éxito de modo aceptable para la sociedad a pesar de un estrés o de una adversidad que implica normalmente un grave riesgo de resultados negativos. También se define como un proceso de competitividad donde la persona debe adaptarse positivamente a las situaciones adversas.

Etimología

Resiliencia viene del término latín resilio, «volver atrás, volver de un salto, resaltar, rebotar». El término se adaptó al uso en psicología y otras ciencias sociales para referirse a las personas que a pesar de sufrir situaciones estresantes no son afectadas psicológicamente por ellas.

La palabra resiliencia, en cuanto a la física y la química, designa la capacidad del acero para recuperar su forma inicial a pesar de los golpes que pueda recibir y a pesar de los esfuerzos que puedan hacerse para deformarlo. La palabra proviene del latín saliere, que se traduce como “saltar hacia atrás, rebotar, ser repelido o surgir”, antecedido por el prefijo “re”, que indica repetición o reanudación.

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.

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.
1. Información general
Comentario: este Check List tiene por objetivo evaluar el status del Laboratorio en los temas relacionados ala Validaciónde Sistemas Computarizados (CSV) y firmas y registros electrónicos (21CFRParte11).
1.1 Nombre del evaluador

_____________________________________

1.2 Cargo / Área (QA, IT, etc.)

_____________________________________

1.3 Fecha de completado el check list

_______ / _______/ _______

1.4 Nombre del Laboratorio

_____________________________________

1.5 El Laboratorio produce (o producirá dentro de los próximos 12 meses) activos o productos para el Mercado de USA o proveerá información parala FDA?

 SI             NO

1.6 El Laboratorio participa (o participará en los próximos 12 meses) en el desarrollo (incluyendo lotes para ensayos clínicos) de activos o productos para el mercado de USA?  SI             NO
1.7 El Laboratorio maneja datos (por ej. devoluciones de eventos adversos) de activos o productos, los cuales son comercializados en el Mercado de USA y podrían ser revisados por los USA?  SI             NO
1.8 Cuál es el nombre del responsable de CSV del Laboratorio?

_____________________________________

Comentarios referidos al ítem 1 “Información general”:

2. Información sobre CSV y 21CFR11
2.1 Plan Maestro de Validación (PMV) de CSV
2.1.1 Tiene un Plan Maestro de Validación de Sistemas Computarizados?  SI             NO
2.1.2 Está aprobado?  SI             NO
2.1.3 Quienes son los aprobadores del PMV?
Nombre                     Cargo / Posición

______________       ________________

______________       ________________

______________       ________________

______________       ________________

2.1.4 Cuando fue la última revisión / actualización del PMV?

_______ / _______/ _______

2.2 Inventario de Sistemas Computarizados
Comentario: Un Inventario de todos los sistemas computarizados en las áreas GxP debe ser confeccionado y mantenido por el responsable del PMV de acuerdo a los lineamientos dela Políticade Validación de Sistemas Computarizados. El mismo debe ser actualizado regularmente y auditado anualmente. Incluye el estatus de los análisis de riesgo GxP y el estatus de la validación de los mismos, así como la ejecución de los análisis de riesgo del 21CFRParte11 y su cumplimiento.
2.2.1 Tiene un Inventario de Sistemas Computarizados?  SI            NO
2.2.2 Utiliza un modelo o template para su inventario?Detallar que tipo de base utiliza para mantener el inventario (por ej. access, excel, etc.).  SI            NO ____________________________________
2.2.3 Todos los Sistemas computarizados están listados en el inventario de sistemas?Si, NO, explique el racional del mismo.  SI            NO ____________________________________
2.2.4 Cuando fue la última revisión / actualización del inventario de sistemas?

_______ / _______/ _______

2.3 Roles y Responsabilidades
2.3.1 Los roles y responsabilidades de CSV están definidas y actualizadas?   SI             NO
2.3.2 Los roles y responsabilidades están incluidas o mencionadas en el PMV?  SI, en el PMV

SI, en un anexo del PMV

NO

2.4
Capacitación en CSV y 21CFR11
2.4.1 Algún miembro del Laboratorio ha recibido entrenamiento en temas relacionados a CSV y 21CFR11?   SI             NO
2.4.2 En caso afirmativo en la pregunta anterior, indique, quién, cuándo y el curso al cual asistió.

_____________________________________

2.4.3 Ha efectuado capacitaciones sobre CSV y 21CFR11 en su Laboratorio?   SI             NO
2.4.4 Cuántas sesiones de capacitación fueron efectuadas?

_____________________________________

2.4.5 Cuándo fueron efectuadas las capacitaciones?

_______ / _______/ _______

_______ / _______/ _______

_______ / _______/ _______

Comentarios sobre el ítem 2 “Información sobre CSV y 21CFR11”
3. Información sobre CSV
3.1
Análisis de riesgo GxP
  Comentario: Un análisis de riesgo GxP evalúa cuando un sistema tiene o no impacto sobre las GxP y por ende necesita o no ser validado.
3.1.1 Tiene un análisis de riesgo GxP de todos los sistemas computarizados disponibles?Si, “NO”, por favor explique, cuales son los sistemas evaluados desde el punto de vista GxP  SI                    NO______________________________
3.1.2 Tiene un template (modelo) para efectuar el análisis de riesgo?  SI             NO
3.1.3 Qué porcentaje de los sistemas disponibles tiene efectuado el análisis de riesgo GxP?

____________________________________

Comentarios del ítem 3 “Información sobre CSV”
4. Información sobre 21CFR11
4.1
Análisis de riesgo 21CFR11
4.1.1 Cuántos análisis de riesgo 21CFRparte11 ha efectuado el Laboratorio?

____________________________________

4.1.2 Tiene un template (modelo) para efectuar el análisis de riesgo?  SI             NO
4.1.3 Qué porcentaje de los sistemas disponibles tiene efectuado el análisis de riesgo 21CFRParte11?

__________________________________

4.2
Plan de remediación del 21CFR11
4.2.1 Elaboró un Plan de remediación para el 21CFR11?  SI             NO
4.2.2 Qué porcentaje de los sistemas críticos 21CFR11 están cubiertos en el Plan de remediación?

__________________________________

4.3
Remediación 21CFR11 de sistemas existentes
4.3.1 Para cuántos Sistemas es necesaria una remediación 21CFR11 (de acuerdo al Plan de remediación)?

__________________________________

4.3.2 Cuántas remediaciones fueron efectuadas?

__________________________________

4.3.3 Qué porcentaje de los sistemas críticos 21CFR11 fueron remediados de acuerdo al Plan de remediación?

__________________________________

Comentarios del ítem 4 “Información sobre 21CFR11”
5. Informes
5.1 Qué porcentaje de los sistemas críticos GxP están validados? ____________________ %
5.2 Qué porcentaje de los sistemas críticos GxP cumplen con el 21CFR11? ____________________ %
5.3 Alcanzó los deadlines de su Plan de remediación? Si, NO, qué porcentaje está vencido?  SI             NO

SI NO,  % Vencido ________________

Comentarios del ítem 5 “Informes”

6. Feedback y Requerimientos
6.1 Ud. Piensa que dispone de los modelos adecuados, asi como los procedimientos necesarios para el cumplimiento de las políticas de Validación de sistemas computarizados?   SI            NO
6.2 Necesita información o SOPs adicionales?  SI             NO
6.3 Cuáles son los requerimientos específicos en cuanto a entrenamiento en CSV y 21CFR11?

__________________________________

6.4 Necesita algún tipo de soporte adicional respecto de CSV&21CFR11?En caso SI, especificar cual.  SI              NO ____________________________________
Por favor indique a continuación cualquier otra recomendación / inquietud que Ud. pueda tener.
 

Espero que les resulte útil.