[:pb]A decisão de executar uma validação de software pode vir de uma exigência normativa ou pela demanda de proteção e garantia dos dados. Tudo depende do valor que a informação pode representar para o negócio.

Porém, a validação de software pode ser um assunto confuso até mesmo entre as empresas que são obrigadas a executá-la. Mas fique tranquilo, neste post iremos desmistificar de vez este assunto.

Vamos lá?

O que é validação de software?

A validação de software é um processo que comprova documentalmente que o sistema cumpre com as funções das quais foi designado, em conformidade com as especificações dos requisitos do usuário e com a garantia de segurança e rastreabilidade de informações.

Minha empresa precisa fazer validação de software?

Qualquer empresa pode optar por executar o procedimento de validação do software como ação de boas práticas para evitar danos ao consumidor e a imagem da empresa.

Mas para alguns segmentos, como é o caso das industrias farmacêuticas, é uma exigência que determinados sistemas computadorizados sejam validados de modo a garantir o cumprimento de sua função.

Qualquer sistema computadorizado precisa ser validado?

Infelizmente não existe uma lista mestra contendo todos os nomes de todos os sistemas que os órgãos regulamentadores exigem que sejam validados. Porém existem guias de perguntas, como o Guia da ANVISA, que ajudam a classificar se o sistema precisa ou não ser validado.

Basicamente, todos os sistemas computadorizados que tenham relação direta ou indireta com a produção de medicamento/produto para saúde ou impacto na rastreabilidade dos mesmos devem ser validados.

Por onde começar a validação de software?

Como ponto de partida, muitas empresas utilizam o guia GAMP5 (Good Automated Manufacturing Practice) – Boas Práticas de Manufatura Automatizada. O guia está atualmente na versão 5, e apresenta como eixo central a estratégia de validar baseado em risco (A Risk Based Approach to Compliant GxP Computerized Systems).

O Guia da ANVISA, que tem o GAMP5 como principal referência, utiliza muito o termo BPx.

BPx – Boas Práticas – é a tradução do termo GxP, usado no Guia de validação de sistemas da ANVISA.

GxP – Good Practices – termo geral para aplicação de boas práticas relacionadas a qualquer área (fabricação, distribuição, pesquisa clínica, laboratório, etc.).

Basicamente, se o sistema tem impacto BPx, então existe a necessidade de validação do sistema. O segundo passo é verificar se o sistema é ou não validável. Depois disso, segue-se para o plano de validação, como mostra o fluxograma abaixo.

Não existe um modelo padrão para o Plano de Validação. Na verdade, cada empresa pode elaborar o seu Plano Mestre de Validação com base em suas políticas e metodologias.

Independente do plano, algumas documentações fazem parte do escopo:

• URS (User Requirement Specification)
• FRS (Functional Requirement Specification)
• IQ (Installation Qualification)
• OQ (Operational Qualification)
• PQ (Performance Qualification)
• etc. (traremos mais detalhes quanto ao escopo destes documentos em um próximo post)

Uma vez realizada a validação, é necessário um gerenciamento de manutenção e verificação da validade dos procedimentos. Tais procedimentos são representados pelos componentes destacados em preto no Fluxograma 1 e fazem parte das atividades de suporte do sistema.

Para compreender melhor a  a necessidade e a importância de tais procedimentos durante e após a validação, é preciso compreender a definição do Ciclo de Vida de um sistema. Ele é composto de quatro fases principais: Conceito, Projeto, Operação e Descontinuidade.

Mas atenção, o Ciclo de Vida aqui descrito não deve ser confundido com a necessidade de se definir abordagem ou método para desenvolvimento de software pelo fornecedor.

As etapas dentro da fase de Projeto são as etapas que também podem acontecer durante a fase de Operação, quando houver a necessidade de mudanças.

As etapas do projeto são:

Planejamento

É importante que os requisitos do usuário estejam claros e documentados. A abordagem desta fase deve estar baseada no entendimento do processo, produto e requisitos regulatórios pertinentes.

Em muitos casos é necessário cumprir com os requisitos da FDA CFR 21 Part 11, que se prevista desde o início do projeto, traz a segurança e rastreabilidade necessária para o bom uso do sistema.

Especificação e Configuração

