|
- Qual a importância da validação dos sistemas
computadores - CSV?
A validação de sistema
computadorizados que tem impacto na saúde do
paciente, qualidade do produto e integridade dos
dados basicamente deve provar que o sistema faz
aquilo que deveria fazer. O ciclo de vida do GAMP (Good
Automated Manufactoring Practice – guia para
validação de sistemas - tem dois objetivos:
a.) documentação
de projeto: os requisitos de usuário somado aos
documentos de especificação documentam o projeto
do sistema e seu desenvolvimento. O lado
esquerdo do ciclo de vida em ‘V’ (veja figura
abaixo) da validação trás muitos benefícios,
como por exemplo evitar que o usuário fique
totalmente dependente do fornecedor e também
evita que dentro da estrutura do próprio usuário
que, quando perde algum profissional da equipe,
que a informação sobre aquele determinado
sistema também não se perca.
b.) desafio
do sistema: o lado direito do ciclo de vida em
‘V’ (veja figura abaixo) é composto pelo
protocolo de testes e seu devido uso para
desafiar o sistema. Basicamente, o conteúdo
destes testes deve contemplar as funções que o
sistema executa, primordialmente as funções
críticas, mas também deve contemplar o que o
sistema não pode fazer, exemplo... o agitador de
um determinado reator não pode funcionar quando
estiver adicionando matéria-prima, ou seja, um
teste para cobrir essa função que não deve
acontecer deve ser contemplado.
- Quais os principais cuidados que os usuários
finais devem ter no projeto/contratação de um
sistema computadorizado que vai gerenciar a
produção?
O maior cuidado que usuário deve ter
na contratação é o atendimento ao FDA 21CFRPart11,
norma que traz regras para uso de registro
eletrônico e assinatura eletrônica. Um sistema é
validável se o mesmo atende tal norma. Basicamente,
não existe nenhum órgão regulamentador ou agência
que inspeciona se o fornecedor realmente atende
todos os requisitos da norma. A conferência e
conclusão deste trabalho ocorre durante o processo
de validação. Daí, o sistema já está comprado,
configurado e instalado. Tarde demais...
Sugere-se então que o usuário cheque
se o sistema é realmente validável antes do
fechamento do contrato.
Duas dicas abaixo podem agilizar este
processo, que são os pontos mais difíceis de
atendimento à norma. Se o fornecedor for capaz de
demonstrar com sucesso os pontos mencionados à
seguir, pode ser um bom sinal:
Os requisitos do part11 que mais
exigem esforços do fornecedor para seu atendimento
são:
a.) audit
trail: registro das ações do usuário no sistema
– deve conter: quem acessou o sistema, de onde (IP
por exemplo), o que fez, quando fez e porque
fez, caso utilize o campo de nota (normalmente
disponível) para tal justificativa. Normalmente,
existe uma tela de ‘logbook’ que contém esse
tipo de informação que às vezes possui até
filtros por tipos de eventos para facilitar a
busca dos eventos separados por natureza;
b.) inviolabilidade
dos arquivos: part11 exige que os arquivos de
dados históricos do processo (ex. temperatura,
umidade, pressão, etc...) somado aos eventos do
audit trail sejam arquivos não editáveis.
Existem outros requisitos que o
part11 contemplam, mas os dois deles mais
vulneráveis em termos de atendimento estão expostos
acima. E agora, como saberemos se o potencial
fornecedor é capaz de atendê-los?
Siga as dicas abaixo, economizando
tempo, indo direto ao ponto:
1.) Para
checagem do audit trail: peça ao fornecedor,
durante um processo de demonstração que faça
alguma mudança de parametrização do sistema, por
exemplo, mudança no valor de um setpoint de
alarme do sensor tag XYZ. Anote os parâmetros
antigos e novos e o respectivo tag do sensor.
Após salva a mudança, peça ao fornecedor que lhe
mostre a lista dos eventos. Verifique se você
encontra quem fez a ação, quando foi, o que foi
feito exatamente sem que ele tenha justificado.
Verifique se os dados que essa tela do sistema
lhe traz condiz com a realidade da mudança
efetuada anteriormente;
2.) Para
checar a inviolabilidade dos arquivos, peça ao
fornecedor que lhe mostre um arquivo eletrônico
típico que o sistema dele gera. Anote o nome
deste arquivo, data e hora que ele foi gerado.
Abra-o usando o bloco de notas. Se o arquivo não
foi editável (que é o que esperamos), ele deve
mostrar algum arquivo como exemplificado abaixo:
Se você abrir uma tela onde as informações não estão
organizadas da maneira convencional, é um bom sinal,
ou seja, o usuário final não pode realmente saber
identificar onde está alocado no arquivo a
informação que potencialmente poderia ser violada. O
próximo passo, seria você selecionar parte do
arquivo e deletá-lo, por exemplo, para simular se o
arquivo do fornecedor abre na ferramenta
convencional dele (que deixa as informações
organizadas para que possamos interpretá-la). A
resposta deveria ser: ‘arquivo corrompido’.
- Como tem sido a evolução da aceitação dos usuários
a necessidade de validação?
Alguns poucos anos atrás, as indústrias que
validavam sistemas eram as multinacionais e as que
exportavam para Europa e/ou Estados Unidos, ou seja,
exigência regulatória ou da matriz. Atualmente, o
mercado regulado sabe que mais dia, menos dia, as
exigências para comercializar o produto no mercado
brasileiro também aumentarão. Neste caso, percebemos
a preocupação da indústria em adquirir pelo menos
uma solução validável, para que ela não perca o
investimento e tenha que trocar o sistema para que
seja validado.
- Comente as principais tendências e o que se
vislumbra para o futuro nesse campo?
Penso que no futuro muito próximo, todo as
indústrias do mercado regulado (Life Sciences)
validarão seus sistemas de chão de fábrica. Essa
abordagem permite que a empresa tenha um controle e
conhecimento do processo e produto de maneira mais
profunda, contribuindo para a melhoria contínua da
qualidade do medicamento. Ajuda habilitar a
indústria à exportar seu produto para qualquer lugar
do mundo.
- Finalmente, comente sobre a 21 CFR Part 11 sobre
assinaturas e registro eletrônicos: qual a definição
básica dessa ação? quando foi implementada e o que
levou essa necessidade de termos assinaturas
eletrônicas? qual a relação entre a parte 11 e a
validação do sistema?
21CFRPart11 foi criada pela FDA para
fomentar o uso da tecnologia no mercado regulado,
que comparado com outros tipos de processo, estavam
se desatualizando. A norma foi criada em 1997 e seu
conteúdo dá base para o que o fornecedor implemente
um sistema e o usuário implemente políticas internas
de privilégios de acesso e senhas de forma que os
eventos do sistema sejam incontestáveis.
O atendimento à norma é uma
ferramenta fabulosa para aumentar a velocidade na
investigação de discrepâncias, uma vez que o
sistemas possuem recursos de disponibilização de
informações de eventos e dados de processo que podem
dar o caminho para a solução da discrepância.
As funções de software que atendem os
requisitos do part11 são intrínsecos ao sistema, ou
seja, não se trata de documentos. Tratam-se de
funções de software e hardware que juntos, são
capazes de guardar todos os eventos de operação e
processo. Quando se pensa em validação de sistemas,
já nos lembramos de documentos, ou seja, devemos
documentar e desafiar o sistema de forma que
deixemos provas documentais que o sistemas está
cumprindo com suas funções definidas pelo usuário.
Como o part11 é uma norma bastante consistente, tão
madura quanto o guia do GAMP e pelo fato do guia
referenciar o atendimento ao part11, acabou-se tendo
a regra de atendimento ao part11 para que o sistema
seja validável. Essa estratégia evita que o usuário
adquira um sistema, gaste esforços de recursos
humanos e financeiros para implementá-lo e validá-lo
com o risco de chegar ao final e não conseguir
atribuir ao sistema o status de ‘validado’. Já
imaginou?
Outro ponto importante para o
atendimento ao part11 é não olhar somente para os
softwares que compõem a solução. Temos que olhar
para todos os componentes do sistema onde os
usuários terão acesso de comunicação com o sistema,
exemplo, interfaces homem-máquina (IHMs), onde o
usuário o utiliza o tempo todo para definir a
receita cadastrada, mudar setpoint de velocidade na
agitação do reator, por exemplo, que impactam
diretamente na qualidade do produto final. Se esse
componente não atende os requisitos, não tem audit
trail, temos o que chamamos na linguagem de
validação de ‘gap’, ou seja, um fenda, uma falha no
sistema onde o que os usuários fizerem no processo,
passa despercebido e o sistema não registra. Desta
forma, você pode ter um arquitetura que se utilize
de um supervisório validável (somente ele) , mas o
sistema não é validável.
Veja ilustração abaixo:
|
