Validação de Sistemas Computadorizados em Saúde

26/05/2021
TREINAMENTO: VALIDAÇÃO DE
SISTEMAS COMPUTADORIZADOS -
Produtos de Interesse a Saúde
REFERÊNCIA NORMATIVA
Guia para Validação de Sistemas Computadorizados – Guia nº 33 / 2020 – Versão 01
IEC 62304 – Medical Devide Software – Software Life Cycle Process
BREVE APRESETAÇÃO INSTRUTOR: Rodrigo Sousa
 Sócio da Qualidade na Prática Consultoria e Auditoria

 Instrutor e consultor associado da Moderna Cursos
 Mestre em Engenharia de Produção (Universidade Federal de São Carlos)
 Especialização em Engenharia da Qualidade (AESA)
 Graduação em Economia (PUC)
 Graduação em Análise de Sistemas (Unicamp)
 Auditor líder ISO 9001:2008/2015 (BSI)
 Mais de 300 clientes (Fabricantes, Importadores e Distribuidores em 15 anos
 Aproximadamente 3 mil horas de auditoria como líder / membro
 Aproximadamente dois mil alunos
 Editor do blog www.qualidadenapratica.com.br/blog
26/05/2021
ALGUNS CLIENTES 4
APRESENTAÇÕES 5
• Nome do aluno
• Empresa que trabalha
• Função/Cargo
• Expectativas com relação ao curso
OBJETIVOS DO CURSO 6
Ao finalizar o curso com sucesso, você:
• Entender como aplicar de forma prática o guia de validação de sistemas

informatizados da ANVISA.
26/05/2021
AGENDA DO CURSO 7
• Duração total: 08 horas
DÚVIDAS, ELOGIOS, RECLAMAÇÕES E SUGESTÕES 8
• Mande um e-mail para atendimento@modernacursos.com.br e

você receberá um posicionamento formal (por meio apropriado).
INTRODUÇÃO
26/05/2021
INTRODUÇÃO 10
O guia foi elaborado para auxiliar no gerenciamento e validação de sistemas

computadorizados que tenham impacto em BPx (Boas Práticas de Fabricação).
O guia não deve ser adotado como regulamento, portanto, o seu cumprimento
não é de caráter compulsório pelo setor regulado.
A proposta é internalizar o documento GAMP 5 de modo a facilitar a

compreensão do leitor acerca das diretrizes propostas por aquele guia
internacional.
Cada empresa deverá avaliar o conteúdo do guia e verificar sua

aplicabilidade. Porém ao optar por utilizar, que seja utilizado o guia de forma
integral no que for aplicável e não parcialmente.
ABRANGÊNCIA 11
O guia se aplica a sistemas computadorizados utilizados em empresas que

executem atividades de fabricar insumos farmacêuticos e medicamentos
observando o cumprimento do preconizado nas Boas Práticas de Fabricação e
Boas Práticas de Laboratório.
O mesmo guia é utilizado por fabricantes de produtos para saúde, cosméticos

e saneantes quando a validação de software for um requisito.
O guia também pode ser utilizado por empresas distribuidoras / importadoras.
ABRANGÊNCIA 12
Nem todas as atividades definidas no guia são aplicáveis a todos os tipos de

sistemas computadorizados. A abordagem pode variar, de acordo com sua
criticidade e complexidade. A decisão deve ser tomada pela empresa
baseando-se no conhecimento dos riscos envolvidos na utilização de sistema
computadorizados.
26/05/2021
CONCEITOS, TERMOS E DEFINIÇÕES
Abordagem do Ciclo de Vida dentro do Sistema 14
de Gerenciamento da Qualidade (SGQ)
Implica na realização de atividades de modo sistemático desde a concepção

até a aposentadoria do sistema, permitindo um gerenciamento e uma
abordagem consistente para todos os sistemas.
Aproveitamento do Envolvimento do Fornecedor 15
As empresas do setor regulado devem buscar maximizar o envolvimento do

fornecedor por todo o ciclo de vida do sistema, caso este possua avaliação
satisfatória, com o propósito de se utilizar o seu conhecimento, experiência e
sua documentação.
O fornecedor pode auxiliar na determinação dos requisitos do usuário, nas

avaliações de risco, na criação das especificações funcionais e outras, na
configuração do sistema, na realização dos testes, no suporte e na
manutenção do sistema.
O planejamento deve determinar como utilizar a documentação do

fornecedor, incluindo a documentação de testes, para evitar desperdício de
esforços e duplicidade. A justificativa para a utilização desta documentação
deve ser baseada na sua avaliação satisfatória do fornecedor, que pode
incluir a realização de auditorias in loco.
26/05/2021
Termos-chave 16
Atendimento às BPx: Atendimento a todos os requisitos regulatórios

farmacêuticos e associados à ciência da vida.
Dono do Processo (Process Owner): É o indivíduo responsável pelo processo de

negócio ou processos gerenciados. Esta pessoa pode ser o chefe da unidade
ou departamento que utiliza o sistema, mas a responsabilidade deve ser
baseada principalmente em conhecimento específico do processo ao invés
da posição na organização.
Dono do Sistema (System Owner): É o indivíduo responsável pela

disponibilidade, suporte e manutenção de um sistema computadorizado, bem
como a segurança dos dados mantidos neste sistema. Geralmente é o chefe
do departamento responsável pelo suporte e manutenção do sistema
Termos-chave 17
Sistema de Gerenciamento da Qualidade: Sistema de gerenciamento para

direcionar e controlar uma organização com respeito à qualidade.
Sistema Computadorizado: Um sistema computadorizado consiste em:

hardware, software e nos componentes de rede, juntamente com as funções
controladas e documentação associada. A figura 1 apresenta uma
representação esquemática de um sistema computadorizado.
Sistema Computadorizado Atendendo às BPx: Sistemas computadorizados

sujeitos aos regulamentos BPx. A companhia regulada deve assegurar que tais
sistemas atendam às regulações apropriadas.
CLASSIFICAÇÃO DE SOFTWARE E
HARDWARE
26/05/2021
CLASSIFICAÇÃO DE SOFTWARE 19
• A empresa deve possuir uma lista contendo todos os sistemas

computadorizados instalados e suas classificações. Inventário de Software.
• A maioria dos sistemas possui componentes de complexidade variável, tais

como um sistema operacional, componentes não configurados, e
componentes configurados ou customizados.
• O esforço deve ser concentrado na seguinte proporção:
Customizado > Configurado > Não-Configurado > Infraestrutura. A

categorização pode ajudar a concentrar o esforço onde o risco é maior.
Categoria 1 – Software de Infraestrutura: Elementos de infraestrutura se

interligam para formar um ambiente integrado para rodar e dar suporte a
aplicações e serviços.
Inclui: sistemas operacionais, gerenciadores de banco de dados, ferramentas

de programação estatística, e pacotes de planilhas (mas não aplicações
desenvolvidas utilizando-se estes pacotes); software de segurança; antivírus e
ferramentas de gerenciamento da configuração.
Categoria 3 – Produtos Não-Configurados: Esta categoria inclui os produtos de

prateleira utilizados para o processo de negócio. Abrange tanto os sistemas
que não podem ser configurados para atender aos processos de negócios
quanto os sistemas que são configuráveis, mas que somente a configuração
default é utilizada.
Categoria 4 – Produtos Configurados: Softwares configuráveis fornecem

interfaces e funções padrão que permitem a configuração de processos de
negócio específico para o usuário. Isto envolve normalmente a configuração
de módulos de software predefinidos. Muito do risco associado com o software
depende do quão bem o sistema é configurado para atender as necessidades
do usuário. Pode haver um aumento do risco associado ao novo software e
atualizações maiores.
26/05/2021
Categoria 5 – Aplicações Customizadas: Estes sistemas e subsistemas são

desenvolvidos para atender a necessidades específicas da empresa regulada.
O risco inerente ao software customizado é alto. A abordagem de ciclo de
vida e as decisões acerca do sistema devem levar em consideração este risco
alto, porque não existe experiência do usuário ou informação sobre
confiabilidade do sistema.
26/05/2021
CLASSIFICAÇÃO DE HARDWARE 27
A avaliação do hardware deve feita levando em consideração seu impacto no

software.
Hardware Categoria 1 – Componentes-Padrão de Hardware:
A maioria dos hardwares utilizados por empresas reguladas pertencem a esta

categoria.
Os componentes do hardware padrão devem ser documentados incluindo
detalhes acerca do fornecedor ou fabricante e número de versão. A correta
instalação e conexões dos componentes devem ser verificadas. O modelo, o
número de versão e se disponível e o número de série do hardware pré-montado
devem ser registrados.
Gerenciamento da configuração e controle de mudanças são aplicáveis.
Geralmente um inventário de hardware, mantido atualizado, é suficiente.

26/05/2021
CLASSIFICAÇÃO DE HARDWARE 28
Hardware Categoria 2 – Componentes Customizados Embutidos de Hardware:
São aplicáveis além dos requisitos descritos no item acima, os descritos neste
item. Itens customizados de hardware devem possuir uma Especificação de
Projeto (EP/DS) e serem sujeitos a testes de aceitação.
Na maioria dos casos uma Auditoria no Fornecedor deve ser realizada para
desenvolvimento de hardware customizado.
Qualquer configuração de hardware deve ser definida na documentação de

projeto e verificada. Gerenciamento da configuração e controle de
mudanças são aplicáveis.
INVENTÁRIOS 29
Inventário dos sistemas computadorizados:
O inventário deve apresentar informação resumida sobre cada sistema,

descrevendo: nome do sistema; equipamento ou aplicação associado(a);
impacto/criticidade; categoria; propriedade (setor, dono do sistema, dono do
processo); versão atual; fornecedor; data e situação de validação.
Inventários de hardware:
Geralmente são contemplados: identificação, descrição, responsável, breve

configuração, localização, tipo (1 ou 2), versão (se houver), fornecedor e quais
softwares possui interface.
CICLO DE VIDA DE SOFTWARE

26/05/2021
Ciclo de vida de software 31
O ciclo de vida de qualquer sistema consiste em quatro fases:
 Conceito
 Projeto
 Operação
 Aposentadoria
• Conceito: a empresa considera a oportunidade de automatizar um ou mais

processos com base em necessidades e benefícios ao negócio.
• Projeto: Esta fase abrange as atividades de definição dos requisitos do usuário,

com base na decisão tomada na fase de conceito, seguida da avaliação e
seleção do fornecedor para aquisição do sistema, com consequente instalação
e validação do sistema computadorizado pela empresa regulada. Em resumo,
nesta etapa são realizadas as atividades de aquisição e validação do sistema
computadorizado.
• Operação: Esta normalmente é a fase mais longa e é gerenciada pelo uso de

procedimentos operacionais definidos e atualizados por pessoas que foram
adequadamente treinadas, instruídas e experientes. Esta fase equivale na
prática ao tempo de utilização do sistema computadorizado validado pela
empresa regulada.
• Aposentadoria: É a fase final do ciclo de vida do sistema computadorizado.

Como o próprio nome diz: o sistema é aposentado. Envolve decisões sobre
retenção, migração ou destruição dos dados e o gerenciamento destes
processos.
26/05/2021
Fonte: Guia 33, ANVISA 2020. Extraído de GAMP5
Ciclo de Vida e Gerenciamento de Riscos 35
O PROCESSO DA VALIDAÇÃO
26/05/2021
INTRODUÇÃO 37
A estratégia apresentada no guia é aplicável aos sistemas pertencentes à

categoria 3, 4 e 5, que são a grande maioria dos sistemas computadorizados
existentes.
A empresa regulada deve incluir a validação de sistemas computadorizados

em sua política de validação e/ou Plano Mestre de Validação.
É recomendado que seja preparado um Plano de Validação para cada

sistema computadorizado que tenha relevância nas BPF, com foco nos
aspectos relacionados à qualidade do paciente, à qualidade do produto e à
integridade dos dados.
INTRODUÇÃO 38
OBS: softwares da
categoria 3 podem
ser testados sem a
necessidade,
obrigatoriamente,
das qualificações.
PLANO MESTRE DE VALIDAÇÃO

26/05/2021
PLANO MESTRE DE VALIDAÇÃO 40
Recomenda-se que o Plano Mestre de Validação contenha a abordagem que será

aplicada para a realização da validação de sistemas computadorizados. Esse Plano
Mestre poderá ser geral, dependendo da estrutura documental da empresa.
O mais comum é ser feito um geral com as estratégias gerais, pois o plano de
validação será feito especificamente para um software.
O plano mestre de validação geralmente contempla os seguintes tópicos, no mínimo:
1. Objetivo
2. Escopo
3. Requerimentos para Revisão e Aprovação do Plano Mestre de Validação
4. Política de validação
5. Controle de Mudanças
6. Responsabilidades
7. Atividades de Validação
• avaliação de fornecedores de sistemas computadorizados;

• inventário de sistemas computadorizados;
• plano de validação;
• análise de riscos;
• classificação de hardware e software para definição de ciclo de vida de
documentos e testes;
• matriz de rastreabilidade;
26/05/2021
• qualificação de equipamentos, infraestrutura, etc.;

• calibração, quando aplicável;
• relatórios de validação;
• manutenção do estado validado;
• descontinuação do sistema;
• treinamentos;
• gerenciamento de desvios;
• segurança e administração (diretrizes para plano de contingência, recuperação de
desastre, backup, restauração, arquivamento, desempenho, instalação, antivírus e
firewall).
PLANO VALIDAÇÃO
PLANO DE VALIDAÇÃO 45
O Plano de Validação é o documento que descreve qual abordagem será aplicada

para a realização da validação de cada sistema computadorizado.
A prática comum é fazer um plano a parte. Assim, você não precisará elaborar um
PMV para cada software.
Eventualmente, algumas informações poderão ser referenciadas do plano mestre.

26/05/2021
Conteúdo do plano de validação:
• Introdução e escopo;
• Visão geral do sistema: propósito do negócio e do uso do sistema, descrição de alto

nível do sistema, arquitetura e diagramas;
• Estrutura organizacional: papéis e responsabilidades do Gerente do Projeto, da

Qualidade, do Fornecedor, de especialistas...
• Abordagem do gerenciamento dos riscos (referência aos critério do PMV);
• Estratégia de validação: incluir a classificação do software e justificar com base nela

as etapas a serem seguidas.
• Resultados esperados: os resultados a serem produzidos devem ser listados, incluindo

a responsabilidade pela produção (de documentos, testes, resultados), revisão e
aprovação.
Conteúdo do plano de validação:
• Critérios de aceitação;
• Controle de mudanças e desvios;
• Procedimentos operacionais padrões (que serão criados ou atualizados e

responsáveis);
• Processos de suporte (treinamentos, gerenciamento da documentação,

gerenciamento da configuração, manutenção de estado validado);
• Cronograma;
• Glossário (se houver).
ESPECIFICAÇÃO DE REQUISITOS DO
USUÁRIO (ERU)
26/05/2021
ERU 49
 A Especificação de Requisitos (ou Requerimentos) do Usuário define de forma clara e

objetiva todos os requisitos necessários que um sistema computadorizado deve atender.
Pode ser usado como um documento contratual em casos de softwares novos.
 Geralmente é elaborado pelo usuário, porém pode ser elaborado em conjunto com o
fornecedor ou por empresa terceirizada. O desenvolvimento deste documento é uma
das tarefas mais importantes que a empresa regulada empreenderá dentro do projeto
de implementação de um sistema computadorizado.
 Durante a elaboração deste documento devem ser estabelecidas todas as

necessidades da empresa em relação ao sistema e o mesmo é impulsionado pelas
necessidades do processo do negócio.
 É recomendável que a elaboração deste documento seja realizada por uma equipe
multidisciplinar.
 Cada requisito de usuário deve ser identificado de forma únivoca.
ERU 50
Os requisitos podem ser agrupados em tipos/grupos e pela importância, por exemplo tipos:
1. Requisitos do usuário / requisitos funcionais;

2. Funcionalidades específicas derivadas de requisitos regulatórios (por exemplo: assinatura eletrônica e
trilha de auditoria);
3. Funções de cálculos (quando aplicável);
4. Requisitos da Interface com o usuário (por exemplo: layout, consultas, alarmes, relatórios, linguagem
utilizada, etc.);
5. Interfaces com outros sistemas ou equipamentos;
6. Requisitos de hardware, sistemas operacionais e base de dados (por exemplo, no caso de sistema
operacional, descrever a especificação mínima e versão);
7. Requisitos de desempenho (por exemplo: número de usuários, capacidade de armazenamento, tempo
de resposta, etc.);
8. Requisitos de segurança de usuário incluindo níveis de acesso (por exemplo: usuário do sistema,
administrador de dados, etc.);
9. Requisitos de acesso ao sistema; quando este for acessado à distância;
10. Requisitos de backup e restauração dos dados;
11. Requisitos para migração de dados;
12. Requisitos de ciclo de vida – lista de documentos;
13. Disponibilidade de recursos;
14. Outros requisitos técnicos.
ERU 51
Os requisitos de usuários podem ser priorizados com ênfase na identificação dos requisitos
mandatórios.
Podendo ser utilizada a abordagem de três níveis de prioridade, descrita abaixo:
 Mandatório (alta);
 Benéfico (média);
 Bom ter (baixa).
26/05/2021
ERU 52
São campos presentes na ERU:
a) Introdução (quem produziu o documento, relação com outros documentos...)

