Você tem dificuldade em convencer sua gerência ou alta direção da necessidade de fazer gerenciamento de risco (incluindo conceitos como verificação, validação, etc) de softwares que fazem parte de seu equipamento eletromédico? A pedido de um cliente, fiz uma explanação sobre os conceitos relacionados e os benefícios que podem ser conseguidos com a implementação de tal estratégia.

Razões legais

Para equipamentos com marcação CE, a diretiva médica européia (MDD) inclui software como parte do equipamento (ou mesmo um equipamento em si). Isso quer dizer que todos os riscos relacionados à utilização de softwares em equipamentos eletromédicos têm que ser aceitáveis em relação ao benefício e têm que ser compatíveis com um elevado grau de proteção da saúde e segurança. Em termos práticos, o melhor modo de cumprir esse requisito essencial é utilizar normas harmonizadas à diretiva, que fornecem presunção de conformidade aos requisitos essenciais. No caso de softwares, as normas aplicáveis harmonizadas são: EN ISO 14971 (gerenciamento de risco) e EN ISO 60601-1-4 (Segurança de softwares e sistemas programáveis).

Para equipamentos no Brasil, a RDC 185 classifica os softwares da mesma maneira, e portanto os riscos também têm que ser aceitáveis. O Brasil não possui o conceito de norma harmonizada, mas a ABNT NBR IEC 60601-1-4 faz parte do processo de certificação e a ABNT NBR ISO 14971 é utilizada como um “framework” geral para a RDC. Além disso, legalmente, todos os produtos devem seguir as normas brasileiras aplicáveis (ver Código de defesa do consumidor – CDC).

Benefício: estar em conformidade com as leis atuais.

—–Razões normativas

As novas normas de equipamentos eletromédicos (principalmente a série 60601 através da nova edição IEC 60601-1:2005) aumentaram o conceito de segurança para incluir a verificação do projeto – através de uma prescrição que obriga o equipamento a ser ensaiado estar também de acordo com a ISO 14971 de gerenciamento de risco. Além disso, o texto da IEC 60601-1-4 sobre software e sistemas programáveis foi incorporado ao texto da norma geral.

Como citado anteriormente, a norma atual ABNT NBR IEC 60601-1-4 é parte integrante do processo pois é uma colateral (e portanto parte integrante) da norma geral ABNT NBR IEC 60601-1. E a ABNT NBR ISO 14971 também existe no Brasil e por causa do CDC deve ser seguida.

Existe também outras normas complementares a serem utilizadas, por exemplo, a IEC 62304 Medical device software – Software life cycle process, para ser utilizada em conjunto com a IEC 60601-1-4.

Benefícios: estar em confomidade com as normas atuais; além disso, antecipar-se e estar em conformidade com os novos conceitos mundiais de segurança de softwares em equipamentos eletromédicos.

—–Razões de segurança do produto

Um conceito a ser percebido é que o software pode afetar a segurança de um produto tanto quanto qualquer outra parte, como por exemplo um transformador de isolação. A literatura sobre problemas de segurança em relação a software é muito extensa – um dos casos mais conhecidos é justamente de um equipamento eletromédicos, o acelerador linear Therac-25 que matou diversos pacientes no início dos anos 80.

Outro conceito a ser percebido é que softwares não são infalíveis, e que testar a segurança em software não é a mesma coisa que testar a segurança em hardware. Diversas falhas em softwares não são detectáveis por meios comuns, diferentemente de falhas em hardwares que são no geral visíveis ou causam eventos visíveis. Levando isso em consideração, a abordagem teórica e prática da gestão de software (e que é incorporada nas normas citadas anteriormente) é verificar o projeto e garantir que no projeto possíveis falhas sejam evitadas e os riscos relacionados sejam minimizados ou proteções contra essas riscos sejam implementados.

Além disso, o próprio conceito de segurança de equipamentos eletromédicos agora inclui o gerenciamento de TODOS os riscos relacionados aos equipamentos, sejam eles riscos vindo de hardware, riscos vindos de software, riscos vindos de usabilidade, etc. Não é possível afirmar que seu equipamento possui riscos aceitáveis/controlados/minimizados em levar os softwares em consideração. Finalmente, não se pode esquecer que outros aspectos de segurança também dependem de software, como por exemplo a usabilidade do produto e alarmes incorporados.

