10 Problemas Frecuentes en CSV

1/5/2018 BLOG para cGMPdoc.
com » Validación de sistemas computarizados
BLOG para cGMPdoc.com

:: Espacio de Discusión y Mejora Contínua ::
Posts tagged ‘Validación de sistemas computarizados’

10 problemas frecuentes en CSV
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.
2. 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.
3. 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.
4. 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
5. 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.
6. 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.
7. 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”)
8. Pruebas incompletas:
http://blog.cgmpdoc.com/tag/validacion-de-sistemas-computarizados/ 1/15
1/5/2018 BLOG para cGMPdoc.com » Validación de sistemas computarizados
Los scripts de prueba no prueban completa o adecuadamente el requisito asociado.
9. 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.
10. 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.

Posteado por cgmpblog el día 15/03/2017 a las 16:49 bajo la categoria GMP.
Tags: BPD, Buenas Prácticas de Documentación, CSV, GxP, IEEE, Plan de Validación, Scripts de testeo, Trazabilidad, URS, Validación de sistemas
computarizados
Comment on this post.
El control de cambios y los sistemas computarizados
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
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.
2. 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.
3. 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.
4. 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.
Tags: cambio, Ciclo de vida, Control de Cambios, CSV, DQ, IQ, Matriz de trazabilidad, OQ, Plan de Validación, PQ, Reporte de Validación, testeos, URS,
Validación, Validación de sistemas computarizados
25 preguntas sobre CSV
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?
Posteado por cgmpblog el día 16/08/2016 a las 03:33 bajo la categoria Actualizaciones.
Tags: 21 CFR Parte 11, análisis de riesgo, audit trail, CAPA, Ciclo de vida de validación de sistemas computarizados, Control de Cambios, CSV, Firmas y
registros electrónicos, GAMP5, integridad de datos, IT compliance, migración de datos, parte 11, propietario del sistema, Sistemas computarizados,
Trazabilidad, URS, Validación, Validación de sistemas computarizados
El análisis de riesgo en 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.
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.
Tags: análisis de riesgo, calidad del producto, CSV, detectabilidad, GAMP 5, GxP, integridad de datos, IT, Probabilidad, propietario del sistema, QA, risk
assessment, salud del paciente, score, Seguridad, severidad, Sistemas computarizados, Validación de sistemas computarizados
2 Comments.
Check list para auditoría de sistemas computarizados
Hace tiempo incluimos un Check de verificación del estatus de CSV (Validación de sistemas computarizados) y parte 11
(Firmas y registros electrónicos), acá les dejo el link.
Este check que estamos incluyendo en este artículo intenta ser una guía para auditar el cumplimiento de CSV en el
laboratorio (o en su proveedor). Esperamos que le sirva de ayuda.
1. Desarrollo del Sistema

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