b) Visão geral do sistema, explicando porque o sistema é necessário e o que é requerido
do sistema.
c) Os requisitos necessários para o sistema de forma clara e com identificação unívoca
de cada requisito.
d) As restrições, envolvendo compatibilidade disponibilidade, níveis de habilidade dos
usuários, melhorias possíveis, suporte...
e) Processo do ciclo de vida.
f) Aprovações.
Quando o sistema é legado, a ERU é necessária, mas não para definir os requisitos que o
sistema deverá atender, mas sim para confirmar as necessidades dos usuários atuais e se o
sistema realmente atende, principalmente aspectos relacionados a segurança e
infraestrutura. Isto acontece porque o sistema está na fase de operação.
ERU - EXEMPLO 53
ERU - IMPORTANTE 54
SÃO REQUISITOS DE USUÁRIOS IMPORTANTES DE SEREM CONSIDERADOS:
a) O sistema deve armazenar dados críticos de operações ou controles com relevância em relação às
BPF.
b) O sistema deve possuir controle para que entradas e modificações de dados sejam realizadas apenas
por pessoas autorizadas (devem ser utilizadas medidas de segurança, tais como utilização de senhas,
código pessoal, chaves ou acesso restrito aos terminais).
c) O sistema deve registrar tentativas de acesso por pessoas não autorizadas.
d) O sistema deve registrar os acessos autorizados, incluindo usuário, hora e data.
e) O sistema deve manter os registros de todas as entradas e alterações quando houver alteração de
dados.
f) O sistema deve possibilitar a impressão dos dados armazenados eletronicamente.
g) O sistema deve garantir a inviolabilidade e proteção dos dados históricos, tanto de processo ou
operações, quanto de rastreabilidade de modificações feitas pelo operador do sistema (por meios
eletrônicos contra danos acidentais ou intencionais).
h) O sistema deve garantir a possibilidade de realização de backup em intervalos regulares.
i) O sistema deve possibilitar que o administrador do sistema crie contas, perfis, reset senhas e bloqueio
de usuários.
26/05/2021
ERU - IMPORTANTE 55
SÃO REQUISITOS DE USUÁRIOS RECOMENDÁVEIS DE SEREM CONSIDERADOS:
a) O sistema deve ter timeout, como parâmetro configurável do sistema.

