O ciclo de vida de desenvolvimento de software na
indústria farmacêutica
Um relato prático com base na experiência de garantia de qualidade de sistemas
computorizados utilizados nesta indústria
Paulo Marques
Gestor de Qualidade de Sistemas de Informação
Departamento de Sistemas de Informação, BIAL
S. Mamede do Coronado, Trofa, Portugal
[email protected]
Resumo — A utilização de qualquer software numa organização
que faça parte do ciclo de vida de um medicamento pressupõe a
preocupação constante com a garantia de qualidade desse mesmo
software. Essa garantia só é possível quando se considera o
software como parte de um sistema computorizado, do qual
também fazem parte hardware e outros equipamentos, outros
softwares, pessoas e processos.
Palavras-chave — sistema computorizado;
validação; farmacêutica; medicamento.
I.
regras normalmente denominam-se de boas práticas e têm força
de lei. As mais importantes são as boas práticas laboratoriais,
as clínicas, de fabrico e de distribuição.
Em Inglês, o termo GXP (Good X Practices) surge então,
naturalmente, para designar o conjunto de todas as boas
práticas (ou seja, GXP = GLP + GCP + GMP + GDP, em que,
por exemplo, GMP = Good Manufacturing Practices).
verificação;
INTRODUÇÃO
Toda a indústria farmacêutica vive perante uma grande
exigência de qualidade em todos os seus processos e produtos.
A vida de um medicamento começa quando uma nova
molécula é sintetizada e só termina quando essa molécula
efetivamente deixe de ser utilizada. Pelo meio, a nova molécula
deve ser patenteada, após a qual normalmente se seguem várias
fases de ensaios laboratoriais e outras de ensaios clínicos.
Se tudo correr bem até aí, o medicamento poderá ser
comercializado, desde que seja aprovado nos mercados a que
seja submetido. Para cada mercado pretendido, a entidade
proponente tem que preparar um dossier de autorização de
introdução no mercado, submetê-lo a aprovação e aguardar que
essa mesma aprovação chegue, o mais rapidamente possível.
Claro que, dito desta forma, tudo isto parece simples, mas
não é, tal a quantidade de burocracias necessárias. Como se
isso não bastasse, o desenvolvimento de um novo medicamento
é uma corrida contra o tempo, porque desde que uma nova
molécula é patenteada, inicia-se um período de proteção e
exclusividade para a entidade dona da patente, para que esta
possa recuperar o esforço no investimento de investigação e
desenvolvimento.
Após aprovação da autorização de introdução num
mercado, começa a produção, controlo de qualidade e
distribuição do medicamento nesse mercado.
Hoje em dia, as autoridades que regulamentam a indústria
farmacêutica encarregam-se de criar e manter um conjunto de
regras para garantir a qualidade de todos os processos
subjacentes a todo este ciclo de vida dos medicamentos. Essas
Figura 1. O ciclo de vida típico de um medicamento
Hoje em dia, todos os processos de âmbito GXP,
regulamentados por boas práticas, são apoiados por vários tipos
de software, os quais estão obviamente sujeitos aos mesmos
padrões de qualidade que se aplicam aos processos e produtos.
É aqui que entra a necessidade de garantir a qualidade do
software utilizado na indústria farmacêutica. Nesse sentido,
muitos autores conceituados na indústria, nomeadamente o
GAMP [1], preconizam a adoção de um modelo específico de
ciclo de vida de desenvolvimento de software — o modelo em
V.
Nos primórdios da utilização do software na indústria
farmacêutica, parecia suficiente falar-se em validação de
software, para garantir a sua qualidade. No entanto, há muito
que o software deixou de ser olhado isoladamente, passando
assim, apenas a ser apenas uma parte de um sistema
computorizado (embora seja certamente a parte principal).
II.
•
Software: Convém não esquecer que existe uma
pequena parte de software (por exemplo, sistemas
operativos, bases de dados, monitorização de
performance ou gestão de segurança) que deve ser
considerada na já referida infraestrutura, por isso
sujeita ao mesmo nível de qualificação;
•
Equipamentos: Aqui há a considerar alguns
componentes (por exemplo, equipamento de
laboratório, de produção ou de distribuição) que
colocam um sistema computorizado longe do típico
sistema cliente/servidor;
•
Pessoas: Têm de estar devidamente habilitadas e serem
formadas para que lhes seja concedida autorização de
utilização do sistema, autorização essa que deverá estar
aprovada pela organização;
•
Processos: O objetivo último da utilização de qualquer
sistema é a melhoria do(s) processo(s) subjacentes. No
entanto, isso só acontece desde que haja uma sintonia
entre todos os componentes do sistema, não
esquecendo toda a documentação que permite manter o
sistema sobre controlo e também informar os
utilizadores sobre a melhor forma de conseguirem os
seus objetivos.
A VALIDAÇÃO DE UM SISTEMA COMPUTORIZADO
A. Definição de sistema computorizado
Obviamente, nenhum software funciona sozinho.
Normalmente, é da conjugação de várias camadas de software
e hardware (que fazem parte de uma infraestrutura
informática), aos quais eventualmente se associam
equipamentos (de laboratório, de produção ou distribuição),
que nasce o conceito de sistema computorizado. Este, no
entanto, não faz sentido sem as pessoas que o utilizam e, ainda,
todo o conjunto tem que estar coerente com a documentação do
sistema de gestão da qualidade da organização, do qual devem
fazer parte todos os documentos que descrevem o sistema e a
sua utilização.
De acordo com Teri Stokes [2], um sistema computorizado
é um conjunto de equipamentos, software, pessoas e
procedimentos, que em conjunto viabilizam a execução de um
determinado processo de negócio.
Hardware
Equipamentos
Pessoas
Software
Processos
Figura 2. Esquema de um sistema computorizado
O conceito de sistema computorizado nasce precisamente
para ser a âncora da garantia de qualidade da utilização do
software na indústria farmacêutica. Claro que, sendo o software
o componente que diferencia a identificação de um sistema
computorizado, as principais atividades da sua validação
centram-se na especificação, construção e verificação do
software.
No entanto, antes de passar a analisar o software específico
de um determinado sistema, convém não esquecer as atividades
de validação normalmente executadas sobre os restantes
componentes:
•
Hardware: A maioria do hardware (por exemplo,
servidores, discos, equipamento ativo de rede,
computadores, impressoras e outros periféricos) que
faz parte de qualquer sistema computorizado é
partilhada numa infraestrutura, o que a torna suscetível
de qualificação, ou seja, de garantia de controlo
permanente de especificações, configuração e testes;
B. Adaptação do modelo em V para validação de um sistema
computorizado
Existindo, na indústria farmacêutica, uma tradição muito
forte de qualificação de equipamentos, desde há algumas
décadas, ainda antes dos mesmos incorporarem a grande
quantidade de hardware e software a que hoje em dia
assistimos, essa tradição foi estendida para a validação de
sistemas computorizados.
Assim, um sistema computorizado é considerado quase
como um equipamento especial, embora mais complexo, mas
cuja qualidade continua a poder ser garantida pelo modelo
tradicional de especificação, construção e verificação, que
assume a conhecida forma em V, ligeiramente modificado.
A extensão desse modelo tradicional em V, consiste
sobretudo na adição de um conjunto de atividades que saem
fora do âmbito concreto de especificação, construção e
verificação do software. Essas atividades dependem de cada
sistema e consistem (embora não estejam limitadas à lista que
se segue) em:
•
Análise do risco que a utilização do sistema
computorizado pode implicar, sobretudo tendo em
conta a criticidade dos processos subjacentes e
comparando esses mesmos processos, antes e depois da
utilização do sistema, da qual resulta a maior ou menor
extensão de validação do sistema (ou seja, maior ou
menor detalhe na execução de todas as atividades de
validação);
•
Avaliação do impacto que o sistema tem na
infraestrutura e no resto dos sistemas utilizados na
mesma organização;
•
Elaboração de um acordo de nível de serviço entre
todas
as
partes
envolvidas
na
conceção,
desenvolvimento, verificação, utilização e manutenção
do sistema;
•
Se aplicável (em sistemas adquiridos, totalmente ou em
parte), definição de critérios de seleção de
fornecedores e sua avaliação, normalmente através de
auditorias, para garantir que o fornecedor escolhido
cumpre os critérios definidos e se preocupa em
embeber a qualidade de forma intrínseca, nos seus
processos de desenvolvimento de software;
•
Especial cuidado na especificação e verificação dos
interfaces com outros sistemas;
•
Definição e verificação dos processos de cópias de
segurança periódica (backups) de toda a informação
gerida no sistema, para que o mesmo possa ser
recuperado, sempre que tal seja necessário, quer seja
na sequência de um pedido ou de um desastre;
•
Elaboração de instruções ou manuais dedicados
exclusivamente à descrição da utilização do sistema,
tendo em conta a realidade da organização onde o
mesmo opera;
•
Se aplicável (se houver descontinuação de um sistema
antigo), pode ser necessário planear a migração de
informação e/ou o arquivo de informação antiga,
garantindo que é cumprido o período de retenção
definido para a informação mais crítica;
•
Definir e aprovar os perfis de acesso ao sistema;
•
Formar os futuros utilizadores do sistema;
•
Elaborar e manter uma descrição técnica do sistema,
que descreva todas as componentes necessárias ao
funcionamento do sistema (por exemplo, bases de
dados, utilizadores e permissões especiais, serviços) e
que, no caso de sistemas configuráveis, deve incluir a
documentação da configuração do sistema.
planeadas, tanto quanto possível. Esse planeamento deve
resultar num documento formal, aprovado pelas partes
interessadas, normalmente designado por plano de validação do
sistema. Esse documento deve justificar a estratégia de
validação do sistema, definir os critérios para que o sistema se
possa considerar validado e prever a estratégia de manutenção
do estado de validação do sistema, ao longo do seu ciclo de
vida.
Uma vez executadas todas as atividades planeadas, deve ser
emitido o respetivo relatório de validação, documento que
identifica os desvios da execução face ao que estava planeado e
resume as anomalias ocorridas durante a validação, sobretudo
na fase de verificação.
C. Atividades principais de validação de sistemas
computorizados
1) Especificação
Esta fase destina-se a definir todos os requisitos que o
sistema deve ser capaz de cumprir. De um ponto de vista
processual, pode dizer-se que a especificação identifica como
são transformados os dados de partida (inputs), para obtenção
dos resultados pretendidos (outputs). O resultado da fase de
especificação servirá como base de trabalho para a fase de
verificação.
É sempre dada atenção especial a determinados requisitos
regulamentares que todos os sistemas devem cumprir,
sobretudo os que se relacionam com registos eletrónicos e
assinaturas eletrónicas [3], para que estas se possam considerar
legalmente equivalentes às assinaturas manuais, em papel.
Dada a obsessão da indústria farmacêutica por processos
estáveis, que se encontram em utilização há anos, suportados
por recursos humanos experientes, citando uma das referências
mais importantes no âmbito GXP [4], sempre que um sistema
substitui uma operação manual, não deve haver qualquer
decréscimo na qualidade do produto, controlo do processo ou
garantia de qualidade, bem como não deve haver qualquer
acréscimo do risco global do processo.
2) Construção
Na fase de construção do sistema, sobretudo na construção
do software específico do mesmo, deve garantir-se o mais
possível que as especificações são cumpridas e se mantêm
atualizadas e ainda que são efetuados testes unitários aos
componentes desenvolvidos especificamente para o sistema em
causa.
3) Verificação
A verificação de um sistema encarrega-se de garantir
formalmente que o mesmo cumpre integralmente os requisitos
especificados. A extensão da verificação de um sistema
depende de muitas variáveis (como sejam o resultado da
análise de risco ou o grau de estandardização/customização),
embora a indústria aprecie que essa verificação seja dividida
nas seguintes qualificações:
Figura 3. O modelo em V para validação de um sistema computorizado
Todas as atividades de validação, tanto as referidas nos
pontos anteriores, como as subjacentes à especificação,
construção e verificação do sistema, devem ser devidamente
•
Qualificação de instalação: Destina-se a garantir que o
software é instalado de acordo com as suas
especificações de desenho, em qualquer dos ambientes
(desenvolvimento / testes / qualidade / produção)
normalmente instalados, permitindo que os mesmos se
possam considerar equivalentes, no âmbito da
verificação;
•
•
Qualificação operacional: Equivalente aos testes de
aceitação em fábrica (ou FAT, Factory Acceptance
Tests), destinam-se a garantir que o sistema opera de
acordo com as suas especificações funcionais e que (se
aplicável) a configuração do sistema lhe confere o
comportamento pretendido;
Qualificação de performance: Equivalente aos testes de
aceitação pelos utilizadores (ou UAT, User Acceptance
Tests), destinam-se a garantir que o sistema cumpre as
suas especificações de requisitos dos utilizadores, em
todos os ambientes operacionais e combinações
possíveis de ser utilizado.
D. Atividades complementares à validação dos sistemas
essenciais para garantir a sua qualidade
Dado que um sistema computorizado se incorpora numa
organização e interage com outros sistemas, processos e
pessoas, só é possível garantir a qualidade de qualquer sistema
computorizado, desde que a execução dos seguintes processos
(pelo menos) esteja assegurada na mesma organização:
•
Gestão de acessos
•
Gestão da infraestrutura
•
Gestão do suporte
•
Gestão de backups e disaster recovery
•
Gestão de alterações e da configuração
•
Formação contínua na utilização dos sistemas
E. Relatividade de conceitos
Claro que esta adaptação do modelo em V funciona bem
enquanto se considera o desenvolvimento inicial de um
sistema. No entanto, rapidamente se percebe que uma vez
validado um sistema, tipicamente se inicia a fase mais
complexa do seu ciclo de vida – a sua utilização e manutenção.
Hoje em dia, sobretudo fruto da evolução tecnológica a que
assistimos diariamente, mas também da constante volatilidade
organizacional, a mudança assume as mais diversas formas e
coloca permanentemente os mais diversos desafios. Por isso, a
qualidade do sistema estará tão assegurada quanto maior for a
capacidade de antever, planear e executar alterações ao sistema
da forma mais controlada possível.
Assim, na prática, assiste-se a uma adoção de outros
modelos de desenvolvimento de software, como o iterativo ou
o ágil, permitindo que esse desenvolvimento seja considerado
como atividade mais contínua no tempo, apesar das boas
práticas da indústria obrigarem a um constante mapeamento
com o tradicional modelo em V.
III.
CONCLUSÕES
Este artigo pretende destacar a visão de uma indústria
muito regulamentada, sujeita a apertados critérios de qualidade,
perante o ciclo de vida de desenvolvimento de software.
A conclusão que se pretende extrair é a de que a indústria
farmacêutica apresenta uma certa dificuldade em se adaptar aos
permanentes desafios de mudança que hoje em dia se
verificam.
Na prática, estes desafios obrigam a um acréscimo de
importância das áreas que gerem as infraestruturas informáticas
nas organizações, passando estas áreas a assumir um papel
preponderante na gestão dos sistemas computorizados
utilizados na organização.
Torna-se, pois, claro, que se tenta adaptar os modelos
teóricos de desenvolvimento de software disponíveis à
realidade evolutiva de conceção, verificação, utilização e
manutenção do software, como parte integrante e fundamental
de um sistema computorizado.
E enquanto a tecnologia se pode posicionar como motor
desta mudança permanente, só o pode fazer desde que seja
assegurada, de forma sustentada, a qualidade dos processos
subjacentes, porque em última análise, está em causa a vida de
seres humanos.
Oxalá a prestação de cuidados médicos e de saúde possa,
algum dia, atingir os mesmos padrões de qualidade impostos às
organizações que operam na indústria farmacêutica.
REFERENCES
[1]
[2]
[3]
[4]
ISPE – International Society for Pharmaceutical Engineering, "GAMP 5:
A Risk-Based Approach to Compliant GxP Computerized Systems",
fevereiro de 2008.
Teri Stokes, "The Survive and Thrive Guide to Computer Validation",
maio de 1998.
US Food and Drug Administration, "21 CFR Part 11 – Electronic
Records; Electronic Signatures; Final Rule", março de 1997.
EudraLex – The Rules Governing Medicinal Products in the European
Union, “Volume 4 – Good Manufacturing Practice – Annex 11:
Computerised Systems", janeiro de 2011.