General
Establecer como es provisto el soporte al Sistema, confirmar que los roles y responsabilidades del hepdesk, de los
administradores y soporte técnico están claramente definidas. Asegurar que el entrenamiento adecuado para cada rol
fue suministrado.
Verificar que el Sistema tiene un propietario que lo maneja con suficiente autoridad y con un presupuesto para su
mantenimiento.
Manejo de problemas
Confirmar que hay un procedimiento vigente para el reporte de problemas, con registro, investigación y resolución de
los mismos.
Verificar que las acciones correctivas y preventivas son implementadas.
Verificar que hay una relación entre el reporte de incidentes y la gestión de cambios para el Sistema.
Gestión de cambio
Asegurar que los procedimientos para iniciar, autorizar y documentar los cambios del Sistema están vigentes.
Confirmar que los cambios son evaluados para asegurar que el impacto sobre las funcionalidades relacionadas es
entendido.
Asegurar que la gestión de los cambios incluye la actualización de la documentación del Sistema, instrucciones de uso,
entrenamiento, datos maestros como la funcionalidad técnica.
Asegurar que los testeos hechos como soporte de los cambios del Sistema confirman que las funciones relacionadas no
son adversamente afectadas y además aseguran que los cambios requeridos son alcanzados.
Accesos y seguridad
Revisar que las medidas de seguridad físicas están definidas para el Sistema y están en uso efectivo. Verificar como son
controlados los accesos físicos al hardware.
Revisar que las medidas de seguridad del software están definidas para el Sistema. Verificar como son controlados los
accesos a las funcionalidades críticas son restringidas a los usuarios apropiados. Verificar que donde la capacidad de
enmendar datos maestros ha sido restringida.
Verificar la existencia de un procedimiento para otorgar y remover los accesos al Sistema de los usuarios. Verificar que
los accesos son revisados periódicamente para asegurar que solo tengan acceso al Sistema los usuarios requeridos.
Asegurar que los ambientes de desarrollo, de testeo y productivo son rutinariamente revisados en búsqueda de virus.
Determinar si los elementos del Sistema tales como Sistema operativo, base de datos y aplicaciones del software son
mantenidos con los últimos parches de seguridad disponibles.
Datos maestros
Asegurar que existe un proceso para el mantenimiento de los datos maestros requeridos por el Sistema.
Confirmar que los roles y responsabilidades están claras respecto a la gestión y aprobación de datos maestros.
Verificar si los datos maestros son chequeados periódicamente para verificar su exactitud.
Planeamiento de Business Continuity /Disaster Recovery (incluyendo back up y recuperación)
Verificar que el Sistema tiene un plan de continuidad del negocio (BC), y que el mismo tiene en cuenta la criticidad del
sistema.
Verificar que el Sistema tiene un plan de disaster recovery (DR), y que el mismo tiene en cuenta la criticidad del
sistema.
Verificar que existe un régimen de back up y recuperación para el Sistema y que el mismo está documentado,
mantenido y testeado. Verificar si el mismo tiene en cuenta la criticidad del Sistema.
3. Revisión periódica
Verificar que el Sistema es sujeto a revisiones periódicas para determinar que actividades tienen que ser efectuadas
para mantener el estado validado.
Confirmar que los resultados de la revisión son registrados y cualquier acción es seguida hasta que se complete.
Tags: 21CFRParte11, back up, Business Continuity, CSV, diseño, entregables de validación, Evaluación de proveedores, Firmas y registros electrónicos,
liberación, Owner, parte 11, proveedores, QA, Recovery, roles y responsabilidades, scripts de testeos, Validación de sistemas computarizados
2 Comments.
Introducción al ciclo de vida de los Sistemas computarizados (Parte II)
Soporte, estrategia de mantenimiento y Gestión del Cambio
Con el fin de mantener el estado validado, el sistema debe ser soportado y mantenido y los cambios deben ser gestionados
adecuadamente. Un mecanismo debe estar en su lugar para registrar los problemas del sistema, investigarlos y seguirlos
hasta el final con el seguimiento apropiado de las acciones correctivas y preventivas, según corresponda.
Los cambios en el sistema pueden ser consecuencia de problemas o cambios en los procesos de negocio y el uso del
sistema. El impacto de cualquier cambio propuesto en la funcionalidad existente debe ser evaluado antes de su
aprobación. Los testeos de soporte del cambio deben demostrar que
(a) la funcionalidad cambiada performa como se esperaba y
(b) no hay un impacto inesperado en las funciones del sistema relacionadas.

De forma periódica debe haber una revisión de la gestión del sistema para determinar que necesita hacerse para mantener el
estado validado. Inputs a la revisión de la gestión pueden incluir:
Cantidad de cambios del sistema

