View
215
Download
0
Category
Preview:
Citation preview
ABNT CB 26 – Comitê Brasileiro Odonto Médico Hospitalar
CE 26:150.01 - Gestão da qualidade e aspectos gerais correspondentes
de produtos para a saúde
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– Relator – Ednilson Porto
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– Relatora – Elaine Koda
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• Deming (anos 50)
Sistemas da qualidadeBS 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• ISO 9001 : 2008
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
• (46003 – 1999)
Normas internacionais
• ISO TC 210 - Quality management and corresponding general aspects for medical devices– ISO 13485 e ISO 13488 (EN 46001/2)(1996)
(2003)– ISO 14969 - orientativo (1999)(2004)
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”– Baseado nos sistemas (processos) da empresa
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:2004Produtos para saúde - Sistemas de gestão da qualidade - Requisitos para fins regulamentares
• Criada por um grupo especial no CB-26
Como criar um SQG baseado em processos?
Revisão da ISO 13485
14 Áreas para revisão
• Escopo e ciclo de vida
• Experiência de uso
• Validação de software no SGQ
14 Áreas para revisão
• Responsabilidades no supply chain
• Gerenciamento de risco
• Busca ativa de informações pós-mercado
14 Áreas para revisão
• Eventos adversos em investigações clínicas
• Rastreabilidade de entrada para saídas de projeto
• Outsourcing
14 Áreas para revisão
• Revisão de requisitos de reclamações
• Planejamento e protocolos de verificação e validação de projetos
• White paper ISO 9001:2008
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
• Propósitos de certificação
Londres, 27-29 de Março de 2012
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
IEC 80002-2
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
• Não é apenas teste!
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)
Controles no ciclo de vida
Fluxos de trabalho de controle no
ciclo de vida
Fase do ciclo de vida –Definir
fluxo de trabalho
nos blocos
Validation
Process SW SystemValidation Planning & Reporting
Iterative Risk Analyses
ProcessDefinition
Likelihood andSeverity of
Harm
Down StreamControls
Likelihood andSeverity of
Harm
Dev
elop
Down Stream Controls or Verifications
Def
ine
SoftwareRequirements
Analysis of SW Failure Risks
ValidationPlanning
Analysis of Process Failure
Risks
Define SW Intended Use
Define Process Requirements
Impl
emen
t/Te
st/D
eplo
y
Fronteiras entre processo e uso de software
Fase do ciclo de vida –fluxos de trabalho
implementar, testar e
implantar
Validation
Process SW SystemValidation Planning & Reporting
Iterative Risk Analyses
Risks to beControlled
**
Results
Acceptance
Likelihood andSeverity of
Harm
Validation Report
Software Release
Analysis of SW Failure Risks
SW Implementation
(design, develop, build & test)
ValidationPlanning
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 to test and type of tests to be used.
Toolbox - Fase de desenvolvimento – Definir
• Definição de requisitos do processo
• Análise de risco do processo• Uso pretendido• Planejamento de validação• Análise crítica formal do software
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
• Especificação do projeto
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)
• Auditoria do vendedor
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
• Teste do sistema de software
Toolbox - Fase de desenvolvimento – Testar
• Teste de caso de uso
• Teste de caso normal
• Testes de robustez (estresse)
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
• Análise de compatibilidade
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
de Risco
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
• Norma de ciclo de vida do produto
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 produtos1
Concepção e desenvolvimento
2Fabricaç
ão
3Rotulagem
e embalagem
4Marketing
5Vend
a
6Utilizaçã
o
7Disposiçã
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
14971)
Conceitos
Perigo
Situação perigosa
Dano
Severidade do dano
Sequ
ência d
e eventos
Probabilidade de ocorrência
do danoRisco
Exposição(P1)
P2
P1 x P2
Figura E.1, ABNT NBR ISO 14971:2009
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
P1 – relacionado à probabilidade de cada situação
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 necessitandode orientação
• Sugestão do WG – criar um novo documento orientativo
• ISO/TR 24971 - Guidance on the application of ISO 14971
Política para determinar o critériode aceitabilidade de risco
• Principal atividade relacionada àsegurança de produto
• Define o grau de segurança do produto
Política para determinar o critériode 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ériode 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ériode 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ériode 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
durante seu ciclo de vida
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 expectativas regulatórias
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
Não
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
Não
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
aceitável
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 norma) em implementar
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
risco
Loop de feedback de produção e pós-produção
• O que é esse loop?
Quais passos?
• Observação e transmissão
• Avaliação
• Açã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 AGRAtualizar 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
• Exemplos
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
– fornecer justificativas para resultados
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
de Engenharia Clínica
TI e produtos para a saúde
• Interação (segurança física)
• Troca de informações (segurança da informação)
• Outros riscos
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)
ISO/IEC JWG 7
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, responsibilities and activities
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 –DTBK
IEC/DTR 80001-2-3
• Application of risk management for IT-networks incorporating medical devices --Part 2-3: Guidance for wireless networks
Rede de TI HDO
IEC/TR 80001-2-4 (Draft)
• Application of risk management for IT-networks incorporating medical devices -Part 2-4: General implementationguidance for Healthcare DeliveryOrganizations
Rede de TI médica autônoma (fora do escopo da IEC 80001-1)
Rede de TI médica autônoma
Rede de TI médica colaborativa
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ânciaRESOLUÇÃ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/outra pessoa (opcional)
Exemplos de código de tipoCó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
Exemplos de código de tipoCó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 fonte
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
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çãoCó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 como hipersensibilidade
25002 Biocompatibilidade
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 normas ISO 10993)
Exemplos de código de avaliaçãoCó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
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çãoCó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 projeto
Falha 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
• Gerenciamento de risco
É 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 Fabricantes
O fim dos conectores luer lock? A Série de Normas Técnicas
ISO 80369
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 perdapermanente de funções
• Uso indiscriminado de conextores luer
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íveis654 ‒ risco amplamente aceitável608 ‒ risco tão baixo quanto possível308 ‒ risco inaceitável
Tubo de alimentação enteral conectado a um tubo traqueal
Tubo epidural conectado a tubo IV
Tubo IV conectado a uma extensão traqueal
Tubo de oxigênio conectado a um tubo IV (conexão nedleless)
Tubo para medir pressão venosa conectado a cateter IV
Tubo IV conectado a cânula nasal
Tubo IV conectado a tudo de alimentação enteral
Seringa erroneamente conectada a um extensão traqueal
Recomendações Joint Comission
– Barreiras físicas (ex. design que não permitacompatibilidade entre conectores cuja indicaçãode uso é diferente entre ambos) eliminando a possibilidade de interconectividade entre tubose cateteres de uso distintos.
– Indústria – projeto de produto de conectoresmédicos com uso pretendido específicos devemser baseados em normas para que não ocorraminterconexões.
ISO/TC 210 JWG4• ISO 80369-1 - Small-bore connectors for
liquids and gases in healthcareapplications -- 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 setsand patient interface devices
Alternate thread and width projections
Connector male (distal, enteral access side)
Small-bore connectors for access ports on enteral feeding setsand patient interface devices
Male connector Female connector
Single-lumen sphygmomanometer and cuff small-bore connector
Small-bore connectors for the limb cuff inflation application
Male connector Female connector
Male and female neuraxial small-bore connectors
Small-bore connectors for neuraxial applications
Dimensions for male luer lock connectors
Variant AVariant 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 62304 e a nova IEC 82304
Sistemas programáveis e software
• ABNT NBR IEC 60601-1:2010 – Cláusula 14
• IEC 62304 : 2006 - Medical devicesoftware - Software life cycle processes
• IEC TR 80002-1:2009 - Medical devicesoftware - Part 1: Guidance on theapplication of ISO 14971 to medical devicesoftware
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– Engenharia de software
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
• Não cobre validação e distribuição final
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 são executados por outros software
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– Resolução de problemas
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 produtode 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ívelcontribuinte 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
– Má utilização razoavelmente previsível
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
Recommended