39

SBCC
abril / maio / junho 2006
Bctusbdu
Este artigo discute aspectos bsicos da validao de
sistemas computadorizados, 21 CFR Part 11, benefcios
e modelos conhecidos para execuo de projetos de
validao nesta rea.
Jouspevp
Na ltima dcada, os sistemas computadorizados tm
se tornado parte vital na manufatura de Ingredientes
Ativos Farmacuticos (API), Intermedirios, Produtos
Finais e Testes Clnicos.
Aplicaes tpicas tais como Controladores Lgicos
Programveis Sistemas Supervisrios, redes de cho de
fbrica e em laboratrios qumico e microbiolgico e
integrao destes sistemas com ERPs (Enterprise Resouce
Planning), so cada vez mais comuns.
As boas prticas atuais de manufatura exigidas por
agncias como FDA (Food and Drug Administration) e
MHRA (Medicines and Healthcare products Regulatory
Agency) e TPP (Therapeutics Products Program) incluem
a validao de sistemas computadorizados que tenham
impacto na qualidade dos Produtos Farmacuticos.
A validao deve demonstrar minimamente que os
parmetros definidos como essenciais para a operao
e manuteno do estado validado devem ser controla-
dos.
A nfase deste artigo estar voltada para os sistemas
de cho de fbrica, ou seja, aqueles que tm interface
direta com o processo farmoqumico. importante frisar
que a validao de sistemas computadorizados dever
estar em consonncia com outros tipos de validao,
tais como validao de processo e a validao dos equi-
pamentos propriamente ditos. Tambm importante
frisar que os sistemas de informtica, ou IT, dependendo
da natureza de sua aplicao, ou seja, se tm ou no
impacto GxP, devem ser validados.
Ftdpqp
Daremos ateno especial aos itens relacionados
infra-estrutura e aos diferentes aplicativos de software
que so utilizados.
Um sistema computadorizado pode no possuir todas
os constituintes abaixo e dessa forma, o esforo de vali-
dao um pouco mais simplificado, porm abordare-
mos todos os tpicos a fim de que o leitor tenha uma
viso mais geral do escopo conceitual de um possvel
sistema:
Hardware
Sistema Operacional
Redes
Aplicativos
Gerenciamento de Riscos
Conformidade com 21 CFR Part 11 e EU Annex 11
introduco a
validaco de sistemas
computadorizados na
industria armacutica
Nbsjp!Mvjt!Wfsoft!ef!Boesbef
tnqcnhcirc dc uicmacc - validacc dc
:isicmas na niiLiciicas dc trasil
ccniaic: mandradcmcnci.ccm.Lr
Nbsjp!Mvjt!Wfsoft!ef!Boesbef+
bsujhp!udojdp
Validacao Sistemas.indd 39 21/06/06 18:24:14
40
SBCC
abril / maio / junho 2006
bsujhp!udojdp
Ciclo de Vida do Sistema
Controle de Alteraes
Retirada do Sistema de Operao
kequlsltos |egals
Muitas agncias regulatrias incluem em seus guias de
inspeo quesitos relacionados validao de sistemas
computadorizados. Na realidade estas agncias apenas
esto cumprindo leis de seus pases, e podemos citar
como exemplo:
Rules and Guidance for Pharmaceutical Manufacturers
and Distributors 2002 Annex 11 MHRA
Guidance for Industry Part 11, Electronic Records;
Electronic Signatures Scope and Application August
2003.
tapas da va|ldaco
1. Identificao do Sistema: Cada instalao que contm
sistemas computadorizado deve ser avaliada e os sis-
temas GxP identificados.
2. Elaborao dos Requisitos do Usurio: Estes devem
definir de maneira clara e precisa o que o usurio quer
que o sistema computadorizado faa. Devem fazer
parte destes requisitos todas as restries de seguran-
a fsica e lgica e devem ser estabelecidos os marcos
regulatrios que orientaro o projeto. Estes requisitos
devem ser testveis e devem poder ser rastreados com
o protocolo de projeto.
3. Determinao da Estratgia de Validao: Elaborar
um gerenciamento de riscos prvio, e refin-lo tanto
quanto possvel durante a etapa de elaborao do
projeto detalhado. Nesta etapa dever ser decidido se
necessria a auditoria nos fornecedores de sistemas
ou no, isto depender das caractersticas dos siste-
mas e sua criticidade em relao critrios cGxP.
4. Produzir o Plano de Validao: Nesta etapa devemos
definir quais os documentos que sero emitidos, e que
estaro suportando o esforo de validao. Tambm
deve ser definida a equipe de validao, seus papis
e responsabilidades. Caso a empresa no possua um
Plano Mestre de Validao, recomenda-se elabor-lo,
pois este orientar no s como construir o plano de
validao especfico de um dado sistema como servir
para outros sistemas a serem instalados na planta.
5. Desenvolvimento do Projeto Detalhado: Nesta fase
temos o desenvolvimento das especificaes de
hardware, software e caso aplicvel da infra-estrutura
de rede. tambm nesta fase que todas as especifi-
caes devero ser formalmente revistas e aprovadas
pelo cliente. Todos os documentos que forem produ-
zidos nesta fase devero estar em conformidade com
os requisitos do usurio e com as definies do plano
de validao.
6. A prxima etapa cobre toda a instalao e testes
necessrios produo de evidncias de que o siste-
ma obedece aos requisitos do usurio e ao projeto
do sistema. A instalao como um todo dever obe-
decer estritamente s definies contidas no projeto
detalhado, sendo que quaisquer desvios devero ser
formalmente aprovados. O teste dever ser formal,
com o executor e uma testemunha aprovando-o indi-
vidualmente. Alm disso, o teste dever possuir uma
relao clara com os requisitos e projeto detalhado,
tudo formalizado numa matriz nica de rastreabilida-
de. Ao final todos os desvios dos critrios de aceitao
dos testes notados e as aes tomadas para corrigi-los
devero fazer parte do relatrio final de testes, o qual
dever ser retido junto com as demais documenta-
es de validao.
7. O fechamento do pacote de validao de um dado
sistema dever ser feito atravs do relatrio de valida-
o onde devem estar descritos os documentos que
fazem parte do pacote de validao, e dever haver
ainda uma declarao formal assinada minimamen-
te pelos responsveis da rea afetada e pela rea de
garantia da qualidade.
8. A prxima etapa a manuteno do estado validado.
Para tanto devem ser desenvolvidos procedimentos
operacionais que regulem o controle de alteraes e
demais atividades tais como: plano de continuidade
operacional, reteno de arquivos, revises peridicas
e back-up.
9. A ltima etapa a aposentadoria, ou retirada do
sistema. Esta pode ser definida atravs de um proce-
dimento operacional que regule no s a retirada do
sistema, como tambm a guarda e recuperao dos
dados contidos no sistema retirado.
8enejiclos da va|ldaco
Uma outra forma de definirmos validao : um
processo de documentao formal das boas prticas
de desenvolvimento de softwares. Todo o conjunto de
Validacao Sistemas.indd 40 21/06/06 18:24:15
41
SBCC
abril / maio / junho 2006
informaes gerado e gerenciado atravs deste proces-
so, leva a uma conformidade comprovada do sistema,
facilitando o suporte operao, manuteno, resul-
tando desta forma em maior produtividade da rea
farmacutica.
Uma considervel parte do conjunto de conhecimento
instalado com um sistema computadorizado provm do
fornecedor ou fornecedores deste sistema. Assim cabe ao
contratante dos servios e/ou materiais exigir que haja
uma transferncia deste conhecimento para o usurio
final de forma a dar robustez ao processo de validao.
Podemos considerar como benefcios advindos deste
conhecimento os seguintes exemplos:
Um melhor entendimento do processo farmoqu-
mico: este ponto de importncia fundamental, no s
durante o processo de validao do sistema computado-
rizado, mas tambm da validao dos outros constituin-
tes do processo, tais como os equipamentos e o processo
propriamente dito. Tambm permitir alteraes mais
confiveis dentro do esprito de um controle de altera-
es rgido, fazendo com que a manuteno do estado
validado seja facilitada.
Aumento da Eficcia Operacional: com o conhecimento
mais profundo do processo, seus equipamentos e siste-
mas tm benefcios, tais como: partida do processo com
altos ndices de qualidade operacional, conhecimento e
adaptao mais rpida dos operadores e representantes
de qualidade, manuteno mais rpida e eficiente.
Reduo do Risco de Falhas: pelo fato, tanto de ope-
radores como pessoal da qualidade e de manuteno
conhecerem melhor o sistema, a ocorrncia de falhas
pode ser minimizada e a recorrncia eliminada.
Qualidade da Informao: em sistemas validados, e com
os requisitos operacionais adequadamente levantados
e detalhados em projeto, mais fcil de extrair informa-
es valiosas em tempo real. Isto permite uma tomada
de deciso com maior qualidade e rapidez.
Benefcios para o Negcio: a validao pode auxiliar na
reduo dos custos de operao e no aumento da lucra-
tividade, j que ela aumenta a eficcia operacional.
|erramentas
A melhor ferramenta para que se atinja ou mantenha
um estado validado o seguimento das boas prticas no
s de manufatura, mas tambm de documentao, teste
e engenharia. A seguir detalharemos algumas definies e
exemplos pertencentes a este tpico:
8oas ratlcas de Documentaco
As boas prticas de documentao asseguram controle
na criao, reviso, aprovao, distribuio e guarda de
documentos controlados. Podemos citar como exemplo:
A formatao da documentao deve ser definida,
incluindo-se a o layout do documento, tamanho de
letra, identificao do autor , nmero de pginas, data
e hora da impresso do documento.
Deve haver uma pgina destinada ao histrico de revi-
ses, indicando seu propsito, seu autor e data.
A documentao seja ela elaborada em mdia eletrnica
ou fsica (papel) dever ser guardada em local seguro
de acordo com procedimentos especficos elaborados
pelos responsveis pela guarda da documentao.
A documentao dever ser guardada conforme o pero-
do de reteno definido em procedimento operacional
da rea de validao de sistemas computadorizados.
Deve ser definido e formalizado, atravs de um proce-
dimento operacional, um perodo para a execuo da
reviso peridica da documentao de validao de
sistemas computadorizados, sendo esta estabelecida e
formalizada atravs de um procedimento operacional.
Esta reviso peridica dever ser documentada e seu
relatrio guardado pelo seu perodo de validade
As aprovaes devero ser documentadas e dever
constar acima da assinatura, as razes pela qual o
documento est sendo aprovado e as conseqncias
desta aprovao.
Todos os documentos superados devem ser guardados
pelo perodo de reteno definido em procedimento.
Alm disso, devem ser guardados separados dos docu-
mentos cuja reviso a mais atual.
Todos os documentos devero ser identificados de
maneira clara e precisa de forma a no incorrer em
erros na sua guarda e arquivamento.
8oas ratlcas de 1este
As boas prticas de teste asseguram que:
Todos os aspectos relevantes de um dado sistema com-
putadorizado sero cobertos, e que todos os testes
sero executados e documentados de forma que per-
mita sua rastreabilidade com os requisitos do usurio
e projeto detalhado.
Os resultados dos testes sejam apresentados de forma
clara e transparente, mostrando no s os resultados
bem sucedidos, mas tambm aqueles para o qual
necessitou-se intervir no sistema a fim de que o resul-
tado estivesse em conformidade com o respectivo
critrio de aceitao.
Os testes devem ser reprodutveis em todo o ciclo de
vida do sistema computadorizado, ou seja, devem apre-
sentar consistentemente o mesmo resultado obtido na
Validacao Sistemas.indd 41 21/06/06 18:24:17
42
SBCC
abril / maio / junho 2006
bsujhp!udojdp
primeira qualificao.
Abaixo listamos alguns exemplos de boas prticas
de teste:
1. Os testes devem ser executados de acordo com um
protocolo previamente aprovado contendo no mni-
mo um plano geral de testes e o conjunto de critrios
de aceitao para cada tipo de teste.
2. Os testes jamais podero ser executados antes da apro-
vao do protocolo acima mencionado.
3. Tanto quanto possvel os autores da planilha de teste
no devero execut-la.
4. A documentao de teste dever conter informaes
sobre quem executa o teste, sua posio, sua qualifica-
o, alm de data, hora, nmero de pginas e identifi-
cao do sistema testado.
5. Cada teste individual dever ser assinado e datado pelo
executor do teste e pela testemunha.
6. Todas as observaes, desvios de um resultado de
teste em relao ao critrio de aceitao, devero ser
registrados formalmente e guardados juntamente com
toda a documentao de teste.
7. Todos os campos de uma planilha de testes que no
forem aplicveis a um teste especfico devero ser pre-
enchidos com NA (no-aplicvel).
8. No so permitidos corretores ou rasuras. Erros devero
ser riscados com uma linha nica acima desta, deve
tambm haver um breve comentrio sobre o erro e
abaixo visto e data do executor do teste.
9. Instrumentos sendo testados dentro da arquitetura de
sistemas computadorizados devem, antes do incio do
teste, serem calibrados e seus certificados de calibrao
serem retidos como documentao GxP.
8oas ratlcas de ngenharla
Boas prticas de engenharia a aplicao de mtodos e
padres de engenharia atravs de todo o ciclo de vida do
projeto, de forma que o resultado final possua o melhor
custo-benefcio e a melhor adequao tcnica conforme
o escopo proposto. Todas as atividades num projeto de
um sistema computadorizado e que so de responsabili-
dade da Engenharia, devero seguir o processo de geren-
ciamento da qualidade implantado dentro da empresa.
Isto assegurar que os protocolos de validao sigam uma
metodologia adequada e garante que os mesmos sejam
to completos quanto possveis.
Como exemplo de atividades / produtos que identifi-
cam boas prticas de engenharia podemos citar:
Plano de Qualidade em Projetos
Plano de Validao
Descritivo de Desenvolvimento do Software
Protocolo de Requisitos do Usurio
Procedimento de Controle de Alteraes
Treinamento e Qualificao do pessoal operacional, de
manuteno e qualidade
Portanto, podemos dizer que projetos de sistemas com-
putadorizados destinados indstria farmacutica deve-
ro estar de acordo com os planos de qualidade, os quais
devem definir e documentar como os requisitos sero
alcanados. A aplicao de boas prticas de engenharia
passa tambm pela conformidade com as boas prticas
anteriormente detalhadas. Todos os requisitos anterior-
mente mencionados para sistemas computadorizados
valem tanto para projetos de IT como para automao
industrial.
|erramentas (Contlnuaco)
Outra excelente ferramenta de auxlio na validao de
sistemas computadorizados o GAMP (Good Automates
Manufacturing Practice) atualmente na verso 4 de
Dezembro de 2001. L podero ser encontradas diretrizes
e recomendaes que norteiam o esforo de validao
cobrindo desde o planejamento, execuo da validao,
operao do sistema, manuteno do estado validado, at
a retirada do sistema de operao.
Dentro do GAMP, encontra-se uma seo onde so
categorizados os diversos tipos de ferramentas de
software passveis de serem usadas para a validao e
implementao de sistemas computadorizados na inds-
tria farmacutica.
Assim sempre que formos utilizar ferramentas de
software em aplicaes GxP deveremos considerar
aspectos tais como:
Definir requisitos que permitam a avaliao do pacote
de software contra as expectativas regulatrias.
Auditar formalmente o fornecedor da ferramenta e veri-
ficar sua aderncia s boas prticas.
Testar formalmente a ferramenta e verificar que sua fun-
cionalidade est dentro das expectativas listadas nos
requisitos do usurio.
Como exemplo destas ferramentas podemos citar
softwares de programao de CLP's (Controladores
Validacao Sistemas.indd 42 21/06/06 18:24:21
43
SBCC
abril / maio / junho 2006
Lgico Programveis) e pacotes de software de interface
supervisria, entre outros.
O exposto se aplica fundamentalmente a ferramentas
do tipo COTS (Commercial Off The Shelf), ou seja, pacotes
comerciais de software prontos e que permitem a cons-
truo de aplicativos especficos.
Para ferramentas de software de aplicao especfica, os
cuidados com auditoria do fornecedor, aderncia s boas
prticas, validao, adequao ao propsito, etc. devem
ser ainda maiores.
Dbufhpsj{bp!ef!Tpguxbsf!)Hbnq!5*
Djdmp!ef!Wjeb!ep!Tjtufnb
Na elaborao do plano mestre de validao impor-
tante que se defina o ciclo de vida dos sistemas GxP que
sero validados e instalados. Para tanto se recomenda
a elaborao do ciclo de vida baseado no modelo do
GAMP. Dependendo do sistema, de sua complexidade,
categorizao conforme GAMP e criticidade nem todas
as fases abaixo necessitaro ser seguidas.
O conceito de ciclo de vida do sistema descreve todos
os aspectos relacionados ao sistema computadorizado
desde a fase de planejamento da validao at a retirada
do sistema de operao. As fases so:
Planejamento e Especificao
Projeto Detalhado e Instalao de Hardware, Software
e Rede
Teste de Hardware, Software e Rede
Aceitao do Sistema
Operao e Manuteno
Retirada do Sistema de Operao
Tvcgbtf!ef!Qmbofkbnfoup
Algumas atividades tpicas durante esta fase so:
1. Definio das Necessidades do Negcio
2. Definio da Equipe de Projeto / Validao
3. Descrio dos Requisitos Fundamentais
4. Realizar Estudo de Viabilidade
5. Alocao dos Recursos de Projeto
6. Elaborao do Plano de Qualidade do Projeto
Tvcgbtf!ef!Ftqfdjgjdbp
Nesta fase elaboramos a qualificao do projeto e os
requisitos do usurio. Baseado nestas definies podemos
realizar uma avaliao dos possveis proponentes, solici-
tando-lhes as especificaes funcionais a fim de avaliar
sua conformidade com os requisitos. Abaixo listamos
algumas atividades e seus resultados esperados pertinen-
tes a esta sub fase do ciclo de vida do sistema.
Atividade Resultado Esperado
Desenvolvimento do Plano de Validao
Plano de Validao elaborado,
revisto e aprovado.
Definio dos Requisitos do Usurio
Protocolo de Requisitos do Usurio,
elaborado, revisto e aprovado.
Elaborao da Anlise de Riscos
Produo do relatrio de anlise
de riscos
Desenvolvimento do Plano Geral de
Testes
Elaborao do Protocolo Geral de Testes
Verificao das Especificaes Funcionais
dos Fornecedores de Sistemas
Eleio da proposta com a melhor rela-
o custo / benefcio / conformidade
Auditoria no Fornecedor escolhido
(Se Necessrio)
Relatrio formal de auditoria
Colocao do Pedido N/A
Categoria
Tipo de
Software
Nvel de Validao
1
Sistema
Operacional
No necessrio que se faa uma auditoria do forne-
cedor e admite-se que a validao do mesmo dar-se-
indiretamente atravs da aplicao do teste nos aplica-
tivos que rodam sob o sistema operacional.
recomendado o registro no IQ de software infor-
maes como tipo do sistema operacional, verso,
pacotes de servio, entre outras.
2 Firmware
Recomenda-se o registro no IQ de software da verso.
Verificar formalmente na Qualificao Operacional
o funcionamento do sistema contra os requisitos do
usurio.
O Desenvolvimento de firmwares especficos deve ser
tratado como categoria 5 desta tabela
3
Pacotes de
Software
Padro
Aqui j podemos, para aplicaes crticas, considerar
uma auditoria no fornecedor do software.
Assumir como necessrios os itens mencionados para
as categorias 1 & 2.
4
Pacotes de
Software
Configurvel
Para aplicaes crticas, uma boa prtica a execuo
de uma auditoria formal no fornecedor do pacote de
software.
Adotar as recomendaes das categorias acima.
Aplicativos especiais enquadram-se como categoria 5.
5
Aplicativos
Especficos
Deve-se realizar a auditoria no fornecedor do aplicativo
especfico
Devem-se seguir todas as recomendaes anteriores
para as demais categorias.
Validacao Sistemas.indd 43 21/06/06 18:24:23
44
SBCC
abril / maio / junho 2006
bsujhp!udojdp
Os requisitos do usurio devem conter pelo menos as
seguintes caractersticas:
Requisitos relacionados ao processo e ao usurio pro-
priamente dito.
Requisitos tcnicos relacionados com interface e perfor-
mance do sistema computadorizado.
Requisitos relacionados qualidade e ao atendimento
normas regulatrias como 21 CFR Part 11.
Todo o requisito independente de sua natureza deve ser
claro, plenamente testvel e rastrevel contra os testes
e o detalhamento do projeto. A maneira mais transpa-
rente de se evidenciar isto atravs de uma matriz ou
tabela de rastreabilidade.
Qspkfup!Efubmibep!f!Jotubmbp!ef!
Ibsexbsf-!Tpguxbsf!f!Sfeft
Esta fase aplicvel somente aos sistemas categorizados
pelo GAMP como categoria 4 ou 5.
Nesta fase, deve ser elaborado, com a ajuda dos pro-
ponentes vencedores, o detalhamento do projeto de
instalao. Este detalhamento ser a pea fundamental
para a composio do protocolo de validao no que
diz respeito ao projeto detalhado. Nele definiremos os
aspectos mais relevantes, e em especial aqueles ligados aos
requisitos do usurio.
Abaixo listamos algumas atividades que so tpicas des-
ta fase do ciclo de vida do sistema computadorizado:
Projeto detalhado do sistema
Elaborao do documento de qualificao do projeto
(DQ)
Elaborao do protocolo de validao relativo ao projeto
detalhado
Montagem e pr-teste no fabricante (Teste de Aceitao
no Fabricante)
Fornecimento por parte do fabricante das documenta-
es de detalhamento finais
Instalao no cliente
Especialmente para softwares classificados como cate-
goria 5, e em alguns casos da categoria 4, deve ser exigido
formalmente do fornecedor do sistema computadorizado
que ele siga os procedimentos de padres de programa-
o do cliente, controle de alteraes e desenvolvimento
de software.
Uftuf!ef!Ibsexbsf-!Tpguxbsf!f!Sfef
O objetivo desta fase a tomada de deciso em relao
aceitao do sistema computadorizado instalado no
cliente final. Durante esta etapa, realizada a qualificao
da instalao, da operao e em alguns casos partes da
Qualificao de Performance (PQ) (teste com gua / flui-
do Inerte). Estes servios podem ou no ser contratados
do fornecedor do sistema, incluindo-se a elaborao dos
protocolos de qualificao em branco. O nvel de teste
no sistema dentro das instalaes do cliente depender
em grande parte da categorizao do sistema conforme
a classificao do GAMP e de sua criticidade quantos aos
aspectos de GxP.
Abaixo listamos algumas atividades tpicas desta fase:
1. Elaborao do Protocolo de Qualificao da Instalao
2. Elaborao do Protocolo de Qualificao Operacional
3. Execuo da Qualificao da Instalao
4. Execuo da Qualificao Operacional
5. Execuo, onde aplicvel, de partes da Qualificao de
Performance.
Todos os protocolos acima devem ser formalmente
aprovados pela equipe de validao antes de serem exe-
cutados.
A elaborao e o preenchimento das planilhas de teste
dever seguir as boas prticas de documentao e de teste
acima listadas.
A cronologia relativa aos testes de IQ / OQ deve ser
seguida com bastante cuidado. Recomenda-se que o
IQ, ou pelo menos as partes mais crticas dele sejam
integralmente testadas antes do incio da qualificao
operacional.
Aps a instalao, a qualificao operacional verificar
a adequao das especificaes funcionais de um dado
sistema. A complementao do IQ, OQ e partes do PQ,
quando aplicvel, permite a execuo da qualificao de
performance no seu sentido mais amplo e encaminha o
sistema para a sua aceitao.
Bdfjubp!ep!Tjtufnb
Esta uma etapa que ao ser completada permite a sada
do sistema da fase de implementao e sua entrada na
fase de operao e manuteno, na qual ele permanecer
a maior parte do seu tempo de vida til.
Terminados os testes, emitida e aprovada toda a docu-
mentao necessria formalizao deste status, elabora-
se e aprova-se o protocolo de aceitao do sistema onde
indicaremos quais protocolos foram desenvolvidos, os
documentos fornecidos por terceiros, etc.
nesta fase que aplicamos, e sua complementao tam-
bm faz parte da aceitao do sistema, o treinamento aos
usurios e manutencistas do sistema computadorizado.
A execuo do PQ, dependendo do sistema, poder
consistir de um perodo de observao e monitoramento
da arquitetura de automao, ou ser a prpria validao
de processo.
Validacao Sistemas.indd 44 21/06/06 18:24:25
45
SBCC
abril / maio / junho 2006
Pqfsbp!f!Nbovufop!ep!Tjtufnb
Uma vez o sistema estando validado, necessrio que
se mantenha o estado alcanado. Para tanto necess-
rio que uma parte da equipe de validao e os usurios
trabalhem conjuntamente a fim de desenvolver pro-
cedimentos operacionais padro. Estes procedimentos
abordam uma srie de temas operacionais e regulatrios
que exigem conformidade a fim de que a validao do
sistema possa ser aceita. Abaixo indicamos alguns desses
temas que so merecedores do desenvolvimento de
procedimentos.
Back Up e Restaurao de aplicativos e dados
Plano de Manuteno da Continuidade Operacional
Procedimentos de Manuteno Preventiva e Corretiva
Controle de Alteraes
Reviso Peridica
Reteno de Arquivos
Retirada do Sistema de Operao
Apesar de julgarmos que todos os temas acima so
importantes, temos de reconhecer que alguns temas se
sobrepem aos outros em termos de criticidade naquilo
que toca a manuteno do estado validado. Assim foca-
remos o detalhamento deste tema nos itens de controle
de alteraes, reviso peridica e reteno de arquivos.
No tema back up e restaurao recomendamos aten-
o aos seguintes itens:
Definio da freqncia do back up: Para isto deve-se
levar em conta a taxa de atualizao do sistema, a
capacidade de armazenamento em disco e a possi-
bilidade de exigncias especficas em determinadas
atividades GxP.
Armazenar as cpias de back up em local sepa-
rado daquele onde esto os dados originais.
Preferencialmente em local prova de fogo e com
controles que evitem a degradao do meio em que
foi gravada a cpia de back up.
Identificao apropriada, regulamentada atravs de
procedimento operacional das cpias de back up.
O controle alteraes a ferramenta mais eficaz no
auxlio manuteno do estado validado de um sistema
computadorizado. Durante o processo de desenvol-
vimento, construo, validao, uso e retirada de um
sistema, devemos ter um procedimento de controle de
alteraes que regule as modificaes passveis de ocor-
rer no sistema computadorizado durante grande parte
do seu ciclo de vida. O escopo envolvido no se restringe
somente ao software, mas tambm a hardware, redes,
polticas de treinamento de operadores, uso do sistema
e documentao.
Neste tema recomendamos especial ateno aos
seguintes itens:
Existncia de um modelo de protocolo que inclua
razo, objetivo, existncia de suporte tcnico e des-
crio da mudana.
Autorizao e conhecimento das reas afetadas e algu-
mas reas que chamaramos de default, tais como
Garantia da Qualidade, rea do responsvel gerencial
do sistema.
Plano de implementao com descrio da atividade,
responsvel e datas previstas para a concluso.
Finalizao do protocolo de alteraes com a aprova-
o ou reprovao formal da proposta de alterao e
seus respectivos motivos.
O procedimento de reviso peridica deve definir o
intervalo desta reviso, a existncia ou no de intervalos
de tolerncia, a necessidade de entrevistas formais com
o usurio da rea e o formato do relatrio de reviso
peridica, entre outras caractersticas. importante
lembrar que a melhor ferramenta para nortear este
trabalho a avaliao de protocolos de alteraes que
afetaram o sistema dentro do perodo de reviso peri-
dica considerado. Quanto aprovao do relatrio, este
dever conter a assinatura do autor, do responsvel da
rea onde o sistema est localizado e da rea de Garantia
da Qualidade.
Toda a documentao de validao, engenharia, dados
histricos, etc. dever ser guardada obedecendo-se a um
critrio que deve estar formalizado em procedimento.
Como exemplo podemos citar que "Um sistema dever
ter todos os seus dados, documentao e aplicativos
guardados indefinidamente at a aposentadoria do
sistema. Uma vez retirado, estes dados devero ser
retidos pelo prazo de validade mximo dos produtos
manufaturados com envolvimento do sistema ora sendo
retirado".
Gbtf!ef!Sfujsbeb!ep!Tjtufnb!ef!Pqfsbp
Um sistema que esteja sob certas restries regulat-
rias no pode ser retirado sem o seguimento de algumas
prticas que visam manter disponveis as informaes
daquele sistema pelo menos obedecendo ao perodo
estipulado no procedimento de reteno de arquivos. A
seguir listamos algumas dessas prticas para ilustrarmos
o conceito.
Elaborao do plano de retirada do sistema, deter-
minando o responsvel pela mudana, e coletando
a aprovao formal do responsvel pela rea onde
o sistema est instalado e da rea de Garantia da
Qualidade.
Iniciar o processo de retirada aps a aprovao formal
Validacao Sistemas.indd 45 21/06/06 18:24:28
46
SBCC
abril / maio / junho 2006
bsujhp!udojdp
de um protocolo de alteraes
Garantir um lugar seguro para os dados e aplicativos
ora sendo retirados
Identific-los apropriadamente
Verificar a possibilidade de migrar os dados do sistema
legado para aquele que o substituir, e validar o pro-
cesso de migrao.
Atualizar toda a documentao de validao e enge-
nharia pertinentes.
Ana|lse e 0erenclamento de klscos
(kej. Ispe ~ 0amp t)
A viso das agncias regulatrias sobre os requisitos
de validao de sistemas computadorizados tem sido
alterada nos ltimos anos, seguindo uma tendncia de
se focar as inspees nos aspectos mais crticos de cada
sistema. Assim devem-se conduzir vrias anlises de
risco durante o ciclo de vida de um sistema computado-
rizado. Este processo conhecido como Gerenciamento
dos Riscos, e requer um plano formal que oriente este
esforo de modo que seja coerente e no perca o foco.
O gerenciamento de riscos encaminha de forma mais
ampla as seguintes questes:
O sistema computadorizado requer validao?
Qual o escopo e a profundidade desse esforo de vali-
dao?
Quais aspectos gerenciados pelo sistema so considera-
dos crticos sade do cliente?
Quais aspectos gerenciados pelo sistema so crticos
continuidade do negcio?
J que no prtico testarmos todos os aspectos rela-
cionados a um sistema de automao, devemos focar os
nossos esforos nos itens crticos revelados pela anlise
de risco.
Cabe agora direcionarmos a nossa abordagem para
uma faceta do Gerenciamento de Riscos que engloba as
avaliaes conduzidas aps o projeto, validao e acei-
tao do sistema. Assim o processo permitir identificar
e minimizar o impacto de eventos adversos no sistema.
Ao mesmo tempo prover uma justificativa plausvel
para o nvel de validao escolhido para o sistema com-
putadorizado, aumentando a conformidade com os
requisitos do usurio.
O Gerenciamento de Riscos envolve diferentes cargos
dentro da empresa e cada um deles possui um papel
diferente no processo. Seguem alguns exemplos:
Responsvel Tcnico do Sistema: Responsvel pela
investigao e avaliao dos riscos identificados como
parte do processo GxP. Ele um aprovador do relat-
rio de anlise de risco.
Responsvel pela rea onde o Sistema est Instalado:
Responsvel pela avaliao dos riscos que impactam
a continuidade do negcio. Ele um aprovador do
relatrio de anlise de risco.
Responsvel pela Garantia da Qualidade: Responsvel
pela avaliao dos riscos que impactam a conformi-
dade com as diretrizes regulatrias
O guia do ISPE (International Society for Pahrmaceutical
Engineering), GAMP em sua verso 4 de dezembro de
2001, oferece no apndice M3 um detalhado modelo de
gerenciamento de risco.
z: C|k Ak1 ::
Com o aumento da automatizao dos processos na
indstria de forma geral e em particular na indstria far-
macutica, introduziu-se uma nova preocupao para as
agncias regulatrias, que a gesto dos aplicativos uti-
lizados no controle e superviso dos processos e dados
oriundos do processo farmoqumico.
A viso da agncia regulatria norte americana FDA
que mais difcil identificar fraudes, erros e falhas no
controle de alteraes quando estamos lidando com
sistemas que manuseiam exclusivamente dados eletr-
nicos ao invs de registros em papel.
Assim pela primeira vez, atravs da lei 21 CFR Part 11
e do guia para a indstria de Setembro de 2003, relativo
interpretao da agncia para esta lei, o FDA introduz
controles especficos no uso de registros eletrnicos e
inclui controles administrativos rgidos na utilizao de
assinaturas eletrnicas. Na prtica esta ao amplia o
conceito de boas prticas s novidades tecnolgicas que
cada vez mais afetam os processos farmoqumicos.
O objetivo da lei 21 CFR Part 11 :
Permitir a introduo de novas tecnologias.
Preservar e proteger registros eletrnicos de natureza
GxP.
Minimizar as fraudes que possam ser cometidas contra
os registros eletrnicos.
Permitir que o FDA possa inspecionar com o mesmo
grau de preciso instalaes cujos processos so for-
temente automatizados.
Ap|lcaco da |el
Para sistemas que tenham sido implantados antes
de Agosto de 1997, mesmo que eles tenham gerado
registros eletrnicos, a lei no se aplica. Assim temas
como rastreabilidade das aes do usurio (Audit Trail)
e outros aspectos da lei no podem ser auditados sob a
tica do 21 CFR Part11.
Validacao Sistemas.indd 46 21/06/06 18:24:30
Outro ponto importante que atravs do Guia para a
Indstria de Setembro de 2003, a FDA aceita como uma
prtica vlida o gerenciamento de riscos para nortear o
esforo de validao e aplicao dos requisitos da lei em
um dado sistema. Assim amparado numa documentao
consistente e formal que justifique a no aplicao dos
conceitos de validao e Parte 11 para certos sistemas
no GxP, a indstria poder canalizar esforo e recursos
para os sistemas efetivamente crticos, fazendo com que
a aplicao da lei seja mais prtica e eficaz.
1plcos rlnclpals da |el
lstemas Hibrldos
Nem todos os sistemas sero puramente eletrnicos
ou baseados em papel. A maioria dos sistemas hoje
instalados apresenta alguma capacidade de registro
eletrnico, porm necessita que os resultados sejam
impressos e assinados manualmente. Estes sistemas so
conhecidos como sistemas hbridos. No existe abso-
lutamente nada na lei que impea a existncia destes
sistemas. Aqui mais uma vez vale a nova interpretao
da agncia que pede que o usurio avalie consistente-
mente o risco envolvido e fornea solues adequadas
para cada um deles
Aplicao de Assinaturas Eletrnicas
A deciso e a responsabilidade sobre o uso de assinatu-
ras eletrnicas so das prprias empresas farmacuticas
e esta deciso dever ser formal, indicando quem a usar
em dado sistema, porque est sendo usada, e em quais
situaes.Alguns exemplos de situaes onde o uso de
assinaturas eletrnicas pode vir a ser til no esforo de
ampliar o nvel de conformidade so dadas abaixo:
Fichas de Fabricao, Relatrios de Batelada
Boletins de Anlise Qumica e Microbiolgica
Mudana no nvel de privilgio de usurios, Incluso,
Excluso de Usurios do Sistema
Relatrios de Desvio
Registros de Treinamento
Ap|lcaco de keglstros de kastreabl|ldade
(Audlt 1ral|s)
Este tpico est intimamente ligado ao uso de regis-
Anote em
sua agenda!
4 a 6 de outubro de 2006
So Paulo
O mais importante simpsio da
Amrica Latina sobre Controle de
Contaminao. Participao de
renomados palestrantes
internacionais e nacionais
Aguarde programa
tcnico completo
Mais informaes sobre participao e
patrocnio: (12) 3922 9976 ou
sbcc@sbcc.com.br
Sinccal.indd 1 20/06/06 17:50:35
Validacao Sistemas.indd 47 21/06/06 18:24:33
48
SBCC
abril / maio / junho 2006
bsujhp!udojdp
tros eletrnicos. Audit Trails so requeridos para aes
do usurio ou entradas de dados que criem, modifi-
quem ou apaguem registros eletrnicos. So exemplos:
Entrada de dados de processo, logon/logoff de usurios,
assinaturas eletrnicas, etc.
A informao deve conter no mnimo quem fez a
ao, o que foi modificado, qual era o estado anterior e
quando foi efetuada. A data e a hora devero ser regis-
tradas junto com a identidade do usurio que afetou
o registro.
uso de keglstros |etrnlcos
Alguns tpicos da lei relacionados ao uso de registros
eletrnicos esto relacionados com atividades corri-
queiras com respeito ao uso de sistemas computado-
rizados, so elas:
Pessoas que usam sistemas computadorizados GxP
para criar, modificar, manter ou transmitir registros
eletrnicos devem empregar procedimentos e con-
troles formais de forma a assegurar sua autenticidade,
integridade e confidencialidade. Abaixo listamos alguns
desses controles:
1. Validao dos sistemas de forma a assegurar pre-
ciso, confiabilidade, consistncia e de que o sis-
tema hbil em discernir registros alterados e/ou
invlidos.
2. Estar pronto para fornecer aos auditores cpias de
registros eletrnicos ou no que sejam plenamen-
te legveis e possam ser auditados pelas agncias
regulatrias.
3. Limitar o acesso a um sistema regulados somente aos
usurios autorizados e treinados para tal objetivo.
4. Uso de registros de rastreabilidade de forma a con-
trolar o que foi feito no sistema, quando foi feito e
por quem.
5. O uso de privilgios diferenciados em relao ao
que pode e no pode ser feito pelos usurios num
sistema regulado
6. O uso de Controle de Alteraes a fim de regular as
modificaes a serem feitas num sistema validado.
Conc|uso
Os benefcios advindos da validao de sistemas com-
putadorizados so indubitveis, todavia a burocracia
envolvida especialmente no volume de documentao
requerido, muitas vezes desencoraja as empresas a apli-
car o conceito. Abaixo conclumos listando alguns bene-
fcios que podem ser conquistados tanto para o negcio
como para o nvel de conformidade com as exigncias
regulatrias.
8enejiclos para o Negclo
O uso de ferramentas de validao e o controle das
atividades de projeto minimizaro as necessidades de
reengenharia dos sistemas, reduzindo os custos globais
do projeto.
Ao entender quais fases e aspectos do projeto do
sistema computadorizado so mais crticos, atravs de
uma anlise risco consistente, permitimos que a equipe
envolvida direcione seus esforos para estas atividades
reduzindo o nmero de horas de projeto e conseqen-
temente seu custo final.
O prvio estudo e elaborao de um protocolo de
requisitos do usurio harmoniza o fornecimento de
equipamentos e servios com a real necessidade do
usurio, evitando desta forma a aquisio de mdulos
suprfluos reduzindo os custos de fornecimento e vali-
dao do sistema.
Atingir as expectativas de agncias como FDA e
MHRA, permitindo-se assim ser aprovado para expor-
tar para mercados de grande escala como EUA e
Unio Europia
8enejiclos em Conjormldade
Aplicando o modelo de ciclo de vida proposto em
vrias publicaes e guias como GAMP, o usurio pode-
r obter alguns benefcios conforme o exemplo abaixo:
Atingir as expectativas de agncias regulatrias como
FDA e MHRA.
Assegurar que os dados retidos eletronicamente no
sistema estaro protegidos contra fraudes, erros
e perdas.
Ter um controle efetivo do uso do sistema por parte
dos usurios
Assegurar que todas as incluses, excluses e/ou altera-
es de forma geral sejam conhecidas e controladas,
mantendo-se assim o estado validado.
Diminuir o tempo de retorno operao em caso de
falha ou sinistro
Garantir que o sistema ir realizar somente aquilo para
o qual ele foi projetado.
kejernclas
GAMP 4 :
Good Automated Manufacturing Practice ISPE
Dezembro 2001
Good Practice and Compliance for Electronic Records
and Signatures ISPE verso 1
Validacao Sistemas.indd 48 21/06/06 18:24:35