Problemas comunes de los usuarios
Cambios técnicos a la infraestructura de apoyo al sistema
Soporte continuo a las partes de origen comercial del sistema (hardware o software)
Cambios en el uso del sistema
Cambios en los procesos de negocio soportados por el sistema
Las recomendaciones resultantes de la revisión periódica deben ser registrados formalmente y las acciones deben ser
seguidas.
Siempre que sea posible, el sistema debe ser mantenido con los parches de seguridad actuales de los sistemas operativos,
bases de datos y software de aplicación con el fin de proteger el proceso y los datos del acceso y cambio no autorizado
(hacking).
Cuando al sistema se puede acceder directamente por medio del proveedor de software (por acceso telefónico o Internet)
este acceso debe ser controlado de manera que los cambios realizados sean gestionados de forma normal.
Copias de seguridad y restauración
Con el fin de asegurar el sistema y sus datos, deben ser identificados requerimientos de back up y recuperación para todos
los sistemas que tienen impacto sobre las GMP. La frecuencia con que se efectúan las copias de seguridad debe ser
determinada de acuerdo a la criticidad del sistema. Los datos respaldados deben estar bien seguros y la recuperación de los
mismos debe ser probada periódicamente, para asegurar que es exitosa.
Continuidad de Negocio / Recuperación de Desastres
La pérdida de sistemas informáticos puede ocurrir por una variedad de razones, que van desde fallas en los equipos, de red o
fallas de software por una catástrofe en la planta. Se prevé que la mayoría de los problemas de sistemas computarizados o
infraestructuras se resolverán rápidamente por procesos de apoyo existentes para minimizar el impacto en los usuarios
finales del sistema. Un problema serio puede, sin embargo, convertirse en un desastre si se deja sin resolver.
El período inmediato que rodea a un desastre puede dar lugar a confusión, el caos y la interrupción significativa de la
operación del negocio de rutina. Las medidas adoptadas en las primeras horas de una crisis tienen una incidencia
significativa en la severidad y la velocidad máxima para reanudar las operaciones normales del negocio. La creación de
planes estructurados ayudará proporcionando responsabilidades y acciones claramente definidas. Estos procedimientos,
junto con un poco de preparación antes del desastre, asegurarán que el impacto en el negocio de cualquier desastre puede
ser gestionado y minimizado.
La continuidad del negocio (BC) y la recuperación de desastres (DR) son dos procesos paralelos que se preparan antes del
desastre y se ejecutan después de que ocurre el desastre. Planificación BC describe cómo los procesos de negocio y
actividades continúan en ausencia de los sistemas informáticos de apoyo. La planificación del BC depende enteramente de la
criticidad del sistema. Para los sistemas la planificación BC puede ser la de no hacer nada hasta que se restablezca el
sistema.
La planificación del DR describe cómo los sistemas se restauran a un estado operativo (incluidos los datos) y deben estar en
su lugar para todos los sistemas computarizados e infraestructura. Una vez más un enfoque basado en el riesgo se toma a
menudo.
Para asegurar que los planes son eficaces en el caso de un desastre tienen que ser precisos, oportunos y completos. Ellos
deben ser revisados y actualizados periódicamente. Cuando sea práctico la revisión debe incluir una prueba o ejercicio de los
planes.
Medidas de seguridad
Las medidas de seguridad deben estar en su lugar para evitar el acceso no autorizado al sistema. La seguridad física puede
implicar el control de acceso al centro de datos o restringir el acceso a áreas específicas dentro de la instalación, por ejemplo
los laboratorios pertinentes o áreas de la planta. Acceso lógico puede incluir controles sobre el acceso al software del
sistema, lo que restringe las funciones críticas del sistema para los usuarios especificados y cambiar las contraseñas en los
sistemas operativos, bases de datos y software de aplicación. Una consideración importante es mantener la seguridad de los
componentes del sistema actualizado con los parches de seguridad proporcionados por el vendedor. El objetivo de la
seguridad física y lógica es la de proteger la funcionalidad y los datos del sistema del cambio no autorizado.
Registros Electrónicos y Firmas Electrónicas
Cuando hay sistemas computarizados de apoyo a los procesos críticos de GMP en una instalación y gran parte de los datos
crudos (raw data) mantenidos electrónicamente, es importante que los registros y firmas asociadas son seguras, confiables y
atribuible. Es importante que el personal de la planta entienda que sus firmas electrónicas son el equivalente de la firma
manuscrita. El Audit trail debe registrar todas los detalles necesarios incluyendo quién creó o modificó un registro y cuándo
(21 CFR Parte 11).
Un par de temas más…
Retiro o decomiso del sistema
Procedimiento mediante la cual un sistema es retirado del uso productivo, aquí el código se archiva, los datos son
convertidos o migrados (si aplica), y el sistema está desmontado y colocado fuera de servicio. El enfoque utilizado para el
retiro sistema debe mantener la integridad de los datos o la necesidad de la utilización de los datos en el futuro.
Migración de datos
La migración de datos es un proceso de una sola vez donde los datos se mueven de un sistema a otro sistema. Esto puede
ser debido a una actualización del sistema o debido a la sustitución de un sistema existente con un nuevo sistema. Este no
es un proceso continuo entre dos sistemas.
El enfoque de la migración de datos debe consistir en un plan de migración, la identificación de los datos que se migra, el
proceso real de la migración de los datos, y un proceso de verificación de la migración para determinar que el proceso de
migración era precisa y exitosa.
Las desviaciones del proceso de migración de datos deben ser documentos y resueltas de acuerdo a su criticidad.
Espero que les resulte interesante, a los que ingresaron por acá, les dejo el link al artículo I, haciendo click aquí.
y para los que quieren profundizar el tema:
Tags: 21 CFR Parte 11, CSV, parte 11, Sistemas computarizadosut, Validación de sistemas computarizados
Introducción al ciclo de vida de los Sistemas computarizados (Parte I)
Introducción
Cualquier planta GMP que elabore, envase, controle y/o distribuya productos farmacéuticos se apoyará en mayor o menor
grado en sistemas computarizados. Estos son fundamentales para garantizar que los procesos y los datos son fiables y
seguros. Con el fin de lograr esto, los sistemas computarizados deben mantenerse en un estado validado.
La validación de un sistema computarizado es el establecimiento de pruebas documentadas que proporciona un alto grado de
seguridad que funcionará consistentemente, de acuerdo con las especificaciones predeterminadas y atributos de calidad
durante todo su ciclo de vida.
¿Qué es una auditoría de sistemas informáticos en una planta GMP?
Una auditoría de los sistemas informáticos es una revisión o inspección de las prácticas, los procedimientos, métodos y
normas de la planta GMP que se aplican durante el ciclo de vida del sistema informatizado.
Su objetivo es determinar si la validación del sistema informático es adecuada para satisfacer las expectativas de la
regulación y del laboratorio y que el proceso se ejecuta constantemente y de acuerdo con los procedimientos establecidos.
La auditoría también determina cómo se desarrollan, mantienen y utilizan en la Planta los sistemas informáticos.
Gestión de los Sistemas Computarizados
Es importante establecer que los sistemas informáticos son manejados adecuadamente dentro de la planta. Ellos deben estar
cubiertos por un sistema de gestión de calidad. Este puede ser el mismo que el resto de la planta o puede ser uno específico,
a medida, para los sistemas computarizados.
Procedimientos y normas deben existir para abordar las siguientes áreas:
Ciclo de Vida de los sistemas computarizados

