Validao de Sistemas Computadorizados

Letcia Lacerda Silva Departamento de Computao Pontifcia Universidade Catlica de Gois (PUC GO) Goinia, GO Brasil
lsleticia@uol.com.br

Abstract. This article describes about the topic of Computer Systems Validation a subject of international scope for industries subject to GMP Good Manufacturing Practices. In Brazil, the regulator ANVISA requires industries with this feature validate software. In this context, here are listed the concepts, scope, methodology, types of validation and examples of features that require validation within the pharmaceutical industry. Resumo. Este artigo descreve sobre o tema Validao de Sistemas Computadorizados um assunto de abrangncia internacional para as indstrias sujeitas BPF Boas Prticas de Fabricao. No Brasil, o rgo regulamentador ANVISA exige que as indstrias com esta caracterstica estejam com os softwares validados. Neste contexto, aqui sero listados os conceitos, a abrangncia, a metodologia, os tipos de validao e exemplos de funcionalidades que exigem validao dentro da indstria farmacutica.

1. Introduo
O conceito de validao foi proposto pela primeira vez em meados de 1970 por dois funcionrios do FDA Food and Drug Administration, com o intuito de se melhorar a qualidade dos produtos farmacuticos. Nesta poca, existiam problemas crticos na indstria farmacutica que envolvia equipamentos, procedimentos, processos e tarefas realizadas. Somente em 1997 este conceito foi estendido para o software, dando incio a uma nova era na indstria farmacutica, chamada de Validao de Sistemas Computadorizados, que o tema deste artigo, que abordar o conceito, a aplicabilidade, a importncia, os tipos de validao, os softwares a serem validados e o ciclo de vida de CSV Computer System Validation (Validao de Sistemas Computadorizados ou Validao de Software).

2. Trabalhos relacionados Conceito e Importncia

A norma ISO 8402 [1] prega que Qualidade a: Totalidade de caractersticas de um produto ou servio que lhe confere a capacidade de satisfazer as necessidades explcitas e implcitas. Dentre as atividades previstas nesta norma, ressaltamos os tpicos abaixo, onde possvel perceber que os termos verificao e validao so tratados separadamente. Garantia da Qualidade ou verificao conjunto de atividades planejadas e sistemticas implementadas no sistema da qualidade e demonstradas como necessrias para prover confiana adequada de que uma entidade atender aos requisitos para a qualidade.

Auditoria ou validao exame sistemtico e independente para determinar se as atividades da qualidade e seus resultados esto de acordo com as disposies planejadas, se estas foram implementadas com eficcia e se so adequadas consecuo dos objetivos. J na Engenharia de Software, so utilizados os termos verificao, validao e teste (VV&T)", que prega testes de sistemas para garantir confiabilidade do software em complemento a outras atividades, como por exemplo, o uso de revises e de tcnicas formais e rigorosas de especificao e de verificao. Para o FDA [2], o conceito de validao a confirmao por testes e evidncias objetivas de que as especificaes de software estejam em conformidade com as necessidades dos usurios e requerimentos previstos, e tambm a documentao de dados que proporciona um alto grau de certeza de que um processo especfico produzir consistentemente um produto que cumpre pr-determinadas especificaes e atributos de qualidade. Conforme pode ser observado, o termo Validao de Sistemas Computadorizados similar ao da ISO 8402 [1] e tambm da etapa VV&T da Engenharia de Software, onde, o principal objetivo garantir que um sistema atender as suas especificaes em todos os aspectos do processo, incluindo a aplicao, qualquer hardware que usa o aplicativo, todas as interfaces com outros sistemas, os usurios, treinamento e documentao. Atualmente, a atividade de teste ainda no empregada em todas as fbricas de software, porm notvel que a sua aplicao contribui para que o software tenha o mnimo de erros possvel. Para as indstrias sujeitas BPF Boas Prticas de Fabricao, por exemplo, as indstrias farmacuticas, a etapa de Validao de Sistemas Computadorizados uma exigncia e, um tpico que cada vez mais est sendo cobrado nas auditorias peridicas do rgo regulamentador ANVISA (Agncia Nacional de Vigilncia Sanitria), pois, atesta um alto grau de confiabilidade dos sistemas, com foco na segurana dos produtos que oferecem risco sade humana. Abaixo esto listadas as principais vantagens da Validao de Sistemas Computadorizados: Reduo de perdas no processo; Menor incidncia de desvios; Maior racionalizao das atividades desenvolvidas; Criao de bases slidas para o desenvolvimento de programas de treinamento.