A etapa de especificação visa permitir que o sistema seja desenvolvido na etapa de configuração, verificado e mantido.

Verificação

São realizados testes de desafio com o objetivo de verificar se as especificações foram atendidas, podendo envolver vários ciclos de revisão e testes dependendo do tipo de sistema, método de desenvolvimento utilizado e seu uso.

Relatório

Recomenda-se que o relatório contemple o resumo das atividades realizadas, desvios encontrados, eventos inesperados, ações corretivas e a comprovação da conformidade aos requisitos especificados e ao uso pretendido para o sistema.

A aceitação e liberação de um sistema com impacto em BPx requer a aprovação do responsável pelo processo, responsável pelo sistema e representante da unidade da qualidade.

Resumo

• A validação na verdade é apenas uma parte do Ciclo de Vida do sistema, do qual desenvolve-se uma série de atividades de suporte para gerenciamento de todas as fases do Ciclo.
• A validação de software é um processo de construir evidências documentadas de que o sistema faz o que ele deve fazer. Isto expressa bem o benefício que a validação pode trazer e a  justificativa  para o esforço de executá-la.
• Buscamos neste post mostrar para você os primeiros passos para compreender o processo de validação de software e por onde começar a partir de uma visão macro de todas as etapas, demonstrando a exigência de um forte envolvimento também das áreas de qualidade e produção.

Propositalmente, deixamos de lado um assunto essencial dentre as atividades de suporte ao processo de validação de software, que é o Gerenciamento de Riscos. É fundamental buscar aplicá-lo em todas as fases do Ciclo de Vida para remover ou reduzir os riscos a um nível aceitável.

Você pode continuar a leitura sobre esse assunto no artigo Como realizar o gerenciamento de riscos na validação de software?

Se você ficou com alguma dúvida sobre o processo de validação de software, escreva para a gente nos comentários. Se a sua empresa precisa de ajuda com a validação de software ou cumprimento com a FDA CFR 21 Part 11, entre em contato conosco para mais detalhes de como a nossa equipe pode auxiliá-lo neste processo.[:es]La decisión de ejecutar una validación de software puede venir de un requisito normativo o por la demanda de protección y garantía de los datos. Todo depende del valor que la información puede representar para el negocio.

Sin embargo, la validación de software puede ser un asunto confuso incluso entre las empresas que están obligadas a ejecutarla. Pero quédese tranquilo, en este post nosotros vamos a desmitificar de una vez para siempre este asunto.

¿Vamos allá?

¿Qué es la validación de software?

La validación de software es un proceso que demuestra a partir de documentos que el sistema cumple con las funciones de las cuales fue designado, de acuerdo con las especificaciones de los requisitos del usuario y con la garantía de seguridad y trazabilidad de informaciones.

¿Mi empresa necesita hacer la validación de software?

Cualquier empresa puede optar por ejecutar el procedimiento de validación de software como acción de buenas prácticas para evitar daños al consumidor y la imagen de la empresa.

Pero para algunos seguimientos, como es el caso de las industrias farmacéuticas, es una exigencia que determinados sistemas computarizados sean validados para garantizar el cumplimiento de su función.

¿Cualquier sistema computarizado necesita ser validado?

Desafortunadamente, no existe una lista maestra con todos los nombres de todos los sistemas que los organismos reguladores exigen que se validen. Pero existen guías de preguntas, como la Guía de la ANVISA (Agencia Nacional Brasileña de Vigilancia Sanitaria), que ayudan a clasificar si el sistema necesita o no ser validado.

Básicamente, todos los sistemas computarizados que tengan relación directa o indirecta con la producción de medicinas/producto para la salud o impacto en la trazabilidad de los mismos deben ser validados.

¿Por dónde empezar la validación de software?

Como punto de partida, muchas empresas utilizan la guía GAMP5 (Good Automated Manufacturing Practice) – Buenas Prácticas de Manufactura Automatizada. La guía está actualmente en la versión 5, y presenta como eje central la estrategia de validación basada en riesgos (A Risk Based Approach to Compliant GxP Computerized Systems).

La Guía de la ANVISA, que tiene el GAMP5 como principal referencia utiliza mucho el término BPx.

BPx – Buenas Prácticas – es la traducción del término GxP, usado en la Guía de validación de sistemas de la ANVISA.