b) O sistema deve ter parâmetro configurável para o nível de complexidade de senha, exemplo: (mínimo
de 6 caracteres, atendendo a pelo menos 3 das regras a seguir: 1 letra minúscula, 1 maiúscula, 1
número e 1 caracter especial).
c) O sistema deve ter parâmetro configurável para bloqueio de conta se o número de tentativas de
logon sem êxito for maior que X tentativas.
d) O sistema deve ter parâmetro configurável para que a senha expire periodicamente.
e) O sistema deve ter parâmetro configurável que obrigue o usuário alterar a senha no primeiro login
quando esta for configurada pelo administrador do sistema.
AVALIAÇÃO DO FORNECEDOR DO
SOFTWARE
FORNECEDOR DO SOFTWARE 57
Quando se tratar de um software novo, o fornecedor do mesmo deverá

ser previamente qualificado.
Este processo é realizado com o preenchimento de acordos de

qualidade e com o levantamento dos requisitos de usuários para
verificação se o sistema atenderá aos requisitos.
Existem três opções para a realização de avaliação de um fornecedor de

sistema/serviço:
• Avaliação básica baseada em informação disponível (sistemas menos críticos);
• Auditoria utilizando um questionário (sistemas padronizados ou configuráveis)
• Auditoria com visita no fornecedor realizada por um especialista, auditor ou time de
auditoria.
26/05/2021
FORNECEDOR DO SOFTWARE 58
Quando se tratar de um software legado, o fornecedor do mesmo