3. Ciclo de Vida CSV

A figura 1 exemplifica as etapas da categoria 04 (quatro) do Ciclo de Vida de Validao de Sistemas Computadorizados, segundo o GAMP5 Good Automated Manufacturing Practice, que sero detalhadas nas subsees abaixo: O Ciclo de Vida chamado de ciclo em V, devido disposio das atividades. O lado esquerdo do ciclo de vida da validao traz muitos benefcios. Por exemplo: com

a documentao dos Requisitos de Usurio e Especificaes, possvel rastrear todos os requisitos e suas alteraes, evitando que o usurio fique dependente do fornecedor e impedindo que a informao se perca com o tempo, como por exemplo, com a sada de pessoas da equipe interna. O lado direito do ciclo de vida da validao composto pelo protocolo de testes e seu devido uso para testar o sistema. Aqui h trs tipos de protocolos, cada um com caractersticas prprias, conforme ser detalhado nas subsees abaixo. Os protocolos de testes devem ser o mais detalhado possvel, para abranger todas as funcionalidades, restries e necessidades de parametrizao no software em questo.
Especificao Requisitos Usurio Qualificao de Performance

Especificao Funcional

Qualificao de Operao

Especificao de Design

Qualificao de Instalao

Construo do Sistema

Figura 1. Ciclo de vida GAMP

3.1. Especificao Requisitos Usurio (ERU) o primeiro documento do ciclo de vida. Nele deve ser descrito o que o sistema deve fazer. N ormalmente, elaborado pelo usurio final, mas, em alguns casos, pode ser elaborado pelo fornecedor do software e aprovado pelo usurio final. Abaixo, exemplos de tpicos a serem inseridos neste documento: Segurana das operaes e dos acessos ao sistema; Requisitos funcionais e operacionais desejveis; Origem dos dados a serem utilizados e manipulados. Especificar por exemplo se dever ser desenvolvida alguma integrao com outros softwares; Definio da configurao do ambiente onde o software ser executado. Ex: Software de Pesagem integrado com balanas de pesagem; Performance exigida;

Aspectos legais a serem atendidos; Alguma possvel restrio; Em caso de software de terceiro, especificar a documentao que dever ser fornecida. Ex: manuais, dicionrios de dados, especificaes funcionais e especificaes tcnicas. 3.2. Especificao Funcional Nesta etapa deve ser definido como o sistema vai atender s necessidades do usurio, listadas na ERU, ou seja, para cada requisito deve ser dada uma resposta de como ser a implementao. O documento aqui gerado descreve as funes que o sistema executa e deve conter: Requisitos Funcionais (Ex: funes configuradas e objetivo) e No Funcionais (Ex: tolerncia a falhas e disponibilidade); Requisitos de Dados (Ex: diretivas de capacidade e armazenamento); Interfaces (Ex: tela, interface com outros equipamentos e softwares). 3.3. Especificao de Design O documento aqui gerado deve conter a configurao dos componentes do sistema em questo, dividida em: Overview (Ex: documento se refere a parte de hardware ou software); Configurao (Ex: configurao dos equipamentos, programas, infraestrutura, construo, instalao e banco de dados utilizado); Hardware (Ex: computadores, requisitos mnimos e sistema operacional exigido). 3.4. Qualificao de Instalao (QI) O protocolo QI contm os requisitos mnimos exigidos para a parte do hardware que se comunicar com o software em questo, conforme as recomendaes e/ou os requerimentos do fornecedor, dentre eles: computadores, servidores, memria disponvel, tamanho do disco rgido, leitores de cdigo de barra e impressora de etiquetas. E, para cada um dos dispositivos de hardware, o usurio deve especificar a configurao do seu hardware. 3.5. Qualificao de Operao (QO) O protocolo de QO contm todos os testes a serem executados pelo usurio, para comprovar que o sistema est executando as atividades previstas. Deve ser observada a cronologia relativa aos testes de QI/QO, onde, a QO s deve ser realizada aps concluso e aprovao da QI.

