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.












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;
Especificao
Requisitos Usurio

Especificao
Funcional
Especificao
de Design
Construo do
Sistema





Qualificao de
Performance
Qualificao de
Operao
Qualificao de
Instalao

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 GxP
1
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 Ato documentado, realizado
durante a produo rotineira.

1
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.












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.
Avaliar os riscos iniciais e
determinar os impactos no Sistema
Identificar funcionalidades que tem impacto na
qualidade do produto e na vida do paciente
Avaliar funcionalidades ligadas ao risco e
identificar controles
Implementar e verificar controles adequados
Rever os riscos e monitor os controles




Passo 1
Passo 2
Passo 3
Passo 4
Passo 5

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 Agncia Nacional de Vigilncia Sanitria
BPF Boas Prticas de Fabricao
CLP Controlador Lgico Programvel
CM Controle de Mudanas
CRM Customer Relationship Management
CSV Computer System Validation
ERP Enterprise Resource Planning
ERU Especificao Requisitos Usurio
FDA Food and Drug Administration
GAMP5 Good Automated Manufacturing Practice
GED Gerenciamento Eletrnico de Documentos
GMP Good Manufacturing Practices
GxP G = Good; P = Practices; x = qualquer atividade vinculada qualidade
ISO International Organization for Standardization
LIMS Laboratory Information Management System
MES Manufacturing Execution System
PMV Plano Mestre de Validao
PMVSC Plano Mestre de Validao de Sistemas Computadorizados
POP Procedimento Operacional Padro
QI Qualificao de Instalao
QO Qualificao de Operao
QP Qualificao de Performance
RNC Relatrio de no conformidade
VSC Validao de Sistemas Computadorizados
WMS 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