Este es el segundo de una serie de tres art\u00edculos que presentan las lecciones que nuestro equipo de validaci\u00f3n aprendi\u00f3 al completar un par de proyectos de validaci\u00f3n que utilizaban el borrador de la FDA de la Gu\u00eda de Aseguramiento del Software Inform\u00e1tico para Sistemas de Producci\u00f3n y Calidad (CSA). El n\u00famero de recursos, la cantidad de trabajo que se realiza y el n\u00famero de entregables completados son siempre m\u00e1ximos durante la fase de ejecuci\u00f3n. Por ello, en la fase de ejecuci\u00f3n es donde se producen m\u00e1s problemas durante el esfuerzo de validaci\u00f3n, lo que repercute significativamente en el coste y el calendario del proyecto. Este art\u00edculo presenta acciones que pueden llevarse a cabo para prevenir o al menos reducir el impacto de los problemas que se producen durante la aplicaci\u00f3n de las metodolog\u00edas CSA en la fase de ejecuci\u00f3n del proyecto. <\/p>\n
Lecci\u00f3n 1: Crear planes y protocolos de pruebas exhaustivos para todas las pruebas de verificaci\u00f3n<\/strong><\/p>\n El plan de validaci\u00f3n identifica los entregables necesarios para completar la validaci\u00f3n de los sistemas. Aun as\u00ed, el contenido de los planes y protocolos de pruebas debe contener informaci\u00f3n y pruebas que cumplan los requisitos de verificaci\u00f3n definidos en el plan. Un \u00e1rea problem\u00e1tica que se introduce al utilizar las directrices de la CSA es el uso de documentos generados por el proveedor para verificar requisitos de bajo riesgo. Los documentos de prueba del proveedor suelen crearse fuera del \u00e1mbito del esfuerzo de validaci\u00f3n, y muchas veces no incluyen las expectativas y los resultados documentados de las pruebas, la identificaci\u00f3n y resoluci\u00f3n de problemas, o la identificaci\u00f3n del ejecutor de la prueba y la fecha de ejecuci\u00f3n de la prueba. Las directrices de la CSA exigen esta informaci\u00f3n en la documentaci\u00f3n de las pruebas cuando se utilizan los resultados de \u00e9stas para verificar el funcionamiento del sistema. No registrar estos elementos durante las pruebas puede retrasar la finalizaci\u00f3n del proyecto debido a la repetici\u00f3n de las pruebas documentadas inadecuadamente. Eval\u00faa el programa y los procedimientos de calidad de un proveedor para confirmar que sus entregas satisfacen los requisitos de la gu\u00eda en cuanto a registros adecuados. Si se revisan las pruebas del proveedor y no satisfacen estos requisitos, es posible modificar las pruebas para que cumplan la orientaci\u00f3n antes de que se ejecuten. Podr\u00eda consistir en a\u00f1adir un espacio adicional para iniciales\/fechas, hacer referencia a una resoluci\u00f3n para un problema encontrado o explicar el objetivo de la prueba con mayor claridad. Un enfoque proactivo para actualizar los documentos de las pruebas de los proveedores puede eliminar la reejecuci\u00f3n de las pruebas de los proveedores que originalmente no cumplen los requisitos de documentaci\u00f3n de la CSA para verificar los registros GxP. <\/p>\n Lecci\u00f3n 2: Supervisa de cerca todas las pruebas<\/strong><\/p>\n Recuerda que muchos proveedores est\u00e1n acostumbrados a realizar sus pruebas de desarrollo y de f\u00e1brica con poca supervisi\u00f3n, registro informal de los resultados de las pruebas y documentaci\u00f3n nominal de los problemas y sus resoluciones. Documentar formalmente los resultados de sus pruebas, registrar los problemas que encuentran (y su resoluci\u00f3n), y firmar y fechar todas las entradas de datos suelen ser pr\u00e1cticas nuevas. Incluso despu\u00e9s de asistir a una sesi\u00f3n de formaci\u00f3n para explicarles el nuevo proceso de pruebas\/documentaci\u00f3n, es posible que vuelvan a caer en los viejos h\u00e1bitos, sobre todo al tratar los problemas y las desviaciones. Esto puede hacer que los resultados de las pruebas y la documentaci\u00f3n entregados no cumplan los requisitos de buena documentaci\u00f3n (GDP) para su uso en el esfuerzo de validaci\u00f3n. Implantar mecanismos de supervisi\u00f3n continua para detectar y resolver los problemas r\u00e1pidamente durante la ejecuci\u00f3n puede minimizar el n\u00famero de resultados inaceptables de las pruebas realizadas por el proveedor. Es especialmente importante supervisar los resultados del proveedor durante las pruebas finales de desarrollo y las FAT, cuando el proveedor se centra en conseguir la aprobaci\u00f3n del sistema para su env\u00edo y no en generar una documentaci\u00f3n de validaci\u00f3n aceptable. <\/p>\n Lecci\u00f3n 3: Comunicaci\u00f3n\/Colaboraci\u00f3n<\/strong><\/p>\n Los planes de validaci\u00f3n que siguen las metodolog\u00edas de validaci\u00f3n existentes requieren una comunicaci\u00f3n eficaz y mucha flexibilidad durante su ejecuci\u00f3n. El empleo de nuevas pr\u00e1cticas con la gu\u00eda CSA magnifica la importancia de utilizar estas dos herramientas a lo largo de la vida del proyecto. Deben celebrarse reuniones que se centren en los problemas, especialmente los relacionados con la adhesi\u00f3n a la gu\u00eda CSA. Fomenta la franqueza en el equipo, ya que algunos miembros pueden sentirse inc\u00f3modos con los cambios y necesitar refuerzos para actuar como es debido. Fomenta un enfoque colaborativo de la desviaci\u00f3n y la resoluci\u00f3n de problemas tambi\u00e9n durante estas reuniones. Establece canales de comunicaci\u00f3n claros para informar y abordar los problemas, proporcionar actualizaciones al proyecto e identificar los recursos adecuados para completar las tareas. Estas acciones ayudan a mantener el calendario del proyecto acelerando la resoluci\u00f3n de problemas, manteniendo informados a los miembros del equipo y aumentando la eficacia de la ejecuci\u00f3n. Una buena pr\u00e1ctica es crear una matriz de trazabilidad de requisitos al principio del proyecto y actualizarla durante cada paso de validaci\u00f3n. Esto identifica cada riesgo de requisito, su rigor de prueba asociado y el documento que verifica los resultados de la prueba para el requisito, pero tambi\u00e9n documenta visualmente el progreso del proyecto, identifica cualquier cambio en los entregables y minimiza las lagunas identificadas cuando el proyecto est\u00e1 a punto de terminar. Esta capacidad de cambiar r\u00e1pidamente la validaci\u00f3n minimizar\u00e1 su impacto en los planes de pruebas y el calendario. <\/p>\n La fase de ejecuci\u00f3n siempre ser\u00e1 la m\u00e1s impredecible de un proyecto de validaci\u00f3n, y la aplicaci\u00f3n de las directrices de la CSA expone a muchos recursos a una filosof\u00eda de validaci\u00f3n del software diferente a la que estaban acostumbrados, lo que puede hacer que las pruebas sean a\u00fan m\u00e1s impredecibles. Poner en pr\u00e1ctica las acciones sugeridas en este art\u00edculo puede eliminar parte de esta imprevisibilidad de la fase de ejecuci\u00f3n, corrigiendo los problemas en una fase temprana del proyecto para reducir la reelaboraci\u00f3n posterior. Los entregables de la fase de ejecuci\u00f3n son extremadamente importantes porque proporcionan a cualquier revisi\u00f3n reglamentaria o futura pruebas documentadas de c\u00f3mo se valid\u00f3 el sistema. Los resultados de la validaci\u00f3n deben ser claros, concisos y completos, y verificar que se cumplen los requisitos del sistema, por muchas pruebas y repeticiones que haya que hacer, as\u00ed que tiene sentido prepararse para hacerlo bien a la primera. <\/p>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":42,"featured_media":316669,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[536],"tags":[301,348,351,444,445],"resource-featured-status":[],"resource-type":[],"class_list":["post-374638","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automatizacion-automatizacion-y-tecnologias-de-la-informacion-integridad-de-datos-sistemas-informaticos","tag-fda","tag-drug-manufacturing","tag-gmp","tag-validation","tag-csa"],"acf":[],"featured_image_src":"https:\/\/caiready.com\/life-sciences\/wp-content\/uploads\/sites\/2\/2024\/03\/Part-2.jpg","featured_image_src_square":"https:\/\/caiready.com\/life-sciences\/wp-content\/uploads\/sites\/2\/2024\/03\/Part-2.jpg","author_info":{"display_name":"Madison Sutton","author_link":"https:\/\/caiready.com\/life-sciences\/es\/blog\/author\/madison-sutton\/"},"_links":{"self":[{"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/posts\/374638","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/users\/42"}],"replies":[{"embeddable":true,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/comments?post=374638"}],"version-history":[{"count":0,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/posts\/374638\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/media\/316669"}],"wp:attachment":[{"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/media?parent=374638"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/categories?post=374638"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/tags?post=374638"},{"taxonomy":"resource-featured-status","embeddable":true,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/resource-featured-status?post=374638"},{"taxonomy":"resource-type","embeddable":true,"href":"https:\/\/caiready.com\/life-sciences\/es\/wp-json\/wp\/v2\/resource-type?post=374638"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Los requisitos de riesgo medio o alto suelen verificarse mediante protocolos m\u00e1s robustos que se crean utilizando procesos y procedimientos que cumplen las GxP y que son revisados y aprobados por el fabricante del medicamento en lugar del proveedor. Estos resultados de las pruebas suelen contener todos los elementos enumerados en la CSA para un registro de pruebas aceptable. Al crear estos documentos, una buena pr\u00e1ctica es incluir una secci\u00f3n en los protocolos que identifique los requisitos verificados con pruebas que ya se han completado y no requieren m\u00e1s verificaci\u00f3n. Por ejemplo, las Pruebas de Aceptaci\u00f3n en el Emplazamiento (SAT) pueden hacer referencia a las Pruebas de Aceptaci\u00f3n en F\u00e1brica (FAT) o a las pruebas de desarrollo que verifican requisitos de bajo riesgo. Las Cualificaciones de Instalaci\u00f3n y Funcionamiento pueden hacer referencia a las SAT o FAT del mismo modo. La aprobaci\u00f3n de protocolos que contengan estas secciones proporciona pruebas de que los grupos de Validaci\u00f3n y Garant\u00eda de Calidad aceptaron estos resultados antes de pasar a la siguiente fase de pruebas. Seguir estas pr\u00e1cticas evita que se ejecuten pruebas excesivas e innecesarias, y evita sorpresas a las partes interesadas del proyecto cuando revisen los requisitos y los resultados de las pruebas m\u00e1s adelante en el proyecto. <\/p>\n
Un m\u00e9todo utilizado para proporcionar esta supervisi\u00f3n adicional consiste en celebrar breves reuniones de estado durante las pruebas del proveedor para responder preguntas y reforzar los requisitos de las pruebas. Revisar una muestra de los resultados de las pruebas durante estas reuniones y presentar ejemplos de resultados de pruebas correctamente documentados, especialmente al principio de las pruebas, puede verificar su cumplimiento de los protocolos, proporcionar un ejemplo visual de resultados de pruebas correctamente registrados y evitar tener que cambiar muchos resultados de pruebas documentados m\u00e1s adelante en el proyecto. Estos cambios a\u00f1aden un n\u00famero sorprendente de recursos y tiempo a las fases posteriores del proyecto, por lo que es una buena pr\u00e1ctica revisar los resultados de las pruebas al principio para evitar que causen problemas m\u00e1s adelante. Este tipo de supervisi\u00f3n tambi\u00e9n agiliza la resoluci\u00f3n de problemas en las primeras fases del proyecto, ya que desaconseja la pr\u00e1ctica anterior de los proveedores de se\u00f1alar muchos problemas detectados durante las pruebas de desarrollo e incluso las FAT, pero no completar la reparaci\u00f3n hasta las pruebas SAT o de cualificaci\u00f3n. Esto era aceptable antes de la CSA porque la mayor\u00eda de las empresas s\u00f3lo aceptaban los resultados de las pruebas de cualificaci\u00f3n durante su esfuerzo de validaci\u00f3n. Aun as\u00ed, es un problema cuando los resultados de las pruebas de desarrollo y FAT se utilizan como registros apropiados en la validaci\u00f3n del sistema. <\/p>\n