Para cada teste a ser realizado, o usurio deve anexar as contraprovas (ideal que sejam apresentadas as imagens as telas do software) e especificar se o teste foi satisfatrio ou no. Para cada teste no satisfatrio, deve ser aberto um RNC Relatrio de No Conformidade, que ser enviado ao responsvel pela ao corretiva, e este deve entrar em contato com o fornecedor do software. Caso o problema seja suscetvel a correo, aps envio de nova verso pelo fornecedor, ser necessrio repetir o tpico especfico da QO para o qual foi aberto RNC, at que toda QO tenha sido finalizada com sucesso. Caso o problema no seja corrigido via software (seja por conceito do software ou indisponibilidade do fornecedor), dever ser adicionado um comentrio no POP (vide sub-tpico 3.8 deste artigo). 3.6. Qualificao de Performance (QP) A execuo do protocolo de QP visa garantir que o sistema quando operando em conjunto capaz de executar com eficcia e dentro do tempo esperado, os mtodos e as especificaes definidas no protocolo. Deve ser observada a cronologia relativa aos testes de QO/QP, onde, a QP s deve ser realizada aps concluso e aprovao da QO. O protocolo de QP pode ser realizado em dois momentos distintos, que so: Ainda na fase de testes, quando o sistema no est em produo neste caso, o fornecedor deve especificar o tempo de resposta do software, de acordo com o hardware especfico. Deve ser levado em considerao tanto a capacidade do hardware local como a velocidade da rede de trabalho. Aps o sistema estar em produo aqui, podem ser realizados testes que garantem que o sistema est executando todas as operaes programadas corretamente, aps vrias atividades simultneas. Este tipo de abordagem mais simples de ser executada do que o anterior. Aps a finalizao da execuo dos testes de performance emitido um relatrio parcial de QP, onde os testes realizados so descritos de forma sucinta, bem como os resultados encontrados e a aceitabilidade ou no desta fase do processo de validao. Este deve ser revisado/aprovado, pela rea dona do sistema, o setor de TI/Engenharia e por ltimo pela Garantia da Qualidade. 3.7. Relatrio final de validao Aps realizao dos protocolos de testes, dever ser elaborado o relatrio final de validao, onde devem estar descritos os documentos que fazem parte do pacote de validao, o resultado obtido ao trmino da validao, os usurios responsveis e os aprovadores. Sugere-se que os usurios da rea afetada e da garantia da qualidade assinem como aprovadores da documentao gerada.

3.8. Criao dos Procedimentos Operacionais Padro Ao ser finalizada a validao, necessrio criar/revisar os POPs Procedimentos Operacionais Padro, de maneira que neles estejam todas as atividades ligadas ao software. Esta importante atividade deve ser feita pelos usurios da rea afetada pela validao, com o apoio da equipe de TI. O ideal que o sistema s permita inseres corretas por parte do usurio, porm, nem sempre isto possvel, pois o que correto para uma empresa pode no ser para outra e, isto acabaria por engessar o software. Porm, a empresa precisa criar mecanismos para garantir que todas as atividades a serem executadas pelo usurio final do sistema esto em conformidade com o padro, sem nenhum desvio que possa acarretar falhas ao processo. E, a maneira correta para isto garantir que os POPs esto sempre atualizados, e sendo utilizados pelas reas responsveis. Abaixo, exemplos de atividades que devem estar registradas em POPs: Backup e restaurao de aplicativos e dados; Procedimento de limpeza da base de dados; Plano de Contingncia, em caso de indisponibilidade de algum dispositivo necessrio ao funcionamento do software; Procedimentos de Manuteno Preventiva e Corretiva; Controle de Alteraes; Reviso Peridica; Reteno de Arquivos; Retirada do Sistema de Operao.