GxP – Good Practices – término general para aplicación de las buenas prácticas relacionadas con cualquier área (fabricación, distribución, investigación clínica, laboratorio, etc.).

Básicamente, si el sistema tiene impacto BPx, entonces existe la necesidad de validación del sistema. El segundo paso es comprobar si el sistema es o no validable. Después de eso, se sigue al plan de validación, como muestra el diagrama de flujo a continuación.

No existe un modelo estándar para el Plan de Validación. En realidad, cada empresa puede elaborar su Plan Maestro de Validación basado en sus políticas y metodologías.

Independiente del plan, algunas documentaciones forman parte del alcance:

• URS (User Requirement Specification)
• FRS (Functional Requirement Specification)
• IQ (Installation Qualification)
• OQ (Operational Qualification)
• PQ (Performance Qualification)
• etc. (vamos a ver más detalles sobre el alcance de estos documentos en un próximo post)

Una vez realizada la validación, es necesaria una gestión de mantenimiento y verificación de la validez de los procedimientos. Estos procedimientos son representados por los componentes destacados en negro en el diagrama de flujo 1 y forman parte de las actividades de soporte del sistema.

Para comprender mejor la necesidad y la importancia de estos procedimientos durante y después de la validación, es necesario comprender la definición del Ciclo de Vida de un sistema. Se compone de cuatro fases principales: Concepto, Proyecto, Operación y Discontinuidad.

Pero atención, el Ciclo de Vida aquí descrito no debe confundirse con la necesidad de definir el enfoque o método para el desarrollo de software por el proveedor.

Las etapas dentro de la fase de Proyecto son las etapas que también pueden ocurrir durante la fase de Operación, cuando haya la necesidad de cambios.

Las etapas del proyecto son:

Planificación

Es importante que los requisitos del usuario estén claros y documentados. El enfoque de esta fase debe estar basado en el entendimiento del proceso, producto y requisitos regulatorios pertinentes.

En muchos casos es necesario cumplir con los requisitos de la FDA CFR 21 Part 11, que si se prevé desde el inicio del proyecto, trae la seguridad y trazabilidad necesaria para el buen uso del sistema.

Especificación y Configuración

La etapa de especificación tiene como objetivo permitir que el sistema sea desarrollado en el paso de configuración, verificado y mantenido.

Verificación

Se realizan pruebas de reto con el objetivo de verificar si las especificaciones fueron atendidas, pudiendo involucrar varios ciclos de revisión y pruebas dependiendo del tipo de sistema, método de desarrollo utilizado y su uso.

Informe

Se recomienda que el informe contemple el resumen de las actividades realizadas, desvíos encontrados, eventos inesperados, acciones correctivas y la comprobación de la conformidad a los requisitos especificados y al uso previsto para el sistema.

La aceptación y liberación de un sistema con impacto en BPx requiere la aprobación del responsable del proceso, responsable del sistema y representante de la unidad de calidad.

Resumen

• La validación en realidad es sólo una parte del Ciclo de Vida del sistema, del cual se desarrolla una serie de actividades de soporte para la gestión de todas las fases del Ciclo.
• La validación es un proceso de construir evidencias documentadas de que el sistema hace lo que debe hacer. Esto expresa bien el beneficio que la validación puede traer y la justificación para el esfuerzo de ejecutarla.
• Buscamos en este post mostrar para usted los primeros pasos para comprender el proceso de validación de software y por dónde empezar a partir de una visión macro de todas las etapas, demostrando la exigencia de una fuerte implicación también de las áreas de calidad y producción.

De modo intencional, dejamos de lado un asunto esencial entre las actividades de soporte al proceso de validación de software, que es la Gestión de Riesgos. Es fundamental buscar aplicarlo en todas las fases del Ciclo de Vida para remover o reducir los riesgos a un nivel aceptable.

Usted puede continuar leyendo sobre este tema en el artículo ¿Cómo realizar la gestión de riesgos en la validación de software?

Si usted tiene alguna duda sobre el proceso de validación de software, escriba para nosotros en los comentarios. Si su empresa necesita ayuda con la validación de software o cumplimiento con la FDA CFR 21 Part 11, póngase en contacto con nosotros  para más detalles sobre cómo nuestro equipo puede ayudarle en este proceso.[:]