ABNT CB 26 - Laboratório de Engenharia Biomédica€¦ · CE 26:150.01 - Gestão da qualidade ......

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