4. Tipos de Validao
A utilizao de softwares na indstria farmacutica iniciou-se antes da necessidade de validao, portanto, a maioria das indstrias j possui softwares em utilizao e que no so validados. Porm, todos os softwares utilizados, que tem impacto GxP1 precisam ser validados. Atualmente, podemos conduzir a validao de trs abordagens diferentes, explicadas pela ANVISA [3]: Validao prospectiva Ato documentado, baseado na execuo de um plano de testes, que ateste que um novo sistema, processo, equipamento ou instrumento, ainda no operacionalizado, satisfaz as especificaes funcionais e expectativas de desempenho. Validao simultnea ou concorrente durante a produo rotineira.
1

Ato documentado, realizado

GxP: G = Good; P = Practices; x = qualquer atividade vinculada qualidade. O x poderia ser substitudo por: manufatura, laboratrio, logstica. Ex: GMP Boas Prticas de Fabricao.

Validao retrospectiva Ato documentado, baseado na reviso e anlise de registros histricos, atestando que um sistema, processo, equipamento ou instrumento, j em uso, satisfaz as especificaes funcionais e expectativas de desempenho. Na validao retrospectiva ou simultnea mais difcil executar as etapas da primeira parte do V do ciclo de vida, uma vez que o fornecedor do software pode no ter as documentaes necessrias para a execuo das atividades de Validao do Sistema em questo. J na validao prospectiva este tipo de problema no deve acontecer, pois, um dos fatores a ser avaliado na escolha do fornecedor deve ser a disponibilidade em fornecer todas as documentaes exigidas.

5. Plano Mestre de Validao

O PMV Plano Mestre de Validao [4] o documento que contm as definies do programa de validao executado na organizao. Aqui devem conter no somente as diretivas de software, mas tambm as diretivas de todos os tpicos a serem validados na indstria farmacutica, como por exemplo: Mtodos analticos, Limpeza, Processos Produtivos e Utilidades. A empresa pode optar em ter um nico PMV para todos os pontos de validao, ou, ter um PMV para tudo que no seja de software e um segundo plano que pode ser chamado de PMVSC Plano Mestre de Validao de Sistemas Computadorizados, especfico para a parte de software. Esta segunda abordagem mais interessante, uma vez que existem particularidades especficas da parte de software, que se tratadas separadas, podem ser melhor detalhadas. O PMVSC deve conter os seguintes tpicos: Objetivo e Escopo definio do objetivo da empresa perante a validao dos sistemas, e quais softwares sero validados; Definio dos responsveis por efetuar qualquer reviso no plano; Inventrios de sistemas computadorizados, especificando quais softwares devero ser validados e a prioridade a ser empregada na validao; Cronograma de validao; Estratgia da validao a ser aplicada na empresa, contendo detalhes do ciclo de vida e o tipo de validao que sero adotados; Definio no Plano de Controle de Mudanas suportado pelos softwares, de maneira a garantir que o software continue como validado, mesmo aps sofrer alteraes; Definio das responsabilidades de cada um dos integrantes do projeto de validao (OBS: dono do sistema, rea responsvel pela validao e garantia da qualidade); Anexo com os templates para cada documento do ciclo de vida da validao.

6. Controle de Mudanas
Uma das atividades mais importantes do ciclo de vida de sistemas validados o controle de todas as mudanas ocorridas no mesmo. As organizaes que possuem softwares validados devem definir uma metodologia eficaz de CM Controle de Mudanas, de modo a garantir que todas as mudanas ocorridas sejam previamente avaliadas. Todas as mudanas realizadas no software, processo, hardware ou infraestrutura, seja durante o projeto ou aps a fase de validao devem ser analisadas, para definio da necessidade de abertura de um Controle de Mudanas. importante frisar que qualquer interveno do tipo melhoria, manuteno e correo de erros/bug, podem fazer com que o sistema perca o status de validado. Da a importncia de avaliao das alteraes. Para a criao de uma metodologia de CM necessrio uma equipe multidisciplinar, visto que uma interveno nestes sistemas pode ter impacto em vrias reas dentro da organizao. Como por exemplo, a rea solicitante, a rea responsvel por executar a alterao proposta, a rea usuria do sistema e a garantia da qualidade (que geralmente a responsvel em avaliar tais intervenes, bem como a necessidade de realizao de testes adicionais ou revalidao). Uma metodologia eficaz de CM deve ter como escopo todo o ciclo de vida do sistema, ou seja, deve levar em considerao a metodologia utilizada pela empresa, a avaliao do impacto da aquisio/desenvolvimento de um novo sistema/projeto, a manuteno, a atualizao e por ltimo a fase de encerramento do ciclo de vida. A avaliao de mudanas deve levar em considerao tanto as normas reguladoras voltadas para a atividade de validao de sistemas, quanto as normas especficas da rea e/ou processo informatizado pelo sistema. Aps cada software validado, deve ser definida uma poltica que especifique os itens que podem ou no gerar a abertura de um CM. Sabemos que mudanas so inevitveis, sejam de carter corretivo, evolutivo ou mesmo emergencial, porm elas devem ser controladas e rastreadas de forma que o seu impacto no produto final no seja negativo, e sim, possam agregar valor e qualidade ao processo e conseqentemente ao produto final. Neste cenrio, a anlise de riscos uma ferramenta que pode auxiliar no processo de gerenciamento destas mudanas, assunto este que ser detalhado a seguir.