deverá ser avaliado com acordos de qualidade.
Pode-se incluir avaliação da documentação do software ou outras

questões relevantes (certificações da empresa, por exemplo).
Se o fornecedor for aprovado, ele deve ser periodicamente reavaliado

pela empresa regulada, de acordo com a frequência definida em
procedimento operacional padrão (para softwares novos ou legados).
ESPECIFICAÇÃO FUNCIONAL
ESPECIFICAÇÃO FUNCIONAL 60
As especificações funcionais (EF/FS) definem o sistema que atende as necessidades do

usuário, descritas nas especificações dos requisitos dos usuários (ERU/URS).
Requisito de Requisito
usuário (ERU) Funcional
26/05/2021
Recomenda-se que as seguintes informações sejam descritas na especificação funcional:
• detalhes dos aspectos funcionais e de dados do sistema que atenderão aos Requisitos
do Usuário, em uma linguagem clara e compreensível para os usuários;
• todas as limitações do sistema, observando quaisquer divergências entre a
funcionalidade fornecida pelo sistema com relação aos requisitos do usuário;
• todas as funções do sistema;
• descrição das interfaces internas e externas.
OBS: a especificação funcional deverá ser testada na fase de testes e gerar evidências.
Um documento de Especificações Funcionais define o que o sistema deve fazer e que

funções e instalações serão fornecidas. Ele fornece uma lista de objetivos de projeto para
o sistema. Os testes formais serão baseados nas especificações funcionais.
O documento contendo as especificações funcionais é produzido pelo fornecedor e deve

ser revisado e aprovado pela empresa regulada. É frequentemente considerado um
documento contratual.
Em casos de softwares legados, algumas vezes pode haver dificuldade em obter estes
dados do fornecedor do software.
Os seguintes aspectos geralmente são descritos:
• Objetivo de cada função ou instalação, e os detalhes de seu uso, incluindo interface com outras
partes do sistema. Entradas, saídas, cálculos críticos, lógicas de funcionamento, e impactos em
outras funções e/ou outros sistemas e/ou o ambiente devem ser o foco;
• desempenho: resposta, tamanho...
• segurança: este tópico deve incluir ação em caso de falhas do software, por exemplo.
• funções que são parametrizáveis/configuráveis e seus limites;
• rastreabilidade para requerimentos específicos dos requisitos do usuário;
• condições de erro, ações para falhas, arquivos de eventos e diagnósticos;
• funções relativas à segurança do sistema.
26/05/2021
É recomendável associar a especificação de usuário com a especificação funcional.