Requerimientos funcionales
Especificaciones de Diseño
Testeos
Instalación / Implementación
Soporte / Mantenimiento
Control de Cambios / Gestión de la Configuración
Back UP / Restauración
Continuidad del negocio y recuperación de desastres
Seguridad
Decomiso
Gestión de desvíos
Es importante determinar el papel de Aseguramiento de la Calidad (QA) en la gestión de los sistemas

informáticos. Aseguramiento de la Calidad puede estar involucrado en cada paso del proceso de validación o limitada a la
aprobación independiente de las entregas de validación. Es posible que una función separada de Gestión de Calidad IS
(ISQM) (dentro de la organización IS) lleve a cabo todas o algunas de las actividades de control de calidad. Es importante
que la relación y el papel de las organizaciones de control de calidad e ISQM están documentadas y que la independencia del
grupo de desarrollo del sistema se mantenga.
Los procedimientos deben describir qué nivel de aprobación se requiere para cada entregable de validación. Como mínimo, la
aprobación QA se esperaría para los Planes de validación, requerimientos e informes de validación y documentación de
control de cambios. Si se producen desviaciones a los procedimientos, confirmar que están documentados, evaluados y
aprobados.
Un inventario de los sistemas debe existir para identificar todos los sistemas de la planta, detallando el propietario y el
impacto GMP. Cualquier sistema con un impacto GMP que se encuentra actualmente en funcionamiento debe ser validado. La
infraestructura de IT también debe ser identificada.
Sistemas críticos GMP pueden incluir:
Sistema de Control de Procesos (SCADA (Supervisory control and data acquisition), autoclaves)
Sistemas de Monitoreo Ambiental
LIMS (Laboratory Information Management System)
MES (Manufacturing Execution Systems)
Sistema de gestión de documentos
ERP (Enterprise Resource Planning) por ejemplo, BPCS, SAP, etc.
Debe quedar claro cómo se determina, evalúa y documenta el impacto GMP o criticidad de un sistema.
Validación
Entregables de validación
En general, las prácticas de documentación GMP estándar debe aplicarse a toda la documentación de validación del sistema
computarizado. Como mínimo esto incluye paginado, datos, historial de revisiones, versión de los documentos, aprobaciones,
y otras buenas prácticas de documentación.
Plan de Validación
El Plan de Validación proporcionará información de planificación específico en lo que respecta a las actividades de validación
que se realizarán para el sistema. El Plan de Validación describe el enfoque de validación que debe tomarse, indica los
entregables de validación y proporciona criterios de aceptación claros. El alcance y la profundidad de validación del sistema
computarizado varían, dependiendo de la naturaleza y la complejidad del sistema. Un enfoque de categorización se puede
tomar donde los sistemas se agrupan en función de su complejidad y su uso.
La GAMP5 clasifica a los sistemas en 4 categorías:
1. Sistemas Operativos disponibles en el mercado. Las aplicaciones se desarrollan para funcionar bajo el control de
estos sistemas operativos. Ej. DOS. Otros sistemas de categoría 1 son los Firmware, los instrumentos y controladores a
menudo incorporan firmware. La configuración puede ser necesaria para el set up y los parámetros del proceso del
entorno de ejecución.
3. Paquetes de software estándar
Son paquetes estándares disponibles en el mercado, proporcionando una solución de estante. Se requiere configuración
limitada para establecer el entorno de ejecución.
4. Paquetes de Software configurables
Los paquetes de software configurables que proporcionan interfaces y funciones que permiten la configuración de
usuario o procesos de negocio específicos estándar.
5. Software a medida
Software desarrollado para satisfacer las necesidades específicas del negocio.
El plan debe indicar la aprobación del propietario de procesos de negocio o el propietario del sistema, los representantes
técnicos y Aseguramiento de la Calidad.
Especificación de requerimientos
La especificación de requisitos (puede ser llamada como URS – especificación de requerimientos de usuarios o simplemente
requisitos del usuario) describe lo que el usuario necesita que haga el sistema.
Los requisitos deben ser únicos y priorizados. Deben estar escritos a un nivel detallado, identificando con precisión los
criterios aceptables para el éxito desde la perspectiva de los usuarios.
Especificación funcional
La especificación funcional (puede ser llamada como Especificaciones de Diseño) describe cómo el sistema está diseñado
para alcanzar los requisitos funcionales. Este entregable es un documento técnico que identifica la solución técnica para la
aplicación, el software subyacente y el hardware necesario para apoyar el sistema. Debe haber trazabilidad clara entre los
requisitos y el diseño funcional. Esto puede conseguirse usando una matriz, referencias cruzadas, la numeración común o
cualquier otro enfoque que hace que sea claro cómo cada requisito se satisface mediante el diseño.
Programación del sistema.
Codificación deben cumplir con los estándares de programación para las pantallas, menús, anotaciones de código, etc.
Cuando sea posible utilizar estándares de codificación de la industria, los mismos deben ser usados. El cumplimiento de los
estándares de codificación debe ser evaluado a través de la revisión formal de código. Un enfoque basado en el riesgo se
puede aplicar a la revisión de código con el código seleccionado basa en la complejidad, criticidad o la experiencia del
desarrollador.
Los defectos encontrados durante la revisión de código deben ser registrados con las acciones correctivas y preventivas,
según corresponda.
Procedimientos para el mantenimiento y el control de versiones múltiples de código fuente deben estar disponibles. En la
práctica esto se logra a menudo usando software de gestión de la configuración comercial por ejemplo, CVS, Microsoft Visual
SourceSafe o IBM Rational ClearQuest.
Siempre que sea posible deben ser utilizados ambientes separados, para el desarrollo y para los testeos. Estos deben ser lo
más similar posible al entorno de producción para el sistema con el fin de asegurar la validez de las pruebas del sistema.
Especificación de testeos
La especificación de testeos describe las pruebas que se realizan para asegurar que el sistema cumple con los requisitos de
los usuarios. Los scripts de testeos deben ser escritos de forma clara. Las pruebas deben probar límites, las fallas y
condiciones de estrés, así como la ejecución exitosa de la funcionalidad requerida. Debe haber trazabilidad de los requisitos.
Debe ser posible demostrar que toda la funcionalidad requerida ha sido probada de forma adecuada.
Es una buena práctica para los tests para ser escritos por alguien que no sea el desarrollador y ejecutados por otra persona
independiente.
Resultados esperados deben estar claramente identificados y los resultados obtenidos se deben documentar con pruebas
suficientes para demostrar el cumplimiento. Las desviaciones de las etapas de testeso o resultados esperados deben estar
documentados.
Las fallas de los tests deben ser registradas e investigadas. Dependiendo del impacto de la falla y la criticidad de las opciones
de la función, puede incluir corregir el código y volver a probar la función (y otras funciones implicadas) o proporcionar una
solución de procedimiento.
Las pruebas pueden llevarse a cabo utilizando un software de testeos automatizados. Deben existir procedimientos que
cubran el mantenimiento de la herramienta de testeos y los scripts de testeos. Los softwares y herramientas de testeos
automatizadas deben ser validados.
Las pruebas pueden existir en diferentes niveles con:
Testeos de unidad (o módulo) – se trata de pruebas técnicas, a veces realizada por el desarrollador, para demostrar que
los módulos de código individual o funciones performan correctamente
Testeos de integración – aseguran que los módulos funcionan correctamente juntos como un sistema en su
conjunto. Esta fase puede incluir la verificación de las interfaces con otros sistemas, aunque las pruebas de la interfaz
puede ser una fase separada.
Testeos de aceptación de usuario – esta fase confirma que las necesidades de los usuarios se han cumplido
Es aceptable tener cada vez mayor formalidad aplicada a fases de prueba en términos del grado de documentación de la
prueba y las pruebas recogidas.
Informe de validación
El informe de validación resume las actividades de validación asociadas con el desarrollo del sistema. Contiene un resumen
de las conclusiones de testeos e informes sobre otros requisitos de validación, por ejemplo, entrenamiento de usuarios y
procedimientos actualizados. Proporciona recomendaciones para la aceptación del sistema. El Informe también presenta una
estrategia para mantener el sistema en un estado validado. Cuando hay alguna excepción a los entregables requeridos por el
plan de validación, éstas se detallan en el informe junto con una justificación. Cualquier acción a ser completada después de
la implementación del sistema debe ser rastreada hasta su finalización.
El Informe de Validación debe ser aprobado antes de que el sistema entre en uso operacional.
Liberación / instalación
La liberación e implementación del sistema se basa en el cumplimiento de los entregables de validación y otros requisitos
previos necesarios para la gestión del sistema. Estos pueden incluir: una construcción confirmada desde el sistema de
gestión de configuración, los procedimientos de instalación, manuales de referencia técnica, manuales de referencia del
sistema, manuales de operación del sistema, procedimientos de procesos, capacitación.
En el artículo II, desarrollamos, estrategia de mantenimiento y gestión del cambio, medidas de seguridad, firmas y registros
electrónicos, e integridad de datos. para leerlo haga click aquí.
Además para aquellos interesados en el tema, le proponemos un Taller sobre el tema, consúltenos en info@cgmpdoc.com
Tags: Ciclo de vida de sistemas computarizados, CSV, cumple 21 CFR Parte 11, parte 11, Sistemas computarizados, Validación de sistemas
computarizados
Nivel de Validacion de los sistemas computarizados
La validación es mandatoria para los sistemas GxP.
El nivel de la validación dependerá de la configuración del software y de cómo el proveedor diseñó, desarrolló y testeó el
sistema computarizado (hardware y software).
La evaluación del proveedor y la categoría del software (de acuerdo a la GAMP5) son claves en el proceso de análisis de
riesgo e influenciarán en la determinación de cuanto esfuerzo será requerido para la validación del sistema computarizado.
Les dejo los flujogramas propuestos para las actividades de validación de las categorías 3, 4 y 5, de acuerdo a la GAMP5
(2008).
Flujograma para un sistema de categoría 3.
Flujograma para un sistema de categoría 4 (adaptado).
Flujograma para un sistema de Categoría 5 (a medida).
¿Qué tipos de sistemas computarizados debemos considerar?
En principio los relacionados a las actividades de controles del proceso, los relacionados al laboratorio, las aplicaciones de IT
y lo relacionado a infraestructura.
Espero que les haya resultado interesante.
Tags: Categoría 3, Categoría 4, Categoría 5, CSV, GAMP5, GxP, ISPE, testeos, URS, Validación de sistemas computarizados
2 Comments.