7. Anlise de Riscos
A atividade de Anlise de Riscos em Validao de Sistemas Computadorizados muito complexa, mas deve sempre ser executada, para que os possveis riscos oriundos da utilizao do software sejam identificados e monitorados o mais cedo possvel no ciclo de vida. Os responsveis pela identificao dos riscos devem ter os seguintes conhecimentos: Nvel do impacto do sistema computadorizado para a sade do paciente; Processos de negcio suportados;

Requisitos do usurio; Requisitos regulatrios, ou seja, exigncias legais; Sistema de componentes e arquitetura; Funcionalidades do sistema; Detalhes do contrato de software. Inicialmente devem ser identificados os perigos, ou seja, as funcionalidades que podem gerar algum tipo de erro. Durante esta avaliao devem ser consideradas as falhas do sistema e aquelas ocasionadas por erros do usurio ao operar o sistema. Ex: insero de um componente manualmente na ordem de produo, que no faz parte da receita do produto que ser produzido. Com base nos perigos, devem ser avaliados os danos ocorridos. Ex: para o perigo anteriormente citado, possvel afirmar que o produto final ser produzido com adulterao da frmula originalmente registrada na ANVISA. Agora, com base no dano, deve ser avaliado o impacto na segurana do paciente e na qualidade do produto. Ex: o produto com sua frmula alterada poder trazer efeitos colaterais ao paciente que o consumir. O guia GAMP5 [6] sugere a execuo das atividades listadas na figura 2 na atividade de anlise de riscos.
Avaliar os riscos iniciais e determinar os impactos no Sistema

Passo 1

Passo 2

Identificar funcionalidades que tem impacto na qualidade do produto e na vida do paciente

Passo 3

Avaliar funcionalidades ligadas ao risco e identificar controles

Passo 4

Implementar e verificar controles adequados

Passo 5

Rever os riscos e monitor os controles

Figura 2. Atividades para Gerenciamento de Riscos

7.1. Avaliar os riscos iniciais e determinar os impactos no sistema (Passo 1) A avaliao inicial dos riscos baseada no conhecimento dos processos do negcio, dos requisitos do usurio, dos requisitos regulatrios e das funcionalidades das reas. No passo 1 deve ser avaliado se o sistema tem impacto GxP.

Caso ao trmino do passo 1 seja identificado que o nvel do risco j est dentro do aceitvel, os demais passos da atividade no precisaro ser executados. 7.2. Identificar funcionalidades que tem impacto na qualidade do produto e na vida do paciente (Passo 2) As funcionalidades identificadas no passo 1 que tem impacto na qualidade do produto e na vida do paciente devem ser melhor detalhadas, levando-se em considerao a especificao, o objetivo do projeto, a arquitetura do sistema e a categorizao dos componentes do sistema. 7.3. Avaliar funcionalidades ligadas ao risco e identificar controles (Passo 3) As funcionalidades identificadas no passo 2 devem ser avaliadas, levando-se em considerao os riscos envolvidos e as tcnicas utilizadas para reduzir os impactos dos danos, caso o risco acontea. A empresa deve criar pontos de controle para mitigao dos riscos. Exemplos de boas prticas a serem seguidas que contribuem com a mitigao dos riscos: Evitar alteraes no projeto; Avaliar o processo, para evitar que o mesmo seja alterado; Durante a especificao, utilizar o maior nvel de detalhes possvel, para evitar alteraes funcionais; Evitar utilizao de termos tcnicos nas documentaes que sero aprovadas por usurios que no so da rea de Tecnologia da Informao; Implementar POPs Procedimentos Operacionais Padro nos processos que contemplam possveis falhas de usurio; Implementar Trilha de Auditoria nos cadastros, para que seja possvel identificar o usurio e a data em que foi realizada qualquer alterao; Aplicar diversos testes que comprovem que o sistema desempenha suas funcionalidades corretamente em condies de erros ou que possua condies de tratamento para os mesmos; Garantir que os usurios do sistema esto treinados nas operaes a serem desempenhadas. 7.4. Implementar e verificar controles adequados (Passo 4) Os pontos de controle detectados no passo 3 devem ser validados, para certificar que foram corretamente implementados, e que os riscos realmente esto sendo mitigados. 7.5. Rever os riscos e monitor os controles (Passo 5) Os riscos j identificados devem ser revistos periodicamente, para certificar que os pontos de controle definidos realmente esto sendo empregados da melhor maneira possvel, e tambm para avaliar o surgimento de novos riscos.

8. Inventrio de Sistemas Computadorizados

Os softwares utilizados na empresa devem ser identificados e controlados, de maneira que possam ser facilmente acessados pelos usurios responsveis. A primeira atividade elencar todos os softwares utilizados na empresa e avaliar quais deles devero ser validados. Em seguida, avaliar os riscos de cada um dos softwares e, por ltimo, com base na pontuao de riscos obtida, montar o cronograma de validao de todos os softwares, levando em considerao que os softwares de maior pontuao no risco devem ser os primeiros a serem validados. responsabilidade da rea de Informtica o controle do parque de softwares, mas, durante sua confeco todas as reas da empresa devem ser consultadas, para validao das informaes armazenadas. Qualquer alterao no parque de informtica seja de incluso de novos softwares ou retirada de produo de um software deve ser atualizada no parque. Alm do software propriamente dito, tambm devem ser controladas todas as planilhas eletrnicas que so responsveis por alguma atividade que tenha impacto GxP. A maneira mais fcil de identificar os sistemas que precisam ser validados avaliar se a funcionalidade por ele executada substituiu alguma operao manual ou crtica para o processo. Neste caso, o software deve ser validado, para garantir que no houve nenhuma reduo na qualidade dos produtos produzidos com a automatizao do processo. Nesta seo os sistemas computadorizados sero apresentados conforme padronizao global, utilizada inclusive pela ANVISA [5], onde os softwares so classificados conforme sua atuao, sendo eles: Sistema de Gesto (Ex: ERP Enterprise Resouce Planning, Logstica e CRM Customer Relationship Management); Operaes de Fabricao (Ex: MES Manufacturing Execution System, LIMS Laboratory Information Management System e WMS Warehouse Management System); Sistema de Automao (Ex: CLP Controlador Lgico Programvel). 8.1. Sistema de Gesto 8.1.1. Sistema ERP ERP Enterprise Resource Planning ou Sistema Integrado de Gesto Empresarial so sistemas de informao que integram os dados e processos da organizao em um nico sistema. A integrao pode ser vista sob a perspectiva funcional (sistemas de finanas, contabilidade, recursos humanos, fabricao, marketing, vendas, compras, etc) e sob a perspectiva sistmica (sistema de processamento de transaes, de informaes gerenciais, de apoio a deciso, etc). Na implantao de novos ERPs, o ideal que o ciclo de vida da validao seja completo. Tambm devem ser validadas as informaes que sero importadas do sistema legado para o novo e qualquer interface com outro sistema que se faa necessria. Abaixo exemplo de funcionalidades que devem ser validadas em um ERP:

Toda a parte de rastreabilidade produtiva dos produtos; Qualificao dos fornecedores; Recebimento de materiais, validando gerao do lote gerado; Quarentena virtual dos materiais e do produto acabado; Armazenamento de materiais no estoque, validando endereamento, movimentaes e transferncias; Criao de Ordem de Produo, validando gerao do lote gerado e se componentes esto em conformidade com a formulao cadastrada; Controle da produo; Controle da estabilidade, validando se sistema gera corretamente os lotes que precisam de teste de estabilidade; Controle do Skip Lote, validando se o sistema est fazendo o controle correto de intercalao dos lotes de materiais a serem inspecionados pelo setor de recebimento de materiais; Rastreabilidade das movimentaes de produtos acabados, controlando as sadas (Ex: venda, doao e descarte) e entradas (Ex: devoluo). 8.1.2. Sistema CRM CRM Customer Relationship Management ou Gesto de Relacionamento com o Cliente so softwares que automatizam as funes de contato com o cliente, com o objetivo de assegurar um bom relacionamento e conseqentemente aumento das vendas. Dentro do CRM esto os softwares de gerenciamento dos pedidos de venda, SAC Servios de Atendimento ao Cliente e Farmacovigilncia (atividade que controla os desvios que surgem aps um medicamento estar em utilizao no mercado). Para a parte de Farmacovigilncia ideal seguir todo o ciclo de vida da validao, para garantir que todos os riscos sejam levantados e todos os testes sejam realizados. 8.1.3. Sistema GED GED Gerenciamento Eletrnico de Documentos so softwares que permitem o armazenamento dos documentos de maneira eletrnica, o que facilita o seu controle, manuteno e manuseio. Os documentos armazenados em forma eletrnica devem ter o mesmo cuidado dos armazenados manualmente, por isto, o software deve ser seguro e confivel. A validao deve seguir todo o ciclo de vida. 8.2. Operaes de Fabricao 8.2.1. Sistema WMS WMS Warehouse Management System ou Sistema de Gerenciamento de Armazm so softwares que automatizam o fluxo de produtos dentro dos armazns. Normalmente,

o software integrado com dispositivos de rdio freqncia, leitores de cdigo de barra e robotizao. Softwares deste tipo devem ser validados seguindo todo o ciclo de vida, uma vez que h automatizao na maioria das atividades. A parte de testes deve ser bastante intensa, para garantir acuracidade das operaes realizadas. 8.2.2. Sistema MES MES Manufacturing Execution System ou Sistema de Execuo da Produo so solues tecnolgicas que tem o objetivo de gerenciar todas as etapas de produo. Normalmente, o MES integrado com o ERP e gerencia e sincroniza as tarefas produtivas com o fluxo de materiais. A validao do software do tipo MES deve seguir todo o fluxo de vida da validao. Sistemas Integrados de Pesagens so exemplos de softwares do tipo MES. 8.2.3. Sistema LIMS LIMS Laboratory Information Management System ou Sistema de Gerenciamento das Informaes no Laboratrio so solues tecnolgicas que propiciam um software de gerenciamento das atividades no laboratrio, integrado com equipamentos de anlise, tipo autoclaves e HPLCs. Softwares deste tipo so muito complexos, pois, depende da integrao com cada um dos equipamentos utilizados no laboratrio e, devem seguir todas as etapas do ciclo de vida da validao. Deve ser definido POP de calibrao dos equipamentos, para que os resultados sejam sempre precisos. Os testes aqui efetuados devem ser bastante precisos, uma vez que este software responsvel pelos resultados dos testes que garantem que o produto est em conformidade com o padro e pode ser liberado para venda aos consumidores. 8.3. Sistema de Automao 8.3.1. Sistemas embarcados So sistemas microprocessados no qual o computador completamente encapsulado ou dedicado ao dispositivo ou sistema que ele controla. Normalmente h um CLP Controlador Lgico Programvel que realiza um conjunto de tarefas pr-definidas, geralmente com requisitos especficos. Para esse tipo de sistema no necessria a criao de um protocolo para a qualificao do equipamento e outro para a validao do sistema. O mesmo protocolo pode conter tanto testes para demonstrar o correto funcionamento do equipamento quanto do sistema nele contido. Exemplos de equipamentos que possuem sistemas embargados e que precisam ser validados: autoclaves, drageadoras e encartuchadoras.

8.3.2. Sistemas individuais (stand alone) So sistemas de automao de alguma parte da indstria, que so chamados de individuais por existirem isolados dos demais sistemas. Exemplos de softwares que aqui se enquadram: Sistema de Monitoramento Microbiolgico, Sistema de Tratamento de Ar e Sistema de Monitoramento Ambiental. O resultado obtido com estes sistemas impactam na qualidade do produto, e, por isto so exigidos pela ANVISA nas indstrias sujeitas BPF. A criticidade dos dados tratados por este tipo de sistema e a integrao com diversos componentes fsicos, tais como sensores que exigem que o sistema seja validado. 9. Termos, siglas e definies A tabela 1 apresenta os termos e as siglas utilizados neste artigo e suas definies.
Tabela 1. Termos utilizados

ANVISA BPF CLP CM CRM CSV ERP ERU FDA GAMP5 GED GMP GxP ISO LIMS MES PMV PMVSC POP QI QO QP RNC VSC WMS

Agncia Nacional de Vigilncia Sanitria Boas Prticas de Fabricao Controlador Lgico Programvel Controle de Mudanas Customer Relationship Management Computer System Validation Enterprise Resource Planning Especificao Requisitos Usurio Food and Drug Administration Good Automated Manufacturing Practice Gerenciamento Eletrnico de Documentos Good Manufacturing Practices G = Good; P = Practices; x = qualquer atividade vinculada qualidade International Organization for Standardization Laboratory Information Management System Manufacturing Execution System Plano Mestre de Validao Plano Mestre de Validao de Sistemas Computadorizados Procedimento Operacional Padro Qualificao de Instalao Qualificao de Operao Qualificao de Performance Relatrio de no conformidade Validao de Sistemas Computadorizados Warehouse Management System

10. Concluso Este artigo trata de Validao de Sistemas Computadorizados, um tema atual e bastante discutido em indstrias farmacuticas, alimentcias, veterinrias e demais sujeitas BPF, onde o rgo regulamentador ANVISA que assegura a qualidade dos produtos e processos, passou a exigir tambm a validao dos softwares utilizados nas atividades que tem impacto GxP. A validao de sistemas no uma atividade isolada e independente, ela deve ser executada e sempre reavaliada ao longo do ciclo de vida do software, para garantir que o seu estado ser sempre validado mesmo aps qualquer alterao sofrida pelo software. As atividades do ciclo de vida de validao so rduas e devem ser executadas com bastante cautela e padronizao, de maneira que, qualquer membro da equipe possa seguir as atividades de validao definidas pela empresa. O ideal que j no incio do projeto seja alocado prazo para as etapas da validao, mas, nem sempre isto possvel, uma vez que a maioria das indstrias j est com o software instalado, porm, no validado. Mas, isto no deve ser motivo para no iniciar a atividade de validao, e sim uma motivao para conseguir validar o software atravs da validao retrospectiva. Estima-se que com o tempo, as indstrias sujeitas BPF que estejam praticando a atividade de Validao de Sistemas Computadorizados, se destaquem em relao s suas concorrentes, pois, elas tm maior probabilidade de oferecer um software sem erros, que atenda s necessidades dos usurios. 11. Referncias [1] ISO 8402 (1994) Quality management and quality assurance. Disponvel em: http://www.iso.org/iso/catalogue_detail.htm?csnumber=20115 Acessado em: 06/09/2009 [2] FDA (2009) Food and Drug Administration. Disponvel em: http://www.fda.gov Acessado em: 13/09/2009 [3] ANVISA (2001) Glossrio de definies legais Disponvel em: http://www.anvisa.gov.br/medicamentos/glossario/glossario_V.htm Acessado em: 06/09/2009 [4] Tutorial Computer System Validation Disponvel em: http://www.labcompliance.com/tutorial/csv/default.aspx Acessado em: 06/09/2009 [5] Guia VSC ANVISA Disponvel em: http://www.anvisa.gov.br Acessado em: 11/10/2009

[6] GAMP5 A Risk-Based Approach to Compliant GxP Computerized Systems Editor: Sion Wyn Publicado em: 2008