Exemplos:
EF 65
São campos presentes na EF:
a) Introdução (quem produziu o documento, relação com outros documentos...)

b) Visão geral do sistema, as principais interfaces, permissões e restrições.
c) As funções documentadas.
d) Descrição de banco de dados.
e) Descrição das interfaces.
f) Atributos não funcionais (disponibilidade, manutenção...).
g) Aprovações.
PROCESSO DE GERENCIAMENTO DO
RISCO À QUALIDADE
26/05/2021
Gerenciamento de Riscos 67
A prioridade do risco visa facilitar a priorização, e servir de referência para definir

tolerância ou aceitabilidade ao risco.
Atenção: A aplicação de uma metodologia eficaz depende da capacidade de definir

com clareza os parâmetros estabelecidos para a classificação alto, médio e baixo de
cada item a ser avaliado. Isso pode ser considerado especificamente no contexto de
cada projeto do sistema.
Os riscos precisam sem entendidos, comunicados e monitorados, assim como as ações

decorrentes.
O processo para gerenciamento do risco à qualidade envolve a execução de

05 (cinco) etapas:
1. Execução da avaliação de risco inicial e determinação do impacto do

sistema;
2. Identificação das funções que tenham impacto na segurança do paciente,
na qualidade do produto e na integridade dos dados;
3. Execução das avaliações de risco funcionais e identificação dos controles
necessários;
4. Implantação e verificação dos controles apropriados;
5. Revisão dos riscos e monitoramento dos controles implantados.
GERENCIAMENTO DE RISCOS 69
26/05/2021
Etapa 1: Execução da avaliação de risco inicial e determinação do impacto do

sistema:
Deve ser realizada uma análise de risco inicial com base no entendimento dos processos
e avaliações dos riscos do negócio, nos requisitos do usuário, nos requisitos regulatórios e
áreas funcionais conhecidas.
Os resultados desta avaliação de risco inicial devem incluir a decisão sobre se o sistema
é regulado pelas BPx (avaliação de BPx). Também deve ser incluída uma avaliação
geral do impacto do sistema.
Geralmente monta-se questionário com critérios e pesos para verificar se o sistema tem
impacto em BPx e quanto é este impacto.
Etapa 2: identificação das Funções
As funções que tenham impacto na segurança do paciente, na qualidade do produto

na integridade dos dados devem ser identificadas pela construção da informação
reunida na etapa 1, referindo-se às especificações relevantes e levando-se em conta a
abordagem do projeto, a arquitetura do sistema e a categorização dos componentes
do sistema.
Etapa 3: Avaliação dos Riscos Funcionais
As funções identificadas na etapa 2 devem ser avaliadas considerando-se os possíveis

perigos e como os potenciais danos advindos destes perigos podem ser controlados.
Pode ser necessário executar uma avaliação mais detalhada que posteriormente
analise a severidade do dano, a probabilidade de ocorrência e a probabilidade de
detecção.
Geralmente, quando o software foi considerado de impacto em BPx, esta avaliação dos
riscos funcionais poderá ocorrer ao longo do processo da validação.
Medidas de controles devem ser estabelecidas: Modificação do projeto do processo;

Modificação do projeto do sistema; Aplicação de procedimentos externos; Aumento
dos detalhes ou formalidade das especificações; Aumentando o número e o nível dos
detalhes das revisões de projeto; Aumentando a extensão ou o rigor das atividades de
verificação.
26/05/2021
Detectabilidade = Probabilidade desta falha

ser detectada antes do risco ocorrer.
Prioridade do Risco = Classe do Risco x
Detectabilidade.
Severidade = Impacto na segurança do paciente,

qualidade do produto e integridade dos dados (ou outro
risco).
Probabilidade = Probabilidade da falha (risco) ocorrer.
Classe do Risco = Severidade x Probabilidade.
Etapa 4: Implantação e Verificação dos Controles
As medidas de controle identificados na etapa 3 devem ser implantadas e verificadas

para assegurar que elas foram implantadas com sucesso.
Etapa 5: Revisão dos Riscos e Monitoramento dos Controles
Durante a execução da revisão periódica dos sistemas, ou em outras oportunidades

definidas, a empresa deve rever os riscos. A verificação deve evidenciar se os controles
ainda são efetivos e ações corretivas devem ser efetuadas se forem encontradas
deficiências.
A empresa também deve considerar os seguintes pontos:

• Se os perigos anteriormente não identificados estão presentes;
• Se os perigos anteriormente identificados não são mais aplicáveis;
• Se o risco estimado associado a um perigo não é mais aceitável;
• Se houve mudança de legislação...
26/05/2021
PROJETO DE SOFTWARE (SOFTWARE

DESIGN)
DESENHO DE SOFTWARE 77
A especificação de desenho fornece detalhe técnico do sistema sendo uma expansão da

especificação funcional.
O uso de diagramas e tabelas para ilustrar o sistema e configurações é altamente

recomendável.
De maneira geral especificações de desenho são produzidas pelo desenvolvedor do

sistema, mas nem sempre com uma qualidade aceitável. Por isso, como sugestão, revise e
padronize.
DESENHO DE SOFTWARE 78
Geralmente contem as seguintes informações ou referência a elas:
a) Descrição do Sistema.
b) Dados do sistema (banco de dados, registros, tipos de dados, formato...) – Dicionário de
dados, porém as vezes temos dificuldades de obter com o fornecedor.
c) Descrição dos módulos com correlação com os módulos. Eventualmente a amarração
consta, inclusive no dicionário de dados.
d) Descrição e exemplos das telas.
OBS: o guia solicita telas do sistema para ilustrar os módulos. Porém você irá gerar as telas
na etapa de testes. Então estão observação poderá constar neste documento e no
desenho de software apenas exemplos.
26/05/2021
PROJETO DO HARDWARE (HARDWARE

DESIGN)
DESENHO DE HARDWARE 80
A Especificação Técnica deve detalhar o desenho e os requisitos relacionados aos