10 Problemas Frecuentes en CSV

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

10 Problemas Frecuentes en CSV

Загружено:

Авторское право:

Доступные форматы

1/5/2018 BLOG para cGMPdoc.

com » Validación de sistemas computarizados

BLOG para cGMPdoc.com

Posts tagged ‘Validación de sistemas computarizados’

Pero mencionemos algunos de ellos:

3. Falta de detalles necesarios

También podes mencionar la falta de criterios de aceptación.

5. Vaga redacción o texto ambiguo

6. Resultados de las pruebas no verificables

7. Buena práctica de documentación (BPD)

10. Falta de 1 proceso para resolver desvíos

Los documentos y registros más vulnerables:

Especificaciones (incluyendo el URS) las más frecuentes

Menos problemas relacionados a CSV conducen a una inspección exitosa.

El control de cambios y los sistemas computarizados

El proceso de control de cambios

Veamos cada una de las etapas:

El testeo debe verificar lo siguiente:

La nueva versión del sistema es entonces liberada para el entorno productivo.

25 preguntas sobre CSV

El análisis de riesgo en CSV

Registro del sistema y determinación del impacto regulatorio

Clasificación de riesgo del sistema

El status GxP del sistema

Estos factores son registrados en el sistema de registro.

Análisis de riesgo funcional

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