Benefícios: levando os conceitos citados em consideração, fica claro que a segurança de produto que utiliza software só pode ser minimamente garantida se o software for avaliado de alguma maneira, e que o método mais aceito de avaliar tal segurança é a avaliação e gerenciamento de risco do projeto (obviamente isto também pode ser feito com um software já pronto, através de uma “retro-inserção” da segurança no software, mas isso é mais caro que fazer a avaliação e gerenciamento durante o projeto).

—–Razões de redução de ocorrências em campo

Dois problemas em dar exemplos numéricos ou práticos de ocorrências em campo de problemas de software são:

1 – muitos defeitos em campo resultantes de problemas de software são identificados erroneamente como resultantes de outras causas.

2 – muitos defeitos em campo resultantes de problemas de software não são nunca detectados, e a acumulação de tais problemas leva a outros problemas que são identificados como causa-raiz.

Ambos são parecidos, mas não são necessariamente iguais.

De qualquer maneira, existem alguns exemplos citados na literatura:

- o artigo “Failure modes in medical device software – an analysis of 15 years of recall data” faz um estudo dos recalls da base de dados do FDA

de 1983 a 1997. O número total de recalls cuja razão foi problema de qualidade em softwares foi de 383. Contudo os próprios autores alertam que esses número não representam a realidade, uma vez que os dois problemas citados acima são aplicáveis e também há o problema de que nem sempre o evento é reportado. Além disso, após 1994 os número aumentam, e chegou-se à conclusão de que foi a maior utilização de softwares em equipamentos que motivou o aumento – é citado que a utilização de software em equipamentos elétricos em geral dobra a cada dois anos.

- o próprio FDA, na publicação “General Principles of Software Validation; Final Guidance for Industry and FDA Staff” cita que entre 1992 e 1998 foram feitos 242 recalls atribuídos a falhas de software.

- fiz uma rápida pesquisa na publicação “Biomedical Safety & Standards“ e essa publicação cita, de 2002 a 2006, pelo menos 75 recalls originados por problemas de software.

Benefícios: pode-se perceber claramente que existem “muitas” ocorrências em campo originárias de problemas de software, e esse número não condiz com a realidade por causa dos problemas citados (1-2). Mesmo não possuindo valores monetários nem número de equipamentos, fica claro que há um enorme gasto sendo realizado por causa de ocorrência em campo, e que existe economia se tais problemas forem considerados e tratados proativamente.

—–Razões de qualidade no projeto e no produto

Conforme já citado anteriormente, a segurança (que é uma das facetas da qualidade) de um equipamentos eletromédicos depende do gerenciamento de todos os riscos relacionados ao mesmo, incluindo os riscos de software. Essa abordagem será OBRIGATÓRIA daqui para a frente nos principais mercados mundiais, no Brasil inclusive. Portanto deverá ser buscada no projeto de no produto final de equipamentos de forma constante e sistemática, para garantir todos os aspectos. Além disso, é interessante lembrar que essa “cultura do gerenciamento de risco” deve existir na empresa na empresa como um todo de forma a ser eficaz.

Benefícios: a implementação de uma sistemática de gerenciamento de risco e validação de software é um ótimo primeiro passo para a implantação de uma “cultura do gerenciamento de risco” em um empresa, de forma a conscientizar os empregados do problema. Isso pode ser visto como um treinamento e atualização profissional que pode, após o sucesso desse primeiro passo, ser extendido para todas as áreas necessárias. Além do mais, já que a validação do software só pode ser feita por gerenciamento de risco (ao contrário do hardware que sempre tem a opção de ensaios físicos) pode-se concluir que tal implementação terá menos resistência a mudanças e portanto ocorrerá de modo mais harmonizado, evitando possíveis problemas de discussão interna.

Technorati : IEC, Normalização, gerenciamento de risco, software

Precisa de consultoria ou treinamento sobre o assunto tratado neste post? Então faça uma visita ao website da SQR Consulting e conheça nossas soluções regulatórias!

Gostou deste post? Então receba atualizações do blog por e-mail ou assine meu feed clicando aqui!