componentes de infraestrutura tecnológica na qual o sistema computadorizado será
instalado para uso. Estrutura:
1. Introdução
2. Requisitos técnicos, tais como:
2.1. Requerimentos para configuração de funções e parâmetros.
2.2. Descrição do hardware.
2.3. Especificações de cabeamento e conectores (internos e externos);
2.4. Diagramas elétricos, considerando sensores, instrumentação, alarmes etc.
2.5. Entradas/saídas de dados, considerando sinais analógicos e/ou digitais;
2.6. Temperatura e umidade do ambiente no qual os equipamentos estão instalados;
2.7. Interferências externas;
2.8. Segurança física.
DESENHO DE HARDWARE 81
3. Especificação de:
3.1. Servidores;
3.2. Arquitetura de rede (como a rede está estruturada);
3.3. Estações de trabalho;
3.4. Eventualmente hardwares utilizados para automação do processo.
26/05/2021
TESTES DO SOFTWARE
TESTES 83
TESTES 84
Os testes devem desafiar o sistema. Assim, por exemplo, se o sistema for concebido ou
pretendido para registrar os valores dos parâmetros monitorados ou controlados em um
banco de dados a uma frequência estabelecida (ex.: a cada segundo, minuto, etc.), essa
condição ou pior caso deve ser testada de forma a assegurar que os dados gerados
durante a rotina serão gravados corretamente.
26/05/2021
TESTES 85
Existem basicamente dois tipos de atividades de testes:
Testes de Caixa Branca (White Box Testing) – também conhecidos como testes baseados
no código ou testes estruturais, onde os testes são identificados com base no código-fonte,
no conhecimento das especificações detalhadas do projeto e outros documentos do
desenvolvimento;
Testes de Caixa Preta (Black Box Testing) – testes realizados com base nas especificações
funcionais, desta forma conhecidos como testes funcionais.
Os testes de caixa preta podem ser suficientes contanto que a avaliação do fornecedor
tenha encontrado evidência adequada da realização dos testes de caixa branca.
COMO EXECUTAR OS TESTES
TESTES 87
A execução dos testes é parte fundamental da validação. Recomenda-se sua execução

em ambiente idêntico a base original.
Os testes visam desafiar o sistema quanto ao atendimento dos requisitos de usuários,

funcionais e técnicos.
26/05/2021
TESTES 88
TESTES 89
TESTES 90
Um relatório completo por teste deve ser documentado (com evidências), bem como um
relatório resumido dos resultados.
Pode-se associar os testes com a especificação funcional.

26/05/2021
QUALIFICAÇÃO DE INSTALAÇÃO 91
A Qualificação de Instalação (QI) visa verificar e documentar as condições de instalação

do sistema e se este cumpre satisfatoriamente com os requisitos previamente aprovados
na especificação técnica. Visando:
• comprovar a sua instalação;

• controlar possíveis atualizações de componentes e versões do sistema;
• comprovar que toda a infraestrutura necessária à operação do sistema seja
qualificada.
QUALIFICAÇÃO DE INSTALAÇÃO 92
Comprovar, no mínimo, a existência de procedimentos / rotinas aprovados para:
• backup e recuperação;
• controle de acesso ao sistema;
• controle de mudanças;
• desvios de qualidade;
• plano de contingência;
• controle de acesso à sala de servidores, quando aplicável.
Os testes solicitados para qualificação de instalação podem ser executados ao final do

processo (na etapa de testes).
Geralmente, a qualificação de operação inicia-se após a conclusão da qualificação de

instalação.
QUALIFICAÇÃO DE OPERAÇÃO 93
A Qualificação de Operação (QO) tem com objetivo referenciar, verificar e documentar

as condições de operação do Sistema e se este cumpre satisfatoriamente com os
requisitos pré-definidos para sua operação. Quando possível, o protocolo deve ser
executado em ambiente de testes, sendo este cópia fiel do ambiente que será usado em
produção (isso para os testes, veja observação).
26/05/2021
A Qualificação de Operação (QO) visa:
• Comprovar o atendimento à especificação funcional;

• Comprovar a existência de procedimentos aprovados para as funcionalidades com
impacto em BPx, segurança e manutenção do sistema;
• Comprovar a compatibilidade de seus componentes com as funcionalidades a serem
qualificadas;
• Possibilitar a verificação da capacidade tecnológica, para todas as funcionalidades a
serem processadas (ex. confiabilidade, eficiência, rastreabilidade, registro de eventos,
etc.);
• Possibilitar a verificação de conformidade com as normas de BPx e outras normas
técnicas aplicáveis;
• Demonstrar que o sistema encontra-se funcionando corretamente através de desafios
documentados com base na análise de riscos.
A documentação deve contemplar, no mínimo:
• Controle da versão do protocolo;

• Página contemplando assinatura dos revisores e aprovadores do protocolo;
• Definição das responsabilidades pela execução das atividades de qualificação (pode
constar do plano);
• Desenvolvimento dos testes;
• Descrição de forma clara e objetiva da metodologia e estrutura adotada para
desenvolvimento dos testes.
Os testes solicitados para qualificação de operação podem ser executados ao final do

Geralmente, a qualificação de desempenho inicia-se após a conclusão da qualificação

de operação.
QUALIFICAÇÃO DE DESEMPENHO 96
A Qualificação de Desempenho (QD) tem como objetivo referenciar, verificar e

documentar que o sistema computadorizado, após ser instalado no ambiente de
produção e estar adequadamente parametrizado, cumpre satisfatoriamente com os
requisitos pré-definidos pela Especificação de Requerimentos do Usuário e/ou
Especificação Funcional.
Visa:
• Comprovar o atendimento aos requisitos do usuário e/ou especificação funcional;
• Comprovar a existência de procedimentos aprovados para as funcionalidades com
impacto em BPx;
• Possibilitar a verificação de conformidade com as normas de BPx e outras normas
técnicas aplicáveis;
• Possibilitar o gerenciamento de segurança (por exemplo: concessão de acesso aos
usuários do sistema computadorizado).
26/05/2021
QUALIFICAÇÃO DE DESEMPENHO 97
A documentação deve contemplar, no mínimo:
• Controle da versão do protocolo;

• Página contemplando assinatura dos revisores e aprovadores do protocolo;
• Definição das responsabilidades pela execução das atividades de qualificação (pode
constar do plano);
• Desenvolvimento dos testes;
• Descrição de forma clara e objetiva da metodologia e estrutura adotada para
desenvolvimento dos testes.
Os testes solicitados para qualificação de desempenho podem ser executados ao final do

Anexar evidências dos testes (como veremos a seguir).
MATRIZ DE RASTREABILIDADE
MATRIZ DE RASTREABILIDADE 99
Sugere-se elaborar uma matriz de rastreabilidade para a validação do software.
A Matriz de Rastreabilidade estabelece a relação entre dois ou mais documentos que são
desenvolvidos durante o processo de validação.
A Matriz assegura que:
• requisitos sejam atendidos e possam ser rastreados às respectivas configurações e/ou

elementos de desenho do sistema;
• requisitos sejam verificados e possam ser rastreados para testar ou verificar atividades
que demonstram que os requisitos foram atendidos;
• maior efetividade no gerenciamento do risco.

26/05/2021
Exemplo do guia:
Exemplo real:
RELATÓRIO DE VALIDAÇÃO
26/05/2021
RELATÓRIO DE VALIDAÇÃO 103
O relatório de validação deve constar no mínimo as seguintes informações:
1. Introdução e Escopo
2. Documentação e atividades geradas durante a validação ou referências

2.1. Riscos;
2.2. Avaliação do Fornecedor;
2.2. Resumo das atividades;
2.3. Avaliação dos resultados dos testes;
2.4. Controles de mudanças;
2.5. Matriz de Rastreabilidade;
2.6. Adendos da documentação de validação (se aplicável);
2.7. Referência a outros documentos.
3. Conclusão
ALGUNS PROCEDIMENTOS CRÍTICOS

CITADOS NAS QUALIFICAÇÕES –
MANUTENÇÃO DO ESTADO
VALIDADO
SOBRE O PROCEDIMENTO CONTROLE DE MUDANÇAS 105
Controles de mudanças devem fornecer um mecanismo eficaz e confiável para a rápida

implementação de tecnologias e melhorias nos sistemas computadorizados.
Pode-se utilizar o procedimento que a empresa já possui ou um específico no contexto da

validação do software.
A mudança deve passar por testes antes de ser implementada.
As mudanças necessárias em um sistema computadorizado validado devem ser

aprovadas por equipe multidisciplinar que envolva a Garantia de Qualidade.
OBS: Em caso de mudanças emergenciais, estas devem ser registradas e, ainda assim, analisadas quanto
ao seu impacto e posteriormente analisadas e aprovadas pela Garantia de Qualidade. Os casos
considerados emergenciais devem estar previstos no procedimento de controle de mudanças da
empresa.
26/05/2021
SOBRE A ADMINISTRAÇÃO DO SISTEMA 106
Deve haver um responsável por assegurar o planejamento, supervisão e/ou execução de

todas as atividades administrativas do sistema.
Este colaborador deve possuir conhecimento ou receber um suporte em questões

relacionadas às BPx, a fim de poder avaliar, em tempo adequado, os possíveis efeitos das
atividades de manutenção / alterações / melhorias.
Devem ser implementadas medidas que assegurem que o sistema e seus dados estejam
protegidos adequadamente contra perdas, danos intencionais ou acidentais, ou
alterações não autorizadas.
SOBRE A ROTINA DE TREINAMENTOS 107
Periodicamente, os usuários e o pessoal de suporte devem ser treinados. Deve ser mantido
registro dos treinamentos realizados.
SOBRE O GERENCIAMENTO DE DESVIOS 108
Quaisquer desvios encontrados no sistema durante o ciclo de vida devem ser investigados
e documentados.
As diretrizes e a metodologia para o programa de gerenciamento de desvios devem estar

descritas em procedimento.
Pode-se utilizar o procedimento que a empresa já possui (não conformidade, por exemplo)
ou um específico no contexto da validação do software.
26/05/2021
SOBRE O PROCEDIMENTO DE BACKUP 109
• O objetivo é proteger contra a perda física ou lógica dos dados do sistema.
• Para a guarda do backup deve ser escolhida uma mídia adequada, levando-se em
consideração: vida útil, condições de armazenamento da mídia e requisitos de
verificação, atualização e regravação.
• O processo de backup deve ser documentado e testado.
• Dados perdidos devem ser tratados como desvios / não conformidades.
SOBRE O PROCEDIMENTO DE BACKUP 110
A documentação do backup deve abranger:
• tipo de backup (total, incremental a cada hora, etc.) e periodicidade;

• número de gravações;
• o que fazer em caso de falhas;
• identificação da mídia;
• local de armazenamento com controle de acesso;
• ferramentas e procedimentos de backup;
• inspeção / verificação periódica do backup executado.
• simulação de restauração do sistema;
• Sincronização;
• descrição das medidas a serem tomadas em caso dos dados armazenados não
poderem mais ser
• lidos devido a mudanças de software e/ou hardware.
SOBRE O PROCEDIMENTO DE RECUPERAÇÃO DE DESASTRE 111
A recuperação de desastre tem por objetivo planejar as ações a serem adotadas para
que sistemas computadorizados validados voltem a operar em ambiente de produção.
Deve existir um procedimento de recuperação após desastres, que considere, pelo menos:
• planos de contingência;
• consequências do sistema estar fora de serviço (impacto em BPx);
• responsabilidades;
• o restabelecimento do sistema e devido treinamento;
• simulação de restauração do sistema;
• especificação técnica de hardware e software necessários;
26/05/2021
REVISÃO PERIÓDICA / ARQUIVAMENTO 112
• A revisão periódica de sistemas computadorizados deve ser realizada com o objetivo

de garantir que possíveis mudanças de processo, de componentes do sistema ou de
manutenções, por exemplo, não tenham impactado no seu estado validado.
• A frequência de revisão deve ser definido.
• Caso seja encontrado algum problema no sistema, um plano de ação deve ser
estabelecido.
• Toda documentação gerada durante o processo de validação deve ser mantida.
Dúvidas?
RODRIGO S. SOUSA 114
Consultor e Auditor em SGQ e Gestão Empresarial
e-mails:
rodrigo@modernacursos.com.br
rodrigo@qualidadenapratica.com.br
Telefones:
(19) 9-8450-3452 WhastApp Empresa
(19) 9-9321-2728 (pessoal)
Instagram:
@rodrigosousabr
26/05/2021
ATÉ A PRÓXIMA.
OBRIGADO!
INSTITUCIONAL
www.modernacursos.com.br
(19) 9-8450-3452
PARCEIROS
Blog Qualidade
www.qualidadenapratica.com.br
Loja da Qualidade
www.lojadaqualidade.com.br

Validação de Sistemas Computadorizados em Saúde

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Validação de Sistemas Computadorizados em Saúde

Enviado por

Direitos autorais:

Formatos disponíveis

26/05/2021

IEC 62304 – Medical Devide Software – Software Life Cycle Process

BREVE APRESETAÇÃO INSTRUTOR: Rodrigo Sousa

 Sócio da Qualidade na Prática Consultoria e Auditoria

Ao finalizar o curso com sucesso, você:

• Entender como aplicar de forma prática o guia de validação de sistemas

• Duração total: 08 horas

DÚVIDAS, ELOGIOS, RECLAMAÇÕES E SUGESTÕES 8

• Mande um e-mail para atendimento@modernacursos.com.br e

O guia foi elaborado para auxiliar no gerenciamento e validação de sistemas

A proposta é internalizar o documento GAMP 5 de modo a facilitar a

Cada empresa deverá avaliar o conteúdo do guia e verificar sua

O guia se aplica a sistemas computadorizados utilizados em empresas que

O mesmo guia é utilizado por fabricantes de produtos para saúde, cosméticos

O guia também pode ser utilizado por empresas distribuidoras / importadoras.

Nem todas as atividades definidas no guia são aplicáveis a todos os tipos de

CONCEITOS, TERMOS E DEFINIÇÕES

Abordagem do Ciclo de Vida dentro do Sistema 14

de Gerenciamento da Qualidade (SGQ)

Implica na realização de atividades de modo sistemático desde a concepção

Aproveitamento do Envolvimento do Fornecedor 15

As empresas do setor regulado devem buscar maximizar o envolvimento do

O fornecedor pode auxiliar na determinação dos requisitos do usuário, nas

O planejamento deve determinar como utilizar a documentação do

Atendimento às BPx: Atendimento a todos os requisitos regulatórios

Dono do Processo (Process Owner): É o indivíduo responsável pelo processo de

Dono do Sistema (System Owner): É o indivíduo responsável pela

Sistema de Gerenciamento da Qualidade: Sistema de gerenciamento para

Sistema Computadorizado: Um sistema computadorizado consiste em:

Sistema Computadorizado Atendendo às BPx: Sistemas computadorizados

• A empresa deve possuir uma lista contendo todos os sistemas

• A maioria dos sistemas possui componentes de complexidade variável, tais

• O esforço deve ser concentrado na seguinte proporção:

Customizado > Configurado > Não-Configurado > Infraestrutura. A

Categoria 1 – Software de Infraestrutura: Elementos de infraestrutura se

Inclui: sistemas operacionais, gerenciadores de banco de dados, ferramentas

Categoria 3 – Produtos Não-Configurados: Esta categoria inclui os produtos de

Categoria 4 – Produtos Configurados: Softwares configuráveis fornecem

Categoria 5 – Aplicações Customizadas: Estes sistemas e subsistemas são

A avaliação do hardware deve feita levando em consideração seu impacto no

Hardware Categoria 1 – Componentes-Padrão de Hardware:

A maioria dos hardwares utilizados por empresas reguladas pertencem a esta

Gerenciamento da configuração e controle de mudanças são aplicáveis.

Geralmente um inventário de hardware, mantido atualizado, é suficiente.

Hardware Categoria 2 – Componentes Customizados Embutidos de Hardware:

Qualquer configuração de hardware deve ser definida na documentação de

Inventário dos sistemas computadorizados:

O inventário deve apresentar informação resumida sobre cada sistema,

Geralmente são contemplados: identificação, descrição, responsável, breve

CICLO DE VIDA DE SOFTWARE

Ciclo de vida de software 31

O ciclo de vida de qualquer sistema consiste em quatro fases:

Ciclo de vida de software 32

• Conceito: a empresa considera a oportunidade de automatizar um ou mais

• Projeto: Esta fase abrange as atividades de definição dos requisitos do usuário,

Ciclo de vida de software 33

• Operação: Esta normalmente é a fase mais longa e é gerenciada pelo uso de

• Aposentadoria: É a fase final do ciclo de vida do sistema computadorizado.

Ciclo de vida de software 34

Fonte: Guia 33, ANVISA 2020. Extraído de GAMP5

Ciclo de Vida e Gerenciamento de Riscos 35

Fonte: Guia 33, ANVISA 2020. Extraído de GAMP5

A estratégia apresentada no guia é aplicável aos sistemas pertencentes à