A modo de ejemplo podemos utilizar los siguientes valores:

Bajo riesgo (1-4)

Riesgo medio (5-10)

Alto riesgo (>10)

Check list para auditoría de sistemas computarizados

1. Desarrollo del Sistema

2. Gestión del sistema

Introducción al ciclo de vida de los Sistemas computarizados (Parte II)

Soporte, estrategia de mantenimiento y Gestión del Cambio

(b) no hay un impacto inesperado en las funciones del sistema relacionadas.

Cantidad de cambios del sistema

Copias de seguridad y restauración

Un par de temas más…

Retiro o decomiso del sistema

y para los que quieren profundizar el tema:

Introducción al ciclo de vida de los Sistemas computarizados (Parte I)

¿Qué es una auditoría de sistemas informáticos en una planta GMP?

Ciclo de Vida de los sistemas computarizados

Es importante determinar el papel de Aseguramiento de la Calidad (QA) en la gestión de los sistemas

La GAMP5 clasifica a los sistemas en 4 categorías:

Programación del sistema.

Las pruebas pueden existir en diferentes niveles con:

Nivel de Validacion de los sistemas computarizados

La validación es mandatoria para los sistemas GxP.

Flujograma para un sistema de categoría 3.

Flujograma para un sistema de categoría 4 (adaptado).

Flujograma para un sistema de Categoría 5 (a medida).

¿Qué tipos de sistemas computarizados debemos considerar?

Espero que les haya resultado interesante.

Вам также может понравиться