ABNT CB 26 – Comitê Brasileiro
Odonto Médico Hospitalar
CE 26:150.01 - Gestão da qualidade
e aspectos gerais correspondentes
CE 26:150.01
• Criação em fevereiro de 2008 • Espelho do
– ISO TC 210 - Quality management and corresponding general aspects for medical devices
– Coordenador – Marcelo Antunes – Secretária – Elaine Koda
6 grupos de trabalho
• GT1 - Aplicação de sistemas da qualidade a produtos para a saúde
– Relator – Marcelo Antunes
• GT2 - Aplicação de gerenciamento de riscos a produtos para a saúde
– Relator – Marcelo Antunes
• GT3 - Softwares de produtos para a saúde
6 grupos de trabalho
• GT4 - Usabilidade de produtos para a saúde
– Relator – Maurício Castagna
• GT5 - Simbologia, nomenclatura e eventos adversos
– Relatora – Rosana M. Moreira Santos
• GT 6 - Projetos de produtos para saúde
Novo grupo em criação
• GT7
• Escopo: Marketing, venda, determinação, avaliação, aquisição e uso de tecnologias de produtos para a saúde
Novidades sobre a revisão da
ISO 13485 – Sistemas de
Qualidade de Produtos para a
Saúde
Histórico - Sistemas da qualidade
em produtos para a saúde
• Controle de qualidade (CQ)
– Shewart (1933) – cartas de controle
• Após II guerra - controle do processo de produção ao invés de controle do produto acabado
• Garantia de qualidade (GQ)
– Sistema de gestão projetado para garantir que produtos e serviços satisfaçam requisitos
Sistemas da qualidade
BS 5750 : 1979 – precursora da ISO 9000 • ISO 9000 : 1987
• ISO 9001 : 1987 – GQ em P&D, Prod, Inst, Serv
• ISO 9002 : 1987 - GQ em Prod, Inst, Serv • ISO 9003 : 1987 – GQ em Teste e Insp
final
• ISO 9000, 9001, 9002, 9003 : 1994 • ISO 9001 : 2000
GMP – Good Manufacturing
Practices
• US GMP Regulations – 1978
– Primeira utilização de CQ – quase GQ - em produtos para a saúde
• Pós-mercado
• Derivado de GMP para medicamentos
– omissão de requisitos de projeto – ênfase em limpeza de plantas
UK Guides to GMP (1979)
• Resposta a problemas com esterilidade de produtos estéreis descartáveis de uso único
• Baseado no Guide to GMP for Pharmaceutical – WHO – seguintes baseados na BS 5750
• Voluntário, mas “ forçado ” via travamento – Registro DHSS para compras do NHS (+ ou – pré-mercado, sem força legal)
De GMP para GQ
1988 – AIMDD
– conformidade com normas de sistemas da qualidade nos procedimentos de avaliação da conformidade
• 1989 – Global approach
– sistemas da qualidade como componente essencial nos procedimentos de avaliação da conformidade de todas as diretivas Nova Abordagem (EN 29000/ISO 9000)
Requisitos particulares para
produtos para a saúde
•CEN / CENELEC – estudo da
aplicabilidade da ISO 9000 a produtos para a saúde (EN 29000)
– objetivo de designação como normas harmonizadas com as diretivas
•Introdução de requisitos adicionais
– EN 46001 e 46002 (1993)(1997) - Aplicação da EN 29001/2 na fabricação de produtos para saúde
Normas internacionais
• ISO TC 210 - Quality management and corresponding general aspects for medical devices
– ISO 13485 e ISO 13488 (EN 46001/2)(1996) (2003)
Quality system regulation
• 21 CFR 820 - Quality system regulation • Desenvolvido em 1996 harmonizado com:
– ISO 9001:1994 – ISO 13485:1996
– ISO 8402:1994 (vocabulário – qualidade)
– Portanto, é mais específica que as normas de qualidade atuais
• Auditorias – sistema próprio - "Quality System Inspection Technique" ou “QSIT”
Anvisa
• Resolução RDC nº 59, de 27 de junho de 2000 • Determina a todos fornecedores de produtos
médicos, o cumprimento dos requisitos estabelecidos pelas "Boas Práticas de Fabricação de Produtos Médicos"
• Baseada na “ 21 CFR 820 - Quality system regulation”
ABNT NBR ISO 13485
• ABNT NBR ISO 13485:2004 Produtos para saúde - Sistemas de gestão
da qualidade - Requisitos para fins
regulamentares
Como criar um SQG baseado em
processos?
14 Áreas para revisão
• Escopo e ciclo de vida • Experiência de uso
14 Áreas para revisão
• Responsabilidades no supply chain • Gerenciamento de risco
14 Áreas para revisão
• Eventos adversos em investigações clínicas
• Rastreabilidade de entrada para saídas de projeto
14 Áreas para revisão
• Revisão de requisitos de reclamações
• Planejamento e protocolos de verificação e validação de projetos
14 Áreas para revisão
• Produto retornado
• Melhoria de requisitos de controle ambiental
Alexandria, Virginia, USA, 17-19 de
outubro de 2011
Áreas adicionais (
24 sub-grupos para
revisão)
• Revisão de requisitos para validação de processos
• Revisão de abordagem por processos • Retenção de requisitos
Áreas adicionais
• Anexos Z da EN ISO 13485:2012 • Lacuna em relação à 21 CFR 820 • Comentários do survey
Áreas adicionais
• Gestão do ciclo de vida do produto (PLM) • Mercados emergentes
Justification study (ISO Guide 72)
Design Specification
Próximos passos
• 9-11 de outubro – Santa Rosa, CA – USA • Avaliação dos trabalhos realizados pelos
sub-grupos
• Criação do primeiro CD – Committee Draft • Publicação esperada – final de 2014
Validação de softwares usados
em sistemas de qualidade – a
Qual requisito?
• ISO 13485 - 7.5.2 – Validação dos processos de produção e fornecimento de serviço
• A organização deve estabelecer procedimentos
documentados para validação da aplicação de software de computador (alterações para tal software e/ou suas aplicações) para produção e fornecimento de serviços, que afetem a capacidade do produto estar em conformidade com os requisitos especificados. Tais aplicações de software devem ser validadas antes do uso inicial. As atividades de validação devem ser documentadas
• Revisão da ISO 13485 – incluir software usados no sistema de gestão
AAMI TIR 36:2007
• Validation of software for regulated processes • Atender ao requisito da 21 CFR 820
– (i)Automated processes. When computers or automated data processing systems are used as part
of production or the quality system, the
manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented
GHTF – Grupo especial de
software
• Sugestão para internacionalização da AAMI TIR 36:2007
• Foco em atender aos requisitos da ISO 13485
Software usado no SGQ de
produtos para a saúde
• Usado para automatizar o projeto, testes, aceitação de componentes, fabricação, rotulagem, embalagem distribuição e gestão de reclamações do produto para a saúde ou que é usado para automatizar qualquer outro aspecto do SQG do produto para a saúde como definido, por exemplo, na ISO 13485
Validação
• Confirmação, através da provisão de evidência objetiva, de que os requisitos para um uso pretendido ou aplicação específica foram atentidos
Validação de software
• Atividades necessárias para construção da confiança no uso do software
• Ciclo de vida do software • Pensamento crítico
• Necessidade de mapeamento de processos (ISO 13485)
Fluxos de
trabalho de
controle no
ciclo de
Fase do
ciclo de
vida –
Definir
fluxo de
trabalho
nos
blocos
ValidationProcess Validation Planning SW System
& Reporting Iterative Risk Analyses Process Definition Likelihood and Severity of Harm Down Stream Controls Likelihood and Severity of Harm Develop Down Stream Controls or Verifications Define Software Requirements Analysis of SW Failure Risks Validation Planning Analysis of Process Failure Risks Define SW Intended Use Define Process Requirements Implement/ Test/Deploy
Fronteiras entre processo e uso de
software
Fase do ciclo de vida – fluxos de trabalho implementar, testar e implantar Validation
Process Validation Planning SW System
& Reporting Iterative Risk Analyses Risks to be Controlled ** Results Acceptance Likelihood and Severity of Harm Validation Report Software Release Analysis of SW Failure Risks SW Implementation (design, develop,
build & test)
Validation Planning
Legend
**: Includes risk control measures as activities such as code reviews and in design such as watchdog timers etc..Also includes direction for targeting areas
Toolbox - Fase de
desenvolvimento – Definir
• Definição de requisitos do
processo
• Análise de risco do processo
• Uso pretendido
• Planejamento de validação
Toolbox - Fase de
desenvolvimento – Definir
• Escolha de modelo de ciclo de
vida de desenvolvimento
• Planejamento de gerenciamento
de risco
• Identificação de medidas de
controle de risco dentro do
processo
Toolbox - Fase de
desenvolvimento – Implementar
• Análise de falha no software
• Documentação e análise da
arquitetura do software
Toolbox - Fase de
desenvolvimento – Implementar
• Análise crítica do P & D
• Identificação de medidas de
controle de risco do software
• Análise crítica ou verificação do
código
Toolbox - Fase de
desenvolvimento – Implementar
• Análise de rastreabilidade
(inputs-outputs)
Toolbox - Fase de
desenvolvimento – Testar
• Planejamento de testes
• Testes de unidades
• Verificação de dados
• Teste de integração
Toolbox - Fase de
desenvolvimento – Testar
• Teste de interface
• Teste de regressão
Toolbox - Fase de
desenvolvimento – Testar
• Teste de caso de uso
• Teste de caso normal
Toolbox - Fase de
desenvolvimento – Testar
• Teste de saída forçada
• Teste de combinação de entradas
• Teste de desempenho
Toolbox - Fase de
desenvolvimento – Implantar
• Análise crítica do procedimento
de usuário
• Treinamento interno da aplicação
• Qualificação da instalação
Toolbox - Fase de
desenvolvimento – Implantar
• Qualificação de operação e
desempenho (junto com
validação do processo)
• Teste de aceitação final
• Certificação do operador
Fase de manutenção
• Planejamento de manutenção
• Análises de problemas
conhecidos
Fase de manutenção
• Análide de compatibilidade de infraestrutura
• Monitorização do sistema
• Processos de backup e recovery • Controles operacionais
Rigor do
processo –
desentende
do impacto e
análise de
risco
Principais pontos da ISO TR
24971 – Guia Orientativo da
ISO 14971 – Gerenciamento
ISO 14971
• Norma mundial (ABNT, ISO, EN, ANSI, outros) • Norma de gestão (gestão por processos)
• “Processo” de gerenciamento de risco • Conceitos estabelecidos de GR
ISO 14971
• Adoção em regulamentações
• Integração dentro de normas – ABNT NBR ISO 13485, ABNT NBR 60601-1 (equivalente à terceira edição da IEC), outras
• Aplicável a todos os produtos para a saúde • Trata de segurança e eficácia
Requisitos regulatórios baseiam-se
no ciclo de vida dos produtos
1 Concepção e desenvolvimento 2 Fabricaç ão 3 Rotulagem e embalagem 4 Marketing 5 Vend a 6 Utilizaçã o 7 Disposiçã o BPF (RDC 59)
Sistemas da qualidade (RDC 59, ISO 13485)
Controle de projeto (RDC 59) Certificação INMETRO (normas de
segurança e desempenho)
Registro (ex: IN 13, Marcação CE)
Registro, Marcação CE
Tecnovigilância, Marcação CE
Requisito essenciais (RDC 56, Anexo 1 da MDD) Sistema de gerenciamento de riscos (ISO
Conceitos
Perigo Situação perigosa Dano Severidade do dano Sequência de eventos Probabilidade de ocorrência do dano Risco Exposição(P1) P2 P1 x P2Figura E.1, ABNT NBR ISO
Conceitos
• Perigo – funcional – saída excessiva • Sequência de evento
– Usuário rotaciona controle de saída com força excessiva (torque X)
– Controle de saída quebra (falha como parte da sequência de eventos)
– Controle de saída é perdido
Conceitos
• Situação perigosa – paciente sob saída excessiva (perigo é potencial, situação perigo é exposição ao perigo)
• Dano - queimadura
• P2 – probabilidade que a saída excessiva leve à dano
Conceitos
• Situação perigosa diferente
• Perigo – funcional – perda de função • Sequência de evento
– Usuário rotaciona controle de saída com força excessiva (torque X)
– Controle de saída quebra (falha como parte da sequência de eventos)
– Controle de saída é perdido
Situação perigosa – produto não possui saída e paciente é tratado ou acha que foi tratado
Revisão sistemática – ISO 14971
• Comentários sobre 5 tópicos necessitando de orientação
• Sugestão do WG – criar um novo
documento orientativo
• ISO/TR 24971 - Guidance on the
Política para determinar o critério
de aceitabilidade de risco
• Principal atividade relacionada à segurança de produto
Política para determinar o critério
de aceitabilidade de risco
• Define se negócio baseado em produto é viável ou não e os riscos de negócio baseado no produto
• Decisão crítica de negócio – pode impactar diversos aspectos, como o regulatório e a visão dos clientes sobe seu produto
• Assinada pela alta direção (no Brasil, responsável legal + técnico)
Política para determinar o critério
de aceitabilidade de risco
• Política- diretrizes sobre como fazer as coisas • Considerar todas as informações relevantes:
– Estado da arte
– Controles de risco conhecidos
– Necessidade e visão de usuários e outros envolvidos – Visão regulatória
Política para determinar o critério
de aceitabilidade de risco
• Exemplo genérico
• Equipamento de raio-X
– Antes – descoberta – poucas informações – Hoje – muitas informações
Política para determinar o critério
de aceitabilidade de risco
• Ocorrência por uso/anos/etc. é apenas um aspectos da política
• Política não é critério!
• Política dá diretrizes para critério para cada produto
Nossos produtos não podem ter
ocorrências que levem a evento adverso grave in mais de 0,01 % de seus usos
Nossos produtos irão possuir medidas de controle de risco detalhadas em todas as normas aplicáveis e, quando opções de controle de risco não forem definidas em normas, iremos implementar medidas de controle de risco que reflitam a prática atual e percepções atuais de todos os
envolvidos, incluindo todas as
Nossos produtos
deverão sempre
possuir um grau
de segurança
comparável, e se
possível melhor
que, outras
soluções de
tratamento no
mercado
Papel de normas internacionais de
produto e processo
• O que são normas de segurança do ponto de vista do processo de gerenciamento de risco?
Papel de normas internacionais de
produto e processo
• O que são normas de segurança do ponto de vista do processo de gerenciamento de risco?
Papel de normas internacionais de
produto e processo
Aplicar o processo de GR de forma completa de acordo com a ISO 14971 e para os P/
SP O P/SP foi identificado em
normas internacionais de segurança para o produto?
O P/SP foi identificado em normas internacionais de segurança para o produto? Identificar Perigo/Situação
Perigosa (P/SP) (4.3 da ISO 14971)
Como foi endereçado? Escolha entre 2.a), 2.b) e 2.c).
Sim
2.a): norma internacional de segurança para produto especifica requisitos e fornece critério específico de aceitação? Os requisitos combinam com o projeto incluindo o
uso destinado?
O uso dos requisitos da norma não fornecem a presunção da aceitabilidade do risco Aplicar o processo de GR de forma completa de acordo com a ISO 14971
e para os P/SP Não há a necessidade de
estimar (4.4) ou avaliar o risco (5)
Identificar o método de controle de risco (6.2 – relacionado com o requisito da
norma) e implementar
Verificar a implementação e eficácia (6.3) através do teste
de funcionamento da norma
Se for aprovado no teste, relatar que o risco residual é
aceitável (6.4)
Sim
2.b): norma internacional de segurança de produto
especifica requisitos, mas não especifica os critérios de aceitação?
Os requisitos combinam com o projeto incluindo o
uso destinado?
O uso dos requisitos da norma não fornecem a presunção da aceitabilidade do risco Estebelecer o critério de aceitação do teste e documentar no plano de gerenciamento de risco Não há a necessidade de estimar (4.4) ou avaliar o risco
(5)
Verificar a implementação e eficácia (6.3) através do teste
de funcionamento da norma
Se for aprovado no teste, relatar que o risco residual é
aceitável (6.4)
Sim
Não
Aplicar o processo de GR de forma completa
de acordo com a ISO 14971 e para o P/SP
Identificar Perigo/Situação Perigosa (P/SP) (4.3 da ISO 14971)
O P/SP foi identificado em normas internacionais de segurança para o produto?
Como foi endereçado? Escolha entre 2.a), 2.b) e 2.c).
2.a): norma internacional de segurança para produto especifica requisitos e fornece critério específico de aceitação? Os requisitos combinam com o projeto incluindo o
uso destinado?
Não há a necessidade de estimar (4.4) ou avaliar o risco
(5)
Identificar o método de controle de risco (6.2 – relacionado com o requisito da
norma) e implementar
Verificar a implementação e efetividade (6.3)através do teste de funcionamento da
norma
Se for aprovado no teste, relatar que o risco residual é
aceitável (6.4)
Sim
Sim
Sim
Situação perigosa identificada: paciente (e produto para a saúde) precisam ser transferidos de uma sala para outra; se colocado em posição de transporte, o produto
desequilibra e o paciente cai.
Sim; a IEC 60601-1:2005, subitem 9.4.2.1
2.a)
Sim, há um requisito específico: o equipamento não deve desequilibrar quando
posicionado em qualquer posição de transporte em utilização normal ou em um plano inclinado a 10° do plano horizontal, e um critério específico de aceitação (teste definido). Se o equipamento desequilibrar, não
atende ao requisito.
Sim, o equipamento é transportável, e pode ser transportável com o paciente sobre o equipamento, o acomodar a transferência de
pacientes.
Risco não estimado nem avaliado antes da implementação do controle de risco
Identificado no arquivo de gerenciamento de risco
Teste realizado: equipamento posicionado em um plano inclinado a 10° do plano horizontal.
Resultado: equipamento não desequilibrou
O equipamento não desequilibrou, desta forma o risco residual relatado é considerado
Identificar Perigo/Situação Perigosa (P/SP) (4.3 da ISO 14971) O P/SP foi identificado em
normas internacionais de segurança para o produto? Como foi endereçado? Escolha entre 2.a), 2.b) e 2.c).
Sim
Sim
Situação perigosa identificada: produto para a saude está danificado e paciente pode cair pelas forças dinâmicas do carregamento do
paciente para o assento Sim; a IEC 60601-1:2005, subitem 9.8.3.3
2.b)
Sim, há requisito que as forças dinâmicas não devem resultar em um risco inaceitável. Há
um teste definido, porém o critério de aprovação/falha deve ser determinado pelo
fabricante.
Sim, as partes do produto para a saúde destinadas a suspender o paciente está sob
efeito de forças dinâmicas. Estabelecer o critério de aceitação do teste Risco não estimando nem avaliado antes da
implementação das medidas de controle de risco
Teste realizado: uma massa foi solta de uma distância de 150 mm sobre o assento. Resultado do teste: dano estrutural no assento
de modo que o paciente não pode utilizar. O risco residual é estimado e avaliado em relação ao critério de aceitação. Neste caso, o risco é considerado inaceitável pois o produto não pode ser utilizado (e para este tipo de produto, não poder ser utilizado é considerado
um risco inaceitável). 2.b): norma
internacional de segurança de produto
especifica requisitos, mas não especifica os critérios de aceitação? Os requisitos combinam com o projeto incluindo o
uso destinado? Estebelecer o critério de aceitação do teste e documentar no plano de gerenciamento de risco Não há a necessidade de estimar (4.4) ou avaliar o risco
(5)
Verificar a implementação e efetividade (6.3)através do teste de funcionamento da
norma Se for aprovado no teste, relatar que o risco residual é
aceitável (6.4)
Sim
Identificado no arquivo de gerenciamento de risco
Identificar a medida de controle de risco (6.2 – relacionado ao requisito da
Identificar Perigo/Situação Perigosa (P/SP) (4.3 da ISO 14971)
O P/SP foi identificado em normas internacionais de segurança para o produto?
Como foi endereçado? Escolha entre 2.a), 2.b) e 2.c).
Sim
Sim
Situação perigosa identificada: produto para a saude aplica um novo tipo de terapia de pressão acústica no paciente (não há norma
particular/específica aplicável)
Sim; a IEC 60601-1:2005, subitem 12.4.6
2.c)
2.c): norma internacional de segurança de produto
identifica o P/SP mas não provê requisitos?
Aplicar o GR de forma completa de acordo com a ISO 14971 e
para o P/SP
Sim, a terapia de pressão acústica é identificado como um perigo, entretanto não
há um requisito específico.
Aplicar o GR de forma completa e verificar o atendimento no arquivo de gerenciamento de
Loop de feedback de produção e
pós-produção
Quais passos?
• Observação e transmissão • Avaliação
Entrada de observações
Entrar com qualquer observação dos usuários, serviços, pacientes, empregados, regulamentos, normas, etc. Transmitir tais informações de forma a estabelecer métodos e procedimentos ao ponto onde as observações foram analisadas.
A observação está relacionada a segurança?
Aplicar critério estabelecido de forma a:
Classificar as observações, onde a segurança é afetada, Análise de tendência, se apropriado,
Completar as informações faltantes
É necessário a atualização do AGR?
Verificar se a observação relacionada a segurança é adequadamente refletida no AGR, i.e., como uma situação de perigo identificada
Atualizar o AGR
Atualizar baseado nos novos dados, i. e, novas suituações perigosas, probabilidade de ocorrêcia ou severidade do dano, avaliação do risco ou sua aceitabilidade
É necessário uma revisão?
Decidir se é necessário uma atualização das medidas de controle de risco para o produto para a saúde ou relacionar os processos. Ainda mais, decidir se o processo necessita ser revisado. Executar a acompanhamento da ação e atualizar o AGR Nenhuma ação necessária relacionada ao GR Sim Sim Sim Não Não Não
Informação para segurança e
divulgação de risco residual
• Informação para segurança – terceira opção de controle de risco
• Divulgação do risco residual – após implementação de controles
Informação para segurança e
divulgação de risco residual
Risco residual geral
• Combinar os riscos residuais de todas as fases do desenvolvimento ou da análise de mudança de mercado
• O risco residual geral do produto é aceitável?
• Critério pode ser diferente do critério de aceitabilidade para riscos separados
Possíveis abordagens – análise
crítica comparativa
• Comparação com produtos similares no mercado levando em consideração informações atuais de eventos adversos
Possíveis abordagens – análise
crítica qualitativa
• Estimar risco residual geral
– utilizar painel de experts independentes
• considerar desempenho clínico
• considerar risco residual legado (a seguir)
• Avaliação
– utilizar critério específico de aceitabilidade de riscos
• Painel deve chegar a consenso
A importância da série IEC
80001 – Gerenciamento de
risco de redes de tecnologia
de informação que incorporam
produtos para a saúde na área
TI e produtos para a saúde
• Interação (segurança física)
• Troca de informações (segurança da informação)
ISO e IEC
• IEC TC 62 – Eletromédicos (Possível SC TI?)
• ISO TC 210 – Gestão da qualidade • ISO TC 215 – Informática em saúde • JWG 7 (Conjunto SC 62A/TC 215)
Série 80001 hoje
• 1 norma publicada
• 3 technical reports publicados • 2 projetos
IEC 80001-1
• IEC 80001-1 - Application of risk
management for IT-networks incorporating
medical devices - Part 1: Roles,
Responsabilidade e papéis
Ciclo de
vida de
redes de Ti
médicas
IEC/TR 80001-2-1
• Application of risk management for IT-networks incorporating medical devices --Part 2-1: Step by Step Risk Management
of Medical IT-Networks; Practical Applications and Examples
Unidade de
recuperação
pós anestesia
IEC/TR 80001-2-2
• Application of risk management for IT-networks incorporating medical devices --Part 2-2: Guidance for the communication of medical device security needs, risks and controls
SECURITY CAPABILITIES
Exemplos
• Automatic logoff – ALOF • Authorization – AUTH
• Cyber security product upgrades – CSUP • Data backup and disaster recovery –
IEC/DTR 80001-2-3
• Application of risk management for IT-networks incorporating medical devices --Part 2-3: Guidance for wireless networks
IEC/TR 80001-2-4 (Draft)
• Application of risk management for ITnetworks incorporating medical devices
-Part 2-4: General implementation
guidance for Healthcare Delivery
Rede de TI médica autônoma (fora do escopo da IEC 80001-1)
Rede de Ti
médica
centralizada
IEC 80001-2-x (proposta)
• Application of risk management for IT-networks incorporating medical devices --Part 2-x: Trustworthy Distributed Alarm Systems
Sistema de chamada de
enfermagem autônomo
Sistema de chamada de
enfermagem distribuído
Sistema de chamada de
enfermagem que utiliza uma rede
de TI genérica
Sistema de chamada de
enfermagem que utiliza uma rede
de TI médica
Codificação de eventos
adversos e queixas técnicas –
ISO 19218-1, ISO 19218-2 e
novos desenvolvimentos
normativos
Informação como componente
essencial no trabalho em vigilância
PORTARIA Nº 1.660, DE 22 DE JULHO DE 2009 - (...) Art. 3º O sistema pelo qual serão
registradas as notificações será aquele disponibilizado pela ANVISA (...)
Informação como componente
essencial no trabalho em vigilância
• RESOLUÇÃO RDC 4, DE 10 DE
FEVEREIRO DE 2009 - (...) Art. 5º. As
notificações relacionadas à
farmacovigilância, conforme descrito no artigo 2º desta Resolução, devem ser encaminhas por meio do sistema eletrônico de notificação do SNVS definido pela , obedecendo aos critérios e prazos a seguir (...)
Informação como componente
essencial no trabalho em vigilância
RESOLUÇÃO-RDC Nº 67, DE 21 DE DEZEMBRO DE 2009 - (...) Art. 11 Para
notificar as ocorrências conforme previsto no Art. 8°desta Resolução, o detentor de registro deve utilizar o sistema de informação eletrônico do SNVS definido pela Anvisa. (...)
Informação como componente
essencial no trabalho em vigilância
RESOLUÇÃO - RDC Nº 2, DE 25 DE JANEIRO DE 2010 - (...) Art. 20. O estabelecimento de saúde deve notificar ao Sistema Nacional de Vigilância Sanitária os eventos adversos e queixas técnicas envolvendo as tecnologias em saúde, conforme disposto em normas e guias específicos. (...)
Normas relacionadas
• ABNT ISO/TS 19218-1
• Produtos para a saúde - Estrutura hierárquica de codificação para eventos adversos - Parte 1: Códigos de tipo de evento adverso
• ABNT ISO/TS 19218-2
• Produtos para a saúde — Estrutura de codificação hierárquica para eventos adversos. — Parte 2: Códigos de avaliação
Definições
• Evento adverso
– evento associado a um produto para a saúde que conduz à morte ou lesão séria de um paciente, usuário ou outra pessoa, ou ainda que poderia conduzir à morte ou lesão séria de um paciente, usuário ou outra pessoa se o evento ocorrer novamente
Definições
• Lesão séria
– deterioração séria no estado de saúde que consiste em
• lesão ou doença que ameaça a vida, ou
• debilidade permanente de uma função do corpo ou dano permanente de uma estrutura do corpo, ou
• condição que necessita de intervenção médica ou cirúrgica para prevenir a debilidade permanente de uma função do corpo ou o dano permanente de uma estrutura do corpo.
Estrutura do sistema de
codificação
Código da nomenclatura do produto Tipo de produto Código de tipo de evento adverso Código do evento adverso avaliado Código do efeito no paciente/usuário/outr a pessoa (opcional)Exemplos de código de tipo
Código nível 1 Termo nível 1 Definição nível 1 Código nível 2 Termo nível 2 Definição nível 2 1400 Problema associado com uma falha do circuito ou componente elétrico ou eletrônico 1401 Arco Problema associado com a passagem de uma corrente elétrica através de uma abertura entre duas superfícies condutoras, resultando tipicamente, em um flash de luz visível.Código nível 1 Termo nível 1 Definição nível 1 Código nível 2 Termo nível 2 Definição nível 2 1400 1402 Falha no circuito Problema associado a uma falha dos caminhos da rede interna ou circuitos elétricos (ou seja, componentes elétricos, placas de circuito, fiação)
Exemplos de código de tipo
Código nível 1 Termo nível 1 Definição nível 1 Código nível 2 Termo nível 2 Definição nível 2 1600 Falha do produto para a saúde implantável 1601 Migração do produto ou componente do produto Problema associado com um movimento indesejado de um produto para a saúde, componente de um produto para a saúde , ou ambos, relacionada com o seu afastamento ou desalojamento a partir de uma fonteExemplos de código de tipo
Código nível 1
Termo nível 1 Definição
nível 1 Código nível 2 Termo nível 2 Definição nível 2 2500 Embalagem (acondicionamento) / expedição Problema associado com a embalagem ou o envio 2501 Danos antes da utilização Problema associado com danos de embalagem ou expedição, antes da utilização do produto para a saúde
Exemplos de código de tipo
Código nível 1
Termo nível 1 Definição
nível 1 Código nível 2 Termo nível 2 Definição nível 2 2502 Entregue como produto não estéril Problema associado com o produto para a saúde entregue não estéril devido à perda da integridade da embalagem
Exemplos de código de avaliação
Código nível 1 Termo nível 1 Definição nível 1 Código nível 2 Termo nível 2 Definição nível 2 25000 Biológicos Um evento relacionado a, causado por, ou afetando a vida ou organismos vivos 25001 Resposta fisiológica anormal ou inesperada Resposta fisiológica anormal ou inesperada tal comohipersensibilidade
25002 Biocompatibili dade
O produto causa resposta celular ou tecidual que provoca um efeito indesejável local ou sistêmico do
receptor ou beneficiário da terapia (ver série de
Exemplos de código de avaliação
Código nível 1 Termo nível 1 Definição nível 1 Código nível 2Termo nível 2 Definição nível 2
25100 Falsificação Um evento associado com a reprodução de um produto para saúde original ou a adulteração da rotulagem ou informações do produto com a intenção de falsear enganosamente o produto para saúde original. 25101 Falsificação A reprodução de um
produto para saúde original. 25102 Informação falsa do produto Rotulagem ou outra informação do produto forjada.
Exemplos de código de avaliação
Código nível 1 Termo nível 1 Definição nível 1 Código nível 2 Termo nível 2 Definição nível 2 25300 Projeto Um evento associado com a falha do produto para saúde de atingir sua função pretendida devido a projeto ou processo inadequado. 25301 Deficiência de projetoFalha do produto para saúde em atender sua
função pretendida devido a projeto inadequado, incluindo avaliação de risco inapropriada. 25305 Usabilidade Deficiência ou inadequação das características de
interface com o operador que estabelece
efetividade, eficiência, facilidade de
aprendizado e satisfação do usuário
Links com outros processos
• CAPA
É um evento adverso ou queixa técnica? Evento adverso ou queixa técnica?
Norma para codificação de queixas
técnicas
• Série ISO 19218 • ECRI • Dados ANVISA • Dados FabricantesO fim dos conectores luer lock?
A Série de Normas Técnicas
Qual o problema?
• UK entre 2001 e 2004 – 3 mortes e 4
alertas acidentes com conectores de
pequeno diâmetro
• EUA – 9 casos de misconnections
resultando em 8 mortes e 1 perda
permanente de funções
Misconnectios – Conexões
errôneas
• Ambiente • Paciente (modalidades) • Usuário • Produtos • Usabilidade!Estudo feito pelo comitê europeu
Sumário da análise de risco de possíveis conexões erradas:
1640 possíveis
654 ‒ risco amplamente aceitável 608 ‒ risco tão baixo quanto possível
Recomendações Joint Comission
– Barreiras físicas (ex. design que não permita compatibilidade entre conectores cuja indicação de uso é diferente entre ambos) eliminando a possibilidade de interconectividade entre tubos e cateteres de uso distintos.
– Indústria – projeto de produto de conectores médicos com uso pretendido específicos devem ser baseados em normas para que não ocorram interconexões.
ISO/TC 210 JWG4
• ISO 80369-1 - Small-bore connectors for
liquids and gases in healthcare
applications -- Part 1: General
requirements
• ISO 80369-2 - Connectors for breathing
systems and driving gases applications
• ISO 80369-3 - Part 3: Connectors for enteral applications
ISO/TC 210 JWG4
• ISO 80369-5 - Part 5: Connectors for limb cuff inflation applications
• ISO 80369-6 - Part 6: Connectors for neuraxial applications
• ISO 80369-7 - Part 7: Connectors with 6%
(Luer) taper for intravascular or hypodermic applications
Soluções ISO/TC 210 JWG4
• Apenas 1 conector normalizado para cada aplicação
– a menos que exista necessidade clínica ou técnica (por ex., 2 na área respiratória)
• Usabilidade no processo de projeto de conectores
Male connector Female connector
Small-bore connectors for breathing systems and driving gases for respiratory use
Alternate thread and width projections
Connector female (proximal/feeding set/syringe side)
Small-bore connectors for access ports on enteral feeding sets and patient interface devices
Alternate thread and width projections Connector male (distal, enteral access side)
Small-bore connectors for access ports on enteral feeding sets and patient interface devices
Male connector Female connector
Single-lumen sphygmomanometer and cuff small-bore connector
Male connector Female connector
Male and female neuraxial small-bore connectors
Variant A
Variant B
Variant C
Female luer lock connectors with lugs in a plane at right angles to axis of fitting
Female luer lock connector and luer access connector with external thread fitting
Female luer lock connectors and locking luer access connectors with external thread fittings
Série ISO 80369 (8
normas)
Segurança de softwares usados
na saúde – revisão da IEC
Sistemas programáveis e
software
• ABNT NBR IEC 60601-1:2010 – Cláusula 14
• IEC 62304 : 2006 - Medical device
software - Software life cycle processes • IEC TR 80002-1:2009 - Medical device
software - Part 1: Guidance on the
application of ISO 14971 to medical device software
Requisitos gerais
• Não há métodos para garantir 100 % de segurança para softwares
• 3 princípios principais:
– Gerenciamento de riscos – Gestão da qualidade
Relação entre
normas
IEC 62304 – requisitos gerais
• Conjunto de processos que devem ser
seguidos no desenvolvimento e manutenção de softwares de produtos para a saúde (SPS) • A escolha de processos deve ser apropriada
aos riscos ao paciente e outras pessoas • Ensaiar o software não é suficiente para
determinar que ele é seguro em sua operação
Processo de desenvolvimento de
software IEC 62304
Processo de manutenção de
software IEC 62304
IEC 62304 - escopo
• Define requisitos de ciclo de vida para software de produtos para a saúde. O conjunto de atividades, processos e tarefas requerido estabelece uma plataforma comum para os processos de
ciclo de vida
Aplicação (revisada)
– Desenvolvimento e manutenção de SPS
– Desenvolvimento e manutenção de SPS quando software é um produto para a saúde ou embutido ou parte integral do produto final – Software que executam em processador ou
Aplicação (revisada)
• Aplica-se independente do dispositivo de armazenamento
• Independentemente da forma de distribuição
• Não aplica-se a software não destinado a execução em processador, por exemplo, dados para controlar a configuração de hardware
IEC 62304 – processos chave
• Processo de desenvolvimento de software • Processo de manutenção de software
• Processo de gerenciamento de risco de software
• Processo de gestão de configuração de software
• Processo de resolução de problemas de software
IEC 62304 – conceitos chave
• Classificação de segurança de sistemas de software e itens de software (revisada) • Gerenciamento de risco de software
• Software de origem desconhecida (SOUP) • Softwares legados (novo)
• Ciclo de vida não acaba com distribuição do produto
– Manutenção
Classificação de segurança de
software (revisada
• Se o software não contribui para situações perigosas, classe A
• Se avaliação de risco de falha de software é aceitável, classe A
• Se avaliação de risco de falha de software não é aceitável, e dano é não-sério, classe B
• Se avaliação de risco de falha de software não é aceitável, e dano é morte ou sério, classe C
Classificação de segurança de
software?
• Determina os processos durante desenvolvimento e manutenção do software
– Por exemplo, arquitetura para classes B e C e testes de componentes para classe B e C, inicialização de variáveis como critério de aceitação para classe C
– Menos rigor para classe A
• Quando um sistema de software é decomposto em itens de software, tais itens de software devem herdar a classificação de segurança do original
– A menos que o fabricante documente uma justificativa para a classificação diferenciada
GR de software
• O processo de GR desta norma deve ser embutido no processo de GR do produto de acordo com a ABNT NBR ISO 14971
GR de software
• Requisitos adicionais para controle de risco de software
– Inlcluindo software que foi identificado durante a análise de risco como possível contribuinte de situações perigosas
– Ou software que é utilizado como controle de riscos de produtos para a saúde
GR de software
• Justificativas
– Desenvolvedores de SW devem entender requisitos mínimos para medidas de controle de risco implementadas em software
– A ABNT NBR ISO 14971 não trata de controle de risco por software
Princípio de GR de
software
Processo de GR de
software
• Análise de software que contribui para situações perigosas
• Identificar itens de software que podem contribuir para situações perigosas identificadas na análise de risco do produto
Processo de GR de software
• As situações perigosas podem ser um resultado direto de falha do software ou de uma medida de controle de risco implementada via software
Processo de GR de software
• Identificar causas potenciais de contribuição para situações perigosas acima
• Exemplos
– Especificação de funcionalidade incorreta ou incompleta
– Falha ou resultados inesperados de SOUP
– Falhas de hardware ou outros defeitos de software que podem resultar em operação imprevisível do software
Processo de GR de software
• Documentar causas potencias
• Documentar seqüências de eventos
• Seqüências que podem resultar em uma situação perigosa como identificado acima
• Definir medidas de controle de risco (em hardware, software, ambiente de trabalho ou instruções de utilização)
Processo de GR de software
• Controles de risco implementados em software
– Deve ser incluído nos requisitos do software
– Deve ser atribuída uma classe de segurança baseada nos efeitos possíveis do perigo ou situação perigosa que a medida de controle de risco está controlando
Processo de GR de software
• A implementação de cada medida de controle de risco acima deve ser verificada • Se uma medida de controle de risco é implementada como software, é necessário avaliar a medida de controle para identificar se há novas seqüências de eventos que possam resultar em situação perigosa
Processo de GR de software
• Análise de risco de modificações de software
• Deve ser realizada análise de modificações do software para determinar se
– Causas adicionais potenciais são introduzidas a uma situação perigosa e
– Medidas de controle de risco de software adicionais são necessárias
Processo de GR de software
• Analisar impacto das modificações em medidas de controle de risco existentes
– Software, hardware, documentação, etc.
• Realizar atividades de GR baseadas nas análises
