Validación de sistemas computarizados

4,678 views
4,527 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,678
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
106
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Validación de sistemas computarizados

  1. 1.  Sec. 11.1 Ámbito de aplicación.  (a) Los registros electrónicos, firmas electrónicas y firmas manuscritas ejecutado a los documentos electrónicos.  (b) Esta parte se aplica a los registros en forma electrónica que se crean, modifican, mantienen archivados, recuperados o transmitidos, en virtud de los requisitos de los registros establecidos en los reglamentos de la Agencia.  (c) Cuando las firmas electrónicas y de sus registros electrónicos asociados cumplen los requisitos de esta parte, la Agencia estudiará la firma electrónica como equivalente a la firma manuscrita completo, iniciales, y otras firmas en general.
  2. 2.  d) Los registros electrónicos que cumplan los requisitos de esta parte se puede utilizar en lugar de los registros en papel. e) Los sistemas informáticos (incluyendo hardware y software), los controles y documentación correspondiente mantenido en esta parte deberán ser fácilmente disponibles para, y sujeto a la inspección de la FDA.
  3. 3. › 11.2 Aplicación.  (a) Las personas pueden utilizar los registros electrónicos en lugar de los registros en papel o la firma electrónica en lugar de las firmas tradicionales, en todo o en parte, siempre que se cumplan los requisitos de esta parte  (b) Para los documentos entregados a la agencia, las personas pueden utilizar los registros electrónicos en lugar de los registros en papel o la firma electrónica en lugar de las firmas tradicionales, en todo o en parte, siempre que:  (1) Los requisitos de esta parte se cumplen, y  (2) El documento o partes de un documento que se presentará se han identificado en el expediente público No. 92S-0251 como el tipo de presentación de la agencia acepta en forma electrónica..
  4. 4. › Sec. 11.3 Definiciones.  Biometría: el método de verificar la identidad de un individuo basada en la medición de la característica física del individuo (s) o acción repetible (s) en caso de estas características y / o acciones son particulares de cada individuo y mensurables  Sistema cerrado: un entorno en el que el acceso al sistema está controlado por las personas que son responsables por el contenido de los registros electrónicos que están en el sistema.
  5. 5. › Sec. 11.3 Definiciones.  La firma digital: la firma electrónica basada en métodos criptográficos de autenticación del emisor, calculado utilizando un conjunto de normas y un conjunto de parámetros tales que la identidad del firmante y la integridad de los datos puedan ser verificados.
  6. 6. › Sec. 11.3 Definiciones.  Registro electrónico de cualquier combinación de texto, gráficos, datos, audio, imagen o representación de otra información en forma digital que se crea, modifica, mantiene archivados, recuperado, o distribuidos por un sistema informático.  Firma electrónica: la recopilación de datos informáticos de cualquier símbolo o una serie de símbolos ejecutado, aprobado o autorizado por un individuo a ser el equivalente jurídicamente vinculante de la firma manuscrita de la persona.
  7. 7. Sec. 11.3 Definiciones.  La firma manuscrita: el nombre o la marca de secuencias de comandos legales de una persona a mano por él mismo y ejecutados o adoptados con la intención de autenticar un escrito en una forma permanente. El acto de la firma de un escrito o se conserva marcado instrumento como un bolígrafo o un lápiz. El nombre o la marca de secuencias de comandos legales, mientras que convencionalmente se aplica al papel, también puede ser aplicada a otros dispositivos que capturan el nombre o la marca.
  8. 8. › Sec. 11.3 Definiciones.  Sistema abierto significa un ambiente en el que el acceso al sistema no es controlado por las personas que son responsables por el contenido de los registros electrónicos que están en el sistema
  9. 9.  Sec. 11.10 Controles para sistemas cerrados › Las personas que utilizan sistemas cerrados para crear, modificar, mantener o transmitir documentos electrónicos se emplearán procedimientos y controles destinados a garantizar la autenticidad, integridad, y, cuando proceda, la confidencialidad de los registros electrónicos, y para garantizar que el firmante no puede repudiar a la facilidad documento firmado, como no auténtica. Dichos procedimientos y controles incluirán los siguientes:  (a) Validación de los sistemas para garantizar la exactitud, fiabilidad, prestaciones que se esperan coherente, y la capacidad de discernir los registros inválidos o alterados.
  10. 10.  (b) La capacidad de generar copias exactas y completas de registros, tanto en forma legible por humanos y electrónicos adecuados para la inspección, examen, y copia por parte de la agencia. Las personas deben comunicarse con la agencia si hay alguna duda respecto a la capacidad del organismo para llevar a cabo ese examen y la copia de los registros electrónicos. (c) Protección de los registros para permitir su recuperación precisa y listo durante el período de retención de registros. (d) Limitar el acceso al sistema a las personas autorizadas.
  11. 11.  (e) Utilización de seguro, generada por ordenador, con marca de tiempo de pistas de auditoría independiente para registrar la fecha y hora de las entradas del operador y las acciones que crear, modificar o eliminar registros electrónicos. Los cambios de registro no podrá ocultar la información previamente grabada. Tal documentación de auditoría se conservarán durante un período de por lo menos mientras que el requerido para los registros electrónicos y objeto estarán disponibles para la revisión de la agencia y la copia. (f) Utilización de los controles del sistema operativo para hacer cumplir permitido la secuencia de pasos y eventos, según proceda.
  12. 12.  (g) Utilización de los controles de la autoridad para garantizar que sólo personas autorizadas pueden utilizar el sistema, firmar electrónicamente un registro, el acceso a la operación o la entrada de sistema o dispositivo de salida, alterar un registro, o realizar la operación en cuestión. (h) Uso de dispositivo (por ejemplo, terminales) los controles para determinar, en su caso, la validez de la fuente de entrada de datos o de instrucciones de funcionamiento. (i) Determinación de que las personas que desarrollar, mantener o utilizar el registro electrónico / sistemas de firma electrónica tiene la educación, la formación y la experiencia para realizar las tareas asignadas.
  13. 13.  (j) El establecimiento de, y la adhesión a las políticas escritas de que las personas rindan cuentas y responsable de las acciones iniciadas bajo su firma electrónica, a fin de disuadir a grabar y la falsificación de la firma. (k) El uso de controles adecuados de los sistemas de documentación, incluyendo: › (1) adecuado control de la distribución, el acceso y la utilización de la documentación para la operación y mantenimiento del sistema. › (2) Revisión y modificación de los procedimientos de control para mantener una pista de auditoría que los documentos de tiempo de desarrollo de la secuencia y la modificación de los sistemas de documentación.
  14. 14.  Sec. 11.30 Controles para los sistemas abiertos. › Las personas que usan sistemas abiertos para crear, modificar, mantener o transmitir documentos electrónicos se emplearán procedimientos y controles destinados a garantizar la autenticidad, integridad, y, cuando proceda, la confidencialidad de los documentos electrónicos desde el punto de su creación, hasta el punto de su recepción. Dichos procedimientos y controles incluirán los identificados en 11.10, según corresponda, y medidas complementarias, tales como la codificación de documentos y uso de estándares apropiados para la firma digital para garantizar, según sea necesario en las circunstancias, la autenticidad de registro, integridad y confidencialidad
  15. 15.  Sec. 11.50 manifestaciones Firma.  (a) los documentos electrónicos firmados se contiene la información asociada con la firma que indica claramente todas las características siguientes:  (1) El nombre impreso del firmante  (2) La fecha y hora en que la firma fue ejecutado,  (3) El significado (por ejemplo, la revisión, aprobación, la responsabilidad, o la autoría) asociado con la firma.  (b) Los artículos señalados en los párrafos (a) (1), (a) (2), y (a) (3) de la presente sección estarán sujetos a los mismos controles que para los registros electrónicos y se incluirán como parte de cualquier forma legible del documento electrónico (como la pantalla electrónica o impresa).
  16. 16.  Sec. 11.70 Firma / registro de vinculación. Las firmas electrónicas y firmas manuscritas ejecutado a los documentos electrónicos estarán vinculados a sus respectivos registros electrónicos para asegurar que las firmas que no pueden ser extirpados, copiado o transferido de otro modo para falsificar un registro electrónico por los medios ordinarios.
  17. 17.  11.100 Requisitos generales. › (a) Cada firma electrónica deberá ser único para una persona y no podrán ser reutilizados por, o reasignado a, cualquier otra persona. › (b) Antes de que una organización establece, asigna, certifica, o de otro tipo de sanciones de firma electrónica de un individuo, o cualquier otro elemento de dicha firma electrónica, la organización deberá comprobar la identidad de la persona.
  18. 18. › (c) Las personas que utilicen la firma electrónica deberá, antes o en el momento de dicho uso, certificar a la agencia que las firmas electrónicas en su sistema, utilizado a partir del 20 de agosto 1997, están destinadas a ser el equivalente jurídicamente vinculante de las tradicionales firma manuscrita.  (1) La certificación deberá presentarse en papel y firmado con una firma manuscrita tradicional, a la Oficina de Operaciones Regionales (HFC-100), 5600 Fishers Lane, Rockville, MD 20857.  (2) Las personas que utilicen la firma electrónica, previa solicitud de agencia, proporcionar una certificación adicional o testimonio de que una firma electrónica es el equivalente jurídicamente vinculante de la firma manuscrita del firmante.
  19. 19.  Sec. 11.200 componentes de firma electrónica y los controles. › Firmas  (a) Electrónico, que no están basados en datos biométricos deberán:  (1) Emplear al menos dos componentes distintos de identificación, tales como un código de identificación y una contraseña.  (i) Cuando una persona ejecuta una serie de fichajes durante un período, continuo sistema de acceso controlado, la primera firma se llevarán a cabo utilizando todos los componentes de firma electrónica; fichajes posteriores se llevarán a cabo mediante al menos un componente de firma electrónica que sólo es ejecutable por, y diseñado para ser utilizado sólo por particulares.  (ii) Cuando una persona ejecuta una o más firmas de no realizar durante un mismo período, el acceso al sistema continuo de control, cada firma deberá ser ejecutado utilizando todos los componentes de firma electrónica.
  20. 20.  (2) ser utilizado únicamente por sus verdaderos propietarios  (3) Será administrado y ejecutado para asegurar que intento de uso de la firma electrónica de un individuo por otra persona que su propietario real requiere la colaboración de dos o más personas. (b) Las firmas electrónicas basadas en la biometría estarán diseñados para asegurar que no puede ser utilizado por nadie más que a sus verdaderos propietarios.
  21. 21.  Sec. 11.300 controles de los códigos de identificación y contraseñas. › Las personas que utilizan la firma electrónica basada en el uso de códigos de identificación, en combinación con las contraseñas se utilizan controles para garantizar su seguridad e integridad. Dichos controles deberán incluir:  (a) Mantener el carácter único de cada código de identificación y una contraseña combinado, de modo que no hay dos personas tienen la misma combinación de código de identificación y una contraseña.  (b) Asegurar que el código de identificación y publicaciones contraseña se comprueban periódicamente, recordó, o revisado (por ejemplo, para cubrir eventos como la caducidad de contraseñas). para asegurarse de que funcionan correctamente y no se han alterado en forma no autorizada.
  22. 22.  (c) A raíz de los procedimientos de gestión de pérdidas por vía electrónica a retirar la autorización perdidos, robados, perdidos o fichas por lo demás, comprometida, tarjetas y otros dispositivos que lleven o generar código de identificación o contraseña, y la expedición de sustitución temporal o permanente, utilizando adecuados, rigurosos controles. (d) Uso de garantías de transacción para la utilización no autorizada de contraseñas y / o códigos de identificación, y de detectar e informar de manera inmediata y urgente de cualquier intento de su uso no autorizado a la unidad de seguridad del sistema, y, como la gestión de su caso, a la organización .
  23. 23.  (e) los ensayos iniciales y periódicos de los dispositivos, tales como fichas o tarjetas, que llevan o generar código de identificación o información de contraseña para asegurarse de que funcionan correctamente y no se han alterado en forma no autorizada.
  24. 24.  Gestión de riesgos › Las decisiones sobre el grado de la validación y de los controles de integridad de datos se deben ser basados en una justificación y documentado mediante un análisis de riesgo del sistema automatizado respecto a su impacto en calidad del producto y seguridad así como seguridad e integridad de datos
  25. 25.  Personales › Es esencial la colaboración estrecha entre personal clave, tal como usuarios, administradores de sistema, garantía de calidad y personal técnico, implicados con el desarrollo, la validación, la gerencia y el uso de sistemas automatizados. Las personas que realizan tales papeles deben tener Cualificaciones apropiadas, entrenamiento, experiencia técnica, responsabilidades. La experiencia, adiestramiento y cualificaciones deben ser documentados así como las responsabilidades de los mismos.
  26. 26.  Validación › La gerencia deberá establecer políticas y planes para la validación de sistemas automatizados, junto con listados actualizado de sistemas y de su funcionalidad de GxP. El estado de la validación de cada sistema debe estar claro y actualizado. El grado de la validación necesario dependerá del tipo y de la complejidad de los sistemas automatizados y del análisis de riesgo documentado del sistema.
  27. 27.  Para la validación de sistemas automatizados costumizados debe haber un proceso para asegura de forma formal la calidad y el funcionamiento durante ciclo de vida del desarrollo del software y de sistema, su implementación, calificación y aceptación, operación, modificación, re- cualificación, mantenimiento, cambios y retiro.
  28. 28.  La documentación de la validación debe cubrir todos los pasos relevantes del ciclo de vida del proyecto específico con los métodos apropiados para la medida y la información. Los requerimientos del usuario deben ser detectables a través del ciclo vida del proceso de validación. Los dueños del sistema deberán poder justificar y defender sus estándares, protocolos, criterios de aceptación, procedimientos y expedientes teniendo en cuenta sus propios análisis de riesgo y de la complejidad, dirigidos a asegurar cumplimiento con las agencias reguladoras.
  29. 29.  La documentación de la validación debe incluir l control del cambio y los expedientes del registro de errores generados durante el proceso de validación. La fase de pruebas del proceso de validación: › Las herramientas de prueba automatizadas usadas para los propósitos de la validación se deben retadas en su precisión. › Evidencia de las pruebas deberán incluir, límites de los parámetros de sistema, límites de los datos y errores durante la ejecución. La gerencia deberá mantener un análisis de riesgo continuo y una revisión periódica de sistemas automatizados para determinar si existe cambio incremental, situación de funcionamiento, desarrollo de regulaciones que pudieran afectar la validación o integridad del sistema. Tales revisiones deberán incluir, registros de errores, historial de mejoras, funcionamiento, confiabilidad, seguridad y estatus de la validación.
  30. 30.  La base de data de la validación deberá incluir: › Mecanismos para asegurar integridad de datos en términos de exactitud y confiabilidad › Provisiones para la seguridad de datos  control de acceso  opiniones,  mecanismos internos de la encripción › Control/protocolos de la transacción › Acoplamientos entre diversas bases de datos › Mecanismos de la recuperación luego de una falla › Prueba de la carga (incluir las necesidades de la corriente y el crecimiento futuro de la base de datos) › Provisiones para el monitoreo de funcionamiento y crecimiento de la data de la post implementación › Archivo en línea , si aplica
  31. 31.  Las hojas de balance (Spreadsheets) deben ser comprobadas en exactitud y confiabilidad y ser almacenadas de una forma que asegure el control de versión apropiado. Los cálculos deben ser asegurados de una manera tal que las formulaciones no estén sobrescritas intencionalmente o accidentalmente. Los cálculos se deben ejecutar con la precisión exhibida en la pantalla o en informes. Las formulaciones se deben también proteger contra entrada accidental en del tipo de datos apropiado (e.g. texto en un campo numérico y o de un formato decimal en el campo numérico entero).
  32. 32.  Sistema › Deberá existir un listado de los sistemas, localización y uso y riesgo. › Registro de cambios › Seguridad ambiental › Descripción escrita del sistema y diagrama de flujo › Interacción con otros sistemas › Limites del sistema › Entradas y salidas › Almacenamiento de data principal › Requisitos de programas › Medidas de seguridad
  33. 33.  Programas (“Software”) › El programas es una parte critica del sistema deberá tener un sistema apropiado de cumplimiento de calidad, además deberá ser cualificado apropiadamente siguiendo evaluación de riesgo y auditorias. › El sistema computadorizado deberá ser diseñado y desarrollado de acuerdo al sistema de gerencia de calidad. › Documentación del suplidor deberá ser revisada y autorizada para garantizar que las necesidades de usuarios son cumplidas. › Auditorias de suplidores deberán ser realizadas y documentadas para que estén disponibles a auditorias requeridas.
  34. 34.  Data › El sistema deberá incluir verificaciones de seguridad y procesamiento de la data incluyendo data transcrita manualmente de otro medio que haga interfase con el sistema. › La Gerencia de Control deberá ser diseñado para asegurar la integridad de datos y la grabación irrefutable de la identidad de los operadores ( es decir el rechazo de contraseñas compartidas) › Los sistemas críticos se deben diseñar y proteger para asegurarse de que los datos y los archivos no se pueden cambiar sin autorizaciones apropiadas y con los registros electrónicos inmutables que registran los cambios realizados incluso en el del más alto nivel del acceso, tal como administrador de sistema.
  35. 35.  Prueba del usuario y la aptitud para el propósito del sistema › Antes de utilizar un nuevo sistema o reemplazo él se debe haber especificado, haber documentado, haber validado, haber probado y haber aprobado. El personal del usuario debe también haber recibido el entrenamiento eficaz documentado en el uso de tales sistemas .
  36. 36.  Seguridad › Controles físicos y/o lógicos deben ser establecidos para restringir el acceso a los sistemas automatizados a las personas autorizadas. Los métodos convenientes de prevenir la entrada desautorizada al sistema pueden incluir:  El uso de llaves,  Tarjetas del paso  Códigos personales con contraseñas  Biométrica  Acceso restricto al material informático  Almacenes de datos.
  37. 37. › Los accesos a usos, carpetas, los archivos y los datos deben ser controlados vía los permisos detallados dentro del sistema de seguridad de información› Debe existir métodos que registren la entrada desautorizada y/o o modificaciones de datos. Éstos los métodos pueden incluir la hora que limita la registración, la encripción, y el reingreso del identificador único para los datos críticos.› Debe haber procedimientos definidos para dar seguimiento mediante auditoria a la edición/alteración, cancelación de la autorización al acceso del sistema/del uso/de datos.› Los mecanismos para la detección de tentativas del acceso desautorizado, al sistema, los archivos y los datos se deben considerarse basados en un análisis de riesgo para poder tomar medidas apropiadas.
  38. 38.  Verificación de exactitud › Para los datos críticos entrados manualmente o transferido de otro sistema debe haber una verificación adicional de la exactitud del dato antes de la transformación posterior de estos datos. Esta verificación debe hacerse por un segundo operador o por medios electrónicos validados. › La criticabilidad y las consecuencias potenciales de datos erróneos o incorrectamente incorporados a un sistema se deben evaluarse en un análisis de riesgo y como parte de la validación.
  39. 39.  Audit Trail › El sistema debe permitir la grabación de la identidad única de operadores datos críticos que entran o que confirman. › Cualquier entrada o alteración de datos críticos se debe ser autorizada y registrada con la razón del cambio. › Registros de todas las entradas debe de creado › Los Audit trail deben ser exactos a las entradas y cambios al sistema › Todos los campos del programa deben estar conectados al Audit trail. › Audit trail debe poder estar accesible y entendible para propósitos de auditoria
  40. 40.  Firmas › Registros electrónicos pueden ser firmados electrónicamente o a mano imprimiendo una copia del registro. › Las firmas y la identificación electrónicas por medios biométricos se esperan:  sea legalmente equivalente a las firmas manuscritas  Unan a su expediente respectivos  Incluya la hora y la fecha que eran aplicadas › Las legislaciones nacionales específicas del país pueden aplicarse a los requisitos y a los controles para los expedientes electrónicos y las firmas electrónicas. Las copias impresas de documentos electrónicamente compilados y electrónicamente firmados deben ser detectable vía impresos de la transacción electrónica original.
  41. 41.  Control de cambio › Las alteraciones a cualquier componente de un sistema automatizado se deben hacer solamente de acuerdo con un procedimiento definido dentro de políticas del cambio. Éstos deben incluir la disposición para la evaluación del impacto del cambio en la calidad del producto y la integridad de los datos y de sistema, cualquier trabajo de validación necesario, información, aprobación y la ejecución del cambio.
  42. 42.  Impresiones › Impresiones de los registros deben indicar cualquier cambio de data que haya sido cambiada del registro original. Para sistemas complejos podría ser necesario inspectores con acceso a estudios electrónicos en línea del sistema.
  43. 43.  Almacenaje de data › Los datos se deben asegurar por medios físicos y electrónicos contra daño voluntarioso o accidental. › Los medios de almacenaje usados deben haber sido evaluados por el área de calidad. › Los datos almacenados se deben comprobar para saber si hay accesibilidad, durabilidad, legibilidad y exactitud. › El mecanismo de la comprobación no debe presentar un riesgo a los datos actuales sobre el sistema. El acceso a los datos se debe asegurar a través del periodo de validez.
  44. 44.  Respaldo (Backup) o migración › Los respaldos regulares de todos los datos relevantes deben ser hechos. Los datos de reserva se deben almacenar en una localización separada y segura. La integridad y la exactitud de datos de reserva se deben comprobar durante o la terminación del proceso de reserva. › Los datos archivados deben ser asegurado por medios físicos y/o electrónicos contra voluntarioso y/o accidental daño. Estos datos se deben comprobar para saber si hay accesibilidad, durabilidad, legibilidad e integridad. Si los cambios se realizan al material informático o a sus programas, entonces la capacidad de restaurar los datos debe ser comprobada. › El respaldo, el archivar, la recuperación y las prácticas de la restauración (recuperación) necesitan ser definidos, ser aprobados y ser establecidos de acuerdo con el fabricante, QMS, ISMS y análisis de riesgo.
  45. 45. › Dentro del Alcance de Validación de Facilidades automatizadas el Sistema computarizado es un componente de las operaciones de facilidades GMP. Para mantener control de un sistema computarizado es requerido validar en una forma que se establezca evidencia auditable de que el sistema realiza la función establecida conforme a la regulación 21 CFR parte 11.
  46. 46.  La validación de Sistemas Computarizados incluye:  Definir y Seguir un Plan de Validaciones  Documentar los pasos de vida del ciclo de validaciones para proveer evidencia de exactitud, confiabilidad, repetitividad e integridad de la data del sistema.  Conducir y reportar pruebas de cualificación requeridas  Revisiones Periódicas a lo largo de todo el ciclo de vida del sistema
  47. 47.  El análisis de riesgo deberá se enfocado en identificar el riesgo al ambiente GMP que regula la manufactura. › Análisis inicial deberá ser implementado en la etapa inicial de planificación e incluir la definición de los limites para determinar y documentar que sistema deberá ser incluido en el proceso de validación y porque. › Los componentes de los programas y “Hardware” principales de cada sistema deberán de ser registrados refiriendo a que proceso GMP impactan. › Segundo paso será determinar la prioridad e incluirla en “URS” requerimientos de usuario.  Definición de uso  Impacto de falla  Malfuncionamiento  El impacto en la calidad del producto sino se utiliza  Seguridad de operación › Análisis final es diseñar
  48. 48.  El tipo de Hardware o software pueden influir en el racional de validaciones y la estrategia a seguir › Software usado en manufactura GMP debe ser validado y debe ser evaluado desde la etapa inicial de diseño DQ. Sistemas complejos incluirán › “Software” Sistemas operacionales - Sistemas Operativos › “Firmware” estandar (Instrumentos Estándares, microcomputadoras, instrumentos inteligentes y controladores) -es el intermediario (interfase) entre las órdenes externas que recibe el dispositivo y su electronica, ya que es el encargado de controlar a ésta última para ejecutar correctamente dichas órdenes externas. › “Commercial Off The Shelf”. -Paquetes de Programación Estándar éstos también se llaman paquetes configurables conservado o de COTS › Software configurables › Software y Firmware Costumizables
  49. 49.  Sistemas Operativos › El sistema operativo por el mismo usualmente no se valida › Si existe una aplicación GMP “Software” en dicha plataforma, como parte de la validación de la aplicación se incluye el sistema operativo. › IQ del software:  Nombre y versión del sistema operativo  Protocolos de comunicación y establecer el uso extendido  Localización copia, debidamente identificada y en un lugar seguro.
  50. 50.  Instrumentos Estándares, microcomputadoras, instrumentos inteligentes y controladores › Software no configurables, solo permiten entrada de datos › Se requiere registrar/ documentar versión software › Documentar configuración de usuario y parámetros › Verificación de operación › El cambio de versión debe ser revisado y evaluado
  51. 51.  Paquetes de Programación Estándar éstos también se llaman paquetes configurables conservado o de COTS (“Commercial Off The Shelf”). › Documentar versión › Se requiere validar el uso › Verificar cumplimiento con las partes aplicables a CFR parte 11.
  52. 52.  Paquetes de programas configurables una característica típica de estos sistemas es que permiten que los usuarios desarrollen sus propios usos por los módulos predefinidos. › Se requiere auditoria suplidor › Validar la aplicación – Siguiendo Ciclo de validación › Ejemplos:  SCADA,LIMS, ISOTrain, Trackwise etc.
  53. 53.  Programas costumizados › Se requiere auditoria suplidor › Validar la aplicación siguiendo ciclo de validación › Evaluación impacto GMP › Risk Assesment
  54. 54.  Aplicación › Es la designación general de programas usados para realizar una función específica usando la computadora. (Ej. word processing). Configurable › Establece un sistema usando una interfases pre-definidas.
  55. 55.  Sistema Operativo › Es el programa que maneja recursos de la computadora de ” hardware” y “software”. › SO realiza las siguientes funciones:  Controlar y localizar la memoria  Prioritizar los requerimientos del sistema  Controlar mecanismos de entradas y salidas(“ input and output devices”)  Facilitar la red (“networking”)  Manejo de archivos
  56. 56.  Un plan de validaciones es un documento formal donde se indica como se llevara a cabo el ciclo de vida de la validación del sistema computadorizado. El mismo deberá incluir: › Propósito › Alcance › Políticas y procedimientos › Estrategia de Validaciones › Estructura, referencias › Localización documentos de validaciones › Descripción de las facilidades, productos, operaciones, equipos de proceso › Registros Sistemas Computadorizados › Evaluación y racional de Validaciones › Programa prioritizacion Validaciones › Justificación de sistemas a no ser validados › Responsabilidades y organización › Adiestramientos › Periodos de revisión › Programas de soporte y documentos de referencia › Análisis de riesgo y criticabilidad
  57. 57.  ¿Que es un sistema computarizado? › Sistema de Manufactura Automatizados › Sistema de Control › Sistemas Automatizados de Laboratorio › Sistemas de Ejecución de Manufactura y Computadoras que Procesa Sistema de Almacenamiento de Data (Laboratorio, Manufactura) › Sistemas que almacenan o procesan data. › El sistema computarizado posee:  “Hardware”  “Software”  “Network”  “Controlled System”
  58. 58.  Cualificación del Vendedor (Auditoría del Vendor) › Evaluación Comercial  Experiencia y soporte técnico  Evaluación de recurso técnico, incluyendo adiestramientos del Vendor  Revisión estatus financiero del Vendor › Evaluación técnica  Organización formal de QA  Estándares  SOP
  59. 59. › Desarrollo estándar del programa  Procedimientos escritos y estándares del programa.  Historia del programa  Códigos de originación disponibles para inspección.  Documentos del Programa controlados y seguros  Reportes de problemas y acciones correctivas.  Programa formal de control de cambio.
  60. 60.  User Requirements Specifications (URS) › Necesidad del usuario la cual será suplida por el sistema computarizado.  Cada requerimiento declarado es único  Requerimientos deben ser:  Claros  Concisos  Consistentes  No duplicados  Requerimientos medibles  Diferenciación entre querer y requerir  Enfoque en funciones y no en implementación de métodos
  61. 61.  User Requirements Specifications (URS)  Ambiente de operación  Limites del sistema  Data en la que operara el sistema  Data de aplicación instrumental  Funciones a ser realizadas por el sistema  Interfase con otros sistemas  Condiciones Ambientales  Acceso de Seguridad  Diagnósticos  Disponibilidad de sistemas  Pruebas y calibraciones  Restricciones
  62. 62.  “Functional Requirements Specification” (FRS) › FDS necesita claramente definir si hay alguna inconformidad con los requerimientos del usuario. › FDS deberá incluir todos los parámetro medibles que pudieran afectar el funcionamiento del sistema computarizado. › Funciones e interacción del sistema computarizado que cumplen con las necesidades del usuario.  Hardware y software  Flujo de Data (Entrada y salida de data)  Funciones de operación normal  Data de manufactura en la cual el sistema opera , conexiones y instrumentación de control al proceso  Integridad de la data (Seguridad de la Data)  Interfase con otras funciones  Almacenamiento  Información Producida  Limite de la variables del sistema
  63. 63.  Traceability Matrix › Establece un mecanismos de seguimiento entre los requerimientos de usuario, especificaciones de funcionamiento del sistema y el diseño de las pruebas para retar el sistema computarizado. De manera que asegura la implementación y eficacia del sistema validado.
  64. 64.  Pruebas del Software › Estructurales (“white- box”)  Prueba el programa mediante “inputs” y “ “outputs” esperados para demostrar que todas las opciones y enlaces pueden ejecutarse. › Funcionales (“black- box”)  Enfocado en problemas que el programa esta supuesto a resolver.  Prueba el programa mediante “inputs” y “ “outputs” a situaciones típicas y extremas.  Particularmente incluye “inputs” que describen excepciones o errores en la descripción del problema.
  65. 65.  Verificación de que todos los aspectos claves del “hardware” instalado cumplen con los códigos apropiados y las especificaciones de diseño. › Instalación Eléctrica › Ambiente (temperatura y humedad) › Componentes del hardware › Instalación de instrumentos y calibración › Suplido eléctrico y protección de los circuitos › Suplido de aire › Circuitos eléctricos › Instalación del programa › Backup del programa
  66. 66. › “Grouding”› Protecciones› Número de Modelo› Número de Serie› Piezas de reemplazo› Manuales de operación› Registros de Calibración› Verificación de versiones y configuraciones del programa.› Inspección general del sistema
  67. 67.  Compare el hardware y software, tal como se recibió, con la orden de compra (incluyendo software, accesorios, piezas de repuesto) Comprobar la documentación para la integridad (manuales de operación, instrucciones de mantenimiento, procedimientos operativos estándar para el ensayo, la seguridad y la validación de certificados) Compruebe no hayan daños en el hardware y periféricos Instalación (hardware, periféricos, dispositivos de red, cables) Instalación del software en el equipo Comprobar la instalación de software adecuado, por ejemplo, son todos los archivos con precisión las copias en el disco duro del ordenador. Utilidades para ello debe incluirse en el propio software.
  68. 68.  Hacer copia de seguridad del software Configurar los dispositivos de red y dispositivos periféricos, como impresoras y los módulos de equipo Identificar y hacer una lista con una descripción de todo el hardware, incluir dibujos en su caso, por ejemplo, para sistemas de red de datos. Haga una lista con una descripción de todo el software instalado en el equipo de Ajustes de configuración de la tienda ya sea electrónicamente o en papel Lista de manuales de los equipos y procedimientos normalizados de trabajo Preparar un informe de instalación
  69. 69.  Evidencia documentada de que cada unidad o subsistema opera según especificado en el las especificaciones de diseño a lo largo de los rangos anticipados y representativos. › Interfase de operación › Entrada y salida de datos › Almacenamiento de datos › Niveles de acceso de la seguridad › Registros y firmas electrónicas › Proceso y secuencia de operación › Lógica e interacción de control con el equipo
  70. 70. › Interfaces a otros sistemas› Exhibiciones de la pantalla› Impresión de reportes› Mensajes de error y alarmas› Informes y datos› Respaldo y recuperación (“Back Up”)› Falla de energía› Desastre y recobrado› SOPs› “Audit Trail”
  71. 71.  PQ debe proporcionar una supervisión intensiva del sistema, en un ambiente operacional, sobre un período del tiempo fijo representativo. Esto debe concentrarse en el uso de procedimientos para permitir el acceso, respaldo y recuperación, operación correcta, integridad de datos del uso, la dirección de los errores de sistema y la supervisión/investigación en cualquier abertura de la seguridad.
  72. 72.  Pruebas de cualificación operacional pueden ser usadas en la cualificación PQ › Acceso de seguridad al sistema › Verificación diagnostica › Operación de interfases › Verificación de instalación del programa › Backup del programa y restauración › Ciclo de control y operación › Alarmas › Operaciones lógicas y secuencias automáticas › Verificación SOPs › Reportes de data › Perdida de potencia y recobro
  73. 73.  Procedimiento de Mantenimiento Control de Cambio Manejo de configuraciones “Back-up and Recovery” Archivo Problemas de acceso e investigaciones Plan de desastre Protección de Virus
  74. 74.  Los procedimientos de mantenimiento del sistema validado debe tener revisión periódica y ser documentados. La revisión incluirá: › Los cambios de sistema › Registro de Problema del Sistema › Acceso y seguridad (“Audit Trail”) › Archivos de “Back-Up” › Registro de Adiestramientos.
  75. 75.  Fallo en la validación de software utilizado como parte de la producción y el sistema de calidad para su uso de acuerdo a un protocolo establecido, y la falta de documento de los resultados de la validación del software, tal como exige la norma 21 CFR § 820.70 (i). Compra de software que tiene módulos del sistema de calidad. Usted afirmó que había comprado el software y tiene previsto tenerlo instalado antes de enero de 2009, con la aplicación y validación de un plazo de 5 a 6 meses. Sin embargo, no aportó ninguna documentación sobre el sistema de software, el plan de validación, o el plan de su empresa para capacitar al personal sobre el uso del sistema ". “Algunos componentes del sistema listados no han sido recogidas en el dibujos de los sistemas de purificación de agua instalado. El software del equipo utilizado para realizar la Cálculos no ha sido validado ".
  76. 76.  a) Las pruebas de la muestra de validación y recopilación de datos se llevó a cabo el 9 de diciembre de 2008, antes de la aprobación del plan de prueba de validación. 19 de diciembre 2008; b) El paso de validación / no los criterios no se cumplió; c) El plan de pruebas de validación no se siguió, y d) La validación de los datos fue incompleta La validación del diseño de software del dispositivo no se realizó para algunas versiones del software y es insuficiente para otras versiones. En concreto, su empresa no ha realizado la validación de su Software después de cambios en la funcionalidad del software se han hecho de su primera distribución de la versión por medio de su versión actual . También la validación de software más actual de su empresa en el Software Plataforma es inadecuada en que la validación que se realizó para la versión consistía principalmente en pruebas funcionales (pruebas de caja de negro) y carece de otros elementos de validación de software, incluyendo pruebas estructurales (pruebas de caja blanca).
  77. 77.  El análisis de riesgos para un dispositivo, cuando los defectos de software son identificados como un riesgo potencial no se actualizó ni fue evaluado periódicamente. Por ejemplo, para los ocho "peligro potencial" defectos de software identificado en la versión 2.2.5 del software del sistema, no hay pruebas de que el archivo de gestión de riesgos fue revisada y actualizada para cualquiera de estos peligros potenciales. Hubo una falta de validación del programa para asegurar que todos los datos generados por el sistema era seguro. Este software ejecuta el equipo de laboratorio HPLC, genera y almacena los datos, y realiza los cálculos durante las pruebas de las materias primas, los materiales en proceso, productos terminados, y las muestras de estabilidad.
  78. 78.  Los niveles de acceso de usuario para el software no se han establecido y documentado. En la actualidad, el personal de laboratorio de uso de una contraseña común para tener acceso al sistema y no hay ningún usuario con restricciones de acceso de supresión o modificación de datos. Además, su sistema no tiene una pista de auditoría para documentar